Hi Johan, Thanks for the review. On 10 July 2018 at 11:19, Johan Hovold <johan@xxxxxxxxxx> wrote: > Hi, > > I finally found some time to dig into the ftdi eeprom handling. > > On Tue, Jun 26, 2018 at 02:54:48PM +0200, Loic Poulain wrote: >> 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. > >> 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. Correct, at least for the 'non-user', area. That means having a userspace tool to manage this specific layout.This is not so complex thought. > > - 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. Yes, there is a bit more public information for FT-X, the application note AN_201 describes the MTP memory map. > > And as the consequences of getting this wrong may result in a bricked > device, I'm even more sceptical about this. > >> 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. I'm fine with that, to be honest I'm interested in adding GPIO control but wanted to progress step by step, EEPROM access being the first one. I thought it could have been valuable to expose it via nvmem, but like you said, we can keep this internal for now. So, I'll come back with new patche(s) for CBUS GPIOs. Regards, Loic -- 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
