Thread (12 messages) 12 messages, 4 authors, 2025-06-19

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help