Messages in this thread | | | Date | Tue, 25 Aug 2020 09:17:32 +0200 | From | Krzysztof Kozlowski <> | Subject | Re: [PATCH v2 13/19] dt-bindings: nvmem: imx-ocotp: Update i.MX 8M compatibles |
| |
On Tue, Aug 25, 2020 at 06:46:53AM +0200, Sascha Hauer wrote: > On Mon, Aug 24, 2020 at 06:26:46PM +0200, Krzysztof Kozlowski wrote: > > + oneOf: > > + - items: > > + - enum: > > + - fsl,imx6q-ocotp > > + - fsl,imx6sl-ocotp > > + - fsl,imx6sx-ocotp > > + - fsl,imx6ul-ocotp > > + - fsl,imx6ull-ocotp > > + - fsl,imx7d-ocotp > > + - fsl,imx6sll-ocotp > > + - fsl,imx7ulp-ocotp > > + - fsl,imx8mq-ocotp > > + - fsl,imx8mm-ocotp > > + - fsl,imx8mn-ocotp > > + - fsl,imx8mp-ocotp > > + - const: syscon > > + - items: > > + # The devices are not really compatible with fsl,imx8mm-ocotp, however > > + # the code for getting SoC revision depends on fsl,imx8mm-ocotp compatible. > > Shouldn't this be fixed? It seems strange to justify a binding with > existing code.
The fsl,imx8mn-ocotp is actually compatible with "mm", only the fsl,imx8mp-ocotp is not (although someone might argue that subset of "mp" falls into "mn").
The problem is that drivers/soc/imx/soc-imx8m.c checks revision only against the fsl,imx8mm-ocotp compatible, not the others. It's the pattern used in that driver also for other i.MX 8. Therefore it is a binding implemented and actually used, regardless whether it is correct from hardware point of view or not.
If that's preferred, I could adjust the drivers/soc/imx/soc-imx8m.c for the incompatible "mp". It should not break anything.
Best regards, Krzysztof
| |