linux-kernel - Re: [PATCH v5 3/3] arm64: dts: qcom: Add base qcs6490-rb3gen2 board dts

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:   Thu, 23 Nov 2023 19:46:22 +0530
From:   Komal Bajaj <quic_kbajaj@...cinc.com>
To:     Caleb Connolly <caleb.connolly@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>
CC:     <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Naina Mehta <quic_nainmeht@...cinc.com>
Subject: Re: [PATCH v5 3/3] arm64: dts: qcom: Add base qcs6490-rb3gen2 board
 dts

Please ignore if received twice.

On 11/20/2023 8:17 PM, Caleb Connolly wrote:
> 
> 
> On 20/11/2023 13:47, Komal Bajaj wrote:
>> Add DTS for Qualcomm qcs6490-rb3gen2 board which uses
>> QCS6490 SoC. This adds debug uart and usb support along
>> with regulators found on this board.
> 
> Hi,
> 
> I understand there was a lot of previous discussion around these two
> boards, sorry to be bringing it up again here, but I have a few more
> questions.
> 
> How similar are these two boards in terms of design? If they're derived
> from the same reference schematic then I think this is a good
> justification to de-duplicate the common DTS parts.

These two are different boards and they don't follow same schema.

> 
> Dropping them in a diff tool [1] it seems as though the only changes are
> the modem reserved memory for the IDP board, some minor regulator
> changes, and the sdcard on the IDP board being enabled. However it's
> important to differentiate between these just, being the same, vs them
> being based on the same reference design.

As I said in the other thread[1], the only difference between these two
boards is just the memory map, we can always comeback and do refactor if
there will be more common things to share between these IOT family
platforms.

[1]https://lore.kernel.org/linux-arm-msm/3d8a8943-af70-c291-d2d8-41067d8404f2@quicinc.com/

> 
> I left some comments on the parts that differ between the boards below,
> but basically my question is: do these boards share enough of the same
> *design* that it would make sense to have a "qcm6490-iot.dtsi" file with
> the common reserved memory and regulators?
> 
> The IDP and rb3 boards would then inherit from there, avoiding a lot of
> duplication and weirdness where some boards have certain regulator
> properties that others don't with it being hard to tell if this is
> intentional or not (this is the case with a lot of the existing upstream
> devices).
> 
> On a related note, should we further split the rb3 board into a
> qcs6490-whatever-som.dtsi file which may define the SoM specific parts?
> This would undoubtebly make it easier for other boards based on the same
> SoM to be bought up and kept up to date.
> 
> [1]: https://quickdiff.net/?unique_id=630F6851-C750-839E-1651-4CA6D997A74D
> 
> 

I agree with your comment to have a common qcs6490-som.dtsi, but will do
this once we upstream the other rb boards based this SoM.

> [...]
> 
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> new file mode 100644
>> index 000000000000..f023dcf768f1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> @@ -0,0 +1,410 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
> [...]
>> +
>> +		vreg_l7b_2p952: ldo7 {
> 
> The IDP board defined voltages here for the sdcard, does the rb3 board
> have an sdcard slot (if so which regulator does it use)?
> 
> Is there a reason not to define the same voltage range for this board?

This regulator in IDP board is used for mmc (sdhc_1) and rb3 does not
have it. Although both have sdcard and I have not pushed the support for
it yet. Will add the voltage ranges here as it was a mistake.

>> +			regulator-allow-set-load;
> 
> This property is set for rb3 but not for the idp board, even though this
> regulator is unused, should this be set?

Again this was some downstream hack that got copied. Sorry for this.
Will remove it.

>> +			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM RPMH_REGULATOR_MODE_HPM>;
>> +			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>> +		};
>> +
> [...]
>> +
>> +		vreg_l9b_1p2: ldo9 {
> Same question as above
>> +			regulator-allow-set-load;
> Same question
>> +			regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM RPMH_REGULATOR_MODE_HPM>;
>> +			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>> +		};
>> +
> [...]
>> +		vreg_l19b_1p8: ldo19 {
>> +			regulator-min-microvolt = <1800000>;
>> +			regulator-max-microvolt = <2000000>;
>> +			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> The IDP board has the regulator-allow-set-load property here, as well as
> regulator-allowed-modes. This regulator is used for the sdcard on that
> board. Is it used for anything on rb3? Can these properties be the same?

As explained above, this property is used for mmc and not sdcard. As of
now, not used.

Thanks,
Komal.