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] [day] [month] [year] [list]
Date:   Thu, 22 Jul 2021 23:04:01 +0530
From:   Sibi Sankar <sibis@...eaurora.org>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     bjorn.andersson@...aro.org, mka@...omium.org, robh+dt@...nel.org,
        saiprakash.ranjan@...eaurora.org, will@...nel.org, ohad@...ery.com,
        agross@...nel.org, mathieu.poirier@...aro.org,
        robin.murphy@....com, joro@...tes.org, p.zabel@...gutronix.de,
        linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, evgreen@...omium.org,
        dianders@...omium.org
Subject: Re: [PATCH v2 10/10] arm64: dts: qcom: sc7280: Update Q6V5 MSS node

On 2021-07-22 04:23, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-07-21 10:16:14)
>> On 2021-07-21 11:17, Stephen Boyd wrote:
>> > Quoting Sibi Sankar (2021-07-20 03:13:00)
>> >
>> >> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> >> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> >> index 56ea172f641f..6d3687744440 100644
>> >> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> >> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> >> @@ -586,7 +586,8 @@
>> >>
>> >>                 remoteproc_mpss: remoteproc@...0000 {
>> >>                         compatible = "qcom,sc7280-mpss-pas";
>> >> -                       reg = <0 0x04080000 0 0x10000>;
>> >> +                       reg = <0 0x04080000 0 0x10000>, <0 0x04180000
>> >> 0 0x48>;
>> >> +                       reg-names = "qdsp6", "rmb";
>> >>
>> >>                         interrupts-extended = <&intc GIC_SPI 264
>> >> IRQ_TYPE_EDGE_RISING>,
>> >>                                               <&modem_smp2p_in 0
>> >> IRQ_TYPE_EDGE_RISING>,
>> >> @@ -597,8 +598,11 @@
>> >>                         interrupt-names = "wdog", "fatal", "ready",
>> >> "handover",
>> >>                                           "stop-ack", "shutdown-ack";
>> >>
>> >> -                       clocks = <&rpmhcc RPMH_CXO_CLK>;
>> >> -                       clock-names = "xo";
>> >> +                       clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
>> >> +                                <&gcc GCC_MSS_OFFLINE_AXI_CLK>,
>> >> +                                <&gcc GCC_MSS_SNOC_AXI_CLK>,
>> >> +                                <&rpmhcc RPMH_CXO_CLK>;
>> >> +                       clock-names = "iface", "offline", "snoc_axi",
>> >> "xo";
>> >>
>> >>                         power-domains = <&rpmhpd SC7280_CX>,
>> >>                                         <&rpmhpd SC7280_MSS>;
>> >> @@ -611,6 +615,15 @@
>> >>                         qcom,smem-states = <&modem_smp2p_out 0>;
>> >>                         qcom,smem-state-names = "stop";
>> >>
>> >> +                       resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
>> >> +                                <&pdc_reset PDC_MODEM_SYNC_RESET>;
>> >> +                       reset-names = "mss_restart", "pdc_reset";
>> >> +
>> >> +                       qcom,halt-regs = <&tcsr_mutex 0x23000 0x25000
>> >> 0x28000 0x33000>;
>> >> +                       qcom,ext-regs = <&tcsr_regs 0x10000 0x10004
>> >> +                                        &tcsr_mutex 0x26004 0x26008>;
>> >> +                       qcom,qaccept-regs = <&tcsr_mutex 0x23030
>> >> 0x23040 0x23020>;
>> >> +
>> >>                         status = "disabled";
>> >>
>> >>                         glink-edge {
>> >
>> > Any reason to not combine this stuff with the previous patch?
>> 
>> I split it into two separate
>> patches just to show that sc7280
>> supports two ways of bringing
>> modem out of reset and method
>> used is determined by the platform.
>> 
> 
> Ok. But if there are two methods do they work with the same node in
> sc7280.dtsi? Because I was expecting to see the node introduced in the
> SoC dtsi file in the final form instead of the half form and then be
> amended in this patch.

Board files enables the mss node
and overloads the compatible depending
on the platform it is expected to
run on. So pretty much the same
node with just changing the compatible
and few additional properties support
both methods. Patch 9 is complete in
itself i.e. it is compliant with
the pas yaml, while patch 10 adds
the bits required to make alternate
method work.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ