On Thu, Jun 20, 2002 at 01:41:25PM +0100, Nick Craig-Wood wrote:
> We are currently building a pile of machines with 6 or more Keyspan
> USA-49W's attached (4 port serial cards).  The actual USB connectivity
> works fine and I've sent GiB of data down the serial ports with no
> errors - very satisfactory.

Glad to hear this.  The 49Ws are very nice devices for the price.

> However what isn't satisfactory is the order that they get enumerated
> and hence exactly which ttyUSB gets assigned to which port.
> 
> Here is an example setup - it has two hubs and 6 keyspan cards
> connected like this.
> 
> Root ----- Hub1 >---- keyspan1
>                 >-----keyspan2
>                 >-----keyspan3
>                 >-----Hub2     >-------keyspan4
>                                >-------keyspan5
>                                >-------keyspan6
> 
> 
> The initial device enumeration goes exactly to plan
> 
>   hub.c: USB new device connect on bus1/2, assigned device number 2  (Hub1)
>   hub.c: USB new device connect on bus1/2/1, assigned device number 3 (keyspan1)
>   hub.c: USB new device connect on bus1/2/2, assigned device number 4 (keyspan2)
>   hub.c: USB new device connect on bus1/2/3, assigned device number 5 (keyspan3)
>   hub.c: USB new device connect on bus1/2/4, assigned device number 6  (Hub2)
>   hub.c: USB new device connect on bus1/2/4/1, assigned device number 7 (keyspan4)
>   hub.c: USB new device connect on bus1/2/4/2, assigned device number 8 (keyspan5)
>   hub.c: USB new device connect on bus1/2/4/3, assigned device number 9 (keyspan6)
> 
> However once they've been enumerated the first time keyspan.o driver
> then downloads the firmware to the device and they get a new device
> number which looks like this after firmware download.
> 
>   hub.c: USB new device connect on bus1/2/2, assigned device number 10
>       = keyspan2 gets ttyUSB0..3
>   hub.c: USB new device connect on bus1/2/3, assigned device number 11
>       = keyspan3 gets ttyUSB4..7
>   hub.c: USB new device connect on bus1/2/4/1, assigned device number 12
>       = keyspan4 gets ttyUSB8..11
>   hub.c: USB new device connect on bus1/2/1, assigned device number 13
>       = keyspan1 gets ttyUSB12..15
>   hub.c: USB new device connect on bus1/2/4/2, assigned device number 14
>       = keyspan5 gets ttyUSB16..19
>   hub.c: USB new device connect on bus1/2/4/3, assigned device number 15
>       = keyspan6 gets ttyUSB20..23
> 
> So now the devices are numbered in a completely illogical fashion.  It
> *seems* to be consistent the numbering scheme from boot to boot but if
> you move one thing about it all changes.  It different on different
> computers too.

But why do you care about device numbers?  Are you trying to talk to the
raw USB devices instead of their /dev/ttyUSBx number?

And in testing it seems that different devices at different points in
the USB tree (like behind hubs) when resetting themselves enumerate
before other devices.  Just like you've noted above.  There really is
nothing we can do about the enumerating issues.

> Also perhaps related on initial enumeration on some hardware one of
> the keyspan units never gets its firmware.

That's not good.  Any debug log messages?

> However using only one hub in the system (with <= 4 keyspans)
> everything is fine.

Ah, because the timing is all the same (they all go through the same
hub, so are talked to in the same order).

> All this tested on vanilla linux 2.4.18 using debian woody and
> hotplug.
> 
> So questions...
> 
> Why does the keyspan driver get a new device number?  Surely it would
> be better to keep the old one which is a) numbered properly and b)
> doesn't waste a device number (yes we did try connecting > 64 keyspans
> to one PC ;-)

Nice, did >64 actually work?  I've never tested the usb-serial core code
with that many different devices (I don't have that many.)

> Can this race like behaviour be fixed?

What exactly do you want to see happen?

I think your problem is that the /dev/ttyUSBx numbers are not assigned
in a repeatable fashion, correct?  If this is your question, then sorry,
but no, 2.4 can not solve this issue right now.

There are plans for the ability to assign specific minor numbers to
specific usb serial devices to be added to 2.5, or at least reporting to
userspace, what physical devices have what minor numbers (like David
stated.)  But that work is still ongoing, and there isn't anything
usable yet, sorry.

Does this help?

greg k-h


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to