Messages in this thread | | | Date | Wed, 1 Feb 2023 10:30:48 +0100 | Subject | Re: [PATCH 3/4] nvmem: mtk-efuse: replace driver with a generic MMIO one | From | Rafał Miłecki <> |
| |
On 1.02.2023 09:48, Michael Walle wrote: >> From: Rafał Miłecki <rafal@milecki.pl> >> >> Mediatek EFUSE uses a simple MMIO that can be handled with a generic >> driver. Replace this driver to avoid code duplication. > > I don't think this is the correct approach. You'll restrict that driver > to being read-only. I admit that right now, it's read only, but it can > be extended to also support efuse writing. With this changes, it's not > possible. > >> static const struct of_device_id mmio_nvmem_of_match_table[] = { >> { .compatible = "mmio-nvmem", }, >> + /* Custom bindings that were introduced before the mmio one */ >> + { .compatible = "mediatek,mt8173-efuse", }, >> + { .compatible = "mediatek,efuse", }, > > Why do you assume that all mediatek efuses will be the same? This should > rather be something like (in the dts/binding): > > compatible = "mediatek,mt8173-efuse", "mmio-nvmem"; > > So if there is no driver for the particular efuse, it will fall back to the > generic one.
Oh great, I'm making circles now.
Rob suggested I should convert existing drivers, see: [PATCH 2/2] nvmem: add generic driver for devices with I/O based access and I thought efuse ones should be good.
Please tell me how I should handle brcm,nvram without wasting more time. I thought I had it sorted out but I just wasted 2 days.
I believe I need to make brcm,nvram NVMEM layout. Without converting it I'm afraid you'll refuse my changes adding cell post processing (that happened to my U-Boot attempts).
Before I convert brcm,nvram to NVMEM layout I need some binding & driver providing MMIO device access. How to handle that?
| |