- 17 Mar, 2023 16 commits
-
-
Herbert Xu authored
The CSR registers go from 0 to 53. So the number of registers should be 54. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Luis Chamberlain authored
There is no need to declare an extra tables to just create directory, this can be easily be done with a prefix path with register_sysctl(). Simplify this registration. Signed-off-by:
Luis Chamberlain <mcgrof@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/crypto/atmel-sha204a.c:129:34: error: ‘atmel_sha204a_dt_ids’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Mario Limonciello authored
Some platforms support using a doorbell to communicate. Export this feature for other drivers to utilize as well. Link: https://lore.kernel.org/linux-i2c/20220916131854.687371-3-jsd@semihalf.com/Suggested-by:
Jan Dabros <jsd@semihalf.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Mario Limonciello authored
Client PSP parts support the platform access interface. Add the register offsets so that client parts will initialize this interface. Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Mario Limonciello authored
Some platforms with a PSP support an interface for features that interact directly with the PSP instead of through a SEV or TEE environment. Initialize this interface so that other drivers can consume it. These drivers may either be subdrivers for the ccp module or external modules. For external modules, export a symbol for them to utilize. Acked-by:
-
Mario Limonciello authored
Some of the bits and fields used for mailboxes communicating with the PSP are common across all mailbox implementations (SEV, TEE, etc). Move these bits into the common `linux/psp.h` so they don't need to be re-defined for each implementation. Acked-by:
Rijo Thomas <Rijo-john.Thomas@amd.com> Acked-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by:
-
Mario Limonciello authored
The TEE subdriver for CCP, the amdtee driver and the i2c-designware-amdpsp drivers all include `psp-sev.h` even though they don't use SEV functionality. Move the definition of `__psp_pa` into a common header to be included by all of these drivers. Reviewed-by:
-
Mario Limonciello authored
The only PSP mailbox that currently supports interrupt on completion is the SEV mailbox. Drop the dead code for the TEE subdriver to potentially call it. Acked-by:
-
Bjorn Helgaas authored
<linux/aer.h> is unused, so remove it. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: Yang Shen <shenyang39@huawei.com> Cc: Zhou Wang <wangzhou1@hisilicon.com> Cc: Nick Terrell <terrelln@fb.com> Acked-by:
Longfang Liu <liulongfang@huawei.com> Signed-off-by:
-
Bjorn Helgaas authored
<linux/aer.h> is unused, so remove it. Signed-off-by:
-
Bjorn Helgaas authored
<linux/aer.h> is unused, so remove it. Signed-off-by:
-
Bjorn Helgaas authored
<linux/aer.h> is unused, so remove it. Signed-off-by:
-
Bjorn Helgaas authored
<linux/aer.h> is unused, so remove it. Signed-off-by:
-
Bjorn Helgaas authored
pci_enable_pcie_error_reporting() enables the device to send ERR_* Messages. Since f26e58bf ("PCI/AER: Enable error reporting when AER is native"), the PCI core does this for all devices during enumeration, so the driver doesn't need to do it itself. Remove the redundant pci_enable_pcie_error_reporting() call from the driver. Also remove the corresponding pci_disable_pcie_error_reporting() from the driver .remove() path. Note that this only controls ERR_* Messages from the device. An ERR_* Message may cause the Root Port to generate an interrupt, depending on the AER Root Error Command register managed by the AER service driver. Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by:
-
Shashank Gupta authored
The thread to arbiter mapping for 4xxx devices does not allow to achieve optimal performance for the compression service as it makes all the engines to compete for the same resources. Update the logic so that a custom optimal mapping is used for the compression service. Signed-off-by:
Shashank Gupta <shashank.gupta@intel.com> Reviewed-by:
-
- 14 Mar, 2023 24 commits
-
-
Damian Muszynski authored
QAT_402xx is a derivative of 4xxx. Add support for that device in the qat_4xxx driver by including the DIDs (both PF and VF), extending the probe and the firmware loader. 402xx uses different firmware images than 4xxx. To allow that the logic that selects the firmware images was modified. Signed-off-by:
Damian Muszynski <damian.muszynski@intel.com> Reviewed-by:
-
Neal Liu authored
'idx' is not initialized if it's not EXP_MODE nor MOD_MODE. Use "else" instead to fix it. Signed-off-by:
Neal Liu <neal_liu@aspeedtech.com> Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/202302261052.CVFRyq6F-lkp@intel.com/Signed-off-by:
-
Horia Geanta authored
Issues: - Job ring device is busy when do kexec reboot - Failed to flush job ring when do system suspend-resume Fix: Flush the job ring to stop the running jobs. Signed-off-by:
Horia Geanta <horia.geanta@nxp.com> Signed-off-by:
Franck LENORMAND <franck.lenormand@nxp.com> Reviewed-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Signed-off-by:
-
Jonathan McDowell authored
A failure loading the safexcel driver results in the following warning on boot, because the IRQ affinity has not been correctly cleaned up. Ensure we clean up the affinity and workqueues on a failure to load the driver. crypto-safexcel: probe of f2800000.crypto failed with error -2 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340 Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4 CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3 Hardware name: MikroTik RB5009 (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : free_irq+0x300/0x340 lr : free_irq+0x2e0/0x340 sp : ffff800008fa3890 x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000 x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50 x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80 x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040 x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370 x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18 x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188 x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0 Call trace: free_irq+0x300/0x340 devm_irq_release+0x14/0x20 devres_release_all+0xa0/0x100 device_unbind_cleanup+0x14/0x60 really_probe+0x198/0x2d4 __driver_probe_device+0x74/0xdc driver_probe_device+0x3c/0x110 __driver_attach+0x8c/0x190 bus_for_each_dev+0x6c/0xc0 driver_attach+0x20/0x30 bus_add_driver+0x148/0x1fc driver_register+0x74/0x120 __platform_driver_register+0x24/0x30 safexcel_init+0x48/0x1000 [crypto_safexcel] do_one_initcall+0x4c/0x1b0 do_init_module+0x44/0x1cc load_module+0x1724/0x1be4 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x1c/0x24 invoke_syscall+0x44/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x20/0x80 el0_svc+0x14/0x4c el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x148/0x14c ---[ end trace 0000000000000000 ]--- Fixes: 1b44c5a6 ("inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by:
Jonathan McDowell <noodles@earth.li> Cc: stable@vger.kernel.org Signed-off-by:
-
Jonathan McDowell authored
At the moment if there is no firmware available for the safexcel driver it will fail to load with a cryptic: crypto-safexcel f2800000.crypto: TRC init: 15360d,80a (48r,256h) crypto-safexcel f2800000.crypto: HW init failed (-2) Raise the logging level of the firmware load failure to err rather than dbg so that it's obvious what the reason for the HW init failure is. Signed-off-by:
Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Shashank Gupta authored
The state machine functions adf_dev_init(), adf_dev_start(), adf_dev_stop() adf_dev_shutdown() and adf_dev_shutdown_cache_cfg() are only used internally within adf_init.c. Do not export these functions and make them static as state transitions are now performed using the safe function adf_dev_up() and adf_dev_down(). This commit does not implement any functional change. Signed-off-by:
-
Shashank Gupta authored
Refactor the restart logic by moving it into the function adf_dev_restart() which uses the safe function adf_dev_up() and adf_dev_down(). This commit does not implement any functional change. Signed-off-by:
-
Shashank Gupta authored
The device state machine functions are unsafe and interdependent on each other. To perform a state transition, these shall be called in a specific order: * device up: adf_dev_init() -> adf_dev_start() * device down: adf_dev_stop() -> adf_dev_shutdown() Replace all the state machine functions used in the QAT driver with the safe wrappers adf_dev_up() and adf_dev_down(). Signed-off-by:
-
Shashank Gupta authored
The sysfs `state` attribute is not protected against race conditions. If multiple processes perform a device state transition on the same device in parallel, unexpected behaviors might occur. For transitioning the device state, adf_sysfs.c calls the functions adf_dev_init(), adf_dev_start(), adf_dev_stop() and adf_dev_shutdown() which are unprotected and interdependent on each other. To perform a state transition, these functions needs to be called in a specific order: * device up: adf_dev_init() -> adf_dev_start() * device down: adf_dev_stop() -> adf_dev_shutdown() This change introduces the functions adf_dev_up() and adf_dev_down() which wrap the state machine functions and protect them with a per-device lock. These are then used in adf_sysfs.c instead of the individual state transition functions. Fixes: 5ee52118 ("crypto: qat - expose device state through sysfs for 4xxx") Signed-off-by:
-
Shashank Gupta authored
The function adf_sysfs_init() is used by qat_4xxx to create sysfs attributes. This is called by the probe function before starting a device. With this sequence, there might be a chance that the sysfs entries for configuration might be changed by a user while the driver is performing a device bring-up causing unexpected behaviors. Delay the creation of sysfs entries after adf_dev_start(). Signed-off-by:
-
Eric Biggers authored
The performance of the crypto fuzz tests has greatly regressed since v5.18. When booting a kernel on an arm64 dev board with all software crypto algorithms and CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled, the fuzz tests now take about 200 seconds to run, or about 325 seconds with lockdep enabled, compared to about 5 seconds before. The root cause is that the random number generation has become much slower due to commit d4150779 ("random32: use real rng for non-deterministic randomness"). On my same arm64 dev board, at the time the fuzz tests are run, get_random_u8() is about 345x slower than prandom_u32_state(), or about 469x if lockdep is enabled. Lockdep makes a big difference, but much of the rest comes from the get_random_*() functions taking a *very* slow path when the CRNG is not yet initialized. Since the crypto self-tests run early during boot, even having a hardware RNG driver enabled (CONFIG_CRYPTO_DEV_QCOM_RNG in my case) doesn't prevent this. x86 systems don't have this issue, but they still see a significant regression if lockdep is enabled. Converting the "Fully random bytes" case in generate_random_bytes() to use get_random_bytes() helps significantly, improving the test time to about 27 seconds. But that's still over 5x slower than before. This is all a bit silly, though, since the fuzz tests don't actually need cryptographically secure random numbers. So let's just make them use a non-cryptographically-secure RNG as they did before. The original prandom_u32() is gone now, so let's use prandom_u32_state() instead, with an explicitly managed state, like various other self-tests in the kernel source tree (rbtree_test.c, test_scanf.c, etc.) already do. This also has the benefit that no locking is required anymore, so performance should be even better than the original version that used prandom_u32(). Fixes: d4150779 ("random32: use real rng for non-deterministic randomness") Cc: stable@vger.kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
aesbs_ecb_encrypt(), aesbs_ecb_decrypt(), aesbs_xts_encrypt(), and aesbs_xts_decrypt() are called via indirect function calls. Therefore they need to use SYM_TYPED_FUNC_START instead of SYM_FUNC_START to cause their type hashes to be emitted when the kernel is built with CONFIG_CFI_CLANG=y. Otherwise, the code crashes with a CFI failure if the compiler doesn't happen to optimize out the indirect calls. Fixes: c50d3285 ("arm64: Add types to indirect called assembly functions") Cc: stable@vger.kernel.org Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
-
Neal Liu authored
Since the acry_dev->buf_addr may be NULL, add error handling to prevent any additional access to avoid potential issues. Signed-off-by:
-
Anthony Yznaga authored
For multithreaded jobs the computed chunk size is rounded up by the caller-specified alignment. However, the number of worker threads to use is computed using the minimum chunk size without taking alignment into account. A sufficiently large alignment value can result in too many worker threads being allocated for the job. Signed-off-by:
Anthony Yznaga <anthony.yznaga@oracle.com> Acked-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by:
-
Vladimir Zapolskiy authored
The added 'qcom,qce' compatible value will serve as a sole QCE IP family compatible, since a particular QCE IP version is discoverablem thus, if it'd be needed to differentiate various IP versions, it can be obtained in runtime. Two IP version based compatibles are left untouched to preserve backward DTB ABI compatibility. Signed-off-by:
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Thara Gopinath authored
On certain Snapdragon processors, the crypto engine clocks are enabled by default by security firmware and the driver should not handle the clocks. Make acquiring of all the clocks optional in crypto engine driver, so that the driver initializes properly even if no clocks are specified in the dt. Tested-by:
Jordan Crouse <jorcrous@amazon.com> Signed-off-by:
Thara Gopinath <thara.gopinath@gmail.com> Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> [Bhupesh: Massage the commit log] Signed-off-by:
-
Thara Gopinath authored
Crypto engine on certain Snapdragon processors like sm8150, sm8250, sm8350 etc. requires interconnect path between the engine and memory to be explicitly enabled and bandwidth set prior to any operations. Add support in the qce core to enable the interconnect path appropriately. Tested-by:
-
Vladimir Zapolskiy authored
Add a family compatible for QCE IP on SM8550 SoC, which is equal to QCE IP found on SM8150 SoC and described in the recently updated device tree bindings documentation, as well add a generic QCE IP family compatible. Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Vladimir Zapolskiy authored
On newer Qualcomm SoCs the crypto engine clocks are enabled by default by security firmware. To drop clocks and clock-names from the list of required properties use 'qcom,sm8150-qce' compatible name. The change is based on Neil Armstrong's observation and an original change. Cc: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Vladimir Zapolskiy authored
Introduce a generic IP family compatible 'qcom,qce' and its two derivatives based on SoC names rather than on IP versions. Having a generic compatible is only partially sufficient, the QCE IP version can be discovered in runtime, however there are two known groups of QCE IP versions, which require different DT properties, these two groups are populated with SoC based compatibles known at the moment. Keep the old compatible 'qcom,crypto-v5.1' and document an existing and already used but not previously documented compatible 'qcom,crypto-v5.4' for backward compatibility of DTB ABI, mark both of the compatibles as deprecated. The change is based on the original one written by Bhupesh Sharma, adding a generic family compatible is suggested by Neil Armstrong. Cc: Bhupesh Sharma <bhupesh.sharma@linaro.org> Cc: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
-
Bhupesh Sharma authored
Add the missing optional property - 'iommus' to the device-tree binding documentation for qcom-qce crypto IP. This property describes the phandle(s) to apps_smmu node with sid mask. Cc: Bjorn Andersson <andersson@kernel.org> Reviewed-by:
Rob Herring <robh@kernel.org> Tested-by:
-
Bhupesh Sharma authored
Add 'interconnects' and 'interconnect-names' as optional properties to the device-tree binding documentation for Qualcomm crypto IP. These properties describe the interconnect path between crypto and main memory and the interconnect type respectively. Cc: Bjorn Andersson <andersson@kernel.org> Acked-by:
-
Bhupesh Sharma authored
Add the entry for 'Documentation/devicetree/bindings/crypto/qcom-qce.yaml' to the appropriate section for 'QUALCOMM CRYPTO DRIVERS' in MAINTAINERS file. Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
-
Bhupesh Sharma authored
Convert Qualcomm QCE crypto devicetree binding to YAML. Reviewed-by:
-
