Re: [PATCH v3 3/6] dt-bindings: nvmem: mediatek: efuse: Reuse mt8186-efuse in mt8188
From: Pablo Sun
Date: Fri Oct 04 2024 - 07:09:11 EST
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