FreeCalypso > hg > fc-usbser-tools
view doc/Replug-after-EEPROM-write @ 86:b7397959ae68
cp2102-decode-ee-desc: show bMaxPacketSize0 in decimal
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Wed, 27 Sep 2023 18:46:10 +0000 |
parents | b6a5ee85c6a3 |
children |
line wrap: on
line source
USB replug after EEPROM modification ==================================== With the current state of software, if you use any of the tools provided in this package to modify the configuration EEPROM content of your USB-serial adapter device (FTDI, CP2102, possibly others to be supported in the future), you then have to physically unplug and replug the USB device. This unplug- replug sequence is needed because: * Most USB-serial chips require a deep reset in order to reread their EEPROM and fully apply the new configuration, which may include a new USB VID:PID or other USB descriptor changes. * With some chips safe and correct EEPROM programming requires unbinding the kernel's usb-serial driver, causing the ttyUSB device for the USB-serial chip (or multiple ttyUSB devices for multichannel chips) to disappear. With the current state of Linux, we can command the kernel to unbind its drivers from a specific interface on a specific chip (*without* rmmod of the responsible driver, killing all other devices of the same tyoe), but we have no way to tell the kernel to rebind everything when we are done. Why is physical plug/unplug manipulation needed, why can't we command the needed effect via software? As it turns out, there are no *valid* reasons why it can't be done - but we are not currently able to do so because Linux kernel USB maintainers are being pricks and won't support functionality that doesn't fit into their worldview. Given that Harald Welte discovered this problem back in 2017: https://laforge.gnumonks.org/blog/20170524-usb-port-powercycle/ https://marc.info/?l=linux-usb&m=149557709602259&w=2 (the thread shows Harald's good-faith attempt to reason with those pricks and their dismissive responses) and given my own (Mother Mychaela's) sour experience with trying to get a simple patch into ftdi_sio (failed attempt to mainline the patch adding support for DUART28C), the situation with Linux currently looks hopeless.