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]
Date:   Mon, 27 Mar 2023 10:57:41 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Alex Elder <elder@...e.org>, Krzysztof Kozlowski <krzk@...nel.org>,
        Alex Elder <elder@...aro.org>, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, andersson@...nel.org,
        agross@...nel.org
Cc:     quic_rohiagar@...cinc.com, caleb.connolly@...aro.org,
        mka@...omium.org, evgreen@...omium.org, quic_cpratapa@...cinc.com,
        quic_avuyyuru@...cinc.com, quic_jponduru@...cinc.com,
        quic_subashab@...cinc.com, elder@...nel.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] ARM: dts: qcom: sdx65: add IPA information



On 26.03.2023 18:04, Alex Elder wrote:
> On 3/25/23 7:12 AM, Konrad Dybcio wrote:
>>
>>
>> On 25.03.2023 12:14, Krzysztof Kozlowski wrote:
>>> On 24/03/2023 21:15, Alex Elder wrote:
>>>> Add IPA-related nodes and definitions to "sdx65.dtsi".  The SMP2P
>>>> nodes (ipa_smp2p_out and ipa_smp2p_in) are already present.
>>>>
>>>> Enable IPA in "sdx65-mtp.dts"; this GSI firmware is loaded by Trust
>>>> Zone on this platform.
>>>>
>>>> Tested-by: Rohit Agarwal <quic_rohiagar@...cinc.com>
>>>> Signed-off-by: Alex Elder <elder@...aro.org>
>>>> ---
>>>>   arch/arm/boot/dts/qcom-sdx65-mtp.dts |  5 ++++
>>>>   arch/arm/boot/dts/qcom-sdx65.dtsi    | 38 ++++++++++++++++++++++++++++
>>>>   2 files changed, 43 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/qcom-sdx65-mtp.dts b/arch/arm/boot/dts/qcom-sdx65-mtp.dts
>>>> index ed98c83c141fc..72e25de0db5fc 100644
>>>> --- a/arch/arm/boot/dts/qcom-sdx65-mtp.dts
>>>> +++ b/arch/arm/boot/dts/qcom-sdx65-mtp.dts
>>>> @@ -245,6 +245,11 @@ &blsp1_uart3 {
>>>>       status = "okay";
>>>>   };
>>>>   +&ipa {
>>>> +    qcom,gsi-loader = "skip";
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>>   &qpic_bam {
>>>>       status = "okay";
>>>>   };
>>>> diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi b/arch/arm/boot/dts/qcom-sdx65.dtsi
>>>> index 192f9f94bc8b4..360d6dc144811 100644
>>>> --- a/arch/arm/boot/dts/qcom-sdx65.dtsi
>>>> +++ b/arch/arm/boot/dts/qcom-sdx65.dtsi
>>>> @@ -11,6 +11,7 @@
>>>>   #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>   #include <dt-bindings/power/qcom-rpmpd.h>
>>>>   #include <dt-bindings/soc/qcom,rpmh-rsc.h>
>>>> +#include <dt-bindings/interconnect/qcom,sdx65.h>
>>>>     / {
>>>>       #address-cells = <1>;
>>>> @@ -299,6 +300,43 @@ tcsr_mutex: hwlock@...0000 {
>>>>               #hwlock-cells = <1>;
>>>>           };
>>>>   +        ipa: ipa@...4000 {
>>>> +            compatible = "qcom,sdx65-ipa";
>>>> +
>>>> +            iommus = <&apps_smmu 0x5e0 0x0>,
>>>> +                 <&apps_smmu 0x5e2 0x0>;
>>>> +            reg = <0x3f40000 0x10000>,
>>>> +                  <0x3f50000 0x5000>,
>>>> +                  <0x3e04000 0xfc000>;
>>>> +            reg-names = "ipa-reg",
>>>> +                    "ipa-shared",
>>>> +                    "gsi";
>>>> +
>>>> +            interrupts-extended = <&intc GIC_SPI 241 IRQ_TYPE_EDGE_RISING>,
>>>> +                          <&intc GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
>>>> +                          <&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
>>>> +                          <&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>;
>>>> +            interrupt-names = "ipa",
>>>> +                       "gsi",
>>>> +                       "ipa-clock-query",
>>>> +                       "ipa-setup-ready";
>>>
>>> These look misaligned.
>>>
>>> With above:
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzk@...nel.org>
>> With this and moving iommus below interconnect:
> 
> Is there guidance somewhere that states what order should be
> used for these properties?
This is a very slippery topic, but..

 Why should iommus be below
> interconnects?
..everybody agrees iommus shouldn't between compatible and
reg (these two go first hand-in-hand) and most of our DTs
have it somewhere low, often below interconnect.

In a perfect world we'd have a computer taking care of this
but for now it remains an open question.

> 
> As I said to Krzysztof, I *think* all of the IPA nodes look
> like this; should all of them be updated to follow whatever
> the preferred convention is?
This is the ugly part of this, we don't have a solid,
widely-agreed-upon scheme of ordering properties other than
some loose guidelines (e.g. compatible, reg, ...,  status),
so I think it's not worth making extra noise in existing files
until figure it out.

Konrad
> 
> Thanks.
> 
>                     -Alex
> 
> 
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>>
>> Konrad
>>>
>>>
>>> Best regards,
>>> Krzysztof
>>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ