On 1.02.2023 11:46, Michael Walle wrote:
Before I convert brcm,nvram to NVMEM layout I need some binding & driver
providing MMIO device access. How to handle that?
I'm not arguing against having the mmio nvmem driver. But I don't
think we should sacrifice possible write access with other drivers. And
I presume write access won't be possible with your generic driver as it
probably isn't just a memcpy_toio().
It is a great fallback for some nvmem peripherals which just maps a
memory region, but doesn't replace a proper driver for an nvmem device.
OK, then maybe I'll retry again with generic MMIO and without converting
existing specific drivers. That is what (AFAIU) Rob asked though.
What bothers me the most isn't the driver change. The driver can be
resurrected once someone will do proper write access, but the generic
"mediatek,efuse" compatible together with the comment above the older
compatible string. These imply that you should use "mediatek,efuse",
but we don't know if all mediatek efuse peripherals will be the
same - esp. for writing which is usually more complex than the reading.
mediatek,efuse was already there, don't blame me for it ;)
nitpick btw: why not "nvmem-mmio"?
Because I read from left to right ;)
It's MMIO based NVMEM. Not MMIO on top of NVMEM.
Sure, we have "nvmem-cells" but that is because those are cells of NVMEM
device.
Unless my English knowledge fails me.
So it's either:
(1) compatible = "mediatek,mt8173-efuse"
(2) compatible = "mediatek,mt8173-efuse", "mmio-nvmem"
(1) will be supported any anyway for older dts and you need to add
the specific compatibles to the nvmem-mmio driver - or keep the
driver as is.
With (2) you wouldn't need to do that and the kernel can load the
proper driver if available or fall back to the nvmem-mmio one. I'd
even make that one "default y" so it will be available on future
kernels and boards can already make use of the nvmem device even
if there is no proper driver for them.
I'd prefer (2). Dunno what the dt maintainers agree.
(2) looks OK, Rob, Krzysztof?
