Re: [PATCH v3 3/6] dt-bindings: nvmem: mediatek: efuse: Reuse mt8186-efuse in mt8188

[Pablo Sun <pablo.sun@mediatek.com>]

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