linux-kernel - Re: [PATCH v8 0/8] NVMEM cells in sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230807112040.55af2163@xps-13>
Date:   Mon, 7 Aug 2023 11:20:40 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Chen-Yu Tsai <wenst@...omium.org>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Robert Marko <robert.marko@...tura.hr>,
        Luka Perkov <luka.perkov@...tura.hr>,
        Michael Walle <michael@...le.cc>, linux-kernel@...r.kernel.org,
        Randy Dunlap <rdunlap@...radead.org>,
        Daniel Golle <daniel@...rotopia.org>,
        Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH v8 0/8] NVMEM cells in sysfs

Hi Chen-Yu,

wenst@...omium.org wrote on Mon, 7 Aug 2023 16:57:03 +0800:

> On Mon, Aug 7, 2023 at 4:24 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > Hello,
> >
> > As part of a previous effort, support for dynamic NVMEM layouts was
> > brought into mainline, helping a lot in getting information from NVMEM
> > devices at non-static locations. One common example of NVMEM cell is the
> > MAC address that must be used. Sometimes the cell content is mainly (or
> > only) useful to the kernel, and sometimes it is not. Users might also
> > want to know the content of cells such as: the manufacturing place and
> > date, the hardware version, the unique ID, etc. Two possibilities in
> > this case: either the users re-implement their own parser to go through
> > the whole device and search for the information they want, or the kernel
> > can expose the content of the cells if deemed relevant. This second
> > approach sounds way more relevant than the first one to avoid useless
> > code duplication, so here is a series bringing NVMEM cells content to
> > the user through sysfs.
> >
> > Here is a real life example with a Marvell Armada 7040 TN48m switch:
> >
> > $ nvmem=/sys/bus/nvmem/devices/1-00563/
> > $ for i in `ls -1 $nvmem/cells/*`; do basename $i; hexdump -C $i | head -n1; done
> > country-code@77
> > 00000000  54 57                                             |TW|
> > crc32@88
> > 00000000  bb cd 51 98                                       |..Q.|
> > device-version@49
> > 00000000  02                                                |.|
> > diag-version@80
> > 00000000  56 31 2e 30 2e 30                                 |V1.0.0|
> > label-revision@4c
> > 00000000  44 31                                             |D1|
> > mac-address@2c
> > 00000000  18 be 92 13 9a 00                                 |......|
> > manufacture-date@34
> > 00000000  30 32 2f 32 34 2f 32 30  32 31 20 31 38 3a 35 39  |02/24/2021 18:59|
> > manufacturer@72
> > 00000000  44 4e 49                                          |DNI|
> > num-macs@6e
> > 00000000  00 40                                             |.@|
> > onie-version@61
> > 00000000  32 30 32 30 2e 31 31 2d  56 30 31                 |2020.11-V01|
> > platform-name@50
> > 00000000  38 38 46 37 30 34 30 2f  38 38 46 36 38 32 30     |88F7040/88F6820|
> > product-name@d
> > 00000000  54 4e 34 38 4d 2d 50 2d  44 4e                    |TN48M-P-DN|
> > serial-number@19
> > 00000000  54 4e 34 38 31 50 32 54  57 32 30 34 32 30 33 32  |TN481P2TW2042032|
> > vendor@7b
> > 00000000  44 4e 49                                          |DNI|
> >
> > This layout with a cells/ folder containing one file per cell has been
> > legitimately challenged by John Thomson. I am not against the idea of
> > having a sub-folder per cell but I did not find a relevant way to do
> > that so for know I did not change the sysfs organization. If someone
> > really wants this other layout, please provide a code snipped which I
> > can integrate.
> >
> > Current support does not include:
> > * The knowledge of the type of data (binary vs. ASCII), so by default
> >   all cells are exposed in binary form.
> > * Write support.
> >
> > Changes in v8:
> > * Fix a compilation warning whith !CONFIG_NVMEM_SYSFS.
> > * Add a patch to return NULL when no layout is found (reported by Dan
> >   Carpenter).
> > * Fixed the documentation as well as the cover letter regarding the
> >   addition of addresses in the cell names.  
> 
> It seems this version no longer creates cells for legacy DT layout formats?
> So while I assume the issue I ran into is fixed, I don't see any cells
> created on the MT8183 either.
> 
> Is this intended?

Not at all, but I am surprised they are no longer created. I will add
fake cells and see how it behaves.

Thanks for the feedback!
Miquèl