- 24 Mar, 2023 8 commits
-
-
Herbert Xu authored
Add dependency on HAS_IOMEM as the build will fail without it. Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202303161354.T2OZFUFZ-lkp@intel.com/Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Uwe Kleine-König authored
A platform device's remove callback is only ever called after the probe callback returned success. In the case of kmb_ocs_aes_remove() this means that kmb_ocs_aes_probe() succeeded before and so platform_set_drvdata() was called with a non-zero argument and platform_get_drvdata() returns non-NULL. This prepares making remove callbacks return void. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Ye Xingchen authored
crypto/algapi.h is included more than once. Signed-off-by:
Ye Xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
-
Yang Li authored
According to commit 890cc39a ("drivers: provide devm_platform_get_and_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Yang Li authored
According to commit 890cc39a ("drivers: provide devm_platform_get_and_ioremap_resource()"), convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by:
-
Herbert Xu authored
The HASH_ALG_COMMON macro cannot be parsed by kdoc so mark it as a normal comment instead of kdoc. Also add HASH_ALG_COMMON as a structure member of shash_alg. Fixes: 0e4e6d7094df ("crypto: hash - Count error stats differently") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Randy Dunlap authored
Fix kernel-doc warnings by adding "struct" keyword or "enum" keyword. Also fix 2 function parameter descriptions. Change some functions and structs from kernel-doc /** notation to regular /* comment notation. async_pq.c:18: warning: cannot understand function prototype: 'struct page *pq_scribble_page; ' async_pq.c:18: error: Cannot parse struct or union! async_pq.c:40: warning: No description found for return value of 'do_async_gen_syndrome' async_pq.c:109: warning: Function parameter or member 'blocks' not described in 'do_sync_gen_syndrome' async_pq.c:109: warning: Function parameter or member 'offsets' not described in 'do_sync_gen_syndrome' async_pq.c:109: warning: Function parameter or member 'disks' not described in 'do_sync_gen_syndrome' async_pq.c:109: warning: Function parameter or member 'len' not described in 'do_sync_gen_syndrome' async_pq.c:109: warning: Function parameter or member 'submit' not described in 'do_sync_gen_syndrome' async_tx.c:136: warning: cannot understand function prototype: 'enum submit_disposition ' async_tx.c:264: warning: Function parameter or member 'tx' not described in 'async_tx_quiesce' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Toke Høiland-Jørgensen authored
The crypto_unregister_alg() function expects callers to ensure that any algorithm that is unregistered has a refcnt of exactly 1, and issues a BUG_ON() if this is not the case. However, there are in fact drivers that will call crypto_unregister_alg() without ensuring that the refcnt has been lowered first, most notably on system shutdown. This causes the BUG_ON() to trigger, which prevents a clean shutdown and hangs the system. To avoid such hangs on shutdown, demote the BUG_ON() in crypto_unregister_alg() to a WARN_ON() with early return. Cc stable because this problem was observed on a 6.2 kernel, cf the link below. Link: https://lore.kernel.org/r/87r0tyq8ph.fsf@toke.dk Cc: stable@vger.kernel.org Signed-off-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
-
- 17 Mar, 2023 23 commits
-
-
Herbert Xu authored
The Crypto API hashing paradigm requires the hardware state to be exported between *each* request because multiple unrelated hashes may be processed concurrently. The stm32 hardware is capable of producing the hardware hashing state but it was only doing it in the export function. This is not only broken for export as you can't export a kernel pointer and reimport it, but it also means that concurrent hashing was fundamentally broken. Fix this by moving the saving and restoring of hardware hash state between each and every hashing request. Fixes: 8a1012d3 ("crypto: stm32 - Support for STM32 HASH module") Reported-by:
Li kunyu <kunyu@nfschina.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
-
Herbert Xu authored
Change the emptymsg check in stm32_hash_copy_hash to rely on whether we have any existing hash state, rather than whether this particular update request is empty. Also avoid computing the hash for empty messages as this could hang. Signed-off-by:
-
Herbert Xu authored
The bit HASH_FLAGS_ERRORS was never used. Remove it. Reviewed-by:
-
Herbert Xu authored
Create a new struct stm32_hash_state so that it may be exported in future instead of the entire request context. Reviewed-by:
-
Herbert Xu authored
The variable hdev->err is never read so it can be removed. Also remove a spurious inclusion of linux/crypto.h. Reviewed-by:
-
Herbert Xu authored
The current finup code is unnecessarily convoluted. There is no need to call update and final separately as update already does all the necessary work on its own. Simplify this by utilising the HASH_FLAGS_FINUP bit in rctx to indicate only finup and use the HASH_FLAGS_FINAL bit instead to signify processing common to both final and finup. Reviewed-by:
-
Herbert Xu authored
There is no need to poll separate for update and final. We could merge them into do_one_request. Also fix the error handling so that we don't poll (and overwrite the error) when an error has already occurred. Reviewed-by:
-
Herbert Xu authored
The CSR registers go from 0 to 53. So the number of registers should be 54. Reviewed-by:
-
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 9 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:
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:
-
