On Mon, 6 Jul 2009, Peter Naulls wrote:
> >> Dubious. It's true that I am still holding it open, but it will eventually be
> >> let go by pppd et al. Apart from that, it's a departure from behaviour in
> >> previous kernel versions.
> >
> > Not at all; the kernel has always behaved this way. Maybe it's not a
> > good way, but it hasn't changed.
>
> I beg to differ. The software in question has been working for more than
> a year's worth of kernels. There's something different about
> 2.6.31-rc2 over 2.6.30 (with your patches). Maybe it's some subtlety
> I'm now triggering.
Or maybe it's that the usb-serial code is now behaving as intended,
whereas in 2.6.30 and below it was buggy. It's hard to tell; I don't
understand the earlier design and the whole tty layer has recently been
revamped.
> >> And how do I determine which interface
> >> is the correct control interface the 3rd, 5th, 10th time it's inserted?
> >
> > I don't know. In fact, I don't even know how you can determine the
> > correct interface the first time. After all, if you had another USB
> > serial device plugged in earlier then all the ttyUSB numbers would get
> > bumped up correspondingly.
>
> Certainly. See below.
>
> > The information may be available in sysfs. It certainly is available
> > in the system log, but digging it out isn't easy.
> >
> >> I don't pretend to be an expert on device allocation etc, in the kernel,
> >> so please correct me here, but this doesn't seem the best.
> >
> > What would you prefer? And what would you do if you had 2 of these
> > devices?
>
> Like you said - and what the code I have already does. Enumerate
> values in /sys and then look for unique USB IDs. I then know for
> certain USB IDs that it's the first device (or in the case of various
> wacky Sierra devices, the nth device). Certainly I assume they're
> sequential, but that could be changed. But If it's now the 3rd device
> instead of the 4th after removal and reinsertion, then that's
> definitely odd.
Okay, I did a little checking. The information you want _is_ available
in sysfs. For example, right now I've got a pl2303-based device
plugged into port 2 of bus 7. Look what shows up:
$ ls /sys/bus/usb/devices/7-2:1.0/
bAlternateSetting bInterfaceSubClass ep_81@ subsystem@
bInterfaceClass bNumEndpoints ep_83@ ttyUSB0/
bInterfaceNumber driver@ modalias uevent
bInterfaceProtocol ep_02@ power/ usb_endpoint/
Notice the "ttyUSB0" directory? In your case you want the fourth
interface, so you'd look for pathnames of the form
/sys/bus/usb/devices/*-*:1.3/.
The information is also available in /proc/tty/driver/usbserial, but
this is less useful because /proc/tty/driver is inaccessible unless you
have superuser privileges.
> Real world context: this is a 3G router which accepts multiple cards,
> on which I expect the customer to do all kinds of crazy plugging and
> unplugging.
>
> Maybe I can work around all this, but what I don't have right now
> is a good characterization of the problem. If you wish, I can
> get that, but I feel it would be more productive for someone who
> knows the code be able to describe what should be happening.
It does seem unnecessary to keep the minor number tied up merely
because the device file is open. Maybe there's some deeper reason for
this I'm not aware of. In any case, below is an experimental patch you
can try out. It should cause usb-serial to release the minor number as
soon as the device is unplugged. (I haven't tried it myself, so you'll
be the first!)
Alan Stern
Index: usb-2.6/drivers/usb/serial/usb-serial.c
===================================================================
--- usb-2.6.orig/drivers/usb/serial/usb-serial.c
+++ usb-2.6/drivers/usb/serial/usb-serial.c
@@ -137,10 +137,6 @@ static void destroy_serial(struct kref *
dbg("%s - %s", __func__, serial->type->description);
- /* return the minor range that this device had */
- if (serial->minor != SERIAL_TTY_NO_MINOR)
- return_serial(serial);
-
serial->type->release(serial);
for (i = 0; i < serial->num_ports; ++i) {
@@ -1158,6 +1154,10 @@ void usb_serial_disconnect(struct usb_in
}
serial->type->disconnect(serial);
+ /* return the minor range that this device had */
+ if (serial->minor != SERIAL_TTY_NO_MINOR)
+ return_serial(serial);
+
/* let the last holder of this object
* cause it to be cleaned up */
usb_serial_put(serial);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
