linux-kernel - Re: [PATCH v4 2/5] dt-bindings: soc: qcom: eud: Add SM6115 / SM4250 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]

Date:   Fri, 5 May 2023 19:54:52 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Bhupesh Sharma <bhupesh.sharma@...aro.org>
Cc:     linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-usb@...r.kernel.org, agross@...nel.org, andersson@...nel.org,
        konrad.dybcio@...aro.org, linux-kernel@...r.kernel.org,
        bhupesh.linux@...il.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org
Subject: Re: [PATCH v4 2/5] dt-bindings: soc: qcom: eud: Add SM6115 / SM4250
 support

On 05/05/2023 18:27, Bhupesh Sharma wrote:
> Hi Krzysztof,
> 
> On Fri, 5 May 2023 at 21:54, Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> On 05/05/2023 08:40, Bhupesh Sharma wrote:
>>> Add dt-bindings for EUD found on Qualcomm SM6115 / SM4250 SoC.
>>>
>>> On this SoC (and derivatives) the enable bit inside 'tcsr_check_reg'
>>> needs to be set first to 'enable' the eud module.
>>>
>>> So, update the dt-bindings to accommodate the third register
>>> property (TCSR Base) required by the driver on these SoCs.
>>>
>>> Also for these SoCs, introduce a new bool property
>>> 'qcom,secure-mode-enable', which indicates that the mode manager
>>> needs to be accessed only via the secure world.
>>
>> Cannot it be implied by compatible?
> 
> I can see this will be used by future SoCs as well from the available
> EUD documentation.
> 
> So let's keep a dedicated dt property as suggested by Bjorn in earlier
> reviews, as otherwise the compatible checks would start getting bigger
> / messier in the driver code, in my opinion, when we add EUD support
> for other SoCs + boards.

I don't understand the last part about compatible checks would grow. Why
would you have any compatible check in the driver? This looks standard
as we do with all SoC properties, so via driver data.

Best regards,
Krzysztof