Hi, I have a very odd problem with FT4242H devices, which I hope someone recognizes. The FT4242H uses an external EEPROM for things like vendor/product strings and serial number. Without the external EEPROM the vendor/product strings reverts to defaults and there is no support for a serial number (which is the thing I'm really interested in). Typically I keep 4 separate devices conneced (so a total of 16 ports). On a cold reboot only about half of the FT4242H devices will read the EEPROM contents. The rest of them will just report defaults when examined with udevadm info. When one of the devices, which failed to report a serial number, is unplugged and plugged back in it will always succeed in reading the EEPROM contents, and will report the stored serial number. I've seen this issue turn up in both kernel 2.6.32.26 and 2.6.40.4. The problem does not seem to be tied to particular devices. For example, if I swap a working and a non-working board the problem usually does not move with the board. If anything, specific USB ports seems to work better than others, but that's not the full explanation either. So far I've not been able to spot any significant difference between a successful and failed read in dmesg or messages. Is there anyone here who is familiar with this type of problem? As a workaround I've tried to use udevadm trigger to simulate unplug + re-plug without any success. The default product string is 'Quad RS232-HS' so I've tried udevadm trigger --verbose --attr-match=interface=Quad* which seems to match only they devices that have failed to read the EEPROM. Unfortunately no combination of remove, add or change has successfully simulated a unplug + re-plug. Is this entirely the wrong approach, or what am I doing wrong? Best regards, -- Joakim Linde Tangiamo AB (formerly TouchTable AB) mail : joakim.linde@xxxxxxxxxxxxx office : +46-(0)31 515730 mobile : +46-(0)730 790054 Skype : joakim_linde_at_work -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
