On Tue, 25 Jun 2013, raespi wrote: > 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 ??. Whoever assembled the system should know that. Besides, you already face this problem in a different form: Which FTDI device gets which address? > Maybe I can tweak my app so that it tries to discover which > are the new ports but how can I identify them ?? I don't know what you mean by "new ports". Ports are pieces of hardware; they don't flash into and out of existence. > 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??. That won't happen unless you remove the wires connecting the sensors to the board, swap the wires, and then reconnect them to the board. > In a medical device this is catastrophic. > Does the kernel always assign them in order ?? 3 and 4 or 4 and 5 ?? The port numbers are fixed. They are built into the hub's hardware. > 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 ?? By "port", I mean the particular connector on the PCB that the sensor is wired to. Under this meaning, your device very definitely _does_ have ports. When the reset happens, it is certainly because of some fault. I can't tell from your description whether the fault is in hardware or software. Alan Stern -- 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
