On 9/5/19 10:38 AM, Wolfram Sang wrote:
/*
* FIXME: What to do if only 8 bits of a 16 bit address are sent?
* The <your vendor & eeprom type> sends only 0xff then. Needs verification
* with other EEPROMs, though. We currently use the 8 bit as a valid
* address.
*/
The eeprom tested is from ST, model M24C64. Should this be added in the code
or in some doc folder?
I think FIXMEs should be in the source itself.
Do you want this as a patch of its own, or as an update of the old patch?
I have another question. I'm considering adding a flag to set the virtual
eeprom in read-only mode on the i2c side (but writable from the sysfs side).
Should this be implemented as a separate i2c_device_id, or by trying to read
som configuration flag from devicetree?
Hmm, not sure yet. There is the "read-only" DT binding which makes it
easy but I see two drawbacks:
1) I am not a big fan of describing slave functionality in DT because to
me this is more configuration than hardware description. I know mileages
vary on this one.
2) This is a DT only solution. If we want to support read-only when
instantiating from userspace, we'd need a seperate mechanism to
configure that, like a sysfs-entry. This adds quite some code.
I currently think a seperate id like "24c02ro" will keep things nicely
simple. Obviously, this solution doesn't scale with number of features.
Having a look at the original AT24 driver, I wouldn't expect other new
features coming.
Thoughts?
Well, the "24c02ro" version will solve our use-case and is by far the
simplest to implement. But as you say it does not scale well with more
features. I can however not see any practical use-cases where we would
need anything else (like "write-only" for instance). I can make an
implementation of that so you can see how it looks. And most likely,
this could be combined with a DT/sysfs version to do the same without
breaking anything in the future if that is required.
One more question, I'm thinking about trying to use the
"request_firmware()" in the kernel in some way to be able to
automatically populate the eeprom with content from some file (the
equivalent of a "pre-flashed eeprom"). Do you have any thoughts about
adding a feature like that?
/BA
