On 25/06/2025 12:28, Bartosz Golaszewski wrote: > On Wed, Jun 25, 2025 at 12:26 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: >> >>>>>> I wouldn't be stoked to see device trees abusing the "gpio-mmio,base" >>>>>> property all of a sudden just because it now exists as a device >>>>>> property though... I kind of wish we had a way to opt out of exposing >>>>>> this to all the sub-property paths. But it seems tiresome, so: >>>>>> >>>>>> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> >>>>>> >>>>>> Yours, >>>>>> Linus Walleij >>>>> >>>>> That's not a problem - this property is not in any DT bindings and as >>>>> such is not an allowed property in DT sources. For out-of-tree DTs? We >>>>> don't care about those. >>>> That's not true, we do care about implied ABI. Try changing/breaking >>>> this later, when users complain their out of tree DTS is affected, and >>>> explaining this all to Greg. >>>> >>> >>> Wait, seriously? I thought that the upstream bindings are the source >>> of truth for device-tree sources... >> >> >> They are, until they are not... ok, we don't really care that much about >> out of tree DTS, but in-tree DTS still could use these and don't care >> about bindings check, right? >> > > Could they though? I can imagine this happening by accident but in > general: you'd expect new sources to follow the bindings and be Yes, that is what I would expect. > verifiable against them? Otherwise, what's the point of the schema? Of course, but do you really think most SoC maintainers even run dtbs_check on their existing or new code? I think some maintainers pay attention, but RISC-V and my tree are the only ones actually actively checking this for existing and new code. Except me, no other maintainer even referenced maintainer-soc-clean-dts profile. I can easily imagine DTS with warnings and undocumented ABI gets merged and then released in some kernel. And when you release such kernel in v6.17 with DTS and drivers, isn't this already an implied ABI? Best regards, Krzysztof
