On Tue, Apr 04, 2006 at 06:46:45PM +0900, Hyok S. Choi wrote:
> On Tuesday 04 April 2006 05:20 pm, Russell King wrote:
> > Why do you think you need such complexity?
> >
> > cancel_rearming_delayed_work() will wait until the poll task has
> > completed and has been removed from the system. It's explicitly
> > designed for work handlers which self-rearm.
>
> Hmm.. Maybe you're right, because dcc_shutdown and dcc_startup, which
> are the only functions that initiate or stop the work, will never be
> called concurrently by different callers?
RTFD. This behaviour _is_ documented. Documentation/serial/driver:
startup(port)
Grab any interrupt resources and initialise any low level driver
state. Enable the port for reception. It should not activate
RTS nor DTR; this will be done via a separate call to set_mctrl.
Locking: port_sem taken.
Interrupts: globally disabled.
shutdown(port)
Disable the port, disable any break condition that may be in
effect, and free any interrupt resources. It should not disable
RTS nor DTR; this will have already been done via a separate
call to set_mctrl.
Locking: port_sem taken.
Interrupts: caller dependent.
If the port semaphore is taken prior to calling either function...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
