Re: [PATCH stblinux.git 2/2] firmware: bcm47xx_nvram: support platform device "brcm,nvram"
From: Rafał Miłecki <rafal@milecki.pl>
Date: 2021-03-03 18:41:31
Also in:
linux-devicetree, linux-mips, lkml
On 02.03.2021 17:59, Florian Fainelli wrote:
On 3/1/21 11:44 PM, Rafał Miłecki wrote:quoted
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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel