On 28/03/2022 15:42, Ahmad Fatoum wrote: > On 28.03.22 15:14, Krzysztof Kozlowski wrote: >> On 28/03/2022 15:07, Ahmad Fatoum wrote: >>> On 28.03.22 14:56, Krzysztof Kozlowski wrote: >>>> You could also add two cases: >>>> 1. three compatibles, deprecated: True, >>>> 2. two compatibles, without imx7d. >>>> >>>> Existing DTS stays with three compatibles for two years and later gets >>>> converted to two compatibles. New DTS should use two compatibles. >>>> >>>> It's quite a lot of churn, but would make in the long term bindings >>>> correct and also not break other users/projects. >>> >>> I don't see why we need to deprecate the old binding. New SoCs >>> can be imx8mm-usdhc compatible from the beginning and need not >>> care about the old binding. Existing SoCs can just remain imx7d-usdhc >>> compatible as they are now. >>> >>> I don't see what the deprecation accomplishes. >> >> It avoids to have too many entries of imx8mm (imx8mm alone, >> imx8mm+imx7d, imx8xx+imx8mm+imx7d). > > I see. I assume use of deprecated binding will be reported on a dtbs_check? Unfortunately no, at least not yet. :-( > If so, the expectation is that downstream projects run dtbs_check on their > imported Linux DT repository, see the deprecation warning and extend > their drivers to comply with it. > > Some time later upstream will remove the deprecated binding and adjust > the device trees. This works for me. > Yes. Plus this gives the notice to downstream projects, to comply with the change of DTS. Best regards, Krzysztof
