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
