- 13 Oct, 2023 23 commits
-
-
Lucas Segarra Fernandez authored
QAT devices implement a mechanism that allows them to go autonomously to a low power state depending on the load. Expose power management info by providing the "pm_status" file under debugfs. This includes PM state, PM event log, PM event counters, PM HW CSRs, per-resource type constrain counters and per-domain power gating status specific to the QAT device. This information is retrieved from (1) the FW by means of ICP_QAT_FW_PM_INFO command, (2) CSRs and (3) counters collected by the device driver. In addition, add logic to keep track and report power management event interrupts and acks/nacks sent to FW to allow/prevent state transitions. Signed-off-by:
Lucas Segarra Fernandez <lucas.segarra.fernandez@intel.com> Reviewed-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Lucas Segarra Fernandez authored
Include kernel.h for GENMASK(), kstrtobool() and types. Add forward declaration for struct adf_accel_dev. Remove unneeded include. This change doesn't introduce any function change. Signed-off-by:
-
Om Prakash Singh authored
Add hw_random interface support in qcom-rng driver as new IP block in Qualcomm SoC has inbuilt NIST SP800 90B compliant entropic source to generate true random number. Keeping current rng_alg interface as well for random number generation using Kernel Crypto API. Signed-off-by:
Om Prakash Singh <quic_omprsing@quicinc.com> Reviewed-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Acked-by:
-
Neil Armstrong authored
Document SM8550 compatible for the True Random Number Generator. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Neil Armstrong authored
It has been reported at [1] the RNG HW on SM8450 is in fact a True Random Number Generator and no more Pseudo, document this by adding a new qcom,trng and the corresponding SoC specific sm8450 compatible. [1] https://lore.kernel.org/all/20230818161720.3644424-1-quic_omprsing@quicinc.com/Suggested-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
-
Herbert Xu authored
As skcipher spawn users can no longer assume the spawn is of type struct skcipher_alg, these helpers are no longer used. Remove them. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
Add code to handle an underlying lskcihper object when grabbing an skcipher spawn. Fixes: 31865c4c ("crypto: skcipher - Add lskcipher") Signed-off-by:
-
Herbert Xu authored
As skcipher spawns can be of two different types (skcipher vs. lskcipher), only the common fields can be accessed. Add a helper to return the common algorithm object. Signed-off-by: -
Herbert Xu authored
Replace skcipher implementation with lskcipher. Signed-off-by: -
Herbert Xu authored
As lskcipher requires the ecb wrapper for the transition add an explicit dependency on it so that it is always present. This can be removed once all simple ciphers have been converted to lskcipher. Reported-by:
Nathan Chancellor <nathan@kernel.org> Fixes: 705b52fe ("crypto: cbc - Convert from skcipher to lskcipher") Signed-off-by:
-
Giovanni Cabiddu authored
Create CRYPTO_QAT namespace for symbols exported by the qat_common module and import those in the QAT drivers. It will reduce the global namespace crowdedness and potential misuse or the API. This does not introduce any functional change. Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
- 12 Oct, 2023 3 commits
-
-
Herbert Xu authored
Remove zlib-deflate test vectors as it no longer exists in the kernel. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org>
-
Herbert Xu authored
Remove the implementation of zlib-deflate because it is completely unused in the kernel. Signed-off-by:
-
Herbert Xu authored
Remove the implementation of zlib-deflate because it is completely unused in the kernel. Signed-off-by:
-
- 05 Oct, 2023 14 commits
-
-
Dimitri John Ledkov authored
Remove support for md4 md5 hash and signatures in x.509 certificate parsers, pkcs7 signature parser, authenticode parser. All of these are insecure or broken, and everyone has long time ago migrated to alternative hash implementations. Also remove md2 & md3 oids which have already didn't have support. This is also likely the last user of md4 in the kernel, and thus crypto/md4.c and related tests in tcrypt & testmgr can likely be removed. Other users such as cifs smbfs ext modpost sumversions have their own internal implementation as needed. Signed-off-by:
Dimitri John Ledkov <dimitri.ledkov@canonical.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
-
Randy Dunlap authored
Correct typo of "destination". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by:
-
Randy Dunlap authored
Correct typos of "destination". Signed-off-by:
-
Alexey Romanov authored
Add compatible for hardware number generator node for Amlogic S4-series. Signed-off-by:
Alexey Romanov <avromanov@sberdevices.ru> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Alexey Romanov authored
For some Amlogic SOC's, mechanism to obtain random number has been changed. For example, S4 now uses status bit waiting algo. Signed-off-by:
-
Weili Qian authored
When the Kunpeng accelerator executes tasks such as encryption and decryption have minimum requirements on the number of device queues. If the number of queues does not meet the requirement, the process initialization will fail. Therefore, the driver checks the number of queues on the device before registering the algorithm. If the number does not meet the requirements, the driver does not register the algorithm to crypto subsystem, the device is still added to the qm_list. Signed-off-by:
Weili Qian <qianweili@huawei.com> Signed-off-by:
-
Weili Qian authored
The type of aeq has only 4bits in dw0 17 to 20bits, but 15bits(17 to 31bits) are read in function qm_aeq_thread(). The remaining 11bits(21 to 31bits) are reserved for aeq, but may not be 0. To avoid getting incorrect value of type, other bits are cleared. Signed-off-by:
-
Longfang Liu authored
If the queue isolation feature is enabled, the number of queues supported by the device changes. When PF is enabled using the current default number of queues, the default number of queues may be greater than the number supported by the device. As a result, the PF fails to be bound to the driver. After modification, if queue isolation feature is enabled, when the default queue parameter is greater than the number supported by the device, the number of enabled queues will be changed to the number supported by the device, so that the PF and driver can be properly bound. Fixes: 8bbecfb4 ("crypto: hisilicon/qm - add queue isolation support for Kunpeng930") Signed-off-by:
Longfang Liu <liulongfang@huawei.com> Signed-off-by:
-
Chang S. Bae authored
Currently, the alignment of each field in struct aesni_xts_ctx occurs right before every access. However, it's possible to perform this alignment ahead of time. Introduce a helper function that converts struct crypto_skcipher *tfm to struct aesni_xts_ctx *ctx and returns an aligned address. Utilize this helper function at the beginning of each XTS function and then eliminate redundant alignment code. Suggested-by:
Eric Biggers <ebiggers@kernel.org> Link: https://lore.kernel.org/all/ZFWQ4sZEVu%2FLHq+Q@gmail.com/Signed-off-by:
Chang S. Bae <chang.seok.bae@intel.com> Cc: linux-crypto@vger.kernel.org Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Chang S. Bae authored
Currently, every field in struct aesni_xts_ctx is defined as a byte array of the same size as struct crypto_aes_ctx. This data type is obscure and the choice lacks justification. To rectify this, update the field type in struct aesni_xts_ctx to match its actual structure. Suggested-by:
-
Chang S. Bae authored
The address alignment code has been duplicated for each mode. Instead of duplicating the same code, refactor the alignment code and simplify the alignment helpers. Suggested-by:
-
Lukas Wunner authored
The ASN.1 module in RFC 5280 appendix A.1 uses EXPLICIT TAGS whereas the one in appendix A.2 uses IMPLICIT TAGS. The kernel's simplified asn1_compiler.c always uses EXPLICIT TAGS, hence definitions from appendix A.2 need to be annotated as IMPLICIT for the compiler to generate RFC-compliant code. In particular, GeneralName is defined in appendix A.2: GeneralName ::= CHOICE { otherName [0] OtherName, ... dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ... } Because appendix A.2 uses IMPLICIT TAGS, the IA5String tag (0x16) of a dNSName is not rendered. Instead, the string directly succeeds the [2] tag (0x82). Likewise, the SEQUENCE tag (0x30) of an OtherName is not rendered. Instead, only the constituents of the SEQUENCE are rendered: An OID tag (0x06), a [0] tag (0xa0) and an ANY tag. That's three consecutive tags instead of a single encompassing tag. The situation is different for x400Address and directoryName choices: They reference ORAddress and Name, which are defined in appendix A.1, therefore use EXPLICIT TAGS. The AKID ASN.1 module is missing several IMPLICIT annotations, hence isn't RFC-compliant. In the unlikely event that an AKID contains other elements beside a directoryName, users may see parse errors. Add the missing annotations but do not tag this commit for stable as I am not aware of any issue reports. Fixes are only eligible for stable if they're "obviously correct" and with ASN.1 there's no such thing. Signed-off-by:Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Fabio Estevam authored
i.MX27 has only one Sahara interrupt. i.MX53 has two. Describe this difference. Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
-
Fabio Estevam authored
Describe the clocks (ipg and ahb) needed by Sahara block to operate. Signed-off-by:
-
