Hi Johan, Srini, On 18 June 2018 at 11:47, Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> wrote: > > > On 18/06/18 09:46, Johan Hovold wrote: >> >> On Thu, Jun 14, 2018 at 10:08:46PM +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. FT230R chip integrates a 128-byte eeprom, FT230X a 2048-byte >>> eeprom... >>> >>> 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. >>> >>> 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. >> >> >> I'm not necessarily against the idea, but nvmem core needs to be fixed >> so that it can handle hotplugging before this can be considered for >> merging. >> >> Right now it just returns -EBUSY from nvmem_unregister(), which results >> in all kinds of memory leaks, use-after-frees and crashes when user >> space holds the character device open while the device is being >> unplugged. Correct me if I'm wrong, but nvmem is just exposed to userspace as a simple sysfs device attribute (nvmem), removing a device and its attribute(s) dynamically is well managed by sysfs, even if userspace has file open. The only risk here is when a kernel internal consumer still has a reference to the nvmem device on removal, which is not the case in our context. > I can also suggest you to try devm_nvmem_register(). Yes, I'm going to send a v2. 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
