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: > > On Fri, Aug 29, 2025 at 02:51:19PM -0500, Rob Herring wrote: > > > On Thu, Aug 28, 2025 at 04:01:19PM +0200, Janne Grunau wrote: > > > > 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.
... > > > > 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) <r...@kernel.org> Thanks Janne
