Messages in this thread | | | Date | Fri, 23 Sep 2022 10:33:33 +0200 | From | Miquel Raynal <> | Subject | Re: Exposing nvmem cells to userspace? |
| |
Hi Srinivas,
srinivas.kandagatla@linaro.org wrote on Thu, 22 Sep 2022 22:33:52 +0100:
> On 22/09/2022 11:23, Miquel Raynal wrote: > > Hello Srinivas, > > > > I am currently looking at the Open Compute Project ONIE Tlv tables in > > modern networking hardware. Thanks to the specification being available > > for many years and rather easy to implement, those tables are already > > present in many switches. Manufacturers just have to provide a small > > storage medium exposing factory-related information (manufacturer, date, > > serial#, mac addresses, etc) in Type-Length-Value fields, as well > > as their own extensions if they want. These tables are common, but > > there is currently no shared decoding logic, each provider maintaining > > its own internally. > > > > I am currently looking for upstreaming an nvmem layout driver for > > exposing the standard nvmem cells. This way, Ethernet drivers might eg. > > take the base MAC address from there. But I feel like there is > > something missing, because the vendor name, the device version, the > > serial number or any other information available in these tables might > > also very well be used by the userspace rather than the kernel drivers > > only. > > Could you explain the userspace side use-case?
Right now I don't have any TBH. But in general, having access to a serial number, a manufacturing date, a hardware batch or whatever other per-device factory information is always useful.
> > Thus, I was wondering if there was some ongoing work to make these > > cells available to userspace (in /sys maybe?) or if this had already > > been discussed somewhere. Otherwise, would you be open to such a > > we had this discussed this in many instances and this is some thing we would desire to have but we never got it moving forward.
Ok.
> > contribution? I guess it would also be a useful debug tool anyway (and > > might very well be moved somewhere else than in /sys). > > getting sysfs working correctly in sync with userspace might be tricky in this particular case as we will be creating cells after the provider driver is created. > > debugfs on the other hand is more doable.
Ok, I might try something with debugfs then. I'll keep this in mind.
Thanks, Miquèl
| |