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]
Message-ID: <9aece4ec-6a14-ea73-fe9c-5f097a018354@codeaurora.org>
Date:   Wed, 29 Apr 2020 15:25:13 +0530
From:   Sharat Masetty <smasetty@...eaurora.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     freedreno <freedreno@...ts.freedesktop.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, dri-devel@...edesktop.org,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Rob Herring <robh@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
        Jordan Crouse <jcrouse@...eaurora.org>, tdas@...eaurora.org
Subject: Re: [PATCH] dt-bindings: arm-smmu: Add a new compatible string and a
 clock


On 4/29/2020 3:57 AM, Doug Anderson wrote:
> Hi,
>
> On Tue, Apr 28, 2020 at 4:39 AM Sharat Masetty <smasetty@...eaurora.org> wrote:
>> This patch adds a new compatible string for sc7180 and also an
>> additional clock listing needed to power the TBUs and the TCU.
>>
>> Signed-off-by: Sharat Masetty <smasetty@...eaurora.org>
>> ---
>>   Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 7 +++++++
>>   1 file changed, 7 insertions(+)
> nit: mention sc7180 in subject, like:
>
> dt-bindings: arm-smmu: Add sc7180 compatible string and mem_iface clock
>
>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index 6515dbe..15946ac 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -28,6 +28,7 @@ properties:
>>             - enum:
>>                 - qcom,msm8996-smmu-v2
>>                 - qcom,msm8998-smmu-v2
>> +              - qcom,sc7180-smmu-v2
>>                 - qcom,sdm845-smmu-v2
>>             - const: qcom,smmu-v2
>>
>> @@ -113,16 +114,22 @@ properties:
>>         present in such cases.
>>
>>     clock-names:
>> +    minItems: 2
>> +    maxItems: 3
>>       items:
>>         - const: bus
>>         - const: iface
>> +      - const: mem_iface_clk
> People usually frown on clock-names ending in "_clk".  Just name it "mem_iface".
>
>
>>     clocks:
>> +    minItems: 2
>> +    maxItems: 3
>>       items:
>>         - description: bus clock required for downstream bus access and for the
>>             smmu ptw
>>         - description: interface clock required to access smmu's registers
>>             through the TCU's programming interface.
>> +      - description: clock required for the SMMU TBUs and the TCU
> Is this clock only needed for sc7180, or would it be useful if we
> enabled certain features on existing devices?  Please document exactly
> when someone would provide this clock and when they'd leave it off.
>
> ...also: maybe it's obvious to those that understand IOMMUs in depth,
> but to me I have no idea what your description means and why it's
> different from the other two clocks.  Any way you could punch up your
> description a little bit?
>
> Looking at sdm845 I see that this clock seems to exist but wasn't
> listed in the IOMMU device tree node.  Is that a mistake on sdm845?
> ...or is it just fine because the GPU holds the clock?  Is there a
> reason the sdm845 solution and the sc7180 solution shouldn't be the
> same (AKA we should either add this clock to the sdm845 device tree
> file or remove it from sc7180)?

I went and checked the downstream SDM845 device tree for GPU SMMU and I 
do see this clock listed on there. I am no expert in SMMU either but my 
understanding is that this clock is needed for core working of the SMMU 
like the pagetable walks, TLB invalidations etc, whereas the other two 
clocks are required to access SMMU register space from the host.My 
proposal is to add this clock to SDM845 as well as a follow up effort so 
that we can remove the Min/MaxItems properties which I do not like.

@Jordan, do you remember why this clock was added to SDM845?

> Thanks!
>
> -Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ