Re: [PATCH v4 2/7] arm: dts: omap: Remove incorrect compatible strings from device trees

[Kory Maincent <kory.maincent@bootlin.com>]

Le Wed, 18 Jun 2025 13:41:19 -0700,
Kevin Hilman <khilman@baylibre.com> a écrit :

> Kory Maincent <kory.maincent@bootlin.com> writes:
> 
> > Several device trees incorrectly included extraneous compatible strings
> > in their compatible property lists. The policy is to only describe the
> > specific board name and SoC name to avoid confusion.
> >
> > Remove these incorrect compatible strings to fix the inconsistency.
> >
> > Also fix board vendor prefixes for BeagleBoard variants that were
> > incorrectly using "ti" instead of "beagle" or "seeed".
> >
> > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>  
> 
> While I agree with adding the new compatibles for clarity, I question
> removing the old ones after so much time in the kernel. 
> 
> As mentioned in earlier reviews, there is other tooling outside the
> kernel that has been built around these strings.  The one that I have in
> mind is KernelCI based tooling that tracks boards based on compatible
> strings.
> 
> While the KernelCI tooling does evolve with these kinds of kernel
> changes, it also still builds and tests older kernels.  So if we want
> these tools to know that "beagle,am335x-bone" on a new kernel and
> "ti,am335x-bone" on an older stable kernel are actually the same board,
> the tools will need to keep track of that mapping as these change.
> 
> So instead of removing them, can't we just make the new ones higher prio
> than the old ones?  That way the tools can see both, and also see which
> one is higher prio.

But we can't add something like what you describe to the bindings. I don't think
they will accept this. And if we don't align the bindings the dtbs check will
complain forever.

> I fully realize this is not necessarily the best technical argument to
> keeping the old and wrong names, so I will defer to DT maintainers on
> this one.  But since it's been wrong for a long time, I'm a bit
> reluctant to remove them completely knowing there will be external tools
> breakage.

Yes, still waiting DT maintainers point of vue on this. :/

I am wondering if I will separate my patch series, the cleaning part raises
lots of push back.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com