Messages in this thread | | | Subject | Re: [PATCH stblinux.git 2/2] firmware: bcm47xx_nvram: support platform device "brcm,nvram" | From | Rafał Miłecki <> | Date | Wed, 3 Mar 2021 12:44:06 +0100 |
| |
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@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@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.
| |