Message-ID: <20250829195119.GA1206685-robh@kernel.org>
Date: Fri, 29 Aug 2025 14:51:19 -0500
From: Rob Herring <robh@...nel.org>
To: Janne Grunau <j@...nau.net>
Cc: Sven Peter <sven@...nel.org>, Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Neal Gompa <neal@...pa.dev>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Hector Martin <marcan@...can.st>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
	Robin Murphy <robin.murphy@....com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Kettenis <kettenis@...nbsd.org>,
	Andi Shyti <andi.shyti@...nel.org>,
	Jassi Brar <jassisinghbrar@...il.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Sasha Finkelstein <fnkl.kernel@...il.com>,
	Marcel Holtmann <marcel@...tmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@...il.com>,
	Johannes Berg <johannes@...solutions.net>,
	van Spriel <arend@...adcom.com>, Lee Jones <lee@...nel.org>,
	Uwe Kleine-König <ukleinek@...nel.org>,
	Stephen Boyd <sboyd@...nel.org>,
	Wim Van Sebroeck <wim@...ux-watchdog.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Michael Turquette <mturquette@...libre.com>,
	Martin Povišer <povik+lin@...ebit.org>,
	Vinod Koul <vkoul@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Marc Zyngier <maz@...nel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
	Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, iommu@...ts.linux.dev,
	linux-gpio@...r.kernel.org, linux-i2c@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linux-bluetooth@...r.kernel.org,
	linux-wireless@...r.kernel.org, linux-pwm@...r.kernel.org,
	linux-watchdog@...r.kernel.org, linux-clk@...r.kernel.org,
	dmaengine@...r.kernel.org, linux-sound@...r.kernel.org,
	linux-spi@...r.kernel.org, linux-nvme@...ts.infradead.org
Subject: Re: [PATCH 00/37] arm64: Add initial device trees for Apple M2
 Pro/Max/Ultra devices

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.
> 
> t6020 is a cut-down version of t6021, so the former just includes the
> latter and disables the missing bits.
> 
> t6022 is two connected t6021 dies. The implementation seems to use
> t6021 and disables blocks based on whether it is useful to carry
> multiple instances. The disabled blocks are mostly on the second die.
> MMIO addresses on the second die have a constant offset. The interrupt
> controller is multi-die aware. This setup can be represented in the
> device tree with two top level "soc" nodes. The MMIO offset is applied
> via "ranges" and devices are included with preprocessor macros to make
> the node labels unique and to specify the die number for the interrupt
> definition.
> 
> The devices itself are very similar to their M1 Pro, M1 Max and M1 Ultra
> counterparts. The existing device templates are SoC agnostic so the new
> devices can reuse them and include their t602{0,1,2}.dtsi file. The
> minor differences in pinctrl and gpio numbers can be easily adjusted.
> 
> With the t602x SoC family Apple introduced two new devices:
> 
> The M2 Pro Mac mini is similar to the larger M1 and M2 Max Mac Studio. The
> missing SDHCI card reader and two front USB3.1 type-c ports and their
> internal USB hub can be easily deleted.
> 
> The M2 Ultra Mac Pro (tower and rack-mount cases) differs from all other
> devices but may share some bits with the M2 Ultra Mac Studio. The PCIe
> implementation on the M2 Ultra in the Mac Pro differs slightly. Apple
> calls the PCIe controller "apcie-ge" in their device tree. The
> implementation seems to be mostly compatible with the base t6020 PCIe
> controller. The main difference is that there is only a single port with
> with 8 or 16 PCIe Gen4 lanes. These ports connect to a Microchip
> Switchtec PCIe switch with 100 lanes to which all internal PCIe devices
> and PCIe slots connect too.
> 
> This series does not include PCIe support for the Mac Pro for two
> reasons:
> - the linux switchtec driver fails to probe and the downstream PCIe
>   connections come up as PCIe Gen1
> - some of the internal devices require PERST# and power control to come
>   up. Since the device are connected via the PCIe switch the PCIe
>   controller can not do this. The PCI slot pwrctrl can be utilized for
>   power control but misses integration with PERST# as proposed in [1].
> 
> This series depends on "[PATCH v2 0/5] Apple device tree sync from
> downstream kernel" [2] due to the reuse of the t600x device templates
> (patch dependencies and DT compilation) and 4 page table level support
> in apple-dart and io-pgtable-dart [3] since the dart instances report
> 42-bit IAS (IOMMU device attach fails without the series).
> 
> 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.

Rob

Powered by blists - more mailing lists