| Message ID | 20200916094952.458003-1-jonathanh@nvidia.com |
|---|---|
| Headers | show |
| Series | Add support for custom names for AT24 EEPROMs | expand |
On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <jonathanh@nvidia.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. Bartosz
On Wed, Sep 23, 2020 at 1:38 PM Thierry Reding <thierry.reding@gmail.com> 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 <jonathanh@nvidia.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 Ok sounds good then. Bartosz
On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <jonathanh@nvidia.com> wrote: > > The AT24 EEPROM driver does not initialise the 'id' field of the > nvmem_config structure and because the entire structure is not > initialised, it ends up with a random value. This causes the NVMEM > driver to append the device 'devid' value to name of the NVMEM > device. Ideally for I2C devices such as the AT24 that already have a > unique name, we would not bother to append the 'devid'. However, given > that this has always been done for AT24 devices, we cannot remove the > 'devid' as this will change the name of the userspace sysfs node for > the NVMEM device. Nonetheless we should ensure that the 'id' field of > the nvmem_config structure is initialised so that there is no chance of > a random value causes problems in the future. Therefore, set the NVMEM > config.id to NVMEM_DEVID_AUTO for AT24 EEPROMs so that the 'devid' is > always appended. > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > --- > drivers/misc/eeprom/at24.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c > index e9df1ca251df..f76624b5c033 100644 > --- a/drivers/misc/eeprom/at24.c > +++ b/drivers/misc/eeprom/at24.c > @@ -715,6 +715,7 @@ static int at24_probe(struct i2c_client *client) > > nvmem_config.name = dev_name(dev); > nvmem_config.dev = dev; > + nvmem_config.id = NVMEM_DEVID_AUTO; > nvmem_config.read_only = !writable; > nvmem_config.root_only = !(flags & AT24_FLAG_IRUGO); > nvmem_config.owner = THIS_MODULE; > -- > 2.25.1 > Ha! I only now noticed I already have a patch for this in my tree from Vadym Kochan for this cycle. I'll drop this one. Bartosz
On Thu, Sep 24, 2020 at 3:14 PM Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote: > > On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter <jonathanh@nvidia.com> wrote: > > > > The AT24 EEPROM driver does not initialise the 'id' field of the > > nvmem_config structure and because the entire structure is not > > initialised, it ends up with a random value. This causes the NVMEM > > driver to append the device 'devid' value to name of the NVMEM > > device. Ideally for I2C devices such as the AT24 that already have a > > unique name, we would not bother to append the 'devid'. However, given > > that this has always been done for AT24 devices, we cannot remove the > > 'devid' as this will change the name of the userspace sysfs node for > > the NVMEM device. Nonetheless we should ensure that the 'id' field of > > the nvmem_config structure is initialised so that there is no chance of > > a random value causes problems in the future. Therefore, set the NVMEM > > config.id to NVMEM_DEVID_AUTO for AT24 EEPROMs so that the 'devid' is > > always appended. > > > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > > --- > > drivers/misc/eeprom/at24.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c > > index e9df1ca251df..f76624b5c033 100644 > > --- a/drivers/misc/eeprom/at24.c > > +++ b/drivers/misc/eeprom/at24.c > > @@ -715,6 +715,7 @@ static int at24_probe(struct i2c_client *client) > > > > nvmem_config.name = dev_name(dev); > > nvmem_config.dev = dev; > > + nvmem_config.id = NVMEM_DEVID_AUTO; > > nvmem_config.read_only = !writable; > > nvmem_config.root_only = !(flags & AT24_FLAG_IRUGO); > > nvmem_config.owner = THIS_MODULE; > > -- > > 2.25.1 > > > > Ha! I only now noticed I already have a patch for this in my tree from > Vadym Kochan for this cycle. I'll drop this one. > > Bartosz -ETOOEARLY, nevermind my comment, it's for a different issue. I queued this for v5.10. Thanks! Bartosz