Safexcel 15600000.crypto failed with error -16

Hi,

has anyone fixed the safexcel load error ?

[   18.623982] crypto-safexcel 15600000.crypto: can't request region for resource [mem 0x15600000-0x1577ffff]
[   18.633693] crypto-safexcel 15600000.crypto: failed to get resource
[   18.639948] crypto-safexcel: probe of 15600000.crypto failed with error -16

the above is on master openwrt

I noticed that the mtk build uses kmod-eip and a couple of more modules / tools but see these need to be ported to 6.1 or otherwise fix the crypto-safexcel error.

thank you

same here:

[ 6211.543098] bus: 'platform': __driver_probe_device: matched device 15600000.crypto with driver crypto-safexcel
[ 6211.553150] bus: 'platform': really_probe: probing driver crypto-safexcel with device 15600000.crypto
[ 6211.562378] crypto-safexcel 15600000.crypto: no pinctrl handle
[ 6211.568245] crypto-safexcel 15600000.crypto: can't request region for resource [mem 0x15600000-0x1577ffff]
[ 6211.577886] crypto-safexcel 15600000.crypto: failed to get resource
[ 6211.584149] crypto-safexcel: probe of 15600000.crypto failed with error -16

it looks like there’s something wrong with the pinctl definitions in DTS … I’ll see whether any workaround for that is possible

1 Like

so I backported the crypto-eip package to openwrt and definitely seems there’s a problem

DDK doesn’t register

ue Sep 10 13:31:51 2024 kern.debug kernel: [  235.614449] Adapter build configuration of DDK-197-GPL v5.6.1:
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.620442]      ADAPTER_PEC_DBG
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.623335]      ADAPTER_PEC_STRICT_ARGS
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.626902]      ADAPTER_PEC_ENABLE_SCATTERGATHER
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.631249]      ADAPTER_PEC_SEPARATE_RINGS
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.635090]      ADAPTER_PEC_DEVICE_COUNT: 14
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.639134]      ADAPTER_PEC_MAX_PACKETS: 32
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.643057]      ADAPTER_MAX_PECLOGICDESCR: 32
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.647145]      ADAPTER_PEC_MAX_SAS: 64
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.650711]      ADAPTER_DESCRIPTORDONETIMEOUT: 20
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.655154]      ADAPTER_DESCRIPTORDONECOUNT: 4
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.659363]      ADAPTER_REMOVE_BOUNCEBUFFERS is NOT set => Bounce ENABLED
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.665890]      ADAPTER_EIP202_INTERRUPTS_ENABLE is SET => Interrupts ENABLED
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.672760]      ADAPTER_PCL_ENABLE
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.675892]      ADAPTER_PCL_FLOW_HASH_ENTRIES_COUNT: 512
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.680962]      ADAPTER_64BIT_HOST is SET => addresses are 64-bit
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.686792]      ADAPTER_64BIT_DEVICE is SET => full 64-bit DMA addresses usable
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.693836]      ADAPTER_DMARESOURCE_BANKS_ENABLE
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.698211] Logging:
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.700390]      LOG_SEVERITY_MAX == LOG_SEVERITY_W_A_R_N_I_N_G
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.705961] Other:
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.707966]      ADAPTER_DRIVER_NAME: Security_IP-197
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.712668]      ADAPTER_LICENSE: GPL
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.715974]      ADAPTER_INTERRUPTS_TRACEFILTER: 0x00000000
Tue Sep 10 13:31:51 2024 kern.debug kernel: [  235.721219]      RPM_DEVICE_CAPABILITIES_STR_MACRO: RPM stubbed

eip-online

[ 1027.636269] LKM_Init: failed, no device detected
[ 1027.690875] Device_Internal_Initialize: Failed to register the platform device
[ 1027.698108] Device_Initialize: failed, error -1

has anyone seen this work at all ?

Yes, it loads on the latest MTK branch build: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/d7d5c7502b6c24795309e259d44158e99feccb9a/autobuild/unified/Readme.md

but unless you need IPSec tunnel support there is no real reason to use this kmod

would you mind to share a console output of the eip and ddk output?

actually think I found the issue the openwrt snapshot dts doesn’t have compatible for ā€œsecurity-ip-197-srvā€

btw it does load now the ddk but not crypto-eip after the above change

[   14.734698] Adapter build configuration of DDK-197-GPL v5.6.1:
[   14.740536]  ADAPTER_PEC_DBG
[   14.743413]  ADAPTER_PEC_STRICT_ARGS
[   14.746975]  ADAPTER_PEC_ENABLE_SCATTERGATHER
[   14.751318]  ADAPTER_PEC_SEPARATE_RINGS
[   14.755150]  ADAPTER_PEC_DEVICE_COUNT: 14
[   14.759147]  ADAPTER_PEC_MAX_PACKETS: 32
[   14.763061]  ADAPTER_MAX_PECLOGICDESCR: 32
[   14.767144]  ADAPTER_PEC_MAX_SAS: 64
[   14.770706]  ADAPTER_DESCRIPTORDONETIMEOUT: 20
[   14.775139]  ADAPTER_DESCRIPTORDONECOUNT: 4
[   14.779308]  ADAPTER_REMOVE_BOUNCEBUFFERS is NOT set => Bounce ENABLED
[   14.785823]  ADAPTER_EIP202_INTERRUPTS_ENABLE is SET => Interrupts ENABLED
[   14.792684]  ADAPTER_PCL_ENABLE
[   14.795811]  ADAPTER_PCL_FLOW_HASH_ENTRIES_COUNT: 512
[   14.800849]  ADAPTER_64BIT_HOST is SET => addresses are 64-bit
[   14.806671]  ADAPTER_64BIT_DEVICE is SET => full 64-bit DMA addresses usable
[   14.813706]  ADAPTER_DMARESOURCE_BANKS_ENABLE
[   14.818049] Logging:
[   14.820224]  LOG_SEVERITY_MAX == LOG_SEVERITY_W_A_R_N_I_N_G
[   14.825783] Other:
[   14.827784]  ADAPTER_DRIVER_NAME: Security_IP-197
[   14.832497]  ADAPTER_LICENSE: GPL
[   14.835803]  ADAPTER_INTERRUPTS_TRACEFILTER: 0x00000000
[   14.841017]  RPM_DEVICE_CAPABILITIES_STR_MACRO: RPM stubbed
[   14.847037] FreeHandles: kmalloc
[   14.850472] GlobalControl97_Capabilities_Get
[   14.854748] EIP202: PEs=1 rings=8 64-bit=Yes, fill level extension=No
[   14.854748] CF size=5 RF size=5 DMA len = 14 Align=2 HDW=2 HostIfc=3
[   14.867515] EIP96 options:
[   14.867515] AES: Yes with CFB/OFB: Yes Fast: Yes
[   14.867515] DES: Yes with CFB/OFB: Yes Fast: No
[   14.867515] ARCFOUR level: 0
[   14.867515] AES-XTS: No Wireless crypto: Yes
[   14.867515] MD5: Yes SHA1: Yes Fast: Yes SHA256: Yes SHA512: Yes
[   14.867515] (X)CBC-MAC: Yes Fast: Yes All key sizes: Yes GHASH Yes
[   14.898588] EIP97 options: PEs=1, In Dbuf size=11 In Tbuf size=8, Out Dbuf size=8, Out Tbuf size=7, Central PRNG: Yes
[   14.898588] Token Generator: No, Transform Record Cache: Yes
[   14.914823] EIP206 options: PE type=0 InClassifier=0 OutClassifier=0 MAC chans=0
[   14.914823] InDBuf=0kB InTBuf=0kB OutDBuf=0kB OutTBuf=0kB
[   14.927674] Global EIP-97 capabilities: EIP-97 v3.3p1  with EIP-202 v2.7p2 and EIP-96 v4.5p0, #PE=01 #rings=08 central-prng=1
[   14.938965] No PRNG in PEs, skip initialization
[   14.943483] Global Status of the EIP-97
[   14.947306] Packet Engine 0 Status
[   14.950697] DFE Status: CD FIFO Words: 0, CDR ID: 15, DMA size: 4
[   14.950697] AtDMA busy: false, DataDMA busy: false, DMA err: false
[   14.962939] DSE Status: RD FIFO Words: 0, RDR ID: 15, DMA size: 0
[   14.962939] Data flush  busy: false, DataDMA busy: false, DMA err: false
[   14.975705] Token Status: Active: 0, loc available: true
[   14.975705] res available: false, read active: false, ccache active: false
[   14.975705] cntx fetch: false, res cntx: false
[   14.975705] processing held: true, busy: false
[   14.996711] Context Status: Err mask: 0000, Available: 0
[   14.996711] Active cntx: false, next cntx: false, result cntx: false Err recov: false
[   15.009821] Interrupt Status: input DMA err: false, output DMA err false
[   15.009821] pkt proc err: false, pkt timeout: false, f a t a l err: false, PE int out: false
[   15.009821] inp DMA enable: false, outp DMA enable false, pkt proc enable: false
[   15.009821] pkt timeout enable: false, f a t a l enable: false,PE int out enable: false
[   15.040376] Output Transfer Status: availabe: 79, min: 4, max: 64, size mask: 254
[   15.047858] No PRNG present in EIP-96
[   15.051529]
[   15.051529] Interface DBG Statistics:
[   15.056655]
[   15.056655] Pipe DBG Statistics:
[   15.061345]          Pipe # 0 Total=         0 Data=         0 Cur=  0 Max=  0
[   15.067949] GlobalControl_EIP207_Init:
[   15.067949] Number of Rings: 8, LA Interfaces: 1, Inline interfaces: 1
[   15.079190] GlobalControl_EIP207_Init cache set 0:
[   15.079190]          FRC  AdminWords=  320 DataWords=  768
[   15.079190]          TRC  AdminWords=  192 DataWords= 2176
[   15.079190]          ARC4 AdminWords=    0 DataWords=    0
[   15.098552] Adapter_Firmware_Acquire for firmware_eip207_ipue.bin
[   15.113785] Adapter_Firmware_Acquire for firmware_eip207_ifpp.bin
[   15.120077] Adapter_Firmware_Acquire for firmware_eip207_opue.bin
[   15.126462] Adapter_Firmware_Acquire for firmware_eip207_ofpp.bin
[   15.134389] Adapter_Firmware_Release
[   15.137955] Adapter_Firmware_Release
[   15.141534] Adapter_Firmware_Release
[   15.145105] Adapter_Firmware_Release
[   15.148667] GlobalControl207_Init: firmware downloaded successfully
[   15.154941]  IPUE firmware v3.5.0, image byte count 8136
[   15.160243]  IFPP firmware v3.5.0, image byte count 16308
[   15.160243]
[   15.167112]  OPUE firmware v3.5.0, image byte count 5036
[   15.172415]  OFPP firmware v3.5.0, image byte count 5044
[   15.172415]
[   15.179195] EIP-207 capabilities
[   15.182417]  Lookup cached:            No
[   15.182417]  FRC combined with TRC:    No
[   15.182417]  ARC4RC present:           No
[   15.182417]  FRC combined with ARC4RC: No
[   15.182417]  TRC combined with ARC4RC: No
[   15.182417]  FRC clients:              2
[   15.182417]  TRC clients:              4
[   15.182417]  ARC4RC clients:           0
[   15.182417]  Lookup clients:           2
[   15.182417]
[   15.219477] Global Classification capabilities: EIP-207 v2.4p0  #cache sets=01 #lookup tables=01
[   15.228249] Global Classification Control Status
[   15.232856] Classification Engine 0 status
[   15.236954] Adapter_Global_Cs_StatusReport: all OK
[   15.241734]  ICE Dropped Packets Counter (low 32-bits):     0x00000000
[   15.241734]  ICE Dropped Packets Counter (high 32-bits):    0x00000000
[   15.241734]  ICE Inbound Packets Counter:                   0x00000000
[   15.241734]  ICE Outbound Packets Counter:                  0x00000000
[   15.241734]  ICE Inbound Octets Counter (low 32-bits):      0x00007331
[   15.241734]  ICE Inbound Octets Counter (high 32-bits):     0x03310331
[   15.241734]  ICE Outbound Octets Counter (low 32-bits):     0x00007331
[   15.241734]  ICE Outbound Octets Counter (high 32-bits):    0x03310331
[   15.241734]  OCE Dropped Packets Counter (low 32-bits):     0x00000000
[   15.241734]  OCE Dropped Packets Counter (high 32-bits):    0x00000000
[   15.241734]
[   15.308295]  ICE Clock Count (low 32-bits):   0x00000000
[   15.308295]  ICE Clock Count (high 32-bits):  0x00000000
[   15.308295]  OCE Clock Count (low 32-bits):   0x00000000
[   15.308295]  OCE Clock Count (high 32-bits):  0x00000000
[   15.308295]
[   15.330964] EIP74 initialized OK
[   15.334185] EIP74 options: Nof Clients=1 Nof AESCores=1
[   15.334185]          AESSpeed=1 FIFODepth=6
[   15.342957] DA_GC: Global DRBG capabilities: EIP-74 v1.1p0
[   15.348428] DA_GC: Global DRBG Status
[   15.352078] EIP 74 status: GenBlockCount=1 StuckOut=false
[   15.352078]          NotInitialized=false ReseedErr=false ReseedWarn=false
[   15.352078]          Instantiated=true AvailableCount=6
[   15.370356] (NULL device *): crypto-eip dts init failed: -19

The native crypto_safexcel upstream driver uses devm_ioremap_resource() during probe stage.
Change it to first get the resource from DTS and then call devm_ioremap() to fix this issue.

https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/21.02/files/target/linux/mediatek/patches-5.4/999-2706-crypto-add-eip197-inside-secure-support.patch

1 Like

I’m still seeing this issue on OpenWRT 24.10 RC5.

I guess it is not yet added to openwrt as openwrt devs need time to update codebase to 6.6 and upstreaming some basic patches.

Not sure if there is a benefit as hnat works different in later kernel versions.

@moore i do not see a change for dts and ioremap call in the patch you’ve linked

Please refer to 2 patches below.

https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/6342b208f4b20286527e2dd46214bf4e6b5ccf51/24.10/files/target/linux/mediatek/patches-6.6/999-2700-crypto-add-eip197-inside-secure-support-for-kernel-6.6.patch

https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/6342b208f4b20286527e2dd46214bf4e6b5ccf51

1 Like

I have a pull with openwrt with a variation of the mtk patch since October

@moore any chance the mtk patch be upstreamed ? it would make things easier… thank you

ok…we’ll upstream the patch in the future.

1 Like

I tried both crypto-safexcel and crypto-eip drivers on stock OpenWrt Snapshot with kernel 6.12.55. Both stalled for me (when tried separately).

crypto-safexcel didn’t spit any error to dmesg but the ā€˜openssl speed’ test process stalls and cannot be killed. Other than that, system continued to run fine.

crypto-eip did cause ā€˜rcu stall’ error to dmesg. A short while later kernel crashed and remained stalled. Required a power cycle to bring back the system.

For crypto-safexcel, I already applied this patch that supposed to resolve ā€˜rcu stall’ on kernel 6.6: 24.10/files/target/linux/mediatek/patches-6.6/999-2702-crypto-avoid-rcu-stall.patch - openwrt/feeds/mtk-openwrt-feeds - Gitiles

Does either crypto driver work for you on kernel 6.12 ?

Cheers

Just want to mention that crypto also causes binding errors (on mt7986) due to few interrupts. Maybe there is a patch too? Possibly it is also a cause why it does not work correctly.

1 Like

yes on openwrt snapshot …

 cat /proc/crypto |grep safe
driver       : safexcel-rfc4309-ccm-aes
module       : crypto_safexcel
driver       : safexcel-rfc4543-gcm-aes
driver       : safexcel-rfc4106-gcm-aes
driver       : safexcel-authenc-hmac-sha384-cbc-des
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha512-cbc-des
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha224-cbc-des
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha256-cbc-des
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha384-cbc-des3_ede
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha512-cbc-des3_ede
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha224-cbc-des3_ede
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha256-cbc-des3_ede
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha1-cbc-des
module       : crypto_safexcel
driver       : safexcel-cmac-aes
module       : crypto_safexcel
driver       : safexcel-xcbc-aes
module       : crypto_safexcel
driver       : safexcel-cbcmac-aes
module       : crypto_safexcel
driver       : safexcel-crc32
module       : crypto_safexcel
driver       : safexcel-ccm-aes
module       : crypto_safexcel
driver       : safexcel-gcm-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha512-ctr-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha384-ctr-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha256-ctr-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha224-ctr-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha1-ctr-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha1-cbc-des3_ede
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha512-cbc-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha384-cbc-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha256-cbc-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha224-cbc-aes
module       : crypto_safexcel
driver       : safexcel-authenc-hmac-sha1-cbc-aes
module       : crypto_safexcel
driver       : safexcel-hmac-sha512
module       : crypto_safexcel
driver       : safexcel-hmac-sha384
module       : crypto_safexcel
driver       : safexcel-hmac-sha256
module       : crypto_safexcel
driver       : safexcel-hmac-sha224
module       : crypto_safexcel
driver       : safexcel-hmac-sha1
module       : crypto_safexcel
driver       : safexcel-hmac-md5
module       : crypto_safexcel
driver       : safexcel-sha512
module       : crypto_safexcel
driver       : safexcel-sha384
module       : crypto_safexcel
driver       : safexcel-sha256
module       : crypto_safexcel
driver       : safexcel-sha224
module       : crypto_safexcel
driver       : safexcel-sha1
module       : crypto_safexcel
driver       : safexcel-md5
module       : crypto_safexcel
driver       : safexcel-ctr-aes
module       : crypto_safexcel
driver       : safexcel-cbc-aes
module       : crypto_safexcel
driver       : safexcel-ecb-aes
module       : crypto_safexcel
driver       : safexcel-cbc-des3_ede
module       : crypto_safexcel
driver       : safexcel-ecb-des3_ede
module       : crypto_safexcel
driver       : safexcel-cbc-des
module       : crypto_safexcel
driver       : safexcel-ecb-des
module       : crypto_safexcel

1 Like

That’s great news. So must be some user error of mine.

I suspected engines of openssl libs. Tried both afalg (and afalg_sync) and devcrypto. Prompt from openssl indicated both types of engines succeed in initialisation, and stalls. This seems to indicate my issue is inside the crypto_safexcel driver.

Check /proc/crypto and I have all those safexcel entries too. I’m wondering what else I could be missing?

here is my crypto config in mt7988a.dtsi

suggest you try snapshot … perhaps is related with kernel 6.6 …

Good suggestion.

I just tried OpenWrt Snapshot image (master branch) from OpenWrt. So everything is stock without anything touched by me. Kernel 6.12.55

I also just tried Openwrt 24.10.4 from OpenWrt. Everything is stock without anything touched by me. Kernel 6.6.110.

Same ā€˜openssl speed’ test. Results:

  • OpenWrt Snapshot (stock/6.12.55)

same stall issue !

  • OpenWrt 24.10.4 (stock/6.6.110)

crypto-safexcel driver fails to initialise. Errors:

[   11.421644] crypto-safexcel 15600000.crypto: can't request region for resource [mem 0x15600000-0x1577ffff]
[   11.431371] crypto-safexcel 15600000.crypto: failed to get resource
[   11.437633] crypto-safexcel: probe of 15600000.crypto failed with error -16

Are we certain that crypto-safexcel driver works on stock OpenWrt images ?

Looks like the memory region is already used…can you search in openwrt dtsi if there is any other node in this range?

Right after I posted my last reply, I realised the error for the case ā€œOpenWrt 24.10.4 (stock/6.6.110)ā€ is what @rmandrad got at the very beginning of this thread.

That means that the fix of resolving the issue at the start of the thread was never picked up by stock OpenWrt in 24.10.x releases. So we can close this riddle.

The more interesting finding is the case for ā€œOpenWrt Snapshot (stock/6.12.55)ā€. The same stall issue. So it’s not related to my compile (and changes) of OpenWrt Snapshot (6.12.x).

I wonder what rmandrad might have done differently so that it works on his compile of OpenWrt Snapshot (6.12.x).