On 02/04/2020 17:24, Steven J. Hill wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The nvmem subsystem shows promise with regards to eeprom and efuse
driver organization and utilization of those values by other drivers.
Where it seems to be lacking is the use case of eeprom and environment
variables accessible by userspace. It seems silly to have a nvmem
driver with a single 'nvmem' or 'eeprom' binary attribute, but still
have to use 'dd' to get individual data values when they are declared
in the device tree. Why is a binary attribute not created in /sys for
each nvmem cell in the process?
I played with a mtd-nvmem driver that treated each eeprom environment
variable like a mtd character device. This was an idea so horrible the
code will never be public. I also tried a hybrid nvmem driver which
acted as producer and consumer, another monstrosity. So, in summary
why are binary attributes not be created for each nvmem cell? Other
design ideas are welcome. Cheers.
There is no strong case for this requirement!
In the existing design userspace can read or write to the nvmem sysfs
file along with /proc/device-tree/ entries for offset and size
information. Is this something that does not work for you?
Or what exactly is the usecase here?
--srini
- -Steve
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQQ7FeQaKpedass6DAiDIrkfYhzfpwUCXoYRxAAKCRCDIrkfYhzf
p/AEAJ0X3cCZvbpfplAepmJ+P5SCUI132ACcC2zVtOeFm82DvRePSTri9qJtdaE=
=5yat
-----END PGP SIGNATURE-----
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
