linux-kernel - Re: [PATCH v2 2/4] arm64: dts: apple: t8103: Add MCA and its support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ae5a10b8-a459-11c9-3fac-4f5de0ba2218@linaro.org>
Date:   Tue, 23 Aug 2022 14:02:43 +0300
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Martin Povišer <povik+lin@...ebit.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        asahi@...ts.linux.dev, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/4] arm64: dts: apple: t8103: Add MCA and its support

On 19/08/2022 17:24, Martin Povišer wrote:
> 
> 
>> On 19. 8. 2022, at 15:12, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> wrote:
>>
>> On 19/08/2022 15:54, Martin Povišer wrote:
>>> Add the MCA I2S transceiver node and its supporting NCO, ADMAC nodes.
>>>
>>> Signed-off-by: Martin Povišer <povik+lin@...ebit.org>
>>> ---
>>> arch/arm64/boot/dts/apple/t8103.dtsi | 70 ++++++++++++++++++++++++++++
>>> 1 file changed, 70 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi
>>> index 51a63b29d404..2dc3125aca5b 100644
>>> --- a/arch/arm64/boot/dts/apple/t8103.dtsi
>>> +++ b/arch/arm64/boot/dts/apple/t8103.dtsi
>>> @@ -532,6 +532,76 @@ port02: pci@2,0 {
>>> 						<0 0 0 4 &port02 0 0 0 3>;
>>> 			};
>>> 		};
>>> +
>>> +		dart_sio: iommu@...004000 {
>>> +			compatible = "apple,t8103-dart", "apple,dart";
>>> +			reg = <0x2 0x35004000 0x0 0x4000>;
>>> +			interrupt-parent = <&aic>;
>>> +			interrupts = <AIC_IRQ 635 IRQ_TYPE_LEVEL_HIGH>;
>>> +			#iommu-cells = <1>;
>>> +			power-domains = <&ps_sio_cpu>;
>>> +		};
>>> +
>>> +		nco_clkref: clock-ref {
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>;
>>> +			clock-frequency = <900000000>;
>>> +			clock-output-names = "nco_ref";
>>> +		};
>>
>> Reference clocks are usually physically outside of SoC (e.g. on the
>> board), so:
>> 1. Not part of "soc" node.
>> 2. It should be defined by board. At least clock-frequency should be there.
> 
> Ah, right, this deserves commentary: Since this is a reverse-engineered
> driver/platform support, we give up on knowing the clock tree exactly. Instead
> we model the clock input to the Numerically Controlled Oscillator (‘nco’ node
> below) with this fabulated fixed clock reference.
> 
> I guess eventually the clock tree is rooted off the SoC, and there’s
> nothing guaranteeing the same reference clock to the NCO across machines (being
> function of the board wiring and the proprietary firmware). In the end I would
> argue for keeping the ‘clock-ref’ here in ’soc' but have the clock-frequency
> defined by board.  Sounds reasonable?

Yes.

Best regards,
Krzysztof