Message-ID: <8452b341-8695-05d8-9d03-47c9aeca0ec7@gmail.com>
Date:   Wed, 1 Feb 2023 10:30:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101
 Thunderbird/96.0
Subject: Re: [PATCH 3/4] nvmem: mtk-efuse: replace driver with a generic MMIO
 one
To:     Michael Walle <michael@walle.cc>
Cc:     devicetree@vger.kernel.org, hayashi.kunihiko@socionext.com,
        krzysztof.kozlowski+dt@linaro.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
        mhiramat@kernel.org, rafal@milecki.pl, robh+dt@kernel.org,
        srinivas.kandagatla@linaro.org
References: <20230201064717.18410-4-zajec5@gmail.com>
 <20230201084821.1719839-1-michael@walle.cc>
From:   =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>
In-Reply-To: <20230201084821.1719839-1-michael@walle.cc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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?