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
On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <[email protected]> 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.
Bartosz
On 23/09/2020 10:15, Bartosz Golaszewski wrote:
> On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <[email protected]> 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.
Thanks. Yes Thierry is picking up the DTS patches.
Cheers
Jon
--
nvpublic
On Wed, Sep 23, 2020 at 11:15:03AM +0200, Bartosz Golaszewski wrote:
> On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <[email protected]> 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
On Wed, Sep 23, 2020 at 1:38 PM Thierry Reding <[email protected]> wrote:
>
> On Wed, Sep 23, 2020 at 11:15:03AM +0200, Bartosz Golaszewski wrote:
> > On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <[email protected]> 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
Ok sounds good then.
Bartosz