From: Christian Marangi <ansuelsmth@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Antoine Tenart <atenart@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
Richard van Schagen <vschagen@icloud.com>,
linux-crypto@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
Date: Thu, 17 Oct 2024 14:29:58 +0200 [thread overview]
Message-ID: <6711034a.050a0220.1ed172.7fa9@mx.google.com> (raw)
In-Reply-To: <dg346xguo5cjx6yotnrdpjyp7n7wwpwnrjvybrrbocekhltpmg@s2j734wd2rnf>
On Thu, Oct 17, 2024 at 10:23:54AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Oct 17, 2024 at 02:43:18AM +0200, Christian Marangi wrote:
> +
> > +description: |
> > + The Inside Secure SafeXcel EIP-93 is a cryptographic engine IP block
> > + integrated in varios devices with very different and generic name from
> > + PKTE to simply vendor+EIP93. The real IP under the hood is actually
> > + developed by Inside Secure and given to license to vendors.
> > +
> > + The IP block is sold with different model based on what feature are
> > + needed and are identified with the final letter. Each letter correspond
> > + to a specific set of feature and multiple letter reflect the sum of the
> > + feature set.
>
> You write it is licensed to vendors, so are you sure these could be
> used alone, without vendor customizations/hookups etc? I think you
> should have a dedicated, SoC-specific compatible in the front. I am not
> sure if this was discussed already, though.
Yes in v1, Rob asked some info about the compatible that was
mediatek,mtk-eip93 or airoha,mtk-eip93.
The thing is that from what I checked from different documentation
around, the register map and how the thing works doesn't change across
vendors, what I have seen is at max specific register added that are
outside of the crypto module usage (example debug register for BUS
bandwidth)
Any suggestion on what could be a good compatible? Honestly I'm more
tempted of using this similar to how is done by the new model EIP197.
> > +
> > + EIP-93 models:
> > + - EIP-93i: (basic) DES/Triple DES, AES, PRNG, IPsec ESP, SRTP, SHA1
> > + - EIP-93ie: i + SHA224/256, AES-192/256
> > + - EIP-93is: i + SSL/DTLS/DTLS, MD5, ARC4
> > + - EIP-93ies: i + e + s
> > + - EIP-93iw: i + AES-XCB-MAC, AES-CCM
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - inside-secure,safexcel-eip93i
> > + - inside-secure,safexcel-eip93ie
> > + - inside-secure,safexcel-eip93is
> > + - inside-secure,safexcel-eip93ies
> > + - inside-secure,safexcel-eip93iw
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > + crypto@1e004000 {
> > + compatible = "inside-secure,safexcel-eip93ies";
> > + reg = <0x1fb70000 0x1000>;
>
> Looks like not matching unit address.
>
Yes sorry a typo, will fix in v3.
--
Ansuel
next prev parent reply other threads:[~2024-10-17 12:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 0:43 [RFC PATCH v2 1/3] spinlock: extend guard with spinlock_bh variants Christian Marangi
2024-10-17 0:43 ` [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine Christian Marangi
2024-10-17 8:23 ` Krzysztof Kozlowski
2024-10-17 12:29 ` Christian Marangi [this message]
2024-10-17 12:48 ` Rob Herring
2024-10-17 12:55 ` Christian Marangi
2024-10-17 12:38 ` Rob Herring
2024-10-17 12:58 ` Christian Marangi
2024-10-17 0:43 ` [RFC PATCH v2 3/3] crypto: Add Mediatek EIP-93 crypto engine support Christian Marangi
2024-10-20 10:23 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6711034a.050a0220.1ed172.7fa9@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=atenart@kernel.org \
--cc=boqun.feng@gmail.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=vschagen@icloud.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.