spinlock: extend guard with spinlock_bh variants
Subsystems (5)
Christian Marangi
maintainerRFC PATCH v2 1/3 spinlock: extend guard with spinlock_bh variants
Extend guard APIs with missing raw/spinlock_bh variants.
--- include/linux/spinlock.h | 13 +++++++++++++ 1 file changed, 13 insertions(+)
include/linux/spinlock.h +13 -0
@@ -550,6 +550,12 @@ DEFINE_LOCK_GUARD_1(raw_spinlock_irq, raw_spinlock_t, DEFINE_LOCK_GUARD_1_COND(raw_spinlock_irq, _try, raw_spin_trylock_irq(_T->lock)) +DEFINE_LOCK_GUARD_1 (raw_spinlock_bh, raw_spinlock_t, +raw_spin_lock_bh (_T->lock), + raw_spin_unlock_bh(_T->lock)) + +DEFINE_LOCK_GUARD_1_COND(raw_spinlock_bh, _try, raw_spin_trylock_bh(_T->lock)) + DEFINE_LOCK_GUARD_1(raw_spinlock_irqsave, raw_spinlock_t, raw_spin_lock_irqsave(_T->lock, _T->flags), raw_spin_unlock_irqrestore(_T->lock, _T->flags),
@@ -571,6 +577,13 @@ DEFINE_LOCK_GUARD_1(spinlock_irq, spinlock_t,DEFINE_LOCK_GUARD_1_COND (spinlock_irq, _try, spin_trylock_irq(_T->lock)) +DEFINE_LOCK_GUARD_1 (spinlock_bh, spinlock_t, +spin_lock_bh (_T->lock), + spin_unlock_bh(_T->lock)) + +DEFINE_LOCK_GUARD_1_COND (spinlock_bh, _try, + spin_trylock_bh(_T->lock)) + DEFINE_LOCK_GUARD_1(spinlock_irqsave, spinlock_t, spin_lock_irqsave(_T->lock, _T->flags), spin_unlock_irqrestore(_T->lock, _T->flags),
Signature · 1 line
2.45.2
Christian Marangi
maintainerRFC PATCH v2 2/3 dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
Add bindings for the Inside Secure SafeXcel EIP-93 crypto engine.
The IP is present on Airoha SoC and on various Mediatek devices and other SoC under different names like mtk-eip93 or PKTE.
---
Changes v2:
- Change to better compatible
- Add description for EIP93 models
.../crypto/inside-secure,safexcel-eip93.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +61 -0
@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/inside-secure,safexcel-eip93.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Inside Secure SafeXcel EIP-93 cryptographic engine + +maintainers: + - Christian Marangi <[email protected]> + +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. + + 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>; + + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + };
Signature · 1 line
2.45.2
Re: [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
On Thu, Oct 17, 2024 at 02:43:18AM +0200, Christian Marangi wrote:
+
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 21
Quoted 10 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +10
-0+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.
Quoted 27 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +27
-0+ + 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
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 58
Quoted 10 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +10
-0+ +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.
Best regards,
Krzysztof
Christian Marangi
maintainerRe: [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
Quoted 17 lines · Krzysztof Kozlowski
On Thu, Oct 17, 2024 at 02:43:18AM +0200, Christian Marangi wrote:
+Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 21
Quoted 10 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +10
-0+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.
Quoted 31 lines
Quoted 31 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +31
-0+ + 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:
Quoted 9 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 58
Quoted 6 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +6
-0+ - | + #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.
Signature · 1 line
Ansuel
Rob Herring
maintainerRe: [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
In reply to Krzysztof KozlowskiQuoted 17 lines · Krzysztof Kozlowski
On Thu, Oct 17, 2024 at 02:43:18AM +0200, Christian Marangi wrote:
+Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 21
Quoted 10 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +10
-0+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.
Probably should, but some reason we haven't on other Inside Secure IP. Perhaps they are just simple enough from a DT perspective to get away without. Also, there may not be any SoC associated with some of these. If there is an SoC, then better to add a compatible to help avoid any future DT changes.
Rob
Christian Marangi
maintainerRe: [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
Quoted 19 lines · Rob Herring
Quoted 17 lines · Krzysztof Kozlowski
On Thu, Oct 17, 2024 at 02:43:18AM +0200, Christian Marangi wrote:
+Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 21
Quoted 10 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +10
-0+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.
Quoted 6 lines
Probably should, but some reason we haven't on other Inside Secure IP. Perhaps they are just simple enough from a DT perspective to get away without. Also, there may not be any SoC associated with some of these. If there is an SoC, then better to add a compatible to help avoid any future DT changes.
Would it be ok to have inside-secure,safexcel-eip93i-mediatek IF some device will require special handling?
Again I expect no vendor to modify how the IP works internally with the descriptor and the common register.
Vendor tag is probably not needed as Vendor are not that crazy to modify a crypto engine IP and cause disaster on the way.
Signature · 1 line
Ansuel
Rob Herring
maintainerRe: [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
In reply to Christian MarangiQuoted 54 lines · Christian Marangi
Add bindings for the Inside Secure SafeXcel EIP-93 crypto engine.
The IP is present on Airoha SoC and on various Mediatek devices and other SoC under different names like mtk-eip93 or PKTE.
Signed-off-by Christian Marangi <[email protected]>---
Changes v2:
- Change to better compatible
- Add description for EIP93 models.../crypto/inside-secure,safexcel-eip93.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yamlDocumentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +33
-0@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/inside-secure,safexcel-eip93.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Inside Secure SafeXcel EIP-93 cryptographic engine + +maintainers: + - Christian Marangi <[email protected]> + +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. + + 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
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 43
Quoted 10 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +10
-0+ - inside-secure,safexcel-eip93ie + - inside-secure,safexcel-eip93is + - inside-secure,safexcel-eip93ies + - inside-secure,safexcel-eip93iw + + reg: + maxItems: 1 + + interrupts: + maxItems: 1
No clocks? All their other IP has clocks.
Quoted 21 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +18
-0+ +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>; + + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + };Signature · 1 line
2.45.2
Christian Marangi
maintainerRe: [RFC PATCH v2 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine
Quoted 60 lines · Rob Herring
Quoted 59 lines · Christian Marangi
Add bindings for the Inside Secure SafeXcel EIP-93 crypto engine.
The IP is present on Airoha SoC and on various Mediatek devices and other SoC under different names like mtk-eip93 or PKTE.
Signed-off-by Christian Marangi <[email protected]>---
Changes v2:
- Change to better compatible
- Add description for EIP93 models.../crypto/inside-secure,safexcel-eip93.yaml | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yamlDocumentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +38
-0@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/inside-secure,safexcel-eip93.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Inside Secure SafeXcel EIP-93 cryptographic engine + +maintainers: + - Christian Marangi <[email protected]> + +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. + + 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 +
Quoted 9 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml line 43
Quoted 5 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +5
-0+ reg: + maxItems: 1 + + interrupts: + maxItems: 1No clocks? All their other IP has clocks.
They are handled internally for each submodule. From the IP side, they can be disabled with some register but in Autonomous mode (the one the driver supports) they are handled automatically.
In short, yes for this "old" IP, no clock.
Quoted 21 lines
Quoted 21 lines
Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file +18
-0+ +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>; + + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + };Signature · 1 line
2.45.2
Signature · 1 line
Ansuel
Christian Marangi
maintainerRFC PATCH v2 3/3 crypto: Add Mediatek EIP-93 crypto engine support
In reply to Christian MarangiAdd support for the Mediatek EIP-93 crypto engine used on MT7621 and new Airoha SoC.
EIP-93 IP supports AES/DES/3DES ciphers in ECB/CBC and CTR modes as well as authenc(HMAC(x), cipher(y)) using HMAC MD5, SHA1, SHA224 and SHA256.
EIP-93 provide regs to signal support for specific chipers and the driver dynamically register only the supported one by the chip.
---
Changes v2:
- Rename all variables from mtk to eip93
- Move to inside-secure directory
- Check DMA map errors
- Use guard API for spinlock
- Minor improvements to code
drivers/crypto/Kconfig | 1 + drivers/crypto/Makefile | 1 + drivers/crypto/inside-secure/eip93/Kconfig | 20 + drivers/crypto/inside-secure/eip93/Makefile | 5 + .../crypto/inside-secure/eip93/eip93-aead.c | 702 ++++++++++++++ .../crypto/inside-secure/eip93/eip93-aead.h | 38 + .../crypto/inside-secure/eip93/eip93-aes.h | 16 + .../crypto/inside-secure/eip93/eip93-cipher.c | 407 ++++++++ .../crypto/inside-secure/eip93/eip93-cipher.h | 60 ++ .../crypto/inside-secure/eip93/eip93-common.c | 824 ++++++++++++++++ .../crypto/inside-secure/eip93/eip93-common.h | 25 + .../crypto/inside-secure/eip93/eip93-des.h | 16 + .../crypto/inside-secure/eip93/eip93-hash.c | 909 ++++++++++++++++++ .../crypto/inside-secure/eip93/eip93-hash.h | 72 ++ .../crypto/inside-secure/eip93/eip93-main.c | 502 ++++++++++ .../crypto/inside-secure/eip93/eip93-main.h | 155 +++ .../crypto/inside-secure/eip93/eip93-regs.h | 335 +++++++ 17 files changed, 4088 insertions(+) create mode 100644 drivers/crypto/inside-secure/eip93/Kconfig create mode 100644 drivers/crypto/inside-secure/eip93/Makefile create mode 100644 drivers/crypto/inside-secure/eip93/eip93-aead.c create mode 100644 drivers/crypto/inside-secure/eip93/eip93-aead.h create mode 100644 drivers/crypto/inside-secure/eip93/eip93-aes.h create mode 100644 drivers/crypto/inside-secure/eip93/eip93-cipher.c create mode 100644 drivers/crypto/inside-secure/eip93/eip93-cipher.h create mode 100644 drivers/crypto/inside-secure/eip93/eip93-common.c create mode 100644 drivers/crypto/inside-secure/eip93/eip93-common.h create mode 100644 drivers/crypto/inside-secure/eip93/eip93-des.h create mode 100644 drivers/crypto/inside-secure/eip93/eip93-hash.c create mode 100644 drivers/crypto/inside-secure/eip93/eip93-hash.h create mode 100644 drivers/crypto/inside-secure/eip93/eip93-main.c create mode 100644 drivers/crypto/inside-secure/eip93/eip93-main.h create mode 100644 drivers/crypto/inside-secure/eip93/eip93-regs.h
drivers/crypto/Kconfig +1 -0
@@ -790,5 +790,6 @@ config CRYPTO_DEV_SA2UL source "drivers/crypto/aspeed/Kconfig" source "drivers/crypto/starfive/Kconfig" +source "drivers/crypto/inside-secure/eip93/Kconfig" endif # CRYPTO_HW
drivers/crypto/Makefile +1 -0
@@ -52,3 +52,4 @@ obj-y += hisilicon/ obj-$(CONFIG_CRYPTO_DEV_AMLOGIC_GXL) += amlogic/ obj-y += intel/ obj-y += starfive/ +obj-y += inside-secure/eip93/
drivers/crypto/inside-secure/eip93/Kconfig new file +20 -0
@@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0 +config CRYPTO_DEV_EIP93 + tristate "Support for EIP93 crypto HW accelerators" + depends on SOC_MT7621 || ARCH_AIROHA ||COMPILE_TEST + select CRYPTO_LIB_AES + select CRYPTO_LIB_DES + select CRYPTO_SKCIPHER + select CRYPTO_AEAD + select CRYPTO_AUTHENC + select CRYPTO_MD5 + select CRYPTO_SHA1 + select CRYPTO_SHA256 + help + EIP93 have various crypto HW accelerators. Select this if + you want to use the EIP93 modules for any of the crypto algorithms. + + If the IP supports it, this provide offload for AES - ECB, CBC and + CTR crypto. Also provide DES and 3DES ECB and CBC. + + Also provide AEAD authenc(hmac(x), cipher(y)) for supported algo.
drivers/crypto/inside-secure/eip93/Makefile new file +5 -0
@@ -0,0 +1,5 @@ +obj-$(CONFIG_CRYPTO_DEV_EIP93) += crypto-hw-eip93.o + +crypto-hw-eip93-y += eip93-main.o eip93-common.o +crypto-hw-eip93-y += eip93-cipher.o eip93-aead.o +crypto-hw-eip93-y += eip93-hash.o
drivers/crypto/inside-secure/eip93/eip93-aead.c new file +702 -0
702 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-aead.h new file +38 -0
@@ -0,0 +1,38 @@ +/* SPDX-License-Identifier: GPL-2.0 +* +* Copyright (C) 2019 - 2021 +* +* Richard van Schagen <[email protected]> +* Christian Marangi <[email protected] +*/ +#ifndef _EIP93_AEAD_H_ +#define _EIP93_AEAD_H_ + +extern struct eip93_alg_template eip93_alg_authenc_hmac_md5_cbc_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha1_cbc_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha224_cbc_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha256_cbc_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_md5_ctr_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha1_ctr_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha224_ctr_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha256_ctr_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_md5_rfc3686_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha1_rfc3686_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha224_rfc3686_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha256_rfc3686_aes; +extern struct eip93_alg_template eip93_alg_authenc_hmac_md5_cbc_des; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha1_cbc_des; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha224_cbc_des; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha256_cbc_des; +extern struct eip93_alg_template eip93_alg_authenc_hmac_md5_cbc_des3_ede; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha1_cbc_des3_ede; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha224_cbc_des3_ede; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha256_cbc_des3_ede; +extern struct eip93_alg_template eip93_alg_authenc_hmac_md5_ecb_null; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha1_ecb_null; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha224_ecb_null; +extern struct eip93_alg_template eip93_alg_authenc_hmac_sha256_ecb_null; + +void eip93_aead_handle_result (struct crypto_async_request *async,int err); + +#endif /* _EIP93_AEAD_H_ */
drivers/crypto/inside-secure/eip93/eip93-aes.h new file +16 -0
@@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 +* +* Copyright (C) 2019 - 2021 +* +* Richard van Schagen <[email protected]> +* Christian Marangi <[email protected] +*/ +#ifndef _EIP93_AES_H_ +#define _EIP93_AES_H_ + +extern struct eip93_alg_template eip93_alg_ecb_aes; +extern struct eip93_alg_template eip93_alg_cbc_aes; +extern struct eip93_alg_template eip93_alg_ctr_aes; +extern struct eip93_alg_template eip93_alg_rfc3686_aes; + +#endif /* _EIP93_AES_H_ */
drivers/crypto/inside-secure/eip93/eip93-cipher.c new file +407 -0
407 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-cipher.h new file +60 -0
60 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-common.c new file +824 -0
824 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-common.h new file +25 -0
@@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0 +* +* Copyright (C) 2019 - 2021 +* +* Richard van Schagen <[email protected]> +* Christian Marangi <[email protected] +*/ + +#ifndef _EIP93_COMMON_H_ +#define _EIP93_COMMON_H_ + +#include "eip93-main.h" + +void *eip93_get_descriptor (struct eip93_device *mtk); +int eip93_put_descriptor (struct eip93_device *mtk,struct eip93_descriptor *desc); + +void eip93_set_sa_record (struct sa_record *sa_record,const unsigned int keylen, +const u32 flags); + +int eip93_parse_ctrl_stat_err (struct eip93_device *mtk,int err); + +int eip93_authenc_setkey (struct crypto_aead *aead,struct sa_record *sa, +const u8 *authkey,unsigned int authkeylen); + +#endif /* _EIP93_COMMON_H_ */
drivers/crypto/inside-secure/eip93/eip93-des.h new file +16 -0
@@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 +* +* Copyright (C) 2019 - 2021 +* +* Richard van Schagen <[email protected]> +* Christian Marangi <[email protected] +*/ +#ifndef _EIP93_DES_H_ +#define _EIP93_DES_H_ + +extern struct eip93_alg_template eip93_alg_ecb_des; +extern struct eip93_alg_template eip93_alg_cbc_des; +extern struct eip93_alg_template eip93_alg_ecb_des3_ede; +extern struct eip93_alg_template eip93_alg_cbc_des3_ede; + +#endif /* _EIP93_DES_H_ */
drivers/crypto/inside-secure/eip93/eip93-hash.c new file +909 -0
877 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-hash.h new file +72 -0
72 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-main.c new file +502 -0
502 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-main.h new file +155 -0
155 lines not on this page · raw message
drivers/crypto/inside-secure/eip93/eip93-regs.h new file +335 -0
335 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
2.45.2
Part of the diff is not shown here. View the raw message.
kernel test robot
build botRe: [RFC PATCH v2 3/3] crypto: Add Mediatek EIP-93 crypto engine support
kernel test robot noticed the following build warnings:
Hi Christian,
[This is a private test report for your RFC patch.] kernel test robot noticed the following build warnings:
[auto build test WARNING on herbert-cryptodev-2.6/master]
[also build test WARNING on herbert-crypto-2.6/master tip/locking/core robh/for-next linus/master v6.12-rc3 next-20241018] [If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-Marangi/dt-bindings-crypto-Add-Inside-Secure-SafeXcel-EIP-93-crypto-engine/20241017-084636 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master patch link: https://lore.kernel.org/r/20241017004335.27471-3-ansuelsmth%40gmail.com patch subject: [RFC PATCH v2 3/3] crypto: Add Mediatek EIP-93 crypto engine support config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20241020/[email protected]/config) compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241020/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All warnings (new ones prefixed by >>):
>> drivers/crypto/inside-secure/eip93/eip93-common.c:392:6: warning: variable 'ndesc_cdr' set but not used [-Wunused-but-set-variable]
392 | int ndesc_cdr = 0, err;
| ^
>> drivers/crypto/inside-secure/eip93/eip93-common.c:563:8: warning: variable 'err' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
563 | if (!rctx->sa_state_ctr)
| ^~~~~~~~~~~~~~~~~~~
drivers/crypto/inside-secure/eip93/eip93-common.c:632:9: note: uninitialized use occurs here
632 | return err;
| ^~~
drivers/crypto/inside-secure/eip93/eip93-common.c:563:4: note: remove the 'if' if its condition is always false
563 | if (!rctx->sa_state_ctr)
| ^~~~~~~~~~~~~~~~~~~~~~~~
564 | goto free_sa_state;
| ~~~~~~~~~~~~~~~~~~
drivers/crypto/inside-secure/eip93/eip93-common.c:518:23: note: initialize the variable 'err' to silence this warning
518 | int offsetin = 0, err;
| ^
| = 0
2 warnings generated.
--
>> drivers/crypto/inside-secure/eip93/eip93-hash.c:75:3: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
75 | u32 sha256_init[] = { SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
| ^
drivers/crypto/inside-secure/eip93/eip93-hash.c:81:3: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
81 | u32 sha224_init[] = { SHA224_H0, SHA224_H1, SHA224_H2, SHA224_H3,
| ^
drivers/crypto/inside-secure/eip93/eip93-hash.c:87:3: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
87 | u32 sha1_init[] = { SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4 };
| ^
drivers/crypto/inside-secure/eip93/eip93-hash.c:92:3: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
92 | u32 md5_init[] = { MD5_H0, MD5_H1, MD5_H2, MD5_H3 };
| ^4 warnings generated.
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for MODVERSIONS
Depends on [n]: MODULES [=y] && !COMPILE_TEST [=y]
Selected by [y]:
- RANDSTRUCT_FULL [=y] && (CC_HAS_RANDSTRUCT [=y] || GCC_PLUGINS [=n]) && MODULES [=y]
vim +/ndesc_cdr +392 drivers/crypto/inside-secure/eip93/eip93-common.c
370
371 /*
372 * Poor mans Scatter/gather function:
373 * Create a Descriptor for every segment to avoid copying buffers.
374 * For performance better to wait for hardware to perform multiple DMA
375 */
376 static int eip93_scatter_combine(struct eip93_device *mtk,
377 struct eip93_cipher_reqctx *rctx,
378 u32 datalen, u32 split, int offsetin)
379 {
380 struct eip93_descriptor *cdesc = rctx->cdesc;
381 struct scatterlist *sgsrc = rctx->sg_src;
382 struct scatterlist *sgdst = rctx->sg_dst;
383 unsigned int remainin = sg_dma_len(sgsrc);
384 unsigned int remainout = sg_dma_len(sgdst);
385 dma_addr_t saddr = sg_dma_address(sgsrc);
386 dma_addr_t daddr = sg_dma_address(sgdst);
387 dma_addr_t state_addr;
388 u32 src_addr, dst_addr, len, n;
389 bool nextin = false;
390 bool nextout = false;
391 int offsetout = 0;
> 392 int ndesc_cdr = 0, err;
393
394 if (IS_ECB(rctx->flags))
395 rctx->sa_state_base = 0;
396
397 if (split < datalen) {
398 state_addr = rctx->sa_state_ctr_base;
399 n = split;
400 } else {
401 state_addr = rctx->sa_state_base;
402 n = datalen;
403 }
404
405 do {
406 if (nextin) {
407 sgsrc = sg_next(sgsrc);
408 remainin = sg_dma_len(sgsrc);
409 if (remainin == 0)
410 continue;
411
412 saddr = sg_dma_address(sgsrc);
413 offsetin = 0;
414 nextin = false;
415 }
416
417 if (nextout) {
418 sgdst = sg_next(sgdst);
419 remainout = sg_dma_len(sgdst);
420 if (remainout == 0)
421 continue;
422
423 daddr = sg_dma_address(sgdst);
424 offsetout = 0;
425 nextout = false;
426 }
427 src_addr = saddr + offsetin;
428 dst_addr = daddr + offsetout;
429
430 if (remainin == remainout) {
431 len = remainin;
432 if (len > n) {
433 len = n;
434 remainin -= n;
435 remainout -= n;
436 offsetin += n;
437 offsetout += n;
438 } else {
439 nextin = true;
440 nextout = true;
441 }
442 } else if (remainin < remainout) {
443 len = remainin;
444 if (len > n) {
445 len = n;
446 remainin -= n;
447 remainout -= n;
448 offsetin += n;
449 offsetout += n;
450 } else {
451 offsetout += len;
452 remainout -= len;
453 nextin = true;
454 }
455 } else {
456 len = remainout;
457 if (len > n) {
458 len = n;
459 remainin -= n;
460 remainout -= n;
461 offsetin += n;
462 offsetout += n;
463 } else {
464 offsetin += len;
465 remainin -= len;
466 nextout = true;
467 }
468 }
469 n -= len;
470
471 cdesc->src_addr = src_addr;
472 cdesc->dst_addr = dst_addr;
473 cdesc->state_addr = state_addr;
474 cdesc->pe_length_word = FIELD_PREP(EIP93_PE_LENGTH_HOST_PE_READY,
475 EIP93_PE_LENGTH_HOST_READY);
476 cdesc->pe_length_word |= FIELD_PREP(EIP93_PE_LENGTH_LENGTH, len);
477
478 if (n == 0) {
479 n = datalen - split;
480 split = datalen;
481 state_addr = rctx->sa_state_base;
482 }
483
484 if (n == 0)
485 cdesc->user_id |= FIELD_PREP(EIP93_PE_USER_ID_DESC_FLAGS,
486 EIP93_DESC_LAST);
487
488 /*
489 * Loop - Delay - No need to rollback
490 * Maybe refine by slowing down at EIP93_RING_BUSY
491 */
492 again:
493 err = eip93_put_descriptor(mtk, cdesc);
494 if (err) {
495 usleep_range(EIP93_RING_BUSY_DELAY,
496 EIP93_RING_BUSY_DELAY * 2);
497 goto again;
498 }
499 /* Writing new descriptor count starts DMA action */
500 writel(1, mtk->base + EIP93_REG_PE_CD_COUNT);
501
502 ndesc_cdr++;
503 } while (n);
504
505 return -EINPROGRESS;
506 }
507
508 int eip93_send_req(struct crypto_async_request *async,
509 const u8 *reqiv, struct eip93_cipher_reqctx *rctx)
510 {
511 struct eip93_crypto_ctx *ctx = crypto_tfm_ctx(async->tfm);
512 struct eip93_device *mtk = ctx->mtk;
513 struct scatterlist *src = rctx->sg_src;
514 struct scatterlist *dst = rctx->sg_dst;
515 struct sa_state *sa_state;
516 struct eip93_descriptor cdesc;
517 u32 flags = rctx->flags;
518 int offsetin = 0, err;
519 u32 datalen = rctx->assoclen + rctx->textsize;
520 u32 split = datalen;
521 u32 start, end, ctr, blocks;
522 u32 iv[AES_BLOCK_SIZE / sizeof(u32)];
523 int crypto_async_idr;
524
525 rctx->sa_state_ctr = NULL;
526 rctx->sa_state = NULL;
527
528 if (IS_ECB(flags))
529 goto skip_iv;
530
531 memcpy(iv, reqiv, rctx->ivsize);
532
533 rctx->sa_state = kzalloc(sizeof(*rctx->sa_state), GFP_KERNEL);
534 if (!rctx->sa_state)
535 return -ENOMEM;
536
537 sa_state = rctx->sa_state;
538
539 memcpy(sa_state->state_iv, iv, rctx->ivsize);
540 if (IS_RFC3686(flags)) {
541 sa_state->state_iv[0] = ctx->sa_nonce;
542 sa_state->state_iv[1] = iv[0];
543 sa_state->state_iv[2] = iv[1];
544 sa_state->state_iv[3] = cpu_to_be32(1);
545 } else if (!IS_HMAC(flags) && IS_CTR(flags)) {
546 /* Compute data length. */
547 blocks = DIV_ROUND_UP(rctx->textsize, AES_BLOCK_SIZE);
548 ctr = be32_to_cpu(iv[3]);
549 /* Check 32bit counter overflow. */
550 start = ctr;
551 end = start + blocks - 1;
552 if (end < start) {
553 split = AES_BLOCK_SIZE * -start;
554 /*
555 * Increment the counter manually to cope with
556 * the hardware counter overflow.
557 */
558 iv[3] = 0xffffffff;
559 crypto_inc((u8 *)iv, AES_BLOCK_SIZE);
560
561 rctx->sa_state_ctr = kzalloc(sizeof(*rctx->sa_state_ctr),
562 GFP_KERNEL);
> 563 if (!rctx->sa_state_ctr) 564 goto free_sa_state;
565
566 memcpy(rctx->sa_state_ctr->state_iv, reqiv, rctx->ivsize);
567 memcpy(sa_state->state_iv, iv, rctx->ivsize);
568
569 rctx->sa_state_ctr_base = dma_map_single(mtk->dev, rctx->sa_state_ctr,
570 sizeof(*rctx->sa_state_ctr),
571 DMA_TO_DEVICE);
572 err = dma_mapping_error(mtk->dev, rctx->sa_state_ctr_base);
573 if (err)
574 goto free_sa_state_ctr;
575 }
576 }
577
578 rctx->sa_state_base = dma_map_single(mtk->dev, rctx->sa_state,
579 sizeof(*rctx->sa_state), DMA_TO_DEVICE);
580 err = dma_mapping_error(mtk->dev, rctx->sa_state_base);
581 if (err)
582 goto free_sa_state_ctr_dma;
583
584 skip_iv:
585
586 cdesc.pe_ctrl_stat_word = FIELD_PREP(EIP93_PE_CTRL_PE_READY_DES_TRING_OWN,
587 EIP93_PE_CTRL_HOST_READY);
588 cdesc.sa_addr = rctx->sa_record_base;
589 cdesc.arc4_addr = 0;
590
591 scoped_guard(spinlock_bh, &mtk->ring->idr_lock)
592 crypto_async_idr = idr_alloc(&mtk->ring->crypto_async_idr, async, 0,
593 EIP93_RING_NUM - 1, GFP_ATOMIC);
594
595 cdesc.user_id = FIELD_PREP(EIP93_PE_USER_ID_CRYPTO_IDR, (u16)crypto_async_idr) |
596 FIELD_PREP(EIP93_PE_USER_ID_DESC_FLAGS, rctx->desc_flags);
597
598 rctx->cdesc = &cdesc;
599
600 /* map DMA_BIDIRECTIONAL to invalidate cache on destination
601 * implies __dma_cache_wback_inv
602 */
603 if (!dma_map_sg(mtk->dev, dst, rctx->dst_nents, DMA_BIDIRECTIONAL)) {
604 err = -ENOMEM;
605 goto free_sa_state_ctr_dma;
606 }
607
608 if (src != dst &&
609 !dma_map_sg(mtk->dev, src, rctx->src_nents, DMA_TO_DEVICE)) {
610 err = -ENOMEM;
611 goto free_sg_dma;
612 }
613
614 return eip93_scatter_combine(mtk, rctx, datalen, split, offsetin);
615
616 free_sg_dma:
617 dma_unmap_sg(mtk->dev, dst, rctx->dst_nents, DMA_BIDIRECTIONAL);
618 free_sa_state_ctr_dma:
619 if (rctx->sa_state_ctr)
620 dma_unmap_single(mtk->dev, rctx->sa_state_ctr_base,
621 sizeof(*rctx->sa_state_ctr),
622 DMA_TO_DEVICE);
623 free_sa_state_ctr:
624 kfree(rctx->sa_state_ctr);
625 if (rctx->sa_state)
626 dma_unmap_single(mtk->dev, rctx->sa_state_base,
627 sizeof(*rctx->sa_state),
628 DMA_TO_DEVICE);
629 free_sa_state:
630 kfree(rctx->sa_state);
631
632 return err;
633 }
634
Signature · 2 lines
0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki