[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 at milecki.pl>
>>
>> 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 at milecki.pl>
>> ---
>> 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.