linux-kernel - Re: [PATCH 3/4] nvmem: mtk-efuse: replace driver with a generic MMIO one

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <618392ed-7d20-a49f-1ec5-b27850d71dec@gmail.com>
Date:   Wed, 1 Feb 2023 12:01:07 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     Michael Walle <michael@...le.cc>
Cc:     devicetree@...r.kernel.org, hayashi.kunihiko@...ionext.com,
        krzysztof.kozlowski+dt@...aro.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, matthias.bgg@...il.com,
        mhiramat@...nel.org, rafal@...ecki.pl, robh+dt@...nel.org,
        srinivas.kandagatla@...aro.org
Subject: Re: [PATCH 3/4] nvmem: mtk-efuse: replace driver with a generic MMIO
 one

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?