quickassist-c2xxx (Intel QAT1.5, Atom C2000/Rangeley): interest in official inclusion?

cc @dl12345 (original author of the quickassist-c2xxx feed package) @lecoq
(maintains the vendor driver fork this depends on) — your input on whether
this is worth pursuing here would be very welcome.

Summary

I've ported the community quickassist-c2xxx package (Intel QAT1.5 for the
Atom C2000/Rangeley SoCs, e.g. C2358) forward to Linux 6.12 and verified it
end-to-end on real hardware — kernel modules load, firmware initializes,
and the vendor SDK's own cpa_sample_code tool drives real symmetric/
asymmetric crypto through the accelerator (up to ~6.7 Gbit/s on AES128-CBC,
zero test failures). Full report:
https://github.com/mab-wien/qat-c2xxx-patches/issues/1

This package has existed as a third-party feed since 2020
(https://github.com/dl12345/quickassist-openwrt-denverton, 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 part of openwrt/packages. PRs with the kernel-6.12 fixes are
open against both the feed and the underlying vendor driver fork:

• https://github.com/dl12345/quickassist-openwrt-denverton/pull/1
• https://github.com/lecoq/qat_c2xxx/pull/2

Question

Before putting together a PR against this repo: is there a known reason
quickassist-c2xxx was never proposed for inclusion here (licensing,
maintenance burden, hardware being considered too niche/EOL, prior
rejected attempts, etc.), or has it simply never been submitted? Atom
C2000/Rangeley is old but still in service in a fair number of routers/
firewalls, and this port is the first time (as far as I can tell) the
driver has been verified against a post-5.x kernel.

If there's appetite for it, I'd want to first finish validating the
strongSwan/XFRM integration path (this is currently only verified against
the vendor SDK's own standalone benchmark tool, not the kernel crypto API),
then bring a PR here with that in place — wanted to check before investing
further whether that's a reasonable plan or whether there's context I'm
missing.

Start with CONTRIBUTING.md and review the linked pull requests in the third-party feed and vendor driver fork. Then investigate the strongSwan/XFRM integration and kernel crypto API path, which has not yet been validated. Done means establishing whether the package is suitable for inclusion and preparing the requested validation and context.