linux-kernel - Re: [PATCH 00/53] icc-rpmh multi-RSC voting groundwork

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, 15 Sep 2023 15:43:27 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Mike Tipton <quic_mdtipton@...cinc.com>
Cc:     Georgi Djakov <djakov@...nel.org>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        cros-qcom-dts-watchers@...omium.org,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/53] icc-rpmh multi-RSC voting groundwork

On 14.09.2023 04:32, Mike Tipton wrote:
> On Wed, Sep 13, 2023 at 10:31:49AM +0200, Konrad Dybcio wrote:
>>> The applicable voters should likely be defined in the target-specific
>>> headers, rather than the common qcom,icc.h. The bit range used for them
>>> could be common, but each target may only support a small subset of the
>>> total set of possible voters across all targets.
>> I'm not sure how client drivers would then choose the
>> correct path other than
>>
>> switch (soc) {
>> case 8450:
>> 	tag = QCOM_ICC_TAG_VOTER_8450_HLOS;
>> 	break;
>> case 8550:
>> 	tag = QCOM_ICC_TAG_VOTER_8550_HLOS;
>> 	break;
>> ...
>> }
>>
>> which would be unacceptable.
> 
> The same general way it's handled for the endpoint bindings, which are
> already target-specific. 
> 
> Any client drivers hardcoding the endpoint bindings in their driver
> would have to include the appropriate, target-specific binding header
> (e.g. qcom,sm8550-rpmh.h). That would only be possible if their driver
> file is itself target-specific. Otherwise, it would have to pull the
> endpoint bindings from devicetree. Or just use the recommended
> of_icc_get() and let devicetree do everything for them. Same for the
> target-specific voter tag bindings.
> 
> Clients can also specify their tags in devicetree. They don't actually
> have to call icc_set_tag() directly. For example:
> 
>     #include <dt-bindings/interconnect/qcom,sm8450.h>
> 
>     interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_VOTER_DISP
>                      &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_VOTER_DISP>;
> 
> Then when they call of_icc_get() for this path it'll automatically have
> QCOM_ICC_TAG_VOTER_DISP set for them.
I think I'd skew towards the "define everything in the DT" approach.

One thing that makes me uneasy to go on with this approach is the
question whether there is a case in which we would want to switch
from e.g. voting through DISP to voting through APPS (or similar)
from within a single device.

Konrad