Hi Wolfram, Sorry, somehow this message of yours slipped through the cracks. On Tue, 17 Mar 2020 16:01:42 +0100, Wolfram Sang wrote: > > And we could introduce a new macro called AT24_CHIP_DATA_MASKED that > > would automacially set the AT24_FLAG_MASKED_RANGE flag and take > > another argument that would contain the address and size of the masked > > register range (we'd put it into the "masked" resource)? > > I am all for generic solutions. One thing to consider here is that we > need a generic way to detect the various types. I guess it will > always(?) be decided on some memory locations having specific values? In the case of Sony VAIO EEPROMs, they can be identified by the combination of the EEPROM's I2C address (always 0x57) and the value of the 4 bytes at register address 0x80 (would read either "PCG-" or "VGN-"). If that's not considered robust enough then I suppose we could improve it further by checking that the DMI vendor is "Sony Corporation". That being said, automatic detection was not even on my mind originally. If we had a specific type defined for these EEPROMs, as we do with SPD EEPROMs, then one could easily instantiate them from user-space using the "new_device" sysfs attribute at the I2C bus level. This is exactly how we have been doing it for SPD EEPROMs until recently, as you have just merged my patch set to automate this recently. And even then, it's still limited to x86 and specific systems at the moment. Incidentally, instantiating these Sony VAIO EEPROMs automatically would share some code with that patch set, so that might be a good sign that it's the right time to look into that. I may give a try to Bartosz's idea to make it somewhat generic if everybody agrees that's the way to go. I'm not deeply familiar with the at24 driver so I'm not sure how to do it, but hopefully it will get clearer as I progress. -- Jean Delvare SUSE L3 Support
