Setting USB probe priority...

[Hans Petter Selasky]

On 08/06/14 08:34, Dan Mahoney wrote:
>
>
> On Wed, 6 Aug 2014, Hans Petter Selasky wrote:
>
>> On 08/06/14 01:50, Peter Losher wrote:
>>> (please include my and Dan's email in any responses as we normally don't
>>> lurk on the USB mailing list)
>>>
>>> So @work we use serial->USB TTY MUX's to handle our serial console needs,
>>> and at some sites we have a need that is greater than a single 16 port
>>> device (the max you can get).  The problem is that with two of these 16 port
>>> USB devices is that sometimes during a reboot that the "second" device gets
>>> probed first and so the first 16 and second 16 /dev/ttyU* blocks swap
>>> around... which of course plays havoc with any symlinks we have to the
>>> devices in rtty or conserver. :(
>>>
>>> Is there any way to tell the USB code to always select a certain device
>>> first?  I assume this has been a issue with USB storage devices so this
>>> shouldn't be a new issue.  And I tried searching for a answer on the web to
>>> no avail.
>>>
>>> Ideas?
>>
>> Hi,
>>
>> USB enumerates in sequential order, but sometimes devices might not be ready
>> to enumerate, and then a port is skipped.
>>
>> Does the device have a serial number?
>>
>> usbconfig -d X.Y dump_device_desc |grep iSerial
>>
>> If yes, this can be filtered by a devd rule, when the device attaches, and
>> then you can switch the serial number to create any symbolic links.
>
> Curiously, it looks like one of our two usb-to-serial devices (both are
> 16-port devices), presents as 16 separate USB devices, and the other
> presents as clusters of four:
>
> iSerialNumber = 0x0003  <FTWVV6Z7>
>    iSerialNumber = 0x0003  <FTWVV70Y>
>    iSerialNumber = 0x0003  <FTWVV72I>
>    iSerialNumber = 0x0003  <FTWVV74C>
>    iSerialNumber = 0x0000  <no string>
>    iSerialNumber = 0x0003  <ST160898>
>    iSerialNumber = 0x0003  <ST160897>
>    iSerialNumber = 0x0000  <no string>
>    iSerialNumber = 0x0003  <ST160900>
>    iSerialNumber = 0x0003  <ST160899>
>    iSerialNumber = 0x0003  <ST160902>
>    iSerialNumber = 0x0003  <ST160901>
>    iSerialNumber = 0x0003  <ST160904>
>    iSerialNumber = 0x0003  <ST160903>
>    iSerialNumber = 0x0003  <ST160906>
>    iSerialNumber = 0x0000  <no string>
>    iSerialNumber = 0x0003  <ST160905>
>    iSerialNumber = 0x0003  <ST160908>
>    iSerialNumber = 0x0003  <ST160907>
>    iSerialNumber = 0x0003  <ST160910>
>    iSerialNumber = 0x0003  <ST160909>
>    iSerialNumber = 0x0003  <ST160912>
>    iSerialNumber = 0x0003  <ST160911>
>
> However, if I understand you correctly, not-ready issues aside, what we
> really need to do is to ensure that our devices are simply plugged into
> USB ports that are probed in the correct order, and assuming they're all
> ready to probe, this shouldn't be a problem.
>
> What I think happened here was that one of these devices was added to
> an earlier-sequenced port after bootup.
>
> Of course, from the back of a server, it's totally non-obvious what the
> sequence is.  Is there an easy way to tell where in the probe sequence a
> given port will be?
>
> -Dan
>

Hi,

Ports are probed 1,2,3,4, if they are labeled as such.

When adding new equipment, you can force a re-enumeration of the root 
HUB, where the devices are attached, and then the order shall be the 
same as at reboot:

usbconfig -d X.1 set_config 255
usbconfig -d X.1 set_config 0

If the devices are attached to different USB controllers there is no 
guarantee about the probe order.

--HPS