Re: [PATCH stblinux.git 2/2] firmware: bcm47xx_nvram: support platform device "brcm,nvram"

[Rafał Miłecki]

On 02.03.2021 17:59, Florian Fainelli wrote:
> On 3/1/21 11:44 PM, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal@xxxxxxxxxx>
> >
> > Add support for platform device providing mapping resource. This allows
> > reading NVRAM based on DT mapping binding. It's required for devices
> > that boot depending on NVRAM stored setup and provides early access to
> > NVRAM data.
> >
> > Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx>
> > ---
> > bcm47xx_nvram driver was originally added through MIPS tree, but this
> > change doesn't affect BCM47XX (MIPS) as it doesn't use DT. It targets
> > ARCH_BCM_5301X so I suggest this goes through the stblinux.git tree.
>
> Can you see if this change can be replaced by the nvmem-rmem work that
> Nicolas recently did to support something similar for the Raspberry Pi 4:
>
> https://lkml.org/lkml/2021/1/29/235

I don't think it fits my case.

It's a reserved memory binding/driver which refers to the system memory.
In NVRAM case we need to do a mapping. I think it's different?

nvmem-rmem registers NVMEM device without providing any cells. It also
doesn't understand NVRAM data structure. I guess nvmem-rmem only exposes
NVMEM for user-space access. I need to access NVRAM to e.g. detect boot
parameters in kernel code.

I was thinking for a moment about treating NVRAM like a NVMEM but NVRAM
doesn't seem to fit current design and kernel API. NVMEM assumes that
every cell has a specific offset and size. Reading NVRAM should be
based on string keys (nof offsets). See nvmem_reg_read_t for details.

This won't make a huge difference I think, but for a slightly cleaner
design I could probably have NVRAM devices without cells and make it
setup NVRAM. Let me see if I can code that.