USB: serial: ftdi_sio: Add MTP NVM support
PATCH v6 1/1 USB: serial: ftdi_sio: Add MTP NVM support
Hi,
I finally found some time to dig into the ftdi eeprom handling.
Quoted 4 lines · Loic Poulain
Most of FTDI's devices have an EEPROM which records FTDI devices configuration setting (e.g. the VID, PID, I/O config...) and user data. For example, FT232R and FTX chips have 128-byte and 2048-byte internal EEPROM respectively.
The "internal" qualifier here is crucial; only FT232R and FTX have internal EEPROMs of a known size. Other device types use external EEPROMs of varying sizes, and which need not even be populated.
And judging from the heuristics used by libftdi, there's no good (known) way to determine the size of the external EEPROMs, which means that this cannot be generalised. Note that handling external EEPROMS also implies dealing with explicit EEPROM erase commands, which does not seem to fit the proposed interface.
Quoted 6 lines
This patch adds support for FTDI EEPROM read/write via USB control transfers and register a new nvm device to the nvmem core.
This permits to expose the EEPROM as a sysfs file, allowing userspace to read/modify FTDI configuration and its user data without having to rely on a specific userspace USB driver.
So I have doubts about the usefulness of all of this.
- You cannot just write the EEPROM from user space without knowing the device-specific layout.
- You also need to make sure to recalculate and update the checksum stored in the final word.
- And for that you obviously need to know the EEPROM size (known for R and FTX).
So in the end you still need something like libftdi to be able to do anything useful with this. Also note that the layout and protocol for handling the EEPROM is only available under NDA or is based on reverse-engineering guess work. For example, it seems like for FT232R you need to set a specific latency timer to be able to write the EEPROM (reliably). And so on.
And as the consequences of getting this wrong may result in a bricked device, I'm even more sceptical about this.
Quoted 3 lines
Moreover, any upcoming new tentative to add CBUS GPIO support could integrate CBUS EEPROM configuration reading in order to determine which of the CBUS pins are available as GPIO.
The CBUS configuration is stored in just a couple of words at a known offset and could easily be retrieved without depending on the nvmem subsystem when needed.
As I assume fiddling with the EEPROM should be rare (e.g. done during development or by hobbyists) and would still depend user-space tools (e.g. for layouts, checksums and external EEPROMs), I think we should just leave it all to user space to deal with.
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html