linux-kernel - Re: [PATCH RFT] arm64: dts: qcom: sm6125: fix SDHCI CQE reg names

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ab0e97a3-ec83-78f2-921a-813a647855f5@linaro.org>
Date:   Tue, 12 Jul 2022 08:53:50 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Martin Botka <martin.botka@...ainline.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        Bhupesh Sharma <bhupesh.sharma@...aro.org>
Subject: Re: [PATCH RFT] arm64: dts: qcom: sm6125: fix SDHCI CQE reg names

On 11/07/2022 16:57, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jul 11, 2022 at 1:26 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> SM6125 comes with SDCC (SDHCI controller) v5, so the second range of
>> registers is cqhci, not core.
>>
>> Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125")
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>
>> ---
>>
>> Not tested on hardware, but no practical impact is expected, because
>> supports-cqe is not defined.
> 
> Maybe the schema should enforce this? If "cqhci" is in reg-names then
> you must have supports-cqe and vice versa?

I have mixed feelings about this. First, I don't know why support-cqe
was not enabled on all devices but only in some DTS (this does not look
like a property of a board but SoC). Second, cqhci address space might
be present in all devices, even if they do not use CQE.
> 
> 
>> ---
>>  arch/arm64/boot/dts/qcom/sm6125.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
>> index 77bff81af433..7664ef7e4da9 100644
>> --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
>> @@ -438,7 +438,7 @@ rpm_msg_ram: sram@...0000 {
>>                 sdhc_1: mmc@...4000 {
>>                         compatible = "qcom,sm6125-sdhci", "qcom,sdhci-msm-v5";
>>                         reg = <0x04744000 0x1000>, <0x04745000 0x1000>;
>> -                       reg-names = "hc", "core";
>> +                       reg-names = "hc", "cqhci";
> 
> Another possible fix would be to just delete the second register
> range. Then it could be added back in once "supports-cqe" was added.

True, but I assume that second address range is there for complete
hardware description.


Best regards,
Krzysztof