quickassist-c2xxx, openssl-qat: add packages (Intel QAT1.5, Atom C2000/Rangeley)

[mab-wien]

Summary

Adds quickassist-c2xxx (Intel QuickAssist Technology v1.5 kernel driver + userspace utilities for Atom C2000/Rangeley SoCs, e.g. C2358) and openssl-qat (the QAT OpenSSL engine wired up against it), ported forward to build and run on current kernels (6.12+).

Opened per the discussion in #30510, specifically in response to:

• @egc112 pointing out the upcoming kernel 6.18 switch
• @brada4 asking about mainline in-tree QAT support

What is verified

• Real hardware (Atom C2358, OpenWrt 25.12, kernel 6.12): kernel modules load, firmware initializes, the vendor SDK's own cpa_sample_code benchmark drives real symmetric/asymmetric crypto through the accelerator (~6.7 Gbit/s AES128-CBC, zero failures), and the QAT OpenSSL engine comes up as [ available ]. Full report: QAT1.5 kernel 6.12 port: real-hardware validation (cpa_sample_code), 73 patches mab-wien/qat-c2xxx-patches#1
• Real hardware, packages from this PR's head (Atom C2358, OpenWrt 25.12.5, kernel 6.12.94, re-run 2026-09-19): built from the PR head with the official 25.12.5 SDK and loaded on the board (from /tmp, without replacing the installed stack). Both kernel modules load cleanly (no dmesg warnings), the device comes up (state=up), qat.init stop/start icp_dev0 works, the engine with the shipped qatengine.cnf.example is [ available ], and RSA-2048 signatures made through the engine verify in software. openssl speed rsa2048 goes from ~150 to ~1260-1290 sign/s and from ~5100 to ~11200-11600 verify/s (single process, 3 s runs).
• CI build, kernel 6.12 (stable SDK): both packages build cleanly end-to-end - https://github.com/mab-wien/quickassist-openwrt-denverton/actions/runs/34697894053
• CI build, kernel 6.18 (current master snapshot SDK, 6.18.52): both packages and both kernel modules (icp_qa_al, usdm_drv) build cleanly - https://github.com/openwrt/packages/actions/runs/35404989582
• Generic package tests (test_entrypoint.sh from openwrt/actions-shared-workflows): reproduced locally against the apks built by CI, the generic checks pass for both packages. quickassist-c2xxx ships a test-version.sh override because adf_ctl / icp_gige_watchdog do not report a version.

Known CI limitations (not caused by this PR)

The x86_64 test job cannot pass at the moment, for two independent reasons (details in this comment):

• The test container image openwrt/rootfs:x86_64-master was last published on 2026-05-29 and points at a kmods index that no longer exists, so apk update fails before any test runs. This affects other PRs as well (e.g. meshtasticd: update to 2.7.26 #30548, modemmanager: fix custom initial EPS bearer username #30543). The publishing job was fixed in ci: fix registry image namespaces docker#213, the next weekly rebuild is due 2026-09-21.
• Even with a refreshed image, the test container cannot resolve the kmods built by this PR (kmod-crypto-qat-c2xxx, kmod-crypto-qat-c2xxx-usdm), because the workflow only stages packages_ci/* while feed kmods end up in bin/targets/<target>/packages/.

About the patches

quickassist-c2xxx carries 82 patches against the vendor source. 67 of them are 40 lines or fewer including the header and are mechanical build/API fixes for the old vendor driver (missing prototypes / static / extern / includes for -Werror, fallthrough annotations, kernel 6.x API changes such as PCIe AER, dma_set_mask, vm_flags_set, proc_ops, class_create(), IOMMU, and ccflags/ldflags plumbing). Most of the line count is a single vendor backport (0002, ~5.9k of ~8.8k lines).

What is NOT yet verified

• The kernel crypto API / strongSwan-XFRM integration path (only the vendor SDK's own standalone benchmark tool and the OpenSSL engine have been used so far, not ip xfrm/IPsec through this driver)
• Runtime on real hardware with kernel 6.18 (build-tested in CI only, the test board currently runs 6.12)
• QAT_C3XXX (Denverton) - present as a sibling Kconfig choice inherited from the existing feed package, but no quickassist-c3xxx package exists yet; out of scope for this PR

Background

• Mainline drivers/crypto/intel/qat/ covers DH895xCC, C3XXX (Denverton), C62X, 4XXX/420XX/6XXX - but not C2XXX/Rangeley, so the vendor driver remains the only option for this specific chip.
• This package has existed as a third-party feed since 2020 (https://github.com/dl12345/quickassist-openwrt-denverton, forum background: https://forum.openwrt.org/t/intel-quick-assist-v1-5-drivers-and-openssl-1-1-1e-acceleration-engine-for-19-07-2/58692) but was never submitted here.
• The vendor source archive for quickassist-c2xxx (Intel's original download URL has been dead for years) is mirrored as a GitHub release asset with a verified sha256sum.

Open questions for reviewers

• Is the GitHub-release vendor-source mirror (rather than an authoritative upstream URL, since Intel's own is dead) acceptable, or is there a preferred approach for this kind of EOL vendor archive?
• Any objections to merging before the XFRM/strongSwan validation is complete, given the CI-verified build + real-hardware benchmark validation already in place?

cc @dl12345 @lecoq

[openwrt-ai]

Blocking: the dirty-patch CI failure and the dangling quickassist-c3xxx dependency. The rest are packaging/init-script fixes.

---

Generated by Claude Code

[BKPepe]

Sorry, in this pull request you are adding more than 80 patches, I am not going to review it or merge it, because it is quite a lot.

[openwrt-ai]

Blocking: the QAT_NONE default makes the x86_64 build fail in configure. The earlier Makefile/init-script threads are untouched by this push and still stand.

---

Generated by Claude Code

[openwrt-ai]

Commit checks

• b4f4e8a9 "openssl-qat: add package" — the body enumerates four build fixes, but the commit also adds patches/0004-use-multiprocess-userstart-for-v2-config.patch (a runtime change, icp_sal_userStart → icp_sal_userStartMultiProcess) and files/qatengine.cnf.example. Both change engine behaviour rather than fix the build and should be named in the message.

---

Generated by Claude Code

[openwrt-ai]

Commit checks

• 66027410 "openssl-qat: add package" — the body enumerates four build fixes, but the commit also adds patches/0004-use-multiprocess-userstart-for-v2-config.patch (a runtime change, icp_sal_userStart → icp_sal_userStartMultiProcess) and files/qatengine.cnf.example. Both change engine behaviour rather than fix the build and should be named in the message.

---

Generated by Claude Code

[mab-wien]

@openwrt-ai Fixed - amended the openssl-qat commit message (now 7f08065) to describe the icp_sal_userStartMultiProcess() runtime fix (required for the v2/"[SSL]" config format quickassist-c2xxx ships - without it cpaCyGetNumInstances() silently returns 0) and the qatengine.cnf.example addition, alongside the four build fixes already listed.

[openwrt-ai]

Nothing blocking in this push.

---

Generated by Claude Code

[mab-wien]

Status of the x86_64 job, so it doesn't look like a problem with this PR's code:

1. Stale test container (repo-wide). The x86_64 test container is built FROM openwrt/rootfs:x86_64-master, which was last pushed to Docker Hub on 2026-05-29. Its distfeeds.list still points at kmods/6.18.33-1-70e27cfe28d8cb55760256504e7c02fe/, which no longer exists on downloads.openwrt.org (the current snapshot kernel is 6.18.52), so apk update fails before any test runs. Other PRs hit the same error, e.g. #30548 and #30543. The publishing job in openwrt/docker was broken (invalid quay.io tag, openwrt/docker#211) and is fixed by openwrt/docker#213, but the images are only rebuilt weekly (Mon 02:30 UTC), so the next refresh should be 2026-09-21.

2. kmods built by this PR are not available to the test container. I reproduced the test locally (real test_entrypoint.sh, current kmods index, the apks CI built for this PR): the generic tests pass for both packages, but apk add of quickassist-c2xxx fails with kmod-crypto-qat-c2xxx (no such package) / kmod-crypto-qat-c2xxx-usdm (no such package). The workflow only copies bin/packages/<arch>/packages_ci/* into the test directory, while kmods built from a feed end up in bin/targets/<target>/packages/, so kmods introduced by the PR itself cannot be resolved until the buildbot has published them.

quickassist-c2xxx really does need its kmods, so I'd rather not change the dependency direction just for the harness, and I expect x86_64 to stay red for this reason. If you'd prefer a green x86_64 anyway, I can invert it (kmods depend on quickassist-c2xxx, which provides the firmware) or help with a workflow change to stage kmods for the test container - just say so.

One correction to my earlier reply about test-version.sh: the kmod apks are not part of the tested set (only the two userspace apks are), so the kmod names in its case statement are unnecessary. I'll drop them with the next push.

[openwrt-ai]

Reviewed 2 new commits; no new issues found.

---

Generated by Claude Code

[mab-wien]

Hi @BKPepe, thanks for looking at this, and understood that 80+ patch files is a lot to review.

For context on what they are: 67 of the 82 are 40 lines or fewer including the patch header, and nearly all are mechanical fixes needed to build the old vendor driver with a current toolchain and kernel: missing prototypes / static / extern / include fixes for -Werror, fallthrough annotations, kernel 6.x API changes (PCIe AER, dma_set_mask, vm_flags_set, proc_ops, class_create(), IOMMU), and ccflags/ldflags plumbing for the vendor build system. Most of the line count is a single vendor backport (0002, ~5.9k of ~8.8k lines).

I can reduce the review surface without changing the result: group them into roughly 10 thematic patches (kernel API compat, missing prototypes/static/includes, fallthrough, build system, musl/userspace, and the vendor backports), and I'd verify that the fully patched source tree is byte-identical before and after. Would that be acceptable to you?

And if this simply isn't something you want in the feed, that's fine. I'd just like to know whether it's worth continuing here or whether another maintainer could take a look.

[openwrt-ai]

Reviewed 2 new commits; no new issues found.

---

Generated by Claude Code