linux-kernel - Re: [PATCH V2 0/5] Add support for custom names for AT24 EEPROMs

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]

Date:   Wed, 23 Sep 2020 13:38:30 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     Jon Hunter <jonathanh@...dia.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        linux-devicetree <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-tegra@...r.kernel.org
Subject: Re: [PATCH V2 0/5] Add support for custom names for AT24 EEPROMs

On Wed, Sep 23, 2020 at 11:15:03AM +0200, Bartosz Golaszewski wrote:
> On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <jonathanh@...dia.com> wrote:
> >
> > For platforms that have multiple boards and hence have multiple EEPROMs
> > for identifying the different boards, it is useful to label the EEPROMs
> > in device-tree so that they can be easily identified. For example, MAC
> > address information is stored in the EEPROM on the processor module for
> > some Jetson platforms which is not only required by the kernel but the
> > bootloader as well. So having a simple way to identify the EEPROM is
> > needed.
> >
> > Changes since V1:
> > - By default initialise the nvmem_config.id as NVMEM_DEVID_AUTO and not
> >   NVMEM_DEVID_NONE
> > - Dropped the 'maxItems' from the dt-binding doc.
> >
> > Jon Hunter (5):
> >   misc: eeprom: at24: Initialise AT24 NVMEM ID field
> >   dt-bindings: eeprom: at24: Add label property for AT24
> >   misc: eeprom: at24: Support custom device names for AT24 EEPROMs
> >   arm64: tegra: Add label properties for EEPROMs
> >   arm64: tegra: Populate EEPROMs for Jetson Xavier NX
> >
> >  .../devicetree/bindings/eeprom/at24.yaml      |  3 +++
> >  .../boot/dts/nvidia/tegra186-p2771-0000.dts   |  1 +
> >  .../arm64/boot/dts/nvidia/tegra186-p3310.dtsi |  1 +
> >  .../arm64/boot/dts/nvidia/tegra194-p2888.dtsi |  1 +
> >  .../boot/dts/nvidia/tegra194-p2972-0000.dts   |  1 +
> >  .../nvidia/tegra194-p3509-0000+p3668-0000.dts | 14 ++++++++++++
> >  .../boot/dts/nvidia/tegra194-p3668-0000.dtsi  | 16 ++++++++++++++
> >  .../arm64/boot/dts/nvidia/tegra210-p2180.dtsi |  1 +
> >  .../boot/dts/nvidia/tegra210-p2371-2180.dts   |  1 +
> >  .../boot/dts/nvidia/tegra210-p3450-0000.dts   |  2 ++
> >  drivers/misc/eeprom/at24.c                    | 22 ++++++++++++++++++-
> >  11 files changed, 62 insertions(+), 1 deletion(-)
> >
> > --
> > 2.25.1
> >
> 
> Just FYI: I'm fine with the at24 part. I can take them through my tree
> for v5.10. Who is taking the DTS patches for tegra? Thierry? I can
> provide you with an immutable branch if that's fine. I can't just ack
> the at24 patches because they conflict with what I already have in my
> tree for v5.10.

I don't think I'll need an immutable branch since the device tree
changes are not dependent on anything in the bindings, except maybe for
validation, or the driver.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)