[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0aa5a003-46d5-4dc7-c720-c847cae95f65@mediatek.com>
Date: Fri, 4 Oct 2024 19:08:45 +0800
From: Pablo Sun <pablo.sun@...iatek.com>
To: Rob Herring <robh@...nel.org>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>, Krzysztof Kozlowski
<krzk@...nel.org>
CC: Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v3 3/6] dt-bindings: nvmem: mediatek: efuse: Reuse
mt8186-efuse in mt8188
Hi Rob, Angelo, and Krzysztof,
Thanks for the thoughtful review, I'd like to follow-up on
Rob's comment:
On 10/3/24 05:11, Rob Herring wrote:
[snip]
> > > diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> > > index 32b8c1eb4e80..70815a3329bf 100644
> > > --- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> > > +++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> > > @@ -39,6 +39,10 @@ properties:
> > > - mediatek,mt8195-efuse
> > > - mediatek,mt8516-efuse
> > > - const: mediatek,efuse
> > > + - items:
> > > + - enum:
> > > + - mediatek,mt8188-efuse
> > > + - const: mediatek,mt8186-efuse
[snip]
>
> What about all the other efuses? The fallback needs to be a subset of
> the 1st compatible.
[snip]
>
> No, but any fallback seems seems a bit odd here. It's one of those
> things that's going to change with every chip.
I think you all agree that the common fallback "mediatek,efuse" should
not longer be used, and such deprecation should be commented both commit
message and the YAML, same as "rockchip,rockchip-efuse" in rockchip-efuse.yaml.
But, Rob has mentioned that I should only define a fallback
if and only if mediatek,mt8186-efuse is a **subset** of mediatek,mt8188-efuse.
It is true that I can merely confirm that they share the same "GPU speed bin"
efuse bit definition and conversion routines.
At this moment I cannot confirm:
- mt8188 has every efuse cells mt8186 defined.
- Every mt8188 efuse cells values must be interpreted the same as mt8186.
So, I don't think mt8186-efuse is a subset of mt8188-efuse in this sense.
Do you think it would be better that we re-use this GPU speed bin conversion
in the eFuse driver implementation, rather than reuse it in the dt-binding?
This is also what Angelo suggested initially for v2 modification.
Many thanks,
Pablo
Powered by blists - more mailing lists