On 06/25/2013 10:26 AM, Alan Stern wrote:
On Tue, 25 Jun 2013, raespi wrote:
On my board I can't hook up my application again to the new address
since it's the only parameter identifiable by it. Both FTDI Devices
have the same product and vendor numbers:
Bus 001 Device 003: ID 0403:6001
Bus 001 Device 004: ID 0403:6001
The address on which they are on is the only ID I've got.
That's not true; there's also the port number. In this case, the log
messages above show one device plugged into port 3 of the hub and the
other device plugged into port 4. Therefore the addresses are
available in the files
/sys/bus/usb/devices/1-1.3/devnum
/sys/bus/usb/devices/1-1.4/devnum
If you plug the devices into different ports, the file paths will
change accordingly.
Yes I'm aware of that. The problem is that which device gets to which
port ??. Maybe I can tweak my app so that it tries to discover which
are the new ports but how can I identify them ?? Say the sensor A gets
to port 3 and sensor B gets to port 4 the first time, but when a reset
happens they get switched in order and sensor A gets to port 5 and
sensor B gets to port 4??. In a medical device this is catastrophic.
Does the kernel always assign them in order ?? 3 and 4 or 4 and 5 ??
Is there
some way to disable the kernel usb reset policy or assign them a
specific address ??
If you disable the reset, the kernel will no longer be able to tell
when devices are plugged in or unplugged. The devices may even stop
working entirely.
You could force the address to be a particular value by hacking the
kernel. But why bother? It's likely to be easier to change your
program to get the addresses based on the port numbers.
I'm using *mdev* from userspace but the type of
address assignment with mdev is the one concerning the device's name
under the /dev directory AFAIK ...
Alan Stern
My device has no ports, it's a custom made industrial PCB if the reset
happens you're saying it's only because of a hardware fault ??
--
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
