linux-kernel - Re: [PATCH 1/2] dt-bindings: crypto: update ccree optional params

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-next>] [day] [month] [year] [list]

Date:   Mon, 16 Nov 2020 12:54:40 -0600
From:   Rob Herring <robh@...nel.org>
To:     Gilad Ben-Yossef <gilad@...yossef.com>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Ofir Drang <ofir.drang@....com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux kernel mailing list <linux-kernel@...r.kernel.org>,
        Robin Murphy <Robin.Murphy@....com>,
        Steven Price <steven.price@....com>
Subject: Re: [PATCH 1/2] dt-bindings: crypto: update ccree optional params

On Thu, Oct 22, 2020 at 1:18 AM Gilad Ben-Yossef <gilad@...yossef.com> wrote:
>
>
> Hi again,
>
> Any opinion on the suggested below?

Sorry, lost in the pile...

> Thanks!
> Gilad
>
>
> On Tue, Sep 29, 2020 at 9:08 PM Gilad Ben-Yossef <gilad@...yossef.com> wrote:
>>
>>
>> On Wed, Sep 23, 2020 at 4:57 AM Rob Herring <robh@...nel.org> wrote:
>> >
>> > On Wed, Sep 16, 2020 at 10:19:49AM +0300, Gilad Ben-Yossef wrote:
>> > > Document ccree driver supporting new optional parameters allowing to
>> > > customize the DMA transactions cache parameters and ACE bus sharability
>> > > properties.
>> > >
>> > > Signed-off-by: Gilad Ben-Yossef <gilad@...yossef.com>
>> > > ---
>> > >  Documentation/devicetree/bindings/crypto/arm-cryptocell.txt | 4 ++++
>> > >  1 file changed, 4 insertions(+)
>> > >
>> > > diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
>> > > index 6130e6eb4af8..1a1603e457a8 100644
>> > > --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
>> > > +++ b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
>> > > @@ -13,6 +13,10 @@ Required properties:
>> > >  Optional properties:
>> > >  - clocks: Reference to the crypto engine clock.
>> > >  - dma-coherent: Present if dma operations are coherent.
>> > > +- awcache: Set write transactions cache attributes
>> > > +- arcache: Set read transactions cache attributes
>> >
>> > dma-coherent already implies these are 011x, 101x or 111x. In my limited
>> > experience configuring these (Calxeda SATA and ethernet), writeback,
>> > write-allocate was pretty much always optimal.
>>
>> Indeed and these are the default. But not all SoC are born equal and
>> we got a request to allow setting these.
>>
>> Maybe instead of numerical values have three possible verbal setting
>> would be better?
>>
>>
>> > > +- awdomain: Set write transactions ACE sharability domain (712, 703, 713 only)
>> > > +- ardomain: Set read transactions ACE sharability domain (712, 703, 713 only)
>> >
>> > This probably needs something common. We may need something for Mali,
>> > too. I don't think different settings for read and write makes much
>> > sense nor does anything beyond IS or OS.
>>
>> I agree. Maybe
>>
>> sharability_domain: either "IS" or "OS"?

It's still an Arm thing, so it would need at least an 'arm,' prefix.
But ideally it wouldn't be Arm specific though I'm not sure if any
such thing is needed for other arches. If common either for Arm or
across arches, then it needs to be documented in a common doc with
some wider agreement than what a device specific property needs.

>> > These could also just be implied by the compatible string (and requiring
>> > an SoC specific one).
>>
>> hm... we could do it but this will require us to know (and publicly
>> acknowledge) of every SoC making use of this piece of hardware design.

That's already a requirement in general. Sometimes we can avoid it,
but that's cases of getting lucky.

>> There is currently no other part of the driver that needs this.

If your DT is part of firmware, then waiting until adding some driver
feature or quirk based on a new DT property is too late. Whereas with
a SoC specific compatible, you can handle any new feature or quirk
without a DT change (e.g. just a stable kernel update). Some platforms
may not care about that model, but in general that's the policy we
follow. Not doing that, we end up with the DWC3 binding.

A fallback compatible is how we avoid updating drivers for every
single SoC unless needed.

Rob