Re: [PATCH v4 2/7] arm: dts: omap: Remove incorrect compatible strings from device trees
From: Kory Maincent <kory.maincent@bootlin.com>
Date: 2025-06-19 08:13:40
Also in:
linux-devicetree, linux-omap, lkml
Le Wed, 18 Jun 2025 13:41:19 -0700, Kevin Hilman [off-list ref] a écrit :
Kory Maincent [off-list ref] writes:quoted
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