On Tue, Sep 02, 2025 at 02:54:34PM -0500, Rob Herring wrote:

On Sat, Aug 30, 2025 at 09:16:20AM +0200, Janne Grunau wrote:

quoted

On Fri, Aug 29, 2025 at 02:51:19PM -0500, Rob Herring wrote:

quoted

On Thu, Aug 28, 2025 at 04:01:19PM +0200, Janne Grunau wrote:

quoted

This series adds device trees for Apple's M2 Pro, Max and Ultra based
devices. The M2 Pro (t6020), M2 Max (t6021) and M2 Ultra (t6022) SoCs
follow design of the t600x family so copy the structure of SoC *.dtsi
files.

...

quoted

quoted

quoted

After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatibles anymore [1]. Instead either the first
compatible SoC or t8103 is used as fallback compatible supported by the
drivers. t8103 is used as default since most drivers and bindings were
initially written for M1 based devices.

An issue here is any OS without the compatibles added to the drivers 
won't work. Does that matter here? Soon as you need any new drivers or 
significant driver changes it won't. The compatible additions could be 
backported to stable. They aren't really any different than new PCI IDs 
which get backported.

I don't think backporting the driver compatible additions to stable
linux is very useful. It is only relevant for t602x devices and the only
way to interact with them is the serial console. The T602x PCIe support
added in v6.16 requires dart changes (the posted 4th level io page table
support) to be useful. After that PCIe ethernet works so there is a
practical way to interact with t602x systems. So there are probably zero
user of upstream linux on those devices 
I'm more concerned about other projects already supporting t602x
devices. At least u-boot and OpenBSD will be affected by this. As short
term solution m1n1 will add the generic compatibles [1] temporarily.
I think keeping this roughly for a year should allow to add the
compatibles and wait for "fixed" releases of those projects.
I'll send fixes for u-boot once the binding changes are reviewed.

Honestly, at least in the cases where the generic compatible works for 
every chip so far, I'd just stick with it. The issue with generic 
compatibles is more that you don't really know if things are going to be 
the same or not. And most of the time, the h/w ends up changing.

If you want to keep it like this since you've already done it, then for 
all the binding patches:

Let's keep with this series. I still have a branch with dt-binding
changes using the generic compatibles but let's keep this approach to
confusion and duplicate review work.

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Thanks

Janne