#
434c1cb9 |
|
13-Dec-2023 |
Nithin Dabilpuram <ndabilpuram@marvell.com> |
crypto: octeontx2 - register error interrupts for inline cptlf Register errors interrupts for inline cptlf attached to PF driver so that SMMU faults and other errors can be reported. Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
92508e7f |
|
13-Dec-2023 |
Srujana Challa <schalla@marvell.com> |
crypto: octeontx2 - add SGv2 support for CN10KB or CN10KA B0 Scatter Gather input format for CPT has changed on CN10KB/CN10KA B0 HW to make it compatible with NIX Scatter Gather format to support SG mode for inline IPsec. This patch modifies the code to make the driver works for the same. This patch also enables CPT firmware load for these chips. Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
c480a421 |
|
11-Dec-2023 |
Bharat Bhushan <bbhushan2@marvell.com> |
crypto: octeontx2 - Fix cptvf driver cleanup This patch fixes following cleanup issues: - Missing instruction queue free on cleanup. This will lead to memory leak. - lfs->lfs_num is set to zero before cleanup, which will lead to improper cleanup. Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
04079104 |
|
29-Nov-2023 |
Bharat Bhushan <bbhushan2@marvell.com> |
crypto: octeontx2 - By default allocate one CPT LF per CPT VF There are limited number CPT LFs (example 64 LFs on cn10k) and these LFs are allocated/attached to CPT VF on its creation. cptpf sysfs parameter "kvf_limits" defines number of CPT LFs per CPT VF. Default "kvf_limits" is initialized to zero and if kvf_limits is zero then number of LF allocated are equal to online cpus in system. For example on 24 core system, 24 CPT LFs will be attached per VF. That means no CPT LF available when creating more than 2 CPT VFs on system which have total 64 LFs. Although VFs gets created but no LF attached to it. There seems no reason to default allocate as many LFs as many online cpus in system. This patch initializes "kvf_limits" to one to limit one LF allocated per CPT VF. "kvf_limits" can be changed in range of 1 to number-of-online-cpus via sysfs. Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
a4855a8c |
|
25-Apr-2023 |
Srujana Challa <schalla@marvell.com> |
crypto: octeontx2 - hardware configuration for inline IPsec On OcteonTX2/OctoenTX3 variants of silicon, Admin function (AF) handles resource allocation and configuration for PFs and their VFs. PFs request the AF directly, via mailboxes. Unlike PFs, VFs cannot send a mailbox request directly. A VF sends mailbox messages to its parent PF, with which it shares a mailbox region. The PF then forwards these messages to the AF. This patch adds code to configure inline-IPsec HW resources for CPT VFs as CPT VFs cannot send a mailbox request directly to AF. Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
8ae5c4d1 |
|
18-May-2023 |
Tejun Heo <tj@kernel.org> |
crypto: octeontx2: Use alloc_ordered_workqueue() to create ordered workqueues BACKGROUND ========== When multiple work items are queued to a workqueue, their execution order doesn't match the queueing order. They may get executed in any order and simultaneously. When fully serialized execution - one by one in the queueing order - is needed, an ordered workqueue should be used which can be created with alloc_ordered_workqueue(). However, alloc_ordered_workqueue() was a later addition. Before it, an ordered workqueue could be obtained by creating an UNBOUND workqueue with @max_active==1. This originally was an implementation side-effect which was broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered"). Because there were users that depended on the ordered execution, 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered") made workqueue allocation path to implicitly promote UNBOUND workqueues w/ @max_active==1 to ordered workqueues. While this has worked okay, overloading the UNBOUND allocation interface this way creates other issues. It's difficult to tell whether a given workqueue actually needs to be ordered and users that legitimately want a min concurrency level wq unexpectedly gets an ordered one instead. With planned UNBOUND workqueue updates to improve execution locality and more prevalence of chiplet designs which can benefit from such improvements, this isn't a state we wanna be in forever. This patch series audits all callsites that create an UNBOUND workqueue w/ @max_active==1 and converts them to alloc_ordered_workqueue() as necessary. WHAT TO LOOK FOR ================ The conversions are from alloc_workqueue(WQ_UNBOUND | flags, 1, args..) to alloc_ordered_workqueue(flags, args...) which don't cause any functional changes. If you know that fully ordered execution is not ncessary, please let me know. I'll drop the conversion and instead add a comment noting the fact to reduce confusion while conversion is in progress. If you aren't fully sure, it's completely fine to let the conversion through. The behavior will stay exactly the same and we can always reconsider later. As there are follow-up workqueue core changes, I'd really appreciate if the patch can be routed through the workqueue tree w/ your acks. Thanks. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Arnaud Ebalard <arno@natisbad.org> Cc: Srujana Challa <schalla@marvell.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Shijith Thotton <sthotton@marvell.com> Cc: Vladis Dronov <vdronov@redhat.com> Cc: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Alexander Lobakin <alobakin@pm.me> Cc: Minghao Chi <chi.minghao@zte.com.cn> Cc: ye xingchen <ye.xingchen@zte.com.cn> Cc: linux-crypto@vger.kernel.org
|
#
72bc4e71 |
|
05-Feb-2023 |
Alexander Lobakin <alobakin@pm.me> |
crypto: octeontx2 - Fix objects shared between several modules cn10k_cpt.o, otx2_cptlf.o and otx2_cpt_mbox_common.o are linked into both rvu_cptpf and rvu_cptvf modules: > scripts/Makefile.build:252: ./drivers/crypto/marvell/octeontx2/Makefile: > cn10k_cpt.o is added to multiple modules: rvu_cptpf rvu_cptvf > scripts/Makefile.build:252: ./drivers/crypto/marvell/octeontx2/Makefile: > otx2_cptlf.o is added to multiple modules: rvu_cptpf rvu_cptvf > scripts/Makefile.build:252: ./drivers/crypto/marvell/octeontx2/Makefile: > otx2_cpt_mbox_common.o is added to multiple modules: rvu_cptpf rvu_cptvf Despite they're build under the same Kconfig option (CONFIG_CRYPTO_DEV_OCTEONTX2_CPT), it's better do link the common code into a standalone module and export the shared functions. Under certain circumstances, this can lead to the same situation as fixed by commit 637a642f5ca5 ("zstd: Fixing mixed module-builtin objects"). Plus, those three common object files are relatively big to duplicate them several times. Introduce the new module, rvu_cptcommon, to provide the common functions to both modules. Fixes: 19d8e8c7be15 ("crypto: octeontx2 - add virtual function driver support") Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
eb33cd91 |
|
25-May-2021 |
Srujana Challa <schalla@marvell.com> |
crypto: octeontx2 - add support to map LMTST region for CN10K On CN10K platform transmit/receive buffer alloc and free from/to hardware had changed to support burst operation. Whereas pervious silicon's only support single buffer free at a time. To Support the same firmware allocates a DRAM region for each PF/VF for storing LMTLINES. These LMTLINES are used to send CPT commands to HW. PF/VF LMTST region is accessed via BAR4. PFs LMTST region is followed by its VFs mbox memory. The size of region varies from 2KB to 256KB based on number of LMTLINES configured. This patch adds support for mapping of PF/VF LMTST region. Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
4cd8c315 |
|
25-May-2021 |
Srujana Challa <schalla@marvell.com> |
crypto: octeontx2 - Add mailbox support for CN10K Mailbox region configuration has some changes on CN10K platform from OcteonTX2(CN9XX) platform. On CN10K platform: The DRAM region allocated to PF is enumerated as PF BAR4 memory. PF BAR4 contains AF-PF mbox region followed by its VFs mbox region. AF-PF mbox region base address is configured at RVU_AF_PFX_BAR4_ADDR PF-VF mailbox base address is configured at RVU_PF(x)_VF_MBOX_ADDR = RVU_AF_PF()_BAR4_ADDR+64KB. PF access its mbox region via BAR4, whereas VF accesses PF-VF DRAM mailboxes via BAR2 indirect access. On CN9XX platform: Mailbox region in DRAM is divided into two parts AF-PF mbox region and PF-VF mbox region i.e all PFs mbox region is contiguous similarly all VFs. The base address of the AF-PF mbox region is configured at RVU_AF_PF_BAR4_ADDR. AF-PF1 mbox address can be calculated as RVU_AF_PF_BAR4_ADDR * mbox size. This patch changes mbox initialization to support both CN9XX and CN10K platform. This patch also removes platform specific name from the PF/VF driver name to make it appropriate for all supported platforms. Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
b33fa5ff |
|
26-Jan-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
crypto: octeontx2 - fix signedness bug in cptvf_register_interrupts() The "num_vec" has to be signed for the error handling to work. Fixes: 19d8e8c7be15 ("crypto: octeontx2 - add virtual function driver support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
6f03f0e8 |
|
15-Jan-2021 |
Srujana Challa <schalla@marvell.com> |
crypto: octeontx2 - register with linux crypto framework CPT offload module utilises the linux crypto framework to offload crypto processing. This patch registers supported algorithms by calling registration functions provided by the kernel crypto API. The module currently supports: - AES block cipher in CBC,ECB and XTS mode. - 3DES block cipher in CBC and ECB mode. - AEAD algorithms. authenc(hmac(sha1),cbc(aes)), authenc(hmac(sha256),cbc(aes)), authenc(hmac(sha384),cbc(aes)), authenc(hmac(sha512),cbc(aes)), authenc(hmac(sha1),ecb(cipher_null)), authenc(hmac(sha256),ecb(cipher_null)), authenc(hmac(sha384),ecb(cipher_null)), authenc(hmac(sha512),ecb(cipher_null)), rfc4106(gcm(aes)). Signed-off-by: Suheil Chandran <schandran@marvell.com> Signed-off-by: Lukasz Bartosik <lbartosik@marvell.com> Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
8ec8015a |
|
15-Jan-2021 |
Srujana Challa <schalla@marvell.com> |
crypto: octeontx2 - add support to process the crypto request Attach LFs to CPT VF to process the crypto requests and register LF interrupts. Signed-off-by: Suheil Chandran <schandran@marvell.com> Signed-off-by: Lukasz Bartosik <lbartosik@marvell.com> Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
19d8e8c7 |
|
15-Jan-2021 |
Srujana Challa <schalla@marvell.com> |
crypto: octeontx2 - add virtual function driver support Add support for the Marvell OcteonTX2 CPT virtual function driver. This patch includes probe, PCI specific initialization and interrupt handling. Signed-off-by: Suheil Chandran <schandran@marvell.com> Signed-off-by: Lukasz Bartosik <lbartosik@marvell.com> Signed-off-by: Srujana Challa <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|