summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-03-02hwmon: (ad7314) Validate leading zero bits and return errorErik Schumacher
Leading zero bits are sent on the bus before the temperature value is transmitted. If any of these bits are high, the connection might be unstable or there could be no AD7314 / ADT730x (or compatible) at all. Return -EIO in that case. Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com> Fixes: 4f3a659581cab ("hwmon: AD7314 driver (ported from IIO)") Link: https://lore.kernel.org/r/24a50c2981a318580aca8f50d23be7987b69ea00.camel@iris-sensing.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (asus-ec-sensors) add PRIME X670E-PRO WIFIShengyu Qu
Add support for PRIME X670E-PRO WIFI. Signed-off-by: Shengyu Qu <wiagn233@outlook.com> Link: https://lore.kernel.org/r/TYCPR01MB84377BEADF97E8E7554EF0CF98C32@TYCPR01MB8437.jpnprd01.prod.outlook.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (ntc_thermistor) Fix module name in the KconfigMaud Spierings
The module name is incorrectly stated with a hyphen while it is an underscore. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Link: https://lore.kernel.org/r/20250227-ntc_thermistor_fixes-v1-1-70fa73200b52@gocontroll.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor tableMaud Spierings
I could not find a single table that has the values currently present in the table, change it to the actual values that can be found in [1]/[2] and [3] (page 15 column 2) [1]: https://www.murata.com/products/productdetail?partno=NCP15XH103F03RC [2]: https://www.murata.com/products/productdata/8796836626462/NTHCG83.txt?1437969843000 [3]: https://nl.mouser.com/datasheet/2/281/r44e-522712.pdf Fixes: 54ce3a0d8011 ("hwmon: (ntc_thermistor) Add support for ncpXXxh103") Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Link: https://lore.kernel.org/r/20250227-ntc_thermistor_fixes-v1-3-70fa73200b52@gocontroll.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (pmbus/core) Replace deprecated strncpy() with strscpy()Thorsten Blum
strncpy() is deprecated for NUL-terminated destination buffers; use strscpy() instead. Compile-tested only. Note(groeck): strscpy() uses sizeof() to determine the length of the destination buffer if it is not provided as argument. Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://lore.kernel.org/r/20250227173936.7746-2-thorsten.blum@linux.dev Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (pmbus) Initialise page count in pmbus_identify()Titus Rwantare
The `pmbus_identify()` function fails to correctly determine the number of supported pages on PMBus devices. This occurs because `info->pages` is implicitly zero-initialised, and `pmbus_set_page()` does not perform writes to the page register if `info->pages` is not yet initialised. Without this patch, `info->pages` is always set to the maximum after scanning. This patch initialises `info->pages` to `PMBUS_PAGES` before the probing loop, enabling `pmbus_set_page()` writes to make it out onto the bus correctly identifying the number of pages. `PMBUS_PAGES` seemed like a reasonable non-zero number because that's the current result of the identification process. Testing was done with a PMBus device in QEMU. Signed-off-by: Titus Rwantare <titusr@google.com> Fixes: 442aba78728e7 ("hwmon: PMBus device driver") Link: https://lore.kernel.org/r/20250227222455.2583468-1-titusr@google.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (k10temp) add support for cyan skillfishMikhail Paulyshka
Add support for Cyan Skillfish (AMD Family 17h Model 47h), which appear to be Zen 2 based APU. The patch was tested with an AMD BC-250 board. Signed-off-by: Mikhail Paulyshka <me@mixaill.net> Link: https://lore.kernel.org/r/20250302155009.49951-1-me@mixaill.net Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (nct6683) Add customer ID for AMD BC-250Mikhail Paulyshka
This value was found on an AMD BC-250 board with an NCT6686D chip. Signed-off-by: Mikhail Paulyshka <me@mixaill.net> Link: https://lore.kernel.org/r/20250302155053.50096-1-me@mixaill.net Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02Merge tag 'gpio-fixes-for-v6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fix from Bartosz Golaszewski: - fix a buggy get_direction() retval check * tag 'gpio-fixes-for-v6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpiolib: Fix Oops in gpiod_direction_input_nonotify()
2025-03-01Merge tag 'i2c-for-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "All driver fixes this time: - fix interrupt initialization sequence (npcm) - fix frequency setting (ls2x) - re-enable interrupts properly at irq handler's exit (amd-asf)" * tag 'i2c-for-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: amd-asf: Fix EOI register write to enable successive interrupts i2c: ls2x: Fix frequency division register access i2c: npcm: disable interrupt enable bit before devm_request_irq
2025-03-01Merge tag 'ata-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Fix a regression where the enablement of the PHYs would be skipped for device trees without any port child nodes (me) - Revert ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives, as it stops systems from entering lower package states. LPM works on newer firmware versions. We will need a more refined quirk that only targets the older firmware versions (me) * tag 'ata-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: Revert "ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives" ata: ahci: Make ahci_ignore_port() handle empty mask_port_map
2025-03-01Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "ARM: - Fix TCR_EL2 configuration to not use the ASID in TTBR1_EL2 and not mess-up T1SZ/PS by using the HCR_EL2.E2H==0 layout. - Bring back the VMID allocation to the vcpu_load phase, ensuring that we only setup VTTBR_EL2 once on VHE. This cures an ugly race that would lead to running with an unallocated VMID. RISC-V: - Fix hart status check in SBI HSM extension - Fix hart suspend_type usage in SBI HSM extension - Fix error returned by SBI IPI and TIME extensions for unsupported function IDs - Fix suspend_type usage in SBI SUSP extension - Remove unnecessary vcpu kick after injecting interrupt via IMSIC guest file x86: - Fix an nVMX bug where KVM fails to detect that, after nested VM-Exit, L1 has a pending IRQ (or NMI). - To avoid freeing the PIC while vCPUs are still around, which would cause a NULL pointer access with the previous patch, destroy vCPUs before any VM-level destruction. - Handle failures to create vhost_tasks" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: retry nx_huge_page_recovery_thread creation vhost: return task creation error instead of NULL KVM: nVMX: Process events on nested VM-Exit if injectable IRQ or NMI is pending KVM: x86: Free vCPUs before freeing VM state riscv: KVM: Remove unnecessary vcpu kick KVM: arm64: Ensure a VMID is allocated before programming VTTBR_EL2 KVM: arm64: Fix tcr_el2 initialisation in hVHE mode riscv: KVM: Fix SBI sleep_type use riscv: KVM: Fix SBI TIME error generation riscv: KVM: Fix SBI IPI error generation riscv: KVM: Fix hart suspend_type use riscv: KVM: Fix hart suspend status check
2025-03-01Revert "ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives"Niklas Cassel
This reverts commit cc77e2ce187d26cc66af3577bf896d7410eb25ab. It was reported that adding ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives breaks entering lower package states for certain systems. It turns out that Samsung SSD 870 QVO actually has working LPM when using a recent SSD firmware version. The author of commit cc77e2ce187d ("ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives") reported himself that only older SSD firmware versions have broken LPM: https://lore.kernel.org/stable/93c10d38-718c-459d-84a5-4d87680b4da7@debian.org/ Unfortunately, he did not specify which older firmware version he was using which had broken LPM. Let's revert this quirk, which has FW version field specified as NULL (which means that it applies for all Samsung SSD 870 QVO firmware versions) for now. Once the author reports which older firmware version(s) that are broken, we can create a more fine grained quirk, which populates the FW version field accordingly. Fixes: cc77e2ce187d ("ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives") Reported-by: Dieter Mummenschanz <dmummenschanz@web.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219747 Link: https://lore.kernel.org/r/20250228122603.91814-2-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-03-01vhost: return task creation error instead of NULLKeith Busch
Lets callers distinguish why the vhost task creation failed. No one currently cares why it failed, so no real runtime change from this patch, but that will not be the case for long. Signed-off-by: Keith Busch <kbusch@kernel.org> Message-ID: <20250227230631.303431-2-kbusch@meta.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-03-01perf/dwc_pcie: fix duplicate pci_dev devicesYunhui Cui
During platform_device_register, wrongly using struct device pci_dev as platform_data caused a kmemdup copy of pci_dev. Worse still, accessing the duplicated device leads to list corruption as its mutex content (e.g., list, magic) remains the same as the original. Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Link: https://lore.kernel.org/r/20250220121716.50324-3-cuiyunhui@bytedance.com Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf/dwc_pcie: fix some unreleased resourcesYunhui Cui
Release leaked resources, such as plat_dev and dev_info. Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Link: https://lore.kernel.org/r/20250220121716.50324-2-cuiyunhui@bytedance.com Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf/arm-cmn: Minor event type housekeepingRobin Murphy
While handling RN-D nodes under the functionally-identical RN-I type works fine for perf tool users using the "rnid_" event aliases, and that is the documented and expected ABI, there's little reason not to be permissive and accept the actual RN-D type as an additional encoding for the same events as well. This may be convenient for other tooling generating event configs directly from its own topology data. In the RN-I event mood, it also seems as good a time as any to clean up a forgotten macro for CCLA_RNI events which ended up being unnecessary. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/ef46a47fc4ab909093f14b2b4289a4835836ab6c.1738851844.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: apple_m1: Don't disable counter in m1_pmu_enable_event()Rob Herring (Arm)
Currently m1_pmu_enable_event() starts by disabling the event counter it has been asked to enable. This should not be necessary as the counter (and the PMU as a whole) should not be active when m1_pmu_enable_event() is called. Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-6-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_v7_pmu: Don't disable counter in ↵Rob Herring (Arm)
(armv7|krait_|scorpion_)pmu_enable_event() Currently (armv7|krait_|scorpion_)pmu_enable_event() start by disabling the event counter it has been asked to enable. This should not be necessary as the counter (and the PMU as a whole) should not be active when *_enable_event() is called. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-5-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_v7_pmu: Drop obvious comments for enabling/disabling counters and ↵Rob Herring (Arm)
interrupts The function calls for enabling/disabling counters and interrupts are pretty obvious as to what they are doing, and the comments don't add any additional value. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-4-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_pmuv3: Don't disable counter in armv8pmu_enable_event()Mark Rutland
Currently armv8pmu_enable_event() starts by disabling the event counter it has been asked to enable. This should not be necessary as the counter (and the PMU as a whole) should not be active when armv8pmu_enable_event() is called. Remove the redundant call to armv8pmu_disable_event_counter(). At the same time, remove the comment immeditately above as everything it says is obvious from the function names below. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-3-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_pmu: Don't disable counter in armpmu_add()Mark Rutland
Currently armpmu_add() tries to handle a newly-allocated counter having a stale associated event, but this should not be possible, and if this were to happen the current mitigation is insufficient and potentially expensive. It would be better to warn if we encounter the impossible case. Calls to pmu::add() and pmu::del() are serialized by the core perf code, and armpmu_del() clears the relevant slot in pmu_hw_events::events[] before clearing the bit in pmu_hw_events::used_mask such that the counter can be reallocated. Thus when armpmu_add() allocates a counter index from pmu_hw_events::used_mask, it should not be possible to observe a stale even in pmu_hw_events::events[] unless either pmu_hw_events::used_mask or pmu_hw_events::events[] have been corrupted. If this were to happen, we'd end up with two events with the same event->hw.idx, which would clash with each other during reprogramming, deletion, etc, and produce bogus results. Add a WARN_ON_ONCE() for this case so that we can detect if this ever occurs in practice. That possiblity aside, there's no need to call arm_pmu::disable(event) for the new event. The PMU reset code initialises the counter in a disabled state, and armpmu_del() will disable the counter before it can be reused. Remove the redundant disable. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-2-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_pmuv3: Call kvm_vcpu_pmu_resync_el0() before enabling countersRob Herring (Arm)
Counting events related to setup of the PMU is not desired, but kvm_vcpu_pmu_resync_el0() is called just after the PMU counters have been enabled. Move the call to before enabling the counters. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-1-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-02-28caif_virtio: fix wrong pointer check in cfv_probe()Vitaliy Shevtsov
del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checked for NULL before calling it, not cfv->vdev. Also the current implementation is redundant because the pointer cfv->vdev is dereferenced before it is checked for NULL. Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev before calling del_vqs(). Fixes: 0d2e1a2926b1 ("caif_virtio: Introduce caif over virtio") Signed-off-by: Vitaliy Shevtsov <v.shevtsov@mt-integration.ru> Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com> Link: https://patch.msgid.link/20250227184716.4715-1-v.shevtsov@mt-integration.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-28Merge tag 'thermal-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "These fix the processing of DT thermal properties and the Power Allocator thermal governor: - Fix parsing cooling-maps in DT for trip points with more than one cooling device (Rafael Wysocki) - Fix granted_power computation in the Power Allocator thermal governor and make it update total_weight on configuration changes after the thermal zone has been registered (Yu-Che Cheng)" * tag 'thermal-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: gov_power_allocator: Update total_weight on bind and cdev updates thermal/of: Fix cdev lookup in thermal_of_should_bind() thermal: gov_power_allocator: Fix incorrect calculation in divvy_up_power()
2025-02-28Merge tag 'pm-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix the handling of processors that stop the TSC in deeper C-states in the intel_idle driver (Thomas Gleixner)" * tag 'pm-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: intel_idle: Handle older CPUs, which stop the TSC in deeper C states, correctly
2025-02-28Merge tag 'iommu-fixes-v6.14-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull iommu fixes from Joerg Roedel: - Intel VT-d fixes: - Fix suspicious RCU usage splat - Fix passthrough for devices under PCIe-PCI bridge - AMD-Vi fix: - Fix to preserve bits when updating device table entries * tag 'iommu-fixes-v6.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/vt-d: Fix suspicious RCU usage iommu/vt-d: Remove device comparison in context_setup_pass_through_cb iommu/amd: Preserve default DTE fields when updating Host Page Table Root
2025-02-28Merge tag 'for-net-2025-02-27' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - mgmt: Check return of mgmt_alloc_skb - btusb: Initialize .owner field of force_poll_sync_fops * tag 'for-net-2025-02-27' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected() Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name() bluetooth: btusb: Initialize .owner field of force_poll_sync_fops ==================== Link: https://patch.msgid.link/20250227223802.3299088-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-28intel_idle: Handle older CPUs, which stop the TSC in deeper C states, correctlyThomas Gleixner
The Intel idle driver is preferred over the ACPI processor idle driver, but fails to implement the work around for Core2 generation CPUs, where the TSC stops in C2 and deeper C-states. This causes stalls and boot delays, when the clocksource watchdog does not catch the unstable TSC before the CPU goes deep idle for the first time. The ACPI driver marks the TSC unstable when it detects that the CPU supports C2 or deeper and the CPU does not have a non-stop TSC. Add the equivivalent work around to the Intel idle driver to cure that. Fixes: 18734958e9bf ("intel_idle: Use ACPI _CST for processor models without C-state tables") Reported-by: Fab Stz <fabstz-it@yahoo.fr> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Fab Stz <fabstz-it@yahoo.fr> Cc: All applicable <stable@vger.kernel.org> Closes: https://lore.kernel.org/all/10cf96aa-1276-4bd4-8966-c890377030c3@yahoo.fr Link: https://patch.msgid.link/87bjupfy7f.ffs@tglx Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-02-28scsi: qla2xxx: Mark device strings as nonstringKees Cook
In preparation for memtostr*() checking that its source is marked as nonstring, annotate the device strings accordingly. Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI Signed-off-by: Kees Cook <kees@kernel.org>
2025-02-28scsi: mpt3sas: Mark device strings as nonstringKees Cook
In preparation for memtostr*() checking that its source is marked as nonstring, annotate the device strings accordingly. Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI Signed-off-by: Kees Cook <kees@kernel.org>
2025-02-28scsi: mpi3mr: Mark device strings as nonstringKees Cook
In preparation for memtostr*() checking that its source is marked as nonstring, annotate the device strings accordingly. Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI Signed-off-by: Kees Cook <kees@kernel.org>
2025-02-28scsi: mptfusion: Mark device strings as nonstringKees Cook
In preparation for memtostr*() checking that its source is marked as nonstring, annotate the device strings accordingly. Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI Signed-off-by: Kees Cook <kees@kernel.org>
2025-02-28Merge tag 'efi-fixes-for-v6.14-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Another couple of EFI fixes for v6.14. Only James's patch stands out, as it implements a workaround for odd behavior in fwupd in user space, which creates EFI variables by touching a file in efivarfs, clearing the immutable bit (which gets set automatically for $reasons) and then opening it again for writing, none of which is really necessary. The fwupd author and LVFS maintainer is already rolling out a fix for this on the fwupd side, and suggested that the workaround in this PR could be backed out again during the next cycle. (There is a semantic mismatch in efivarfs where some essential variable attributes are stored in the first 4 bytes of the file, and so zero length files cannot exist, as they cannot be written back to the underlying variable store. So now, they are dropped once the last reference is released.) Summary: - Fix CPER error record parsing bugs - Fix a couple of efivarfs issues that were introduced in the merge window - Fix an issue in the early remapping code of the MOKvar table" * tag 'efi-fixes-for-v6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/mokvar-table: Avoid repeated map/unmap of the same page efi: Don't map the entire mokvar table to determine its size efivarfs: allow creation of zero length files efivarfs: Defer PM notifier registration until .fill_super efi/cper: Fix cper_arm_ctx_info alignment efi/cper: Fix cper_ia_proc_ctx alignment
2025-02-28x86/mm: Reduce header dependencies in <asm/set_memory.h>Kevin Brodsky
Commit: 03b122da74b2 ("x86/sgx: Hook arch_memory_failure() into mainline code") ... added <linux/mm.h> to <asm/set_memory.h> to provide some helpers. However the following commit: b3fdf9398a16 ("x86/mce: relocate set{clear}_mce_nospec() functions") ... moved the inline definitions someplace else, and now <asm/set_memory.h> just declares a bunch of mostly self-contained functions. No need for the whole <linux/mm.h> inclusion to declare functions; just remove that include. This helps avoid circular dependency headaches (e.g. if <linux/mm.h> ends up including <linux/set_memory.h>). This change requires a couple of include fixups not to break the build: * <asm/smp.h>: including <asm/thread_info.h> directly relies on <linux/thread_info.h> having already been included, because the former needs the BAD_STACK/NOT_STACK constants defined in the latter. This is no longer the case when <asm/smp.h> is included from some driver file - just include <linux/thread_info.h> to stay out of trouble. * sev-guest.c relies on <asm/set_memory.h> including <linux/mm.h>, so we just need to make that include explicit. [ mingo: Cleaned up the changelog ] Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20241212080904.2089632-3-kevin.brodsky@arm.com
2025-02-28Convert regulator drivers to useMark Brown
Merge series from Raag Jadav <raag.jadav@intel.com>: This series converts regulator drivers to use the newly introduced[1] devm_kmemdup_array() helper. [1] https://lore.kernel.org/r/20250212062513.2254767-1-raag.jadav@intel.com
2025-02-28Convert sound drivers to use devm_kmemdup_array()Mark Brown
Merge series from Raag Jadav <raag.jadav@intel.com>: This series converts sound drivers to use the newly introduced[1] devm_kmemdup_array() helper. [1] https://lore.kernel.org/r/20250212062513.2254767-1-raag.jadav@intel.com
2025-02-28gpiolib: Fix Oops in gpiod_direction_input_nonotify()Dan Carpenter
The gpiod_direction_input_nonotify() function is supposed to return zero if the direction for the pin is input. But instead it accidentally returns GPIO_LINE_DIRECTION_IN (1) which will be cast into an ERR_PTR() in gpiochip_request_own_desc(). The callers dereference it and it leads to a crash. I changed gpiod_direction_output_raw_commit() just for consistency but returning GPIO_LINE_DIRECTION_OUT (0) is fine. Cc: stable@vger.kernel.org Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/254f3925-3015-4c9d-aac5-bb9b4b2cd2c5@stanley.mountain [Bartosz: moved the variable declarations to the top of the functions] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-28regulator: cros-ec: use devm_kmemdup_array()Raag Jadav
Convert to use devm_kmemdup_array() and while at it, make the size robust against type changes. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20250228072057.151436-3-raag.jadav@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-28regulator: devres: use devm_kmemdup_array()Raag Jadav
Convert to use devm_kmemdup_array() which is more robust. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20250228072057.151436-2-raag.jadav@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-28EDAC/amd64: Simplify return statement in dct_ecc_enabled()Thorsten Blum
Simplify the return statement to improve the code's readability. No functional changes. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> Link: https://lore.kernel.org/r/20250201130953.1377-2-thorsten.blum@linux.dev
2025-02-28pmdomain: rockchip: add regulator supportSebastian Reichel
Some power domains require extra voltages to be applied. For example trying to enable the GPU power domain on RK3588 fails when the SoC does not have VDD GPU enabled. The same is expected to happen for the NPU, which also has a dedicated supply line. We get the regulator using devm_of_regulator_get(), so a missing dependency in the devicetree is handled gracefully by printing a warning and creating a dummy regulator. This is necessary, since existing DTs do not have the regulator described. They might still work if the regulator is marked as always-on. It is also working if the regulator is enabled at boot time and the GPU driver is probed before the kernel disables unused regulators. The regulator itself is not acquired at driver probe time, since that creates an unsolvable circular dependency. The power domain driver must be probed early, since SoC peripherals need it. Regulators on the other hand depend on SoC peripherals like SPI, I2C or GPIO. MediaTek does not run into this, since they have two power domain drivers. Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-7-a4f9c24e5b81@kernel.org [Ulf: Fixed conflict when applying] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-02-28pmdomain: rockchip: fix rockchip_pd_power error handlingPeter Geis
The calls rockchip_pd_power makes to rockchip_pmu_set_idle_request lack any return error handling, causing device drivers to incorrectly believe the hardware idle requests succeed when they may have failed. This leads to software possibly accessing hardware that is powered off and the subsequent SError panic that follows. Add error checking and return errors to the calling function to prevent such crashes. gst-launch-1.0 videotestsrc num-buffers=2000 ! v4l2jpegenc ! fakesink Setting pipeline to PAUSED ...er-x64 Pipeline is PREROLLING ... Redistribute latency... rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'hevc', val=0x98260 SError Interrupt on CPU2, code 0x00000000bf000002 -- SError Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20241214215802.23989-1-pgwipeout@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-5-a4f9c24e5b81@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-02-28pmdomain: rockchip: reduce indentation in rockchip_pd_powerSebastian Reichel
Rework the logic, so that the function exits early when the power domain state is already correct to reduce code indentation. No functional change intended. Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-4-a4f9c24e5b81@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-02-28pmdomain: rockchip: forward rockchip_do_pmu_set_power_domain errorsSebastian Reichel
Currently rockchip_do_pmu_set_power_domain prints a warning if there have been errors turning on the power domain, but it does not return any errors and rockchip_pd_power() tries to continue setting up the QOS registers. This usually results in accessing unpowered registers, which triggers an SError and a full system hang. This improves the error handling by forwarding the error to avoid kernel panics. Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-3-a4f9c24e5b81@kernel.org [Ulf: Fixed conflict when applying] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-02-28pmdomain: rockchip: cleanup mutex handling in rockchip_pd_powerSebastian Reichel
Use the cleanup infrastructure to handle the mutex, which slightly improve code readability for this function. Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-2-a4f9c24e5b81@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-02-28pmdomain: Merge tag regulator-devm-of-get into nextUlf Hansson
Merge the tag regulator-devm-of-get from git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into next. This introduces devm_of_regulator_get without the _optional suffix, since that is more sensible for the Rockchip usecase. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-02-28pmdomain: Merge tag 'v6.14-rc4' from Linus into nextUlf Hansson
Linux 6.14-rc4
2025-02-28iommu/vt-d: Fix suspicious RCU usageLu Baolu
Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts locally") moved the call to enable_drhd_fault_handling() to a code path that does not hold any lock while traversing the drhd list. Fix it by ensuring the dmar_global_lock lock is held when traversing the drhd list. Without this fix, the following warning is triggered: ============================= WARNING: suspicious RCU usage 6.14.0-rc3 #55 Not tainted ----------------------------- drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by cpuhp/1/23: #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55 Call Trace: <TASK> dump_stack_lvl+0xb7/0xd0 lockdep_rcu_suspicious+0x159/0x1f0 ? __pfx_enable_drhd_fault_handling+0x10/0x10 enable_drhd_fault_handling+0x151/0x180 cpuhp_invoke_callback+0x1df/0x990 cpuhp_thread_fun+0x1ea/0x2c0 smpboot_thread_fn+0x1f5/0x2e0 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x12a/0x2d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4a/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat about a possible deadlock between dmar_global_lock and cpu_hotplug_lock. This is avoided by not holding dmar_global_lock when calling iommu_device_register(), which initiates the device probe process. Fixes: d74169ceb0d2 ("iommu/vt-d: Allocate DMAR fault interrupts locally") Reported-and-tested-by: Ido Schimmel <idosch@nvidia.com> Closes: https://lore.kernel.org/linux-iommu/Zx9OwdLIc_VoQ0-a@shredder.mtl.com/ Tested-by: Breno Leitao <leitao@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20250218022422.2315082-1-baolu.lu@linux.intel.com Tested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2025-02-28iommu/vt-d: Remove device comparison in context_setup_pass_through_cbJerry Snitselaar
Remove the device comparison check in context_setup_pass_through_cb. pci_for_each_dma_alias already makes a decision on whether the callback function should be called for a device. With the check in place it will fail to create context entries for aliases as it walks up to the root bus. Fixes: 2031c469f816 ("iommu/vt-d: Add support for static identity domain") Closes: https://lore.kernel.org/linux-iommu/82499eb6-00b7-4f83-879a-e97b4144f576@linux.intel.com/ Cc: stable@vger.kernel.org Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20250224180316.140123-1-jsnitsel@redhat.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
generated by cgit (git 2.34.1) at 2025-09-16 07:20:47 +0000