aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-05-11Merge tag 'amd-drm-fixes-6.9-2024-05-10' of ↵Dave Airlie7-18/+51
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.9-2024-05-10: amdgpu: - DCN 3.5 fix - MST DSC fixes - S0i3 fix - S4 fix - HDP MMIO mapping fix - Fix a regression in visible vram handling amdkfd: - Spatial partition fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-10Merge branch 'thermal-intel'Rafael J. Wysocki8-8/+15
Merge updates of Intel thermal drivers for v6.10: - Add missing MODULE_DESCRIPTION() to multiple files in the int340x_thermal and intel_soc_dts_iosf drivers (Srinivas Pandruvada). - Adjust the update delay and capabilities-per-event values in the Intel HFI thermal driver to prevent it from missing events and allow it to process more data in one go (Ricardo Neri). * thermal-intel: thermal: intel: hfi: Increase the number of CPU capabilities per netlink event thermal: intel: hfi: Rename HFI_MAX_THERM_NOTIFY_COUNT thermal: intel: hfi: Shorten the thermal netlink event delay to 100ms thermal: intel: hfi: Rename HFI_UPDATE_INTERVAL thermal: intel: Add missing module description
2024-05-10Merge tag 'block-6.9-20240510' of git://git.kernel.dk/linuxLinus Torvalds6-20/+25
Pull block fixes from Jens Axboe: - NVMe pull request via Keith: - nvme target fixes (Sagi, Dan, Maurizo) - new vendor quirk for broken MSI (Sean) - Virtual boundary fix for a regression in this merge window (Ming) * tag 'block-6.9-20240510' of git://git.kernel.dk/linux: nvmet-rdma: fix possible bad dereference when freeing rsps nvmet: prevent sprintf() overflow in nvmet_subsys_nsid_exists() nvmet: make nvmet_wq unbound nvmet-auth: return the error code to the nvmet_auth_ctrl_hash() callers nvme-pci: Add quirk for broken MSIs block: set default max segment size in case of virt_boundary
2024-05-10Merge tag 'spi-fix-v6.9-rc7' of ↵Linus Torvalds2-12/+3
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "Two device specific fixes here, one avoiding glitches on chip select with the STM32 driver and one for incorrectly configured clocks on the Microchip QSPI controller" * tag 'spi-fix-v6.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: microchip-core-qspi: fix setting spi bus clock rate spi: stm32: enable controller before asserting CS
2024-05-10Merge tag 'loongarch-kvm-6.10' of ↵Paolo Bonzini500-2700/+5415
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson into HEAD LoongArch KVM changes for v6.10 1. Add ParaVirt IPI support. 2. Add software breakpoint support. 3. Add mmio trace events support.
2024-05-10Merge tag 'regulator-fix-v6.9-rc7' of ↵Linus Torvalds2-15/+19
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "Two fixes here, one from Johan which fixes error handling when we attempt to create duplicate debugfs files and one for an incorrect specification of ramp_delay with the rtq2208" * tag 'regulator-fix-v6.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: core: fix debugfs creation regression regulator: rtq2208: Fix the BUCK ramp_delay range to maximum of 16mVstep/us
2024-05-10Merge tag 'iommu-fixes-v6.9-rc7' of ↵Linus Torvalds2-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Fix offset miscalculation on ARM-SMMU driver - AMD IOMMU fix for initializing state of untrusted devices * tag 'iommu-fixes-v6.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault() iommu/amd: Enhance def_domain_type to handle untrusted device
2024-05-10drm/amdgpu: Fix comparison in amdgpu_res_cpu_visibleMichel Dänzer1-1/+1
It incorrectly claimed a resource isn't CPU visible if it's located at the very end of CPU visible VRAM. Fixes: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3343 Reviewed-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reported-and-Tested-by: Jeremy Day <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]> CC: [email protected]
2024-05-10drm/amdkfd: don't allow mapping the MMIO HDP page with large pagesAlex Deucher1-2/+5
We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. Fixes: d8e408a82704 ("drm/amdkfd: Expose HDP registers to user space") Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2024-05-10gpiolib: cdev: fix uninitialised kfifoKent Gibson1-0/+14
If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active. Fixes: 65cff7046406 ("gpiolib: cdev: support setting debounce") Signed-off-by: Kent Gibson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
2024-05-10Merge tag 'gtp-24-05-07' of ↵David S. Miller1-130/+735
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/gtp Pablo neira Ayuso says: ==================== gtp pull request 24-05-07 This v3 includes: - fix for clang uninitialized variable per Jakub. - address Smatch and Coccinelle reports per Simon - remove inline in new IPv6 support per Simon - fix memleaks in netlink control plane per Simon -o- The following patchset contains IPv6 GTP driver support for net-next, this also includes IPv6 over IPv4 and vice-versa: Patch #1 removes a unnecessary stack variable initialization in the socket routine. Patch #2 deals with GTP extension headers. This variable length extension header to decapsulate packets accordingly. Otherwise, packets are dropped when these extension headers are present which breaks interoperation with other non-Linux based GTP implementations. Patch #3 prepares for IPv6 support by moving IPv4 specific fields in PDP context objects to a union. Patch #4 adds IPv6 support while retaining backward compatibility. Three new attributes allows to declare an IPv6 GTP tunnel GTPA_FAMILY, GTPA_PEER_ADDR6 and GTPA_MS_ADDR6 as well as IFLA_GTP_LOCAL6 to declare the IPv6 GTP UDP socket. Up to this patch, only IPv6 outer in IPv6 inner is supported. Patch #5 uses IPv6 address /64 prefix for UE/MS in the inner headers. Unlike IPv4, which provides a 1:1 mapping between UE/MS, IPv6 tunnel encapsulates traffic for /64 address as specified by 3GPP TS. Patch has been split from Patch #4 to highlight this behaviour. Patch #6 passes up IPv6 link-local traffic, such as IPv6 SLAAC, for handling to userspace so they are handled as control packets. Patch #7 prepares to allow for GTP IPv4 over IPv6 and vice-versa by moving IP specific debugging out of the function to build IPv4 and IPv6 GTP packets. Patch #8 generalizes TOS/DSCP handling following similar approach as in the existing iptunnel infrastructure. Patch #9 adds a helper function to build an IPv4 GTP packet in the outer header. Patch #10 adds a helper function to build an IPv6 GTP packet in the outer header. Patch #11 adds support for GTP IPv4-over-IPv6 and vice-versa. Patch #12 allows to use the same TID/TEID (tunnel identifier) for inner IPv4 and IPv6 packets for better UE/MS dual stack integration. This series integrates with the osmocom.org project CI and TTCN-3 test infrastructure (Oliver Smith) as well as the userspace libgtpnl library. Thanks to Harald Welte, Oliver Smith and Pau Espin for reviewing and providing feedback through the osmocom.org redmine platform to make this happen. ==================== Signed-off-by: David S. Miller <[email protected]>
2024-05-10iommu/arm-smmu-v3: Make the kunit into a moduleJason Gunthorpe5-2/+15
It turns out kconfig has problems ensuring the SMMU module and the KUNIT module are consistently y/m to allow linking. It will permit KUNIT to be a module while SMMU is built in. Also, Fedora apparently enables kunit on production kernels. So, put the entire kunit in its own module using the VISIBLE_IF_KUNIT/EXPORT_SYMBOL_IF_KUNIT machinery. This keeps it out of vmlinus on Fedora and makes the kconfig work in the normal way. There is no cost if kunit is disabled. Fixes: 56e1a4cc2588 ("iommu/arm-smmu-v3: Add unit tests for arm_smmu_write_entry") Reported-by: Thorsten Leemhuis <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Jason Gunthorpe <[email protected]> Tested-by: Thorsten Leemhuis <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-05-10Revert "media: v4l2-ctrls: show all owned controls in log_status"Hans Verkuil1-13/+5
This reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739. This patch introduced a potential deadlock scenario: [Wed May 8 10:02:06 2024] Possible unsafe locking scenario: [Wed May 8 10:02:06 2024] CPU0 CPU1 [Wed May 8 10:02:06 2024] ---- ---- [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); For now just revert. Fixes: 9801b5b28c69 ("media: v4l2-ctrls: show all owned controls in log_status") Cc: [email protected] Signed-off-by: Hans Verkuil <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]>
2024-05-10media: ov2740: Ensure proper reset sequence on probe()Hans de Goede1-1/+8
Before this commit on probe() the driver would do: reset=1 // from probe() calling gpiod_get(GPIOD_OUT_HIGH) reset=0 // from resume() msleep(20) // from resume() So if reset was 0 before getting the GPIO the reset line would only be driven high for a very short time and sometimes there would be errors reading the id register afterwards. Add a msleep(20) after getting the reset line to ensure the sensor is properly reset: reset=1 // from probe() calling gpiod_get(GPIOD_OUT_HIGH) msleep(20) // from probe() reset=0 // from resume() msleep(20) // from resume() Signed-off-by: Hans de Goede <[email protected]> Tested-by: Stanislaw Gruszka <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
2024-05-10media: intel/ipu6: Don't print user-triggerable errors to kernel logSakari Ailus1-5/+5
Use dev_dbg() for printing messages on user-triggerable conditions that have no relation to driver or hardware issues. Fixes: 3c1dfb5a69cf ("media: intel/ipu6: input system video nodes and buffer queues") Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Bingbu Cao <[email protected]> Signed-off-by: Hans Verkuil <[email protected]>
2024-05-10crypto: atmel-sha204a - provide the otp contentLothar Rubusch1-0/+45
Set up sysfs for the Atmel SHA204a. Provide the content of the otp zone as an attribute field on the sysfs entry. Thereby make sure that if the chip is locked, not connected or trouble with the i2c bus, the sysfs device is not set up. This is mostly already handled in atmel-i2c. Signed-off-by: Lothar Rubusch <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: atmel-sha204a - add reading from otp zoneLothar Rubusch3-0/+52
Provide a read function reading the otp zone. The otp zone can be used for storing serial numbers. The otp zone, as also data zone, are only accessible if the chip was locked before. Locking the chip is a post production customization and has to be done manually i.e. not by this driver. Without this step the chip is pretty much not usable, where putting or not putting data into the otp zone is optional. Signed-off-by: Lothar Rubusch <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: atmel-i2c - rename read functionLothar Rubusch2-4/+4
Make the memory read function name more specific to the read memory zone. The Atmel SHA204 chips provide config, otp and data zone. The implemented read function in fact only reads some fields in zone config. The function renaming allows for a uniform naming scheme when reading from other memory zones. Signed-off-by: Lothar Rubusch <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: atmel-i2c - add missing arg descriptionLothar Rubusch1-0/+1
Add missing description for argument hwrng. Signed-off-by: Lothar Rubusch <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: iaa - Use kmemdup() instead of kzalloc() and memcpy()Thorsten Blum1-4/+2
Fixes the following two Coccinelle/coccicheck warnings reported by memdup.cocci: iaa_crypto_main.c:350:19-26: WARNING opportunity for kmemdup iaa_crypto_main.c:358:18-25: WARNING opportunity for kmemdup Signed-off-by: Thorsten Blum <[email protected]> Reviewed-by: Tom Zanussi <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: sahara - use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang1-8/+8
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: caam - i.MX8ULP donot have CAAM page0 accessPankaj Gupta1-0/+3
iMX8ULP have a secure-enclave hardware IP called EdgeLock Enclave(ELE), that control access to caam controller's register page, i.e., page0. At all, if the ELE release access to CAAM controller's register page, it will release to secure-world only. Clocks are turned on automatically for iMX8ULP. There exists the caam clock gating bit, but it is not advised to gate the clock at linux, as optee-os or any other entity might be using it. Signed-off-by: Pankaj Gupta <[email protected]> Reviewed-by: Gaurav Jain <[email protected]> Reviewed-by: Horia Geanta <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: caam - init-clk based on caam-page0-accessPankaj Gupta1-1/+15
CAAM clock initializat is done based on the basis of soc specific info stored in struct caam_imx_data: - caam-page0-access flag - num_clks CAAM driver needs to be aware of access rights to CAAM control page i.e., page0, to do things differently. Signed-off-by: Pankaj Gupta <[email protected]> Reviewed-by: Gaurav Jain <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: starfive - Use fallback for unaligned dma accessJia Jie Ho1-5/+7
Dma address mapping fails on unaligned scatterlist offset. Use sw fallback for these cases. Signed-off-by: Jia Jie Ho <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: starfive - Do not free stack bufferJia Jie Ho1-1/+0
RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. Cc: <[email protected]> #6.7+ Signed-off-by: Jia Jie Ho <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: starfive - Skip unneeded fallback allocationJia Jie Ho1-6/+4
Skip sw fallback allocation if RSA module failed to get device handle. Signed-off-by: Jia Jie Ho <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10crypto: starfive - Skip dma setup for zeroed messageJia Jie Ho1-0/+4
Skip dma setup and mapping for AES driver if plaintext is empty. Signed-off-by: Jia Jie Ho <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2024-05-10clocksource/drivers/arm_arch_timer: Mark hisi_161010101_oem_info constStephen Boyd1-1/+1
This isn't modified at runtime. Mark it const so it can move to read-only data. Cc: dann frazier <[email protected]> Cc: Hanjun Guo <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Mark Rutland <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Hanjun Guo <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-05-10clocksource/drivers/timer-ti-dm: Remove an unused field in struct dmtimerChristophe JAILLET1-1/+0
In "struct dmtimer", the 'rate' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/c9f7579922c587fce334a1aa9651f3189de7a00b.1714513336.git.christophe.jaillet@wanadoo.fr
2024-05-10clocksource/drivers/renesas-ostm: Avoid reprobe after successful early probeGeert Uytterhoeven1-0/+1
The Renesas OS Timer (OSTM) driver contains two probe points, of which only one should complete: 1. Early probe, using TIMER_OF_DECLARE(), to provide the sole clocksource on (arm32) RZ/A1 and RZ/A2 SoCs, 2. Normal probe, using a platform driver, to provide additional timers on (arm64 + riscv) RZ/G2L and similar SoCs. The latter is needed because using OSTM on RZ/G2L requires manipulation of its reset signal, which is not yet available at the time of early probe, causing early probe to fail with -EPROBE_DEFER. It is only enabled when building a kernel with support for the RZ/G2L family, so it does not impact RZ/A1 and RZ/A2. Hence only one probe method can complete on all affected systems. As relying on the order of initialization of subsystems inside the kernel is fragile, set the DT node's OF_POPULATED flag after a succesful early probe. This makes sure the platform driver's probe is never called after a successful early probe. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviwed-by: Lad Prabhakar <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/bd027379713cbaafa21ffe9e848ebb7f475ca0e7.1710930542.git.geert+renesas@glider.be
2024-05-10clocksource/drivers/renesas-ostm: Allow OSTM driver to reprobe for RZ/V2H(P) SoCLad Prabhakar1-1/+1
The RZ/V2H(P) (R9A09G057) SoC is equipped with the Generic Timer Module, also known as OSTM. Similar to the RZ/G2L SoC, the OSTM on the RZ/V2H(P) SoC requires the reset line to be deasserted before accessing any registers. Early call to ostm_init() happens through TIMER_OF_DECLARE() which always fails with -EPROBE_DEFER, as resets are not available that early in the boot process. To address this issue on the RZ/V2H(P) SoC, enable the OSTM driver to be reprobed through the platform driver probe mechanism. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-05-10iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()Jason Gunthorpe1-3/+1
This was missed because of the function pointer indirection. nvidia_smmu_context_fault() is also installed as a irq function, and the 'void *' was changed to a struct arm_smmu_domain. Since the iommu_domain is embedded at a non-zero offset this causes nvidia_smmu_context_fault() to miscompute the offset. Fixup the types. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000 [0000000000000120] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1 Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023 Workqueue: events_unbound deferred_probe_work_func pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nvidia_smmu_context_fault+0x1c/0x158 lr : __free_irq+0x1d4/0x2e8 sp : ffff80008044b6f0 x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970 x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30 x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000 x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888 x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0 x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000 x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057 Call trace: nvidia_smmu_context_fault+0x1c/0x158 __free_irq+0x1d4/0x2e8 free_irq+0x3c/0x80 devm_free_irq+0x64/0xa8 arm_smmu_domain_free+0xc4/0x158 iommu_domain_free+0x44/0xa0 iommu_deinit_device+0xd0/0xf8 __iommu_group_remove_device+0xcc/0xe0 iommu_bus_notifier+0x64/0xa8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x90 bus_notify+0x44/0x70 device_del+0x264/0x3e8 pci_remove_bus_device+0x84/0x120 pci_remove_root_bus+0x5c/0xc0 dw_pcie_host_deinit+0x38/0xe0 tegra_pcie_config_rp+0xc0/0x1f0 tegra_pcie_dw_probe+0x34c/0x700 platform_probe+0x70/0xe8 really_probe+0xc8/0x3a0 __driver_probe_device+0x84/0x160 driver_probe_device+0x44/0x130 __device_attach_driver+0xc4/0x170 bus_for_each_drv+0x90/0x100 __device_attach+0xa8/0x1c8 device_initial_probe+0x1c/0x30 bus_probe_device+0xb0/0xc0 deferred_probe_work_func+0xbc/0x120 process_one_work+0x194/0x490 worker_thread+0x284/0x3b0 kthread+0xf4/0x108 ret_from_fork+0x10/0x20 Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1) Cc: [email protected] Fixes: e0976331ad11 ("iommu/arm-smmu: Pass arm_smmu_domain to internal functions") Reported-by: Jerry Snitselaar <[email protected]> Closes: https://lore.kernel.org/all/jto5e3ili4auk6sbzpnojdvhppgwuegir7mpd755anfhwcbkfz@2u5gh7bxb4iv Signed-off-by: Jason Gunthorpe <[email protected]> Tested-by: Jerry Snitselaar <[email protected]> Acked-by: Jerry Snitselaar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2024-05-10pwm: pca9685: Drop explicit initialization of struct ↵Uwe Kleine-König1-2/+2
i2c_device_id::driver_data to 0 The driver doesn't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove the trailing commas after the sentinel entry. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]>
2024-05-09ptp: ocp: fix DPLL functionsVadim Fedorenko1-3/+3
In ptp_ocp driver pin actions assume sma_nr starts with 1, but for DPLL subsystem callback 0-based index was used. Fix it providing proper index. Fixes: 09eeb3aecc6c ("ptp_ocp: implement DPLL ops") Signed-off-by: Vadim Fedorenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-05-10Merge tag 'drm-xe-next-fixes-2024-05-09-1' of ↵Dave Airlie4-2/+9
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Use ordered WQ for G2H handler. (Matthew Brost) - Use flexible-array rather than zero-sized (Lucas De Marchi) Signed-off-by: Dave Airlie <[email protected]> From: Thomas Hellstrom <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/Zjz7SzCvfA3vQRxu@fedora
2024-05-10Merge tag 'drm-misc-next-fixes-2024-05-08' of ↵Dave Airlie31-160/+172
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next-fixes for v6.10-rc1: - panthor fixes. - Reverting Kconfig changes, and moving drm options to submenu. - Hide physical fb address in fb helper. - zynqmp bridge fix. - Revert broken ti-sn65dsi83 fix. Signed-off-by: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-10Merge tag 'drm-msm-next-2024-05-07' of ↵Dave Airlie134-41420/+25387
https://gitlab.freedesktop.org/drm/msm into drm-next Updates for v6.10 Core: - Switched to generating register header files during build process instead of shipping pre-generated headers - Merged DPU and MDP4 format databases. DP: - Stop using compat string to distinguish DP and eDP cases - Added support for X Elite platform (X1E80100) - Reworked DP aux/audio support - Added SM6350 DP to the bindings (no driver changes, using SM8350 as a fallback compat) GPU: - a7xx perfcntr reg fixes - MAINTAINERS updates - a750 devcoredump support Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGtpw6dNR9JBikFTQ=TCpt-9FeFW+SGjXWv+Jv3emm0Pbg@mail.gmail.com
2024-05-10Merge tag 'drm-xe-fixes-2024-05-09' of ↵Dave Airlie4-3/+13
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Fix use zero-length element array - Move more from system wq to ordered private wq - Do not ignore return for drmm_mutex_init Signed-off-by: Dave Airlie <[email protected]> From: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c3rduifdp5wipkljdpuq4x6uowkc2uyzgdoft4txvp6mgvzjaj@7zw7c6uw4wrf
2024-05-10media: bcm2835-unicam: Fix a NULL vs IS_ERR() checkDan Carpenter1-2/+2
The media_pad_remote_pad_unique() function returns error pointers, not NULL. Update the check accordingly. Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]>
2024-05-10media: bcm2835-unicam: Do not print error when irq not foundRicardo Ribalda1-3/+1
platform_get_irq() already prints an error for us. Fix this cocci warning: drivers/media/platform/broadcom/bcm2835-unicam.c:2664:2-9: line 2664 is redundant because platform_get_irq() already prints an error Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Ricardo Ribalda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]>
2024-05-10media: bcm2835-unicam: Do not replace IRQ retcode during probeRicardo Ribalda1-3/+1
platform_get_irq() cannot return the value 0. It will either return a non-zero irq or a errcode. If a errcode is returned, we need to populate the error code upwards. It will give a more accurate reason of why it failed to the caller, who might decide to retry later. Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]>
2024-05-10media: bcm2835-unicam: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]>
2024-05-09vfio/pci: Collect hot-reset devices to local bufferAlex Williamson1-29/+49
Lockdep reports the below circular locking dependency issue. The mmap_lock acquisition while holding pci_bus_sem is due to the use of copy_to_user() from within a pci_walk_bus() callback. Building the devices array directly into the user buffer is only for convenience. Instead we can allocate a local buffer for the array, bounded by the number of devices on the bus/slot, fill the device information into this local buffer, then copy it into the user buffer outside the bus walk callback. ====================================================== WARNING: possible circular locking dependency detected 6.9.0-rc5+ #39 Not tainted ------------------------------------------------------ CPU 0/KVM/4113 is trying to acquire lock: ffff99a609ee18a8 (&vdev->vma_lock){+.+.}-{4:4}, at: vfio_pci_mmap_fault+0x35/0x1a0 [vfio_pci_core] but task is already holding lock: ffff99a243a052a0 (&mm->mmap_lock){++++}-{4:4}, at: vaddr_get_pfns+0x3f/0x170 [vfio_iommu_type1] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_lock){++++}-{4:4}: __lock_acquire+0x4e4/0xb90 lock_acquire+0xbc/0x2d0 __might_fault+0x5c/0x80 _copy_to_user+0x1e/0x60 vfio_pci_fill_devs+0x9f/0x130 [vfio_pci_core] vfio_pci_walk_wrapper+0x45/0x60 [vfio_pci_core] __pci_walk_bus+0x6b/0xb0 vfio_pci_ioctl_get_pci_hot_reset_info+0x10b/0x1d0 [vfio_pci_core] vfio_pci_core_ioctl+0x1cb/0x400 [vfio_pci_core] vfio_device_fops_unl_ioctl+0x7e/0x140 [vfio] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x8d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (pci_bus_sem){++++}-{4:4}: __lock_acquire+0x4e4/0xb90 lock_acquire+0xbc/0x2d0 down_read+0x3e/0x160 pci_bridge_wait_for_secondary_bus.part.0+0x33/0x2d0 pci_reset_bus+0xdd/0x160 vfio_pci_dev_set_hot_reset+0x256/0x270 [vfio_pci_core] vfio_pci_ioctl_pci_hot_reset_groups+0x1a3/0x280 [vfio_pci_core] vfio_pci_core_ioctl+0x3b5/0x400 [vfio_pci_core] vfio_device_fops_unl_ioctl+0x7e/0x140 [vfio] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x8d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&vdev->memory_lock){+.+.}-{4:4}: __lock_acquire+0x4e4/0xb90 lock_acquire+0xbc/0x2d0 down_write+0x3b/0xc0 vfio_pci_zap_and_down_write_memory_lock+0x1c/0x30 [vfio_pci_core] vfio_basic_config_write+0x281/0x340 [vfio_pci_core] vfio_config_do_rw+0x1fa/0x300 [vfio_pci_core] vfio_pci_config_rw+0x75/0xe50 [vfio_pci_core] vfio_pci_rw+0xea/0x1a0 [vfio_pci_core] vfs_write+0xea/0x520 __x64_sys_pwrite64+0x90/0xc0 do_syscall_64+0x8d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&vdev->vma_lock){+.+.}-{4:4}: check_prev_add+0xeb/0xcc0 validate_chain+0x465/0x530 __lock_acquire+0x4e4/0xb90 lock_acquire+0xbc/0x2d0 __mutex_lock+0x97/0xde0 vfio_pci_mmap_fault+0x35/0x1a0 [vfio_pci_core] __do_fault+0x31/0x160 do_pte_missing+0x65/0x3b0 __handle_mm_fault+0x303/0x720 handle_mm_fault+0x10f/0x460 fixup_user_fault+0x7f/0x1f0 follow_fault_pfn+0x66/0x1c0 [vfio_iommu_type1] vaddr_get_pfns+0xf2/0x170 [vfio_iommu_type1] vfio_pin_pages_remote+0x348/0x4e0 [vfio_iommu_type1] vfio_pin_map_dma+0xd2/0x330 [vfio_iommu_type1] vfio_dma_do_map+0x2c0/0x440 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0xc5/0x1d0 [vfio_iommu_type1] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x8d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &vdev->vma_lock --> pci_bus_sem --> &mm->mmap_lock Possible unsafe locking scenario: block dm-0: the capability attribute has been deprecated. CPU0 CPU1 ---- ---- rlock(&mm->mmap_lock); lock(pci_bus_sem); lock(&mm->mmap_lock); lock(&vdev->vma_lock); *** DEADLOCK *** 2 locks held by CPU 0/KVM/4113: #0: ffff99a25f294888 (&iommu->lock#2){+.+.}-{4:4}, at: vfio_dma_do_map+0x60/0x440 [vfio_iommu_type1] #1: ffff99a243a052a0 (&mm->mmap_lock){++++}-{4:4}, at: vaddr_get_pfns+0x3f/0x170 [vfio_iommu_type1] stack backtrace: CPU: 1 PID: 4113 Comm: CPU 0/KVM Not tainted 6.9.0-rc5+ #39 Hardware name: Dell Inc. PowerEdge T640/04WYPY, BIOS 2.15.1 06/16/2022 Call Trace: <TASK> dump_stack_lvl+0x64/0xa0 check_noncircular+0x131/0x150 check_prev_add+0xeb/0xcc0 ? add_chain_cache+0x10a/0x2f0 ? __lock_acquire+0x4e4/0xb90 validate_chain+0x465/0x530 __lock_acquire+0x4e4/0xb90 lock_acquire+0xbc/0x2d0 ? vfio_pci_mmap_fault+0x35/0x1a0 [vfio_pci_core] ? lock_is_held_type+0x9a/0x110 __mutex_lock+0x97/0xde0 ? vfio_pci_mmap_fault+0x35/0x1a0 [vfio_pci_core] ? lock_acquire+0xbc/0x2d0 ? vfio_pci_mmap_fault+0x35/0x1a0 [vfio_pci_core] ? find_held_lock+0x2b/0x80 ? vfio_pci_mmap_fault+0x35/0x1a0 [vfio_pci_core] vfio_pci_mmap_fault+0x35/0x1a0 [vfio_pci_core] __do_fault+0x31/0x160 do_pte_missing+0x65/0x3b0 __handle_mm_fault+0x303/0x720 handle_mm_fault+0x10f/0x460 fixup_user_fault+0x7f/0x1f0 follow_fault_pfn+0x66/0x1c0 [vfio_iommu_type1] vaddr_get_pfns+0xf2/0x170 [vfio_iommu_type1] vfio_pin_pages_remote+0x348/0x4e0 [vfio_iommu_type1] vfio_pin_map_dma+0xd2/0x330 [vfio_iommu_type1] vfio_dma_do_map+0x2c0/0x440 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0xc5/0x1d0 [vfio_iommu_type1] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x8d/0x170 ? rcu_core+0x8d/0x250 ? __lock_release+0x5e/0x160 ? rcu_core+0x8d/0x250 ? lock_release+0x5f/0x120 ? sched_clock+0xc/0x30 ? sched_clock_cpu+0xb/0x190 ? irqtime_account_irq+0x40/0xc0 ? __local_bh_enable+0x54/0x60 ? __do_softirq+0x315/0x3ca ? lockdep_hardirqs_on_prepare.part.0+0x97/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f8300d0357b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 75 68 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007f82ef3fb948 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8300d0357b RDX: 00007f82ef3fb990 RSI: 0000000000003b71 RDI: 0000000000000023 RBP: 00007f82ef3fb9c0 R08: 0000000000000000 R09: 0000561b7e0bcac2 R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 R13: 0000000200000000 R14: 0000381800000000 R15: 0000000000000000 </TASK> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]>
2024-05-09hwmon: Drop explicit initialization of struct i2c_device_id::driver_data to ↵Uwe Kleine-König4-5/+5
0 (part 2) These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. This is a follow up to commit d8a66f3621c2 ("hwmon: Drop explicit initialization of struct i2c_device_id::driver_data to 0") which I created before identifying a few corner cases in my conversion script. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2024-05-10kbuild: use $(src) instead of $(srctree)/$(src) for source directoryMasahiro Yamada37-69/+62
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for checked-in source files. It is merely a convention without any functional difference. In fact, $(obj) and $(src) are exactly the same, as defined in scripts/Makefile.build: src := $(obj) When the kernel is built in a separate output directory, $(src) does not accurately reflect the source directory location. While Kbuild resolves this discrepancy by specifying VPATH=$(srctree) to search for source files, it does not cover all cases. For example, when adding a header search path for local headers, -I$(srctree)/$(src) is typically passed to the compiler. This introduces inconsistency between upstream and downstream Makefiles because $(src) is used instead of $(srctree)/$(src) for the latter. To address this inconsistency, this commit changes the semantics of $(src) so that it always points to the directory in the source tree. Going forward, the variables used in Makefiles will have the following meanings: $(obj) - directory in the object tree $(src) - directory in the source tree (changed by this commit) $(objtree) - the top of the kernel object tree $(srctree) - the top of the kernel source tree Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src). Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2024-05-09tpm: disable the TPM if NULL name changesJames Bottomley3-16/+67
Update tpm2_load_context() to return -EINVAL on integrity failures and use this as a signal when loading the NULL context that something might be wrong. If the signal fails, check the name of the NULL primary against the one stored in the chip data and if there is a mismatch disable the TPM because it is likely to have suffered a reset attack. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: add the null key name as a sysfs exportJames Bottomley1-0/+18
This is the last component of encrypted tpm2 session handling that allows us to verify from userspace that the key derived from the NULL seed genuinely belongs to the TPM and has not been spoofed. The procedure for doing this involves creating an attestation identity key (which requires verification of the TPM EK certificate) and then using that AIK to sign a certification of the Elliptic Curve key over the NULL seed. Userspace must create this EC Key using the parameters prescribed in TCG TPM v2.0 Provisioning Guidance for the SRK ECC; if this is done correctly the names will match and the TPM can then run a TPM2_Certify operation on this derived primary key using the newly created AIK. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: add session encryption protection to tpm2_get_random()James Bottomley1-4/+17
If some entity is snooping the TPM bus, they can see the random numbers we're extracting from the TPM and do prediction attacks against their consumers. Foil this attack by using response encryption to prevent the attacker from seeing the random sequence. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: add hmac checks to tpm2_pcr_extend()James Bottomley1-17/+10
tpm2_pcr_extend() is used by trusted keys to extend a PCR to prevent a key from being re-loaded until the next reboot. To use this functionality securely, that extend must be protected by a session hmac. This patch adds HMAC protection so tampering with the tpm2_pcr_extend() command in flight is detected. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Add the rest of the session HMAC APIJames Bottomley1-0/+400
The final pieces of the HMAC API are for manipulating the session area of the command. To add an authentication HMAC session tpm_buf_append_hmac_session() is called where tpm2_append_auth() would go. If a non empty password is passed in, this is correctly added to the HMAC to prove knowledge of it without revealing it. Note that if the session is only used to encrypt or decrypt parameters (no authentication) then tpm_buf_append_hmac_session_opt() must be used instead. This functions identically to tpm_buf_append_hmac_session() when TPM_BUS_SECURITY is enabled, but differently when it isn't, because effectively nothing is appended to the session area. Next the parameters should be filled in for the command and finally tpm_buf_fill_hmac_session() is called immediately prior to transmitting the command which computes the correct HMAC and places it in the command at the session location in the tpm buffer Finally, after tpm_transmit_cmd() is called, tpm_buf_check_hmac_response() is called to check that the returned HMAC matched and collect the new state for the next use of the session, if any. The features of the session are controlled by the session attributes set in tpm_buf_append_hmac_session(). If TPM2_SA_CONTINUE_SESSION is not specified, the session will be flushed and the tpm2_auth structure freed in tpm_buf_check_hmac_response(); otherwise the session may be used again. Parameter encryption is specified by or'ing the flag TPM2_SA_DECRYPT and response encryption by or'ing the flag TPM2_SA_ENCRYPT. the various encryptions will be taken care of by tpm_buf_fill_hmac_session() and tpm_buf_check_hmac_response() respectively. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> # crypto API parts Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.