summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-20PM: dpm_watchdog: add module param to backtrace all CPUsSergey Senozhatsky
Add dpm_watchdog_all_cpu_backtrace module parameter which controls all CPU backtrace dump before the DPM watchdog panics the system. This is expected to help understand what might have caused device timeout. Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://patch.msgid.link/20251007063551.3147937-1-senozhatsky@chromium.org [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-10-20PM: sleep: Introduce CALL_PM_OP() macro to simplify codeKaushlendra Kumar
Add CALL_PM_OP() macro to eliminate a repetitive code pattern in power management generic operations. Replace analogous driver PM callback invocation logic across all pm_generic_*() functions with a single macro that handles the NULL pointer checks and function calls. This reduces code size while maintaining the same functionality and improving code maintainability. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://patch.msgid.link/20250919124437.3075016-1-kaushlendra.kumar@intel.com [ rjw: Subject and changelog edits, adjust white space ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-10-20iio: adc: max14001: New driverMarilene Andrade Garcia
The MAX14001/MAX14002 is configurable, isolated 10-bit ADCs for multi-range binary inputs. In addition to ADC readings, the MAX14001/MAX14002 offers more features, like a binary comparator, a filtered reading that can provide the average of the last 2, 4, or 8 ADC readings, and an inrush comparator that triggers the inrush current. There is also a fault feature that can diagnose seven possible fault conditions. And an option to select an external or internal ADC voltage reference. MAX14001/MAX14002 features implemented so far: - Raw ADC reading. - MV fault disable. - Selection of external or internal ADC voltage reference, depending on whether it is declared in the device tree. Co-developed-by: Kim Seer Paller <kimseer.paller@analog.com> Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com> Signed-off-by: Marilene Andrade Garcia <marilene.agarcia@gmail.com> Tested-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-20drm/i915/panic: fix panic structure allocation memory leakJani Nikula
Separating the panic allocation from framebuffer allocation in commit 729c5f7ffa83 ("drm/{i915,xe}/panic: move framebuffer allocation where it belongs") failed to deallocate the panic structure anywhere. The fix is two-fold. First, free the panic structure in intel_user_framebuffer_destroy() in the general case. Second, move the panic allocation later to intel_framebuffer_init() to not leak the panic structure in error paths (if any, now or later) between intel_framebuffer_alloc() and intel_framebuffer_init(). v2: Rebase Fixes: 729c5f7ffa83 ("drm/{i915,xe}/panic: move framebuffer allocation where it belongs") Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Reported-by: Michał Grzelak <michal.grzelak@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Michał Grzelak <michal.grzelak@intel.com> # v1 Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251015095135.2183415-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 8f8ef09fcf6a3b00369bfc704e8f68d7474eca94) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-20scsi: fnic: Self-assignment of intr_time_type has no effectQiang Liu
Remove the self-assignment statement of the intr_time_type variable. Signed-off-by: Qiang Liu <liuqiang@kylinos.cn> Reviewed-by: Karan Tilak Kumar <kartilak@cisco.com> Link: https://patch.msgid.link/20251017075504.143491-1-liuqiangneo@163.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-10-20drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02Dnyaneshwar Bhadane
Load the DMC for Xe3_LPD version 30.02. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://lore.kernel.org/r/20251016131517.2032684-1-dnyaneshwar.bhadane@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-10-20accel/amdxdna: Support firmware debug bufferLizhi Hou
To collect firmware debug information, the userspace application allocates a AMDXDNA_BO_DEV buffer object through DRM_IOCTL_AMDXDNA_CREATE_BO. Then it associates the buffer with the hardware context through DRM_IOCTL_AMDXDNA_CONFIG_HWCTX which requests firmware to bind the buffer through a mailbox command. The firmware then writes the debug data into this buffer. The buffer can be mapped into userspace so that applications can retrieve and analyze the firmware debug information. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/20251016203016.819441-1-lizhi.hou@amd.com
2025-10-20scsi: smartpqi: Prefer kmalloc_array() over kmalloc()Bhanu Seshu Kumar Valluri
As a best practice use kmalloc_array() to safely calculate dynamic object sizes without overflow. [mkp: line exceeding 100 chars, added newline] Acked-by: Don Brace <don.brace@microchip.com> Signed-off-by: Bhanu Seshu Kumar Valluri <bhanuseshukumar@gmail.com> Link: https://patch.msgid.link/20251007065345.8853-1-bhanuseshukumar@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-10-20scsi: megaraid_sas: Avoid a couple -Wflex-array-member-not-at-end warningsGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Use the new TRAILING_OVERLAP() helper to fix the following warnings: drivers/scsi/megaraid/megaraid_sas_fusion.h:1153:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/scsi/megaraid/megaraid_sas_fusion.h:1198:32: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] This helper creates a union between a flexible-array member (FAM) and a set of MEMBERS that would otherwise follow it --in this case 'struct MR_LD_SPAN_MAP ldSpanMap[MAX_LOGICAL_DRIVES_DYN]' and 'struct MR_LD_SPAN_MAP ldSpanMap[MAX_LOGICAL_DRIVES]' in the corresponding structures. This overlays the trailing members onto the FAM (struct MR_LD_SPAN_MAP ldSpanMap[];) while keeping the FAM and the start of MEMBERS aligned. The static_assert() ensures this alignment remains, and it's intentionally placed inmediately after the corresponding structures --no blank line in between. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/aM1E7Xa8qYdZ598N@kspp Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-10-20scsi: isci: Avoid -Wflex-array-member-not-at-end warningGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Move the conflicting declaration (which happens to be in a union, so we're moving the entire union) to the end of the corresponding structure. Notice that `struct ssp_response_iu` is a flexible structure, this is a structure that contains a flexible-array member. With these changes fix the following warning: drivers/scsi/isci/task.h:92:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/aM09bpl1xj9KZSZl@kspp Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-10-20scsi: core: Fix a regression triggered by scsi_host_busy()Bart Van Assche
Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag iterators") introduced the following regression: Call trace: __srcu_read_lock+0x30/0x80 (P) blk_mq_tagset_busy_iter+0x44/0x300 scsi_host_busy+0x38/0x70 ufshcd_print_host_state+0x34/0x1bc ufshcd_link_startup.constprop.0+0xe4/0x2e0 ufshcd_init+0x944/0xf80 ufshcd_pltfrm_init+0x504/0x820 ufs_rockchip_probe+0x2c/0x88 platform_probe+0x5c/0xa4 really_probe+0xc0/0x38c __driver_probe_device+0x7c/0x150 driver_probe_device+0x40/0x120 __driver_attach+0xc8/0x1e0 bus_for_each_dev+0x7c/0xdc driver_attach+0x24/0x30 bus_add_driver+0x110/0x230 driver_register+0x68/0x130 __platform_driver_register+0x20/0x2c ufs_rockchip_pltform_init+0x1c/0x28 do_one_initcall+0x60/0x1e0 kernel_init_freeable+0x248/0x2c4 kernel_init+0x20/0x140 ret_from_fork+0x10/0x20 Fix this regression by making scsi_host_busy() check whether the SCSI host tag set has already been initialized. tag_set->ops is set by scsi_mq_setup_tags() just before blk_mq_alloc_tag_set() is called. This fix is based on the assumption that scsi_host_busy() and scsi_mq_setup_tags() calls are serialized. This is the case in the UFS driver. Reported-by: Sebastian Reichel <sebastian.reichel@collabora.com> Closes: https://lore.kernel.org/linux-block/pnezafputodmqlpumwfbn644ohjybouveehcjhz2hmhtcf2rka@sdhoiivync4y/ Cc: Ming Lei <ming.lei@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Ming Lei <ming.lei@redhat.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patch.msgid.link/20251007214800.1678255-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-10-20Revert "PCI: qcom: Prepare for the DWC ECAM enablement"Krishna Chaitanya Chundru
This reverts commit 4660e50cf81800f82eeecf743ad1e3e97ab72190. Commit f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'") enabled ECAM access by using the config space start as DBI address. However, this approach breaks vendor drivers that rely on the DBI address for internal accesses, especially when the vendor config space is 256MB aligned. To resolve this, avoid using the DBI as the start of config space and instead introduce a custom ECAM PCI ops implementation. Revert the qcom specific ECAM preparation logic in 4660e50cf818 ("PCI: qcom: Prepare for the DWC ECAM enablement") since it's no longer necessary. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20251017-ecam_fix-v1-2-f6faa3d0edf3@oss.qualcomm.com
2025-10-20PCI: dwc: Use custom pci_ops for root bus DBI vs ECAM config accessKrishna Chaitanya Chundru
When the vendor configuration space is 256MB aligned, the DesignWare PCIe host driver enables ECAM access and sets the DBI base to the start of the config space. This causes vendor drivers to incorrectly program iATU regions, as they rely on the DBI address for internal accesses. To fix this, avoid overwriting the DBI base when ECAM is enabled. Instead, introduce a custom pci_ops that accesses the DBI region directly for the root bus and uses ECAM for other buses. Fixes: f6fd357f7afb ("PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'") Reported-by: Ron Economos <re@w6rz.net> Closes: https://lore.kernel.org/all/eac81c57-1164-4d74-a1b4-6f353c577731@w6rz.net/ Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Ron Economos <re@w6rz.net> Link: https://patch.msgid.link/20251017-ecam_fix-v1-1-f6faa3d0edf3@oss.qualcomm.com
2025-10-20nbd: override creds to kernel when calling sock_{send,recv}msg()Ondrej Mosnacek
sock_{send,recv}msg() internally calls security_socket_{send,recv}msg(), which does security checks (e.g. SELinux) for socket access against the current task. However, _sock_xmit() in drivers/block/nbd.c may be called indirectly from a userspace syscall, where the NBD socket access would be incorrectly checked against the calling userspace task (which simply tries to read/write a file that happens to reside on an NBD device). To fix this, temporarily override creds to kernel ones before calling the sock_*() functions. This allows the security modules to recognize this as internal access by the kernel, which will normally be allowed. A way to trigger the issue is to do the following (on a system with SELinux set to enforcing): ### Create nbd device: truncate -s 256M /tmp/testfile nbd-server localhost:10809 /tmp/testfile ### Connect to the nbd server: nbd-client localhost ### Create mdraid array mdadm --create -l 1 -n 2 /dev/md/testarray /dev/nbd0 missing After these steps, assuming the SELinux policy doesn't allow the unexpected access pattern, errors will be visible on the kernel console: [ 142.204243] nbd0: detected capacity change from 0 to 524288 [ 165.189967] md: async del_gendisk mode will be removed in future, please upgrade to mdadm-4.5+ [ 165.252299] md/raid1:md127: active with 1 out of 2 mirrors [ 165.252725] md127: detected capacity change from 0 to 522240 [ 165.255434] block nbd0: Send control failed (result -13) [ 165.255718] block nbd0: Request send failed, requeueing [ 165.256006] block nbd0: Dead connection, failed to find a fallback [ 165.256041] block nbd0: Receive control failed (result -32) [ 165.256423] block nbd0: shutting down sockets [ 165.257196] I/O error, dev nbd0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.257736] Buffer I/O error on dev md127, logical block 0, async page read [ 165.258263] I/O error, dev nbd0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.259376] Buffer I/O error on dev md127, logical block 0, async page read [ 165.259920] I/O error, dev nbd0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.260628] Buffer I/O error on dev md127, logical block 0, async page read [ 165.261661] ldm_validate_partition_table(): Disk read failed. [ 165.262108] I/O error, dev nbd0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.262769] Buffer I/O error on dev md127, logical block 0, async page read [ 165.263697] I/O error, dev nbd0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.264412] Buffer I/O error on dev md127, logical block 0, async page read [ 165.265412] I/O error, dev nbd0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.265872] Buffer I/O error on dev md127, logical block 0, async page read [ 165.266378] I/O error, dev nbd0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.267168] Buffer I/O error on dev md127, logical block 0, async page read [ 165.267564] md127: unable to read partition table [ 165.269581] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.269960] Buffer I/O error on dev nbd0, logical block 0, async page read [ 165.270316] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.270913] Buffer I/O error on dev nbd0, logical block 0, async page read [ 165.271253] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 165.271809] Buffer I/O error on dev nbd0, logical block 0, async page read [ 165.272074] ldm_validate_partition_table(): Disk read failed. [ 165.272360] nbd0: unable to read partition table [ 165.289004] ldm_validate_partition_table(): Disk read failed. [ 165.289614] nbd0: unable to read partition table The corresponding SELinux denial on Fedora/RHEL will look like this (assuming it's not silenced): type=AVC msg=audit(1758104872.510:116): avc: denied { write } for pid=1908 comm="mdadm" laddr=::1 lport=32772 faddr=::1 fport=10809 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 The respective backtrace looks like this: @security[mdadm, -13, handshake_exit+221615650 handshake_exit+221615650 handshake_exit+221616465 security_socket_sendmsg+5 sock_sendmsg+106 handshake_exit+221616150 sock_sendmsg+5 __sock_xmit+162 nbd_send_cmd+597 nbd_handle_cmd+377 nbd_queue_rq+63 blk_mq_dispatch_rq_list+653 __blk_mq_do_dispatch_sched+184 __blk_mq_sched_dispatch_requests+333 blk_mq_sched_dispatch_requests+38 blk_mq_run_hw_queue+239 blk_mq_dispatch_plug_list+382 blk_mq_flush_plug_list.part.0+55 __blk_flush_plug+241 __submit_bio+353 submit_bio_noacct_nocheck+364 submit_bio_wait+84 __blkdev_direct_IO_simple+232 blkdev_read_iter+162 vfs_read+591 ksys_read+95 do_syscall_64+92 entry_SYSCALL_64_after_hwframe+120 ]: 1 The issue has started to appear since commit 060406c61c7c ("block: add plug while submitting IO"). Cc: Ming Lei <ming.lei@redhat.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2348878 Fixes: 060406c61c7c ("block: add plug while submitting IO") Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Tested-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-10-20can: netlink: can_changelink(): allow disabling of automatic restartMarc Kleine-Budde
Since the commit c1f3f9797c1f ("can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode"), the automatic restart delay can only be set for devices that implement the restart handler struct can_priv::do_set_mode. As it makes no sense to configure a automatic restart for devices that doesn't support it. However, since systemd commit 13ce5d4632e3 ("network/can: properly handle CAN.RestartSec=0") [1], systemd-networkd correctly handles a restart delay of "0" (i.e. the restart is disabled). Which means that a disabled restart is always configured in the kernel. On systems with both changes active this causes that CAN interfaces that don't implement a restart handler cannot be brought up by systemd-networkd. Solve this problem by allowing a delay of "0" to be configured, even if the device does not implement a restart handler. [1] https://github.com/systemd/systemd/commit/13ce5d4632e395521e6205c954493c7fc1c4c6e0 Cc: stable@vger.kernel.org Cc: Andrei Lalaev <andrey.lalaev@gmail.com> Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251020-certain-arrogant-vole-of-sunshine-141841-mkl@pengutronix.de Fixes: c1f3f9797c1f ("can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode") Link: https://patch.msgid.link/20251020-netlink-fix-restart-v1-1-3f53c7f8520b@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20can: rockchip-canfd: rkcanfd_start_xmit(): use can_dev_dropped_skb() instead ↵Marc Kleine-Budde
of can_dropped_invalid_skb() In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly. Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode. Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251017-bizarre-enchanted-quokka-f3c704-mkl@pengutronix.de/ Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-3-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20can: esd: acc_start_xmit(): use can_dev_dropped_skb() instead of ↵Marc Kleine-Budde
can_dropped_invalid_skb() In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly. Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode. Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251017-bizarre-enchanted-quokka-f3c704-mkl@pengutronix.de/ Fixes: 9721866f07e1 ("can: esd: add support for esd GmbH PCIe/402 CAN interface family") Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-2-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb() instead of ↵Marc Kleine-Budde
can_dropped_invalid_skb() In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly. Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode. Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/all/20251017-bizarre-enchanted-quokka-f3c704-mkl@pengutronix.de/ Fixes: f00647d8127b ("can: bxcan: add support for ST bxCAN controller") Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-1-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-10-20remoteproc: mtk_scp: Construct FW path if firmware-name not presentAngeloGioacchino Del Regno
After a reply on the mailing lists [1] it emerged that the DT property "firmware-name" should not be relied on because of possible issues with firmware versions. For MediaTek SCP, there has never been any firmware version vs driver version desync issue but, regardless, the firmwares are always using the same name and they're always located in a path with a specific pattern. Instead of unconditionally always relying on the firmware-name devicetree property to get a path to the SCP FW file, drivers should construct a name based on what firmware it knows and what hardware it is running on. In order to do that, add a `scp_get_default_fw_path()` function that constructs the path and filename based on two of the infos that the driver can get: 1. The compatible string with the highest priority (so, the first one at index 0); and 2. The type of SCP HW - single-core or multi-core. This means that the default firmware path is generated as: - Single core SCP: mediatek/(soc_model)/scp.img for example: mediatek/mt8183/scp.img; - Multi core SCP: mediatek/(soc_model)/scp_c(core_number).img for example: mediatek/mt8188/scp_c0.img for Core 0, and mediatek/mt8188/scp_c1.img for Core 1. Note that the generated firmware path is being used only if the "firmware-name" devicetree property is not present in the SCP node or in the SCP Core node(s). [1 - Reply regarding firmware-name property] Link: https://lore.kernel.org/all/7e8718b0-df78-44a6-a102-89529d6abcce@app.fastmail.com/ Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20251015084103.10737-1-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-20spi: intel-pci: Add support for Intel Wildcat Lake SPI serial flashMika Westerberg
Add Intel Wildcat Lake SPI serial flash PCI ID to the list of supported devices. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20251020145415.3377022-4-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-20spi: intel-pci: Add support for Arrow Lake-H SPI serial flashMika Westerberg
Add Intel Arrow Lake-H PCI ID to the driver list of supported devices. This is the same controller found in previous generations. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20251020145415.3377022-3-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-20spi: intel: Add support for 128M component densityMika Westerberg
With the recent hardware the flash component density can be increased to 128M. Update the driver to support this. While there log a warning if we encounter an unsupported value in this field. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20251020145415.3377022-2-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-20USB: serial: option: add UNISOC UIS7720Renjun Wang
Add support for UNISOC (Spreadtrum) UIS7720 (A7720) module. T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4064 Rev=04.04 S: Manufacturer=Unisoc-phone S: Product=Unisoc-phone S: SerialNumber=0123456789ABCDEF C: #Ifs= 9 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0&1: RNDIS, 2: LOG, 3: DIAG, 4&5: AT Ports, 6&7: AT2 Ports, 8: ADB Signed-off-by: Renjun Wang <renjunw0@foxmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2025-10-20drm/panfrost: Rename panfrost_job functions to reflect real roleAdrián Larumbe
panfrost_job_* prefixed functions in panfrost_job.c deal with both panfrost_job objects and also the more general JM (Job Manager) side of the device itself. This is confusing. Reprefix functions that program the JM to panfrosot_jm_* instead. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-12-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Remove unused device propertyAdrián Larumbe
The as_in_use_mask device state variable is no longer in use. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-11-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Add forward declaration and types headerAdrián Larumbe
This is to make LLVM syntactic analysers happy. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-10-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Make re-enabling job interrupts at device reset optionalAdrián Larumbe
Rather than remasking interrupts after a device reset in the main reset path, allow selecting whether to do this with an additional bool parameter. To this end, split reenabling job interrupts into two functions, one that clears the interrupts and another one which unmasks them conditionally. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-9-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Don't rework job IRQ enable mask in the enable pathAdrián Larumbe
Up until now, panfrost_job_enable_interrupts() would always recalculate the same job IRQ enablement mask, which is effectively a constant. Replace it with a compile-time constant value, and also in another couple places where an equivalent expression was being used. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-8-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle page mapping failureAdrián Larumbe
When mapping the pages of a BO, either a heap type at page fault time or else a non-heap BO at object creation time, if the ARM page table mapping function fails, we unmap what had been mapped so far and bail out. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-7-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Check sgt to know whether pages are already mappedAdrián Larumbe
In the MMU's page fault ISR for a heap object, determine whether the faulting address belongs to a 2MiB block that was already mapped by checking its corresponding sgt in the Panfrost BO. This is done in preparation for a future commit in which the MMU mapping helper might fail, but the page array is left populated, so this cannot be used as a check for an early bail-out. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-6-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle error when allocating AS numberAdrián Larumbe
If we reach the beginning of the LRU AS list, then return an error. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-5-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle job HW submit errorsAdrián Larumbe
Avoid waiting for the DRM scheduler job timedout handler, and instead, let the DRM scheduler core signal the error fence immediately when HW job submission fails. That means we must also decrement the runtime-PM refcnt for the device, because the job will never be enqueued or inflight. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-4-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Handle inexistent GPU during probeAdrián Larumbe
Just in case we're dealing with a yet not recognised device. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-3-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20drm/panfrost: Replace DRM driver allocation method with newer oneAdrián Larumbe
Drop the deprecated DRM driver allocation method in favour of devm_drm_dev_alloc(). Overall just make it the same as in Panthor. Also discard now superfluous generic and platform device pointers inside the main panfrost device structure. Some ancient checkpatch issues unearthed as a result of these changes were also fixed, like lines too long or double assignment in one line. Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://lore.kernel.org/r/20251019145225.3621989-2-adrian.larumbe@collabora.com Signed-off-by: Steven Price <steven.price@arm.com>
2025-10-20accel/qaic: Fix mismatched types in min()Zack McKevitt
Use min_t() instead of min() to resolve compiler warnings for mismatched types. Signed-off-by: Zack McKevitt <zmckevit@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251015153715.184143-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-20accel/qaic: Use check_add_overflow in sahara for 64b typesZack McKevitt
Use check_add_overflow instead of size_add in sahara when 64b types are being added to ensure compatibility with 32b systems. The size_add function parameters are of size_t, so 64b data types may be truncated when cast to size_t on 32b systems. When using check_add_overflow, no type casts are made, making it a more portable option. Signed-off-by: Zack McKevitt <zmckevit@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251015165408.213645-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-20drm/rockchip: Use temporary variablesDaniel Stone
Brevity is good. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-6-daniels@collabora.com
2025-10-20drm/rockchip: Rename variables for clarityDaniel Stone
actual_w and actual_h were the clipped source width, so rename them to fit the use. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-5-daniels@collabora.com
2025-10-20drm/rockchip: Return error code for errorsDaniel Stone
Instead of silently disabling small planes, refuse to create them at all. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-4-daniels@collabora.com
2025-10-20drm/rockchip: Declare framebuffer width/height boundsDaniel Stone
The VOP2 has limitations on its input and output sizes. The clipped display region must be at least 4px in each dimension for both framebuffer source and plane destination, and the clipped source region must be no greater than a per-version limit. It is never valid for VOP2 to have a framebuffer which is less than four pixels in either dimension, so declare that as our min width/height, enforced by AddFB failing if the user tries. It can theoretically be valid to have a single large framebuffer of which only certain clipped regions are shown, but this is a very uncommon case. Declaring to userspace that the framebuffer's maximum width and height is the maximum source clip helps it make better decisions as to which mode to use, instead of trying unsupported sizes and having to fall back. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-3-daniels@collabora.com
2025-10-20drm/rockchip: Demote normal drm_err to debugDaniel Stone
A plane check failing is a normal and expected condition, as userspace isn't aware of the specific constraints and will try any and every combination until one succeeds. Push this down to a debug message, so users can see it if they want to, but make sure we don't spam the log during normal operation. Fixes: 604be85547ce4 ("drm/rockchip: Add VOP2 driver") Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251015110042.41273-2-daniels@collabora.com
2025-10-20dm-verity: use 2-way interleaved SHA-256 hashing when supportedEric Biggers
When the crypto library provides an optimized implementation of sha256_finup_2x(), use it to interleave the hashing of pairs of data blocks. On some CPUs this nearly doubles hashing performance. The increase in overall throughput of cold-cache dm-verity reads that I'm seeing on arm64 and x86_64 is roughly 35% (though this metric is hard to measure as it jumps around a lot). For now this is done only on data blocks, not Merkle tree blocks. We could use sha256_finup_2x() on Merkle tree blocks too, but that is less important as there aren't as many Merkle tree blocks as data blocks, and that would require some additional code restructuring. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-verity: reduce scope of real and wanted digestsEric Biggers
In preparation for supporting interleaved hashing where dm-verity will need to keep track of the real and wanted digests for multiple data blocks simultaneously, stop using the want_digest and real_digest fields of struct dm_verity_io from so many different places. Specifically: - Make various functions take want_digest as a parameter rather than having it be implicitly passed via the struct dm_verity_io. - Add a new tmp_digest field, and use this instead of real_digest when computing a digest solely for the purpose of immediately checking it. The result is that real_digest and want_digest are used only by verity_verify_io(). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-verity: use SHA-256 library for SHA-256Eric Biggers
When the hash algorithm is SHA-256 and the verity version is not 0, use the SHA-256 library instead of crypto_shash. This is a prerequisite for making dm-verity interleave the computation of SHA-256 hashes for increased performance. That optimization is available in the SHA-256 library but not in crypto_shash. Even without interleaved hashing, switching to the library also slightly improves performance by itself because it avoids the overhead of crypto_shash, including indirect calls and other API overhead. (Benchmark on x86_64, AMD Zen 5: hashing 4K blocks gets 2.1% faster.) SHA-256 is by far the most common hash algorithm used with dm-verity. It makes sense to optimize for the common case and fall back to the generic crypto layer for uncommon cases, as suggested by Linus: https://lore.kernel.org/r/CAHk-=wgp-fOSsZsYrbyzqCAfEvrt5jQs1jL-97Wc4seMNTUyng@mail.gmail.com Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-verity: remove log message with shash driver nameEric Biggers
I added this log message in commit bbf6a566920e ("dm verity: log the hash algorithm implementation"), to help people debug issues where they forgot to enable the architecture-optimized SHA-256 code in their kconfig or accidentally enabled a slow hardware offload driver (such as QCE) that overrode the faster CPU-accelerated code. However: - The crypto layer now always enables the architecture-optimized SHA-1, SHA-256, and SHA-512 code. Moreover, for simplicity the driver name is now fixed at "sha1-lib", "sha256-lib", etc. - dm-verity now uses crypto_shash instead of crypto_ahash, preventing the mistake of accidentally using a slow driver such as QCE. Therefore, this log message generally no longer provides useful information. Remove it. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm: Fix deadlock when reloading a multipath tableBenjamin Marzinski
Request-based devices (dm-multipath) queue I/O in blk-mq on noflush suspends. Any queued IO will make it impossible to freeze the queue. If a process attempts to update the queue limits while there is queued IO, it can be get stuck holding the limits lock, while unable to freeze the queue. If device-mapper then attempts to update the limits during a table swap, it will deadlock trying to grab the limits lock while making it impossible to flush the IO. Disallow updating the queue limits during a table swap, when updating an immutable request-based dm device (dm-multipath) during a noflush suspend. It is userspace's responsibility to make sure that the new table uses the same limits as the existing table if it asks for a noflush suspend. Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm: sysfs: use sysfs_emit() in dm-sysfs.cVivek BalachandharTN
Replace sprintf()+strlen() with sysfs_emit(), the preferred helper for sysfs show() routines. sysfs_emit() returns the number of bytes written, guarantees NUL-termination, and clamps to PAGE_SIZE-1. Reference: Documentation/filesystems/sysfs.rst. No functional change intended. Signed-off-by: Vivek BalachandharTN <vivek.balachandhar@gmail.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm: remove useless md->nr_zones variableBenjamin Marzinski
md->nr_zones is no longer used for anything. Remove it. Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-crypt: use folio_nr_pages() instead of shift operationPedro Demarchi Gomes
folio_nr_pages() is a faster helper function to get the number of pages when NR_PAGES_IN_LARGE_FOLIO is enabled. Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-10-20dm-crypt: Use MD5 library instead of crypto_shashEric Biggers
The lmk IV mode, which dm-crypt supports for Loop-AES compatibility, involves an MD5 computation. Update its implementation to use the MD5 library API instead of crypto_shash. This has many benefits, such as: - Simpler code. Notably, much of the error-handling code is no longer needed, since the library functions can't fail. - Reduced stack usage. crypt_iv_lmk_one() now allocates only 112 bytes on the stack instead of 520 bytes. - The library functions are strongly typed, preventing bugs like https://lore.kernel.org/r/f1625ddc-e82e-4b77-80c2-dc8e45b54848@gmail.com - Slightly improved performance, as the library provides direct access to the MD5 code without unnecessary overhead such as indirect calls. To preserve the existing behavior of lmk support being disabled when the kernel is booted with "fips=1", make crypt_iv_lmk_ctr() check fips_enabled itself. Previously it relied on crypto_alloc_shash("md5") failing. (I don't know for sure that lmk *actually* needs to be disallowed in FIPS mode; this just preserves the existing behavior.) Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-30 14:57:01 +0000