Re: [PATCH 00/37] arm64: Add initial device trees for Apple M2 Pro/Max/Ultra devices

[Nick Chan <towinchenmi@gmail.com>]

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