Documentation/devicetree/bindings/arm/apple.yaml | 39 +- .../devicetree/bindings/arm/apple/apple,pmgr.yaml | 33 +- .../devicetree/bindings/clock/apple,nco.yaml | 17 +- .../bindings/cpufreq/apple,cluster-cpufreq.yaml | 3 + .../devicetree/bindings/dma/apple,admac.yaml | 17 +- .../devicetree/bindings/gpu/apple,agx.yaml | 6 + .../devicetree/bindings/i2c/apple,i2c.yaml | 27 +- .../bindings/interrupt-controller/apple,aic2.yaml | 1 + .../devicetree/bindings/iommu/apple,dart.yaml | 14 +- .../devicetree/bindings/iommu/apple,sart.yaml | 4 +- .../devicetree/bindings/mailbox/apple,mailbox.yaml | 1 + .../devicetree/bindings/mfd/apple,smc.yaml | 17 +- .../net/bluetooth/brcm,bcm4377-bluetooth.yaml | 1 + .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 + .../devicetree/bindings/nvme/apple,nvme-ans.yaml | 29 +- .../devicetree/bindings/pinctrl/apple,pinctrl.yaml | 27 +- .../bindings/power/apple,pmgr-pwrstate.yaml | 27 +- .../devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 3 +- .../devicetree/bindings/sound/apple,mca.yaml | 17 +- .../devicetree/bindings/spi/apple,spi.yaml | 16 +- .../devicetree/bindings/spmi/apple,spmi.yaml | 17 +- .../devicetree/bindings/watchdog/apple,wdt.yaml | 27 +- arch/arm64/boot/dts/apple/Makefile | 8 + arch/arm64/boot/dts/apple/t600x-j375.dtsi | 1 + arch/arm64/boot/dts/apple/t6020-j414s.dts | 26 + arch/arm64/boot/dts/apple/t6020-j416s.dts | 26 + arch/arm64/boot/dts/apple/t6020-j474s.dts | 47 + arch/arm64/boot/dts/apple/t6020.dtsi | 22 + arch/arm64/boot/dts/apple/t6021-j414c.dts | 26 + arch/arm64/boot/dts/apple/t6021-j416c.dts | 26 + arch/arm64/boot/dts/apple/t6021-j475c.dts | 37 + arch/arm64/boot/dts/apple/t6021.dtsi | 69 + arch/arm64/boot/dts/apple/t6022-j180d.dts | 121 ++ arch/arm64/boot/dts/apple/t6022-j475d.dts | 42 + arch/arm64/boot/dts/apple/t6022-jxxxd.dtsi | 38 + arch/arm64/boot/dts/apple/t6022.dtsi | 347 +++ arch/arm64/boot/dts/apple/t602x-common.dtsi | 465 ++++ arch/arm64/boot/dts/apple/t602x-die0.dtsi | 577 +++++ arch/arm64/boot/dts/apple/t602x-dieX.dtsi | 129 ++ arch/arm64/boot/dts/apple/t602x-gpio-pins.dtsi | 81 + arch/arm64/boot/dts/apple/t602x-j414-j416.dtsi | 45 + arch/arm64/boot/dts/apple/t602x-j474-j475.dtsi | 38 + arch/arm64/boot/dts/apple/t602x-nvme.dtsi | 42 + arch/arm64/boot/dts/apple/t602x-pmgr.dtsi | 2268 ++++++++++++++++++++ drivers/clk/clk-apple-nco.c | 1 + drivers/dma/apple-admac.c | 1 + drivers/mfd/macsmc.c | 1 + drivers/nvme/host/apple.c | 1 + drivers/pinctrl/pinctrl-apple-gpio.c | 1 + drivers/pmdomain/apple/pmgr-pwrstate.c | 1 + drivers/spi/spi-apple.c | 1 + drivers/spmi/spmi-apple-controller.c | 1 + drivers/watchdog/apple_wdt.c | 1 + sound/soc/apple/mca.c | 1 + 54 files changed, 4722 insertions(+), 113 deletions(-)
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.
The series adds those fallback compatibles to drivers where necessary,
annotates the SoC lists for generic compatibles as "do not extend" and
adds t6020 per-SoC compatibles.
[1]: https://lore.kernel.org/linux-pci/20250819-pci-pwrctrl-perst-v1-0-4b74978d2007@oss.qualcomm.com/
[2]: https://lore.kernel.org/asahi/20250823-apple-dt-sync-6-17-v2-0-6dc0daeb4786@jannau.net/
[3]: https://lore.kernel.org/asahi/20250821-apple-dart-4levels-v2-0-e39af79daa37@jannau.net/
[4]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
Signed-off-by: Janne Grunau <j@jannau.net>
---
Hector Martin (3):
arm64: dts: apple: Add initial t6020/t6021/t6022 DTs
arm64: dts: apple: Add J414 and J416 Macbook Pro device trees
arm64: dts: apple: Add J180d (Mac Pro, M2 Ultra, 2023) device tree
Janne Grunau (34):
dt-bindings: arm: apple: Add t6020x compatibles
dt-bindings: arm: apple: apple,pmgr: Add t6020-pmgr compatible
pmdomain: apple: Add "apple,t8103-pmgr-pwrstate"
dt-bindings: power: apple,pmgr-pwrstate: Add t6020 compatible
dt-bindings: cpufreq: apple,cluster-cpufreq: Add t6020 compatible
dt-bindings: interrupt-controller: apple,aic2: Add apple,t6020-aic compatible
dt-bindings: iommu: dart: Add apple,t6020-dart compatible
pinctrl: apple: Add "apple,t8103-pinctrl" as compatible
dt-bindings: pinctrl: apple,pinctrl: Add apple,t6020-pinctrl compatible
dt-bindings: i2c: apple,i2c: Add apple,t6020-i2c compatible
dt-bindings: mailbox: apple,mailbox: Add t6020 compatible
dt-bindings: gpu: apple,agx: Add agx-{g14s,g14c,g14d} compatibles
dt-bindings: iommu: apple,sart: Add apple,t6020-sart compatible
nvme-apple: Add "apple,t8103-nvme-ans2" as compatible
dt-bindings: nvme: apple: Add apple,t6020-nvme-ans2 compatible
dt-bindings: net: bcm4377-bluetooth: Add BCM4388 compatible
dt-bindings: net: bcm4329-fmac: Add BCM4388 PCI compatible
mfd: macsmc: Add "apple,t8103-smc" compatible
dt-bindings: mfd: apple,smc: Add t6020-smc compatible
dt-bindings: pwm: apple,s5l-fpwm: Add t6020-fpwm compatible
spmi: apple: Add "apple,t8103-spmi" compatible
dt-bindings: spmi: apple,spmi: Add t6020-spmi compatible
watchdog: apple: Add "apple,t8103-wdt" compatible
dt-bindings: watchdog: apple,wdt: Add t6020-wdt compatible
clk: clk-apple-nco: Add "apple,t8103-nco" compatible
dt-bindings: clock: apple,nco: Add t6020-nco compatible
dmaengine: apple-admac: Add "apple,t8103-admac" compatible
dt-bindings: dma: apple,admac: Add t6020-admac compatible
ASoC: apple: mca: Add "apple,t8103-mca" compatible
ASoC: dt-bindings: apple,mca: Add t6020-mca compatible
spi: apple: Add "apple,t8103-spi" compatible
spi: dt-bindings: apple,spi: Add t6020-spi compatible
arm64: dts: apple: Add ethernet0 alias for J375 template
arm64: dts: apple: Add J474s, J475c and J475d device trees
Documentation/devicetree/bindings/arm/apple.yaml | 39 +-
.../devicetree/bindings/arm/apple/apple,pmgr.yaml | 33 +-
.../devicetree/bindings/clock/apple,nco.yaml | 17 +-
.../bindings/cpufreq/apple,cluster-cpufreq.yaml | 3 +
.../devicetree/bindings/dma/apple,admac.yaml | 17 +-
.../devicetree/bindings/gpu/apple,agx.yaml | 6 +
.../devicetree/bindings/i2c/apple,i2c.yaml | 27 +-
.../bindings/interrupt-controller/apple,aic2.yaml | 1 +
.../devicetree/bindings/iommu/apple,dart.yaml | 14 +-
.../devicetree/bindings/iommu/apple,sart.yaml | 4 +-
.../devicetree/bindings/mailbox/apple,mailbox.yaml | 1 +
.../devicetree/bindings/mfd/apple,smc.yaml | 17 +-
.../net/bluetooth/brcm,bcm4377-bluetooth.yaml | 1 +
.../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
.../devicetree/bindings/nvme/apple,nvme-ans.yaml | 29 +-
.../devicetree/bindings/pinctrl/apple,pinctrl.yaml | 27 +-
.../bindings/power/apple,pmgr-pwrstate.yaml | 27 +-
.../devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 3 +-
.../devicetree/bindings/sound/apple,mca.yaml | 17 +-
.../devicetree/bindings/spi/apple,spi.yaml | 16 +-
.../devicetree/bindings/spmi/apple,spmi.yaml | 17 +-
.../devicetree/bindings/watchdog/apple,wdt.yaml | 27 +-
arch/arm64/boot/dts/apple/Makefile | 8 +
arch/arm64/boot/dts/apple/t600x-j375.dtsi | 1 +
arch/arm64/boot/dts/apple/t6020-j414s.dts | 26 +
arch/arm64/boot/dts/apple/t6020-j416s.dts | 26 +
arch/arm64/boot/dts/apple/t6020-j474s.dts | 47 +
arch/arm64/boot/dts/apple/t6020.dtsi | 22 +
arch/arm64/boot/dts/apple/t6021-j414c.dts | 26 +
arch/arm64/boot/dts/apple/t6021-j416c.dts | 26 +
arch/arm64/boot/dts/apple/t6021-j475c.dts | 37 +
arch/arm64/boot/dts/apple/t6021.dtsi | 69 +
arch/arm64/boot/dts/apple/t6022-j180d.dts | 121 ++
arch/arm64/boot/dts/apple/t6022-j475d.dts | 42 +
arch/arm64/boot/dts/apple/t6022-jxxxd.dtsi | 38 +
arch/arm64/boot/dts/apple/t6022.dtsi | 347 +++
arch/arm64/boot/dts/apple/t602x-common.dtsi | 465 ++++
arch/arm64/boot/dts/apple/t602x-die0.dtsi | 577 +++++
arch/arm64/boot/dts/apple/t602x-dieX.dtsi | 129 ++
arch/arm64/boot/dts/apple/t602x-gpio-pins.dtsi | 81 +
arch/arm64/boot/dts/apple/t602x-j414-j416.dtsi | 45 +
arch/arm64/boot/dts/apple/t602x-j474-j475.dtsi | 38 +
arch/arm64/boot/dts/apple/t602x-nvme.dtsi | 42 +
arch/arm64/boot/dts/apple/t602x-pmgr.dtsi | 2268 ++++++++++++++++++++
drivers/clk/clk-apple-nco.c | 1 +
drivers/dma/apple-admac.c | 1 +
drivers/mfd/macsmc.c | 1 +
drivers/nvme/host/apple.c | 1 +
drivers/pinctrl/pinctrl-apple-gpio.c | 1 +
drivers/pmdomain/apple/pmgr-pwrstate.c | 1 +
drivers/spi/spi-apple.c | 1 +
drivers/spmi/spmi-apple-controller.c | 1 +
drivers/watchdog/apple_wdt.c | 1 +
sound/soc/apple/mca.c | 1 +
54 files changed, 4722 insertions(+), 113 deletions(-)
---
base-commit: 50ee15a27ec4cc41e99ee5e9011de7875569cd52
change-id: 20250811-dt-apple-t6020-1359ce9bf2e7
prerequisite-change-id: 20250813-apple-dt-sync-6-17-d1fc1c89f7ca:v2
prerequisite-patch-id: 1405c7c78139704a4cbeb1adc67786b2c7971a3f
prerequisite-patch-id: 65865050e9e7427bac04f47d0b7927aacaac19bd
prerequisite-patch-id: 9240e5f435fb3406e77b4e4e9b02eb3d52e660e6
prerequisite-patch-id: c16715c9a9fcb396b7e4365fd767b05604b8de81
prerequisite-patch-id: a675ad20c2b427a021dafb5d6c8716497741604c
Best regards,
--
Janne Grunau <j@jannau.net>
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. > 37 patches, 9-15 separate subsystems. That's really not how you are suppose to upstream things. Please split this per subsystem. Few bindings without drivers could be together, though. Best regards, Krzysztof
On Thu, Aug 28, 2025 at 10:01 AM Janne Grunau <j@jannau.net> 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.
>
> The series adds those fallback compatibles to drivers where necessary,
> annotates the SoC lists for generic compatibles as "do not extend" and
> adds t6020 per-SoC compatibles.
>
> [1]: https://lore.kernel.org/linux-pci/20250819-pci-pwrctrl-perst-v1-0-4b74978d2007@oss.qualcomm.com/
> [2]: https://lore.kernel.org/asahi/20250823-apple-dt-sync-6-17-v2-0-6dc0daeb4786@jannau.net/
> [3]: https://lore.kernel.org/asahi/20250821-apple-dart-4levels-v2-0-e39af79daa37@jannau.net/
> [4]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Hector Martin (3):
> arm64: dts: apple: Add initial t6020/t6021/t6022 DTs
> arm64: dts: apple: Add J414 and J416 Macbook Pro device trees
> arm64: dts: apple: Add J180d (Mac Pro, M2 Ultra, 2023) device tree
>
> Janne Grunau (34):
> dt-bindings: arm: apple: Add t6020x compatibles
> dt-bindings: arm: apple: apple,pmgr: Add t6020-pmgr compatible
> pmdomain: apple: Add "apple,t8103-pmgr-pwrstate"
> dt-bindings: power: apple,pmgr-pwrstate: Add t6020 compatible
> dt-bindings: cpufreq: apple,cluster-cpufreq: Add t6020 compatible
> dt-bindings: interrupt-controller: apple,aic2: Add apple,t6020-aic compatible
> dt-bindings: iommu: dart: Add apple,t6020-dart compatible
> pinctrl: apple: Add "apple,t8103-pinctrl" as compatible
> dt-bindings: pinctrl: apple,pinctrl: Add apple,t6020-pinctrl compatible
> dt-bindings: i2c: apple,i2c: Add apple,t6020-i2c compatible
> dt-bindings: mailbox: apple,mailbox: Add t6020 compatible
> dt-bindings: gpu: apple,agx: Add agx-{g14s,g14c,g14d} compatibles
> dt-bindings: iommu: apple,sart: Add apple,t6020-sart compatible
> nvme-apple: Add "apple,t8103-nvme-ans2" as compatible
> dt-bindings: nvme: apple: Add apple,t6020-nvme-ans2 compatible
> dt-bindings: net: bcm4377-bluetooth: Add BCM4388 compatible
> dt-bindings: net: bcm4329-fmac: Add BCM4388 PCI compatible
> mfd: macsmc: Add "apple,t8103-smc" compatible
> dt-bindings: mfd: apple,smc: Add t6020-smc compatible
> dt-bindings: pwm: apple,s5l-fpwm: Add t6020-fpwm compatible
> spmi: apple: Add "apple,t8103-spmi" compatible
> dt-bindings: spmi: apple,spmi: Add t6020-spmi compatible
> watchdog: apple: Add "apple,t8103-wdt" compatible
> dt-bindings: watchdog: apple,wdt: Add t6020-wdt compatible
> clk: clk-apple-nco: Add "apple,t8103-nco" compatible
> dt-bindings: clock: apple,nco: Add t6020-nco compatible
> dmaengine: apple-admac: Add "apple,t8103-admac" compatible
> dt-bindings: dma: apple,admac: Add t6020-admac compatible
> ASoC: apple: mca: Add "apple,t8103-mca" compatible
> ASoC: dt-bindings: apple,mca: Add t6020-mca compatible
> spi: apple: Add "apple,t8103-spi" compatible
> spi: dt-bindings: apple,spi: Add t6020-spi compatible
> arm64: dts: apple: Add ethernet0 alias for J375 template
> arm64: dts: apple: Add J474s, J475c and J475d device trees
>
> Documentation/devicetree/bindings/arm/apple.yaml | 39 +-
> .../devicetree/bindings/arm/apple/apple,pmgr.yaml | 33 +-
> .../devicetree/bindings/clock/apple,nco.yaml | 17 +-
> .../bindings/cpufreq/apple,cluster-cpufreq.yaml | 3 +
> .../devicetree/bindings/dma/apple,admac.yaml | 17 +-
> .../devicetree/bindings/gpu/apple,agx.yaml | 6 +
> .../devicetree/bindings/i2c/apple,i2c.yaml | 27 +-
> .../bindings/interrupt-controller/apple,aic2.yaml | 1 +
> .../devicetree/bindings/iommu/apple,dart.yaml | 14 +-
> .../devicetree/bindings/iommu/apple,sart.yaml | 4 +-
> .../devicetree/bindings/mailbox/apple,mailbox.yaml | 1 +
> .../devicetree/bindings/mfd/apple,smc.yaml | 17 +-
> .../net/bluetooth/brcm,bcm4377-bluetooth.yaml | 1 +
> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
> .../devicetree/bindings/nvme/apple,nvme-ans.yaml | 29 +-
> .../devicetree/bindings/pinctrl/apple,pinctrl.yaml | 27 +-
> .../bindings/power/apple,pmgr-pwrstate.yaml | 27 +-
> .../devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 3 +-
> .../devicetree/bindings/sound/apple,mca.yaml | 17 +-
> .../devicetree/bindings/spi/apple,spi.yaml | 16 +-
> .../devicetree/bindings/spmi/apple,spmi.yaml | 17 +-
> .../devicetree/bindings/watchdog/apple,wdt.yaml | 27 +-
> arch/arm64/boot/dts/apple/Makefile | 8 +
> arch/arm64/boot/dts/apple/t600x-j375.dtsi | 1 +
> arch/arm64/boot/dts/apple/t6020-j414s.dts | 26 +
> arch/arm64/boot/dts/apple/t6020-j416s.dts | 26 +
> arch/arm64/boot/dts/apple/t6020-j474s.dts | 47 +
> arch/arm64/boot/dts/apple/t6020.dtsi | 22 +
> arch/arm64/boot/dts/apple/t6021-j414c.dts | 26 +
> arch/arm64/boot/dts/apple/t6021-j416c.dts | 26 +
> arch/arm64/boot/dts/apple/t6021-j475c.dts | 37 +
> arch/arm64/boot/dts/apple/t6021.dtsi | 69 +
> arch/arm64/boot/dts/apple/t6022-j180d.dts | 121 ++
> arch/arm64/boot/dts/apple/t6022-j475d.dts | 42 +
> arch/arm64/boot/dts/apple/t6022-jxxxd.dtsi | 38 +
> arch/arm64/boot/dts/apple/t6022.dtsi | 347 +++
> arch/arm64/boot/dts/apple/t602x-common.dtsi | 465 ++++
> arch/arm64/boot/dts/apple/t602x-die0.dtsi | 577 +++++
> arch/arm64/boot/dts/apple/t602x-dieX.dtsi | 129 ++
> arch/arm64/boot/dts/apple/t602x-gpio-pins.dtsi | 81 +
> arch/arm64/boot/dts/apple/t602x-j414-j416.dtsi | 45 +
> arch/arm64/boot/dts/apple/t602x-j474-j475.dtsi | 38 +
> arch/arm64/boot/dts/apple/t602x-nvme.dtsi | 42 +
> arch/arm64/boot/dts/apple/t602x-pmgr.dtsi | 2268 ++++++++++++++++++++
> drivers/clk/clk-apple-nco.c | 1 +
> drivers/dma/apple-admac.c | 1 +
> drivers/mfd/macsmc.c | 1 +
> drivers/nvme/host/apple.c | 1 +
> drivers/pinctrl/pinctrl-apple-gpio.c | 1 +
> drivers/pmdomain/apple/pmgr-pwrstate.c | 1 +
> drivers/spi/spi-apple.c | 1 +
> drivers/spmi/spmi-apple-controller.c | 1 +
> drivers/watchdog/apple_wdt.c | 1 +
> sound/soc/apple/mca.c | 1 +
> 54 files changed, 4722 insertions(+), 113 deletions(-)
> ---
> base-commit: 50ee15a27ec4cc41e99ee5e9011de7875569cd52
> change-id: 20250811-dt-apple-t6020-1359ce9bf2e7
> prerequisite-change-id: 20250813-apple-dt-sync-6-17-d1fc1c89f7ca:v2
> prerequisite-patch-id: 1405c7c78139704a4cbeb1adc67786b2c7971a3f
> prerequisite-patch-id: 65865050e9e7427bac04f47d0b7927aacaac19bd
> prerequisite-patch-id: 9240e5f435fb3406e77b4e4e9b02eb3d52e660e6
> prerequisite-patch-id: c16715c9a9fcb396b7e4365fd767b05604b8de81
> prerequisite-patch-id: a675ad20c2b427a021dafb5d6c8716497741604c
>
This is quite a series, but pretty straightforward.
Reviewed-by: Neal Gompa <neal@gompa.dev>
--
真実はいつも一つ！/ Always, there's only one truth!
Janne Grunau 於 2025/8/28 晚上10:01 寫道: > 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. > > The series adds those fallback compatibles to drivers where necessary, > annotates the SoC lists for generic compatibles as "do not extend" and > adds t6020 per-SoC compatibles. The series is inconsistent about the use of generic fallback compatibles. "apple,aic2", "apple,s5l-fpwm", "apple,asc-mailbox-v4" is still used. [...] Best regards, Nick Chan
On Fri, Aug 29, 2025 at 12:11:40AM +0800, Nick Chan wrote: > > Janne Grunau 於 2025/8/28 晚上10:01 寫道: > > 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. > > > > The series adds those fallback compatibles to drivers where necessary, > > annotates the SoC lists for generic compatibles as "do not extend" and > > adds t6020 per-SoC compatibles. > > The series is inconsistent about the use of generic fallback compatibles. > > "apple,aic2", "apple,s5l-fpwm", "apple,asc-mailbox-v4" is still used. Those are less generic than say "apple,spi". For "apple,aic2" especially it's clear which SoCs use it and the set is closed (ignoring iphone SoCs which very likely will never run linux). For the interrupt controller the fallout of not using the "apple,aic2" is larger since even m1n1 expect that. irq driver is special in so far as it requires more than adding a compatible. I think "apple,s5l-fpwm" and "apple,asc-mailbox-v4" are specific enough and describe simple hardware so the will not cause issues unlike the complex firmware based "apple,nvme-ans2". Janne
Janne Grunau 於 2025/8/29 凌晨12:50 寫道: > On Fri, Aug 29, 2025 at 12:11:40AM +0800, Nick Chan wrote: >> Janne Grunau 於 2025/8/28 晚上10:01 寫道: >>> 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. >>> >>> The series adds those fallback compatibles to drivers where necessary, >>> annotates the SoC lists for generic compatibles as "do not extend" and >>> adds t6020 per-SoC compatibles. >> The series is inconsistent about the use of generic fallback compatibles. >> >> "apple,aic2", "apple,s5l-fpwm", "apple,asc-mailbox-v4" is still used. > Those are less generic than say "apple,spi". For "apple,aic2" especially > it's clear which SoCs use it and the set is closed (ignoring iphone SoCs > which very likely will never run linux). For the interrupt controller > the fallout of not using the "apple,aic2" is larger since even m1n1 > expect that. irq driver is special in so far as it requires more than > adding a compatible. > I think "apple,s5l-fpwm" and "apple,asc-mailbox-v4" are specific enough > and describe simple hardware so the will not cause issues unlike the > complex firmware based "apple,nvme-ans2". All of these compatibles has around the same specificity as "apple,nvme-ans2" which is a mistake of using A11's version (ans2) to describe the M1 nvme (ans3). Though I do agree "apple,asc-mailbox-v4", "apple,s5l-fpwm" and "apple,aic2" should be fine compatibility-wise. Although AIC2 compatible should be fine that may not hold for later versions since Linux's AIC driver is actually AIC + core complex FIQ stuff, so when you do add newer AICs it is probably better to use SoC-specific compatible there. > > Janne > Best regards, Nick Chan
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
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.
> >
> > 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.
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.
Janne
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.
> > >
> > > 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.
>
> 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:
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Rob
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) <robh@kernel.org> Thanks Janne
On Thu, 28 Aug 2025 at 16:01, Janne Grunau <j@jannau.net> 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.
>
> The series adds those fallback compatibles to drivers where necessary,
> annotates the SoC lists for generic compatibles as "do not extend" and
> adds t6020 per-SoC compatibles.
>
> [1]: https://lore.kernel.org/linux-pci/20250819-pci-pwrctrl-perst-v1-0-4b74978d2007@oss.qualcomm.com/
> [2]: https://lore.kernel.org/asahi/20250823-apple-dt-sync-6-17-v2-0-6dc0daeb4786@jannau.net/
> [3]: https://lore.kernel.org/asahi/20250821-apple-dart-4levels-v2-0-e39af79daa37@jannau.net/
> [4]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
>
> Signed-off-by: Janne Grunau <j@jannau.net>
Is it okay for me to pick up the pmdomain patches (patch3 and patch4)
by now - or what route are you planning to get this merged through?
Kind regards
Uffe
> ---
> Hector Martin (3):
> arm64: dts: apple: Add initial t6020/t6021/t6022 DTs
> arm64: dts: apple: Add J414 and J416 Macbook Pro device trees
> arm64: dts: apple: Add J180d (Mac Pro, M2 Ultra, 2023) device tree
>
> Janne Grunau (34):
> dt-bindings: arm: apple: Add t6020x compatibles
> dt-bindings: arm: apple: apple,pmgr: Add t6020-pmgr compatible
> pmdomain: apple: Add "apple,t8103-pmgr-pwrstate"
> dt-bindings: power: apple,pmgr-pwrstate: Add t6020 compatible
> dt-bindings: cpufreq: apple,cluster-cpufreq: Add t6020 compatible
> dt-bindings: interrupt-controller: apple,aic2: Add apple,t6020-aic compatible
> dt-bindings: iommu: dart: Add apple,t6020-dart compatible
> pinctrl: apple: Add "apple,t8103-pinctrl" as compatible
> dt-bindings: pinctrl: apple,pinctrl: Add apple,t6020-pinctrl compatible
> dt-bindings: i2c: apple,i2c: Add apple,t6020-i2c compatible
> dt-bindings: mailbox: apple,mailbox: Add t6020 compatible
> dt-bindings: gpu: apple,agx: Add agx-{g14s,g14c,g14d} compatibles
> dt-bindings: iommu: apple,sart: Add apple,t6020-sart compatible
> nvme-apple: Add "apple,t8103-nvme-ans2" as compatible
> dt-bindings: nvme: apple: Add apple,t6020-nvme-ans2 compatible
> dt-bindings: net: bcm4377-bluetooth: Add BCM4388 compatible
> dt-bindings: net: bcm4329-fmac: Add BCM4388 PCI compatible
> mfd: macsmc: Add "apple,t8103-smc" compatible
> dt-bindings: mfd: apple,smc: Add t6020-smc compatible
> dt-bindings: pwm: apple,s5l-fpwm: Add t6020-fpwm compatible
> spmi: apple: Add "apple,t8103-spmi" compatible
> dt-bindings: spmi: apple,spmi: Add t6020-spmi compatible
> watchdog: apple: Add "apple,t8103-wdt" compatible
> dt-bindings: watchdog: apple,wdt: Add t6020-wdt compatible
> clk: clk-apple-nco: Add "apple,t8103-nco" compatible
> dt-bindings: clock: apple,nco: Add t6020-nco compatible
> dmaengine: apple-admac: Add "apple,t8103-admac" compatible
> dt-bindings: dma: apple,admac: Add t6020-admac compatible
> ASoC: apple: mca: Add "apple,t8103-mca" compatible
> ASoC: dt-bindings: apple,mca: Add t6020-mca compatible
> spi: apple: Add "apple,t8103-spi" compatible
> spi: dt-bindings: apple,spi: Add t6020-spi compatible
> arm64: dts: apple: Add ethernet0 alias for J375 template
> arm64: dts: apple: Add J474s, J475c and J475d device trees
>
> Documentation/devicetree/bindings/arm/apple.yaml | 39 +-
> .../devicetree/bindings/arm/apple/apple,pmgr.yaml | 33 +-
> .../devicetree/bindings/clock/apple,nco.yaml | 17 +-
> .../bindings/cpufreq/apple,cluster-cpufreq.yaml | 3 +
> .../devicetree/bindings/dma/apple,admac.yaml | 17 +-
> .../devicetree/bindings/gpu/apple,agx.yaml | 6 +
> .../devicetree/bindings/i2c/apple,i2c.yaml | 27 +-
> .../bindings/interrupt-controller/apple,aic2.yaml | 1 +
> .../devicetree/bindings/iommu/apple,dart.yaml | 14 +-
> .../devicetree/bindings/iommu/apple,sart.yaml | 4 +-
> .../devicetree/bindings/mailbox/apple,mailbox.yaml | 1 +
> .../devicetree/bindings/mfd/apple,smc.yaml | 17 +-
> .../net/bluetooth/brcm,bcm4377-bluetooth.yaml | 1 +
> .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
> .../devicetree/bindings/nvme/apple,nvme-ans.yaml | 29 +-
> .../devicetree/bindings/pinctrl/apple,pinctrl.yaml | 27 +-
> .../bindings/power/apple,pmgr-pwrstate.yaml | 27 +-
> .../devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 3 +-
> .../devicetree/bindings/sound/apple,mca.yaml | 17 +-
> .../devicetree/bindings/spi/apple,spi.yaml | 16 +-
> .../devicetree/bindings/spmi/apple,spmi.yaml | 17 +-
> .../devicetree/bindings/watchdog/apple,wdt.yaml | 27 +-
> arch/arm64/boot/dts/apple/Makefile | 8 +
> arch/arm64/boot/dts/apple/t600x-j375.dtsi | 1 +
> arch/arm64/boot/dts/apple/t6020-j414s.dts | 26 +
> arch/arm64/boot/dts/apple/t6020-j416s.dts | 26 +
> arch/arm64/boot/dts/apple/t6020-j474s.dts | 47 +
> arch/arm64/boot/dts/apple/t6020.dtsi | 22 +
> arch/arm64/boot/dts/apple/t6021-j414c.dts | 26 +
> arch/arm64/boot/dts/apple/t6021-j416c.dts | 26 +
> arch/arm64/boot/dts/apple/t6021-j475c.dts | 37 +
> arch/arm64/boot/dts/apple/t6021.dtsi | 69 +
> arch/arm64/boot/dts/apple/t6022-j180d.dts | 121 ++
> arch/arm64/boot/dts/apple/t6022-j475d.dts | 42 +
> arch/arm64/boot/dts/apple/t6022-jxxxd.dtsi | 38 +
> arch/arm64/boot/dts/apple/t6022.dtsi | 347 +++
> arch/arm64/boot/dts/apple/t602x-common.dtsi | 465 ++++
> arch/arm64/boot/dts/apple/t602x-die0.dtsi | 577 +++++
> arch/arm64/boot/dts/apple/t602x-dieX.dtsi | 129 ++
> arch/arm64/boot/dts/apple/t602x-gpio-pins.dtsi | 81 +
> arch/arm64/boot/dts/apple/t602x-j414-j416.dtsi | 45 +
> arch/arm64/boot/dts/apple/t602x-j474-j475.dtsi | 38 +
> arch/arm64/boot/dts/apple/t602x-nvme.dtsi | 42 +
> arch/arm64/boot/dts/apple/t602x-pmgr.dtsi | 2268 ++++++++++++++++++++
> drivers/clk/clk-apple-nco.c | 1 +
> drivers/dma/apple-admac.c | 1 +
> drivers/mfd/macsmc.c | 1 +
> drivers/nvme/host/apple.c | 1 +
> drivers/pinctrl/pinctrl-apple-gpio.c | 1 +
> drivers/pmdomain/apple/pmgr-pwrstate.c | 1 +
> drivers/spi/spi-apple.c | 1 +
> drivers/spmi/spmi-apple-controller.c | 1 +
> drivers/watchdog/apple_wdt.c | 1 +
> sound/soc/apple/mca.c | 1 +
> 54 files changed, 4722 insertions(+), 113 deletions(-)
> ---
> base-commit: 50ee15a27ec4cc41e99ee5e9011de7875569cd52
> change-id: 20250811-dt-apple-t6020-1359ce9bf2e7
> prerequisite-change-id: 20250813-apple-dt-sync-6-17-d1fc1c89f7ca:v2
> prerequisite-patch-id: 1405c7c78139704a4cbeb1adc67786b2c7971a3f
> prerequisite-patch-id: 65865050e9e7427bac04f47d0b7927aacaac19bd
> prerequisite-patch-id: 9240e5f435fb3406e77b4e4e9b02eb3d52e660e6
> prerequisite-patch-id: c16715c9a9fcb396b7e4365fd767b05604b8de81
> prerequisite-patch-id: a675ad20c2b427a021dafb5d6c8716497741604c
>
> Best regards,
> --
> Janne Grunau <j@jannau.net>
>
On Thu, Sep 04, 2025 at 12:41:58PM +0200, Ulf Hansson wrote:
> On Thu, 28 Aug 2025 at 16:01, Janne Grunau <j@jannau.net> 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.
> >
> > The series adds those fallback compatibles to drivers where necessary,
> > annotates the SoC lists for generic compatibles as "do not extend" and
> > adds t6020 per-SoC compatibles.
> >
> > [1]: https://lore.kernel.org/linux-pci/20250819-pci-pwrctrl-perst-v1-0-4b74978d2007@oss.qualcomm.com/
> > [2]: https://lore.kernel.org/asahi/20250823-apple-dt-sync-6-17-v2-0-6dc0daeb4786@jannau.net/
> > [3]: https://lore.kernel.org/asahi/20250821-apple-dart-4levels-v2-0-e39af79daa37@jannau.net/
> > [4]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
> >
> > Signed-off-by: Janne Grunau <j@jannau.net>
>
> Is it okay for me to pick up the pmdomain patches (patch3 and patch4)
> by now - or what route are you planning to get this merged through?
Sorry, I forgot to mention the merge strategy in the cover letter. I've
picking up all acked patches that are not yet picked up and we'll merge
them through the apple-soc tree.
This includes all dt-binding patches, patch4.
Feel free to pick up or ack patch3
Janne
On Thu, 28 Aug 2025 16:01:19 +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.
>
> [...]
Applied to git@github.com:AsahiLinux/linux.git (apple-soc/drivers-6.18), thanks!
[03/37] pmdomain: apple: Add "apple,t8103-pmgr-pwrstate"
https://github.com/AsahiLinux/linux/commit/442816f97a4f
Best regards,
--
Sven Peter <sven@kernel.org>
On Thu, 28 Aug 2025 16:01:19 +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.
>
> [...]
Applied, thanks!
[02/37] dt-bindings: arm: apple: apple,pmgr: Add t6020-pmgr compatible
commit: 27ac175609b31853a336917f9596024589989d4c
[04/37] dt-bindings: power: apple,pmgr-pwrstate: Add t6020 compatible
commit: 9ee3fa4f1dd03ba24be886fcde82286b38378121
[05/37] dt-bindings: cpufreq: apple,cluster-cpufreq: Add t6020 compatible
commit: 46d7b4c16ee7afc67e21c1044d22ec197e5a3498
[06/37] dt-bindings: interrupt-controller: apple,aic2: Add apple,t6020-aic compatible
commit: d45bed97401a3b76c968ec08f0292220e32ab852
[07/37] dt-bindings: iommu: dart: Add apple,t6020-dart compatible
commit: d248111a13852e9823300060f07fefce3ccf3c2a
[08/37] pinctrl: apple: Add "apple,t8103-pinctrl" as compatible
commit: 100896ab413284dcf77340c114bafffb96f6fd14
[09/37] dt-bindings: pinctrl: apple,pinctrl: Add apple,t6020-pinctrl compatible
commit: 1b70bfcc576eb8007c003f285c5834ec7cf1beba
[11/37] dt-bindings: mailbox: apple,mailbox: Add t6020 compatible
commit: b4958f928e0d587bd35318a72bdf6a8df8387933
[12/37] dt-bindings: gpu: apple,agx: Add agx-{g14s,g14c,g14d} compatibles
commit: 49d7ce3ca93ea90110d334f4f8ce2f68a3536475
[13/37] dt-bindings: iommu: apple,sart: Add apple,t6020-sart compatible
commit: a93d0de2403a8b1a1686665d5808e4d1d39d5b24
[15/37] dt-bindings: nvme: apple: Add apple,t6020-nvme-ans2 compatible
commit: 1c9e6a0db3a86bf8f99981570f81e9fb1fa33d4a
[16/37] dt-bindings: net: bcm4377-bluetooth: Add BCM4388 compatible
commit: 2ba11087d283d00c7a99b45672d564eb1de872dc
[17/37] dt-bindings: net: bcm4329-fmac: Add BCM4388 PCI compatible
commit: b6b8d3ffaffacdb534c2fc151014b8e7ba382a94
[19/37] dt-bindings: mfd: apple,smc: Add t6020-smc compatible
commit: 306632217c123ef23c917c7348c32ad29599ba15
[22/37] dt-bindings: spmi: apple,spmi: Add t6020-spmi compatible
commit: 155eb6a9838776bd217e8942e5074e3b4bdcb5ff
[24/37] dt-bindings: watchdog: apple,wdt: Add t6020-wdt compatible
commit: bb7a2260fea3f637afafecaae9478c93211f9e8f
[26/37] dt-bindings: clock: apple,nco: Add t6020-nco compatible
commit: c7c5be895e32299f38035b6c05fa68a7d5c57a50
[28/37] dt-bindings: dma: apple,admac: Add t6020-admac compatible
commit: a90183490c54bf793cabb5b54b30cc40b24ce129
[30/37] ASoC: dt-bindings: apple,mca: Add t6020-mca compatible
commit: ae45b991c9f76e8988b7d3bb4b39e4b7c73dceb7
[29/37] ASoC: apple: mca: Add "apple,t8103-mca" compatible
commit: 186b1b4b5b3d40ea53d739aa025c3a9f8cb37f4c
Best regards,
--
Janne Grunau <j@jananu.net>
© 2016 - 2025 Red Hat, Inc.