On Tue, 6 Jun 2006 00:34:41 -0700
Greg KH <[email protected]> wrote:
| On Sat, Jun 03, 2006 at 07:19:17PM -0300, Luiz Fernando N. Capitulino wrote:
| > On Fri, 2 Jun 2006 15:44:35 -0700
| > Greg KH <[email protected]> wrote:
| >
| > | On Fri, Jun 02, 2006 at 03:41:21PM -0700, Pete Zaitcev wrote:
| > | > On Fri, 2 Jun 2006 13:50:14 -0700, Greg KH <[email protected]> wrote:
| > | > > On Fri, Jun 02, 2006 at 12:03:14AM -0300, Luiz Fernando N.Capitulino wrote:
| > | >
| > | > > > 2. The new pl2303's set_termios() can (still) sleep. Serial Core's
| > | > > > documentation says that that method must not sleep, but I couldn't find
| > | > > > where in the Serial Core code it's called in atomic context. So, is this
| > | > > > still true? Isn't the Serial Core's documentation out of date?
| > | > >
| > | > > If this is true then we should just stop the port right now, as the USB
| > | > > devices can not handle this. They need to be able to sleep to
| > | > > accomplish this functionality.
| > | > >
| > | > > Russell, is this a requirement of the serial layer? Why?
| > | >
| > | > Shouldn't it be all right to schedule the change at the moment of
| > | > that call and have it happen later? Resisting a temptation to abuse
| > | > keventd and schedule_work and using a tasklet may help with latency
| > | > enough to make this tolerable.
| > |
| > | Some devices require more than one usb message to set all of the proper
| > | termios bits in the device. Creating a way to queue them up and fire
| > | them off later, and handle errors if something happened in the middle,
| > | after we told userspace the termios change succeeded, might get quite
| > | messy :(
| >
| > But set_termios() returns nothing, and look what termios
| > man page says about tcsetattr() return value:
| >
| > """
| > Note that tcsetattr() returns success if any of the requested changes could
| > be successfully carried out. Therefore, when making multiple changes it may be
| > necessary to follow this call with a further call to tcgetattr() to check that
| > all changes have been performed successfully.
| > """
|
| Good point, I forgot about that.
|
| > Also, why do they need to sleep? Did you note that my version of
| > set_mctrl() is atomic?
|
| Yes, that looks "atomic" in a way, but when the function returns, the
| value is not really set. It only happens some time in the future when
| the urb completes (and hopefully it works, no retry is allowed...)
|
| So it might be a bit "racy" :)
Oh, that's true.
Is it acceptable? The hardware is capable to queue URBs, right?
--
Luiz Fernando N. Capitulino
-
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]
