Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d1d07787-129d-e363-12d4-17f7858ab255@linaro.org>
Date:   Thu, 22 Sep 2022 22:33:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: Exposing nvmem cells to userspace?
Content-Language: en-US
To:     Miquel Raynal <miquel.raynal@bootlin.com>
Cc:     Robert Marko <robert.marko@sartura.hr>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        linux-kernel@vger.kernel.org
References: <20220922122347.1866f758@xps-13>
From:   Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
In-Reply-To: <20220922122347.1866f758@xps-13>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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?

> 
> 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.

> 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.

--srini
> 
> Thanks for your time,
> Miquèl