Re: [PATCH 2/3] nvmem: mtk-efuse: add support for 32-bit aligned reads

Roman Vivchar <[email protected]>
Newsgroups org.infradead.lists.linux-mediatek,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <fjbTxmhINpeE9M-4eyCFuhueFEH1J4fJBRN90DeIFMEfvxbwx8XeTLnkLsSDq2nchJJFFZxUe_SUNQuGWUDiB4taXJ5lRkLUhT1C_i3L8Rw=@protonmail.com>
On Monday, July 20th, 2026 at 3:48 PM, AngeloGioacchino Del Regno <[email protected]> wrote:

> On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:

...
 
> it's easier at this point if you simply do
> 
> 	if (pdata->needs_aligned_read) {
> 		econfig.stride = 4;
> 		econfig.reg_read = mtk_reg_read_aligned;
> 	} else {
> 		econfig.stride = 1;
> 		econfig.reg_read = mtk_reg_read;
> 	}
> 
> and you avoid touching mtk_reg_read entirely.

stride = 4 means we can't do something like reg = <0x1 0x1>;
For example, CPU speedbin is sitting at 0x181, but we can model that as
0x180.
cpu_speedbin: cpu-speedbin@180 {
    /* This is technically reg = <0x181 0x1> and bits = <0 2> */
    reg = <0x180 0x4>;
    bits = <8 2>;
};

I'm not sure what are mediatek preferences in the devicetree since
things change quite frequently... Downstream never triggers this hw bug
because it uses readl everywhere for each efuse.

I would keep the stride = 1 so we don't need workarounds in the DT, but
the reg_read indeed sounds better :)

Let me know if you have any objections.

Best regards,
Roman
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.