summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-28PCI: imx6: Fix i.MX6Q/DL boot hang caused by improper PHY power sequencingRichard Zhu
commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators") introduced a boot hang on i.MX6Q/DL variants by reordering imx_pcie_host_init() to call imx6q_pcie_enable_ref_clk() (which powered up the PHY) before imx6q_pcie_core_reset() (which powered it back down). Before 610fa91d9863, the sequence was: 1. imx_pcie_assert_core_reset() - power down PHY (set TEST_PD), set REF_CLK_EN 2. imx_pcie_clk_enable() - power up PHY (clear TEST_PD), set REF_CLK_EN 3. Link training starts with PHY powered up (TEST_PD cleared) 4. Link training succeeds After 610fa91d9863, the sequence became: 1. imx_pcie_clk_enable() - power up PHY (clear TEST_PD), set REF_CLK_EN 2. imx_pcie_assert_core_reset() - power down PHY (set TEST_PD), set REF_CLK_EN 3. imx_pcie_deassert_core_reset() - does nothing 4. Link training starts with PHY powered down (TEST_PD set) 5. Link training fails and boot hangs when PHY register accesses hang To fix this: - Remove TEST_PD PHY power control from imx6q_pcie_enable_ref_clk() - Remove REF_CLK_EN control from imx6q_pcie_core_reset() - Add TEST_PD PHY power control to imx6qp_pcie_core_reset(), which previously relied on imx6q_pcie_enable_ref_clk() to power up the PHY by clearing TEST_PD - Clear TEST_PD to power on PHY in imx_pcie_deassert_core_reset() These changes together ensure the correct sequence: 1. REF_CLK_EN set in clk_enable() (TEST_PD untouched) 2. TEST_PD set in assert_core_reset() (PHY power off) 3. TEST_PD cleared in deassert_core_reset() (PHY power on) 4. Link training starts with proper PHY state The i.MX6Q/DL PCIe PHY requires approximately 120us between TEST_PD de-assertion and link training start. Add usleep_range(200, 500) in imx6q_pcie_core_reset() after clearing TEST_PD to satisfy this requirement. Add explicit imx_pcie_assert_core_reset() calls in error paths and host_exit() to ensure no power leak. Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators") Reported-by: Leonardo Costa <leoreis.costa@gmail.com> Closes: https://lore.kernel.org/lkml/20260629143439.361560-1-leoreis.costa@gmail.com/ Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Leonardo Costa <leonardo.costa@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260728035159.2702021-1-hongxing.zhu@oss.nxp.com
2026-07-28ALSA: usb-audio: Fix boot-time audio stuttering for USB Audio deviceZhang Heng
This USB Audio device (0x1e0b:0xd01e) exhibits audio stuttering during boot when playing audio. Once the system is fully booted, playback is normal. The device reports its isochronous endpoints with the Asynchronous sync type (bmAttributes = 0x03), which causes the driver to calculate nurbs = min(max_urbs, ...) = 3, providing only ~16ms of buffering. During boot, the higher system scheduling jitter (e.g., from init scripts, device enumeration, and driver probing) can exceed this buffer depth, causing audible stuttering. This patch adds a device-specific quirk (QUIRK_FLAG_PLAYBACK_URB_FIXUP) that applies two changes for this device: 1. Forces nurbs to MAX_URBS (12), providing sufficient buffering 2. Sets URB_ISO_ASAP flag for more consistent xHCI scheduling Both changes are required together for stable boot-time playback: - The larger buffer absorbs scheduling jitter during boot - URB_ISO_ASAP ensures consistent URB submission timing, preventing the xHCI scheduler from introducing variable delays Test methodology: - Without patch: reboot and play audio → stuttering audible in all tests (reproduced consistently across multiple attempts) - With nurbs=8 only: occasional minor stuttering observed after multiple tests (insufficient buffer depth) - With full patch (nurbs=12 + URB_ISO_ASAP): reboot and play audio → no stuttering observed (tested in 10+ reboot cycles without reproducing the issue) Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260728111309.1271834-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-28ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)Robert Abrahamse
Add USB mixer mapping quirk for later revisions of the Corsair Virtuoso headset with USB IDs 0x1b1c:0x0a43 (wired) and 0x1b1c:0x0a44 (wireless). These devices exhibit the same mixer label collision as earlier Virtuoso variants: all controls are labelled "Headset", causing applications like PulseAudio to move the sidetone control instead of the main playback volume. Signed-off-by: Robert Abrahamse <denobyte2@gmail.com> Link: https://patch.msgid.link/20260728140314.11601-1-denobyte2@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-28ALSA: pcm: wake linked drain waiters on unlinkNorbert Szetei
snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained. Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei <norbert@doyensec.com> Link: https://patch.msgid.link/A0705100-D10B-4286-9980-0142ABEEAD51@doyensec.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-28PCI: Fix UAF when probe runs concurrent to dyn ID removalGary Guo
Dynamic IDs are only guaranteed to be valid when dynids.lock is held, as remove_id_store() can free the node. Thus, make a copy in pci_match_device(). Also, clarify that the id parameter is only valid during probe. Fixes: 0994375e9614 ("PCI: add remove_id sysfs entry") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://lore.kernel.org/all/20260619170503.518F61F00A3A@smtp.kernel.org/ Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-9-3580726844e1@garyguo.net
2026-07-28PCI: Fix dyn_id add TOCTOUGary Guo
Currently there is a TOCTOU issue in new_id_store() as the dyn ID insertion in pci_add_dynid() and the pci_match_device() are in separate critical sections. Fix this by moving the existing ID check to inside pci_add_dynid() and only check against the static ID table outside the critical section. Fixes: 3853f9123c18 ("PCI: Avoid duplicate IDs in driver dynamic IDs list") Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-8-3580726844e1@garyguo.net
2026-07-28PCI: Make pci_match_one_device() match on ID instead of deviceGary Guo
PCI dynamic ID needs to match IDs against a new ID to see if it already exists. Existing APIs can only match IDs against devices, so the dynamic ID insertion code creates a temporary device only for matching purposes. Rename pci_match_one_device() to pci_match_one_id() so it can be used for this purpose instead; add a pci_id_from_device() helper to make it easy to convert users. Similarly, convert pci_match_id() to do_pci_match_id(). But keep the existing API because there are many users. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-7-3580726844e1@garyguo.net
2026-07-28agp/amd-k7: Don't rely on address of pci_device_idGary Guo
Address of pci_device_id cannot be relied on due to presence of dynamic ID and driver_override. Use driver_data instead. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-6-3580726844e1@garyguo.net
2026-07-28agp/via: Don't rely on address of pci_device_idGary Guo
Address of pci_device_id cannot be relied on due to presence of dynamic ID and driver_override. Use driver_data instead. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-5-3580726844e1@garyguo.net
2026-07-28mlxsw: pci: Don't store pci_device_idGary Guo
pci_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. This stored ID is unused so remove it. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-4-3580726844e1@garyguo.net
2026-07-28ipack: tpci200: Don't store pci_device_idGary Guo
pci_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. This stored ID is unused so remove it. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-3-3580726844e1@garyguo.net
2026-07-28scsi: nsp32: Don't store pci_device_idGary Guo
pci_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from pci_dev, so just store driver_data. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-2-3580726844e1@garyguo.net
2026-07-28ata: ata_generic: Don't store pci_device_idGary Guo
pci_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from pci_dev, so just store driver_data. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Damien Le Moal <dlemoal@kernel.org> Link: https://patch.msgid.link/20260723-pci_id_fix-v4-1-3580726844e1@garyguo.net
2026-07-28Merge tag 'realtek-dt-v7.3' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/yu_chun/linux into soc/dt arm64: realtek: Device tree updates for v7.3 This pull request includes the following Realtek DT updates for v7.3, please pull the following: - Add GPIO node support for the RTD1625 SoC. - Marc adds the missing the EL2 virtual timer interrupt. * tag 'realtek-dt-v7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/yu_chun/linux: arm64: dts: realtek: Add GPIO support for RTD1625 arm64: dts: realtek: Add EL2 virtual timer interrupt Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-07-28KVM: x86/mmu: Check all address spaces before skipping unsyncJinu Kim
mmu_try_to_unsync_pages() skips the shadow-page lookup when the supplied memslot allows a hugepage, because a shadow page would disallow hugepages. But hugepage metadata is per-address-space while shadow pages are shared across all address spaces. With SMM, the other address space can therefore have a shadow page even when the supplied memslot allows a hugepage. Check the corresponding memslot in the other address space before taking the fast path. Skip the shadow-page lookup only when all address spaces allow a hugepage. Fixes: b3ae3ceb5569 ("KVM: x86/mmu: KVM: x86/mmu: Skip unsync when large pages are allowed") Assisted-by: Codex:GPT-5 Signed-off-by: Jinu Kim <kimjw04271234@gmail.com> [invert direction of the conditional. - Paolo] Message-ID: <20260721103512.2136240-3-kimjw04271234@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-28KVM: x86/mmu: Check write tracking in all address spacesJinu Kim
kvm_gfn_is_write_tracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other. Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and eventually triggering the BUG in pte_list_remove(). Fixes: 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") Assisted-by: Codex:GPT-5 Signed-off-by: Jinu Kim <kimjw04271234@gmail.com> Message-ID: <20260721103512.2136240-2-kimjw04271234@gmail.com> [invert direction of the conditional. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-28cpufreq/amd-pstate: Document missing kernel-doc membersDavid Vernet
kernel-doc warns about five undescribed members in amd-pstate.h: union perf_cached's @val and struct amd_cpudata's @raw_epp, @current_profile, @ppdev and @profile_name. Describe them. Signed-off-by: David Vernet <void@manifault.com> Acked-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://lore.kernel.org/r/20260728073150.54964-2-void@manifault.com Signed-off-by: Mario Limonciello <superm1@kernel.org>
2026-07-28hwmon: (pmbus) Fix return value from pmbus_update_byte_data()Guenter Roeck
pmbus_update_byte_data() is supposed to return a negative error code or 0. However, if no change is made to the register, it actually returns the register value. This can result in problems if the calling code explicitly expects to see an error code or 0. Fix it to return 0 on success or the error code as expected. Fixes: 11c119986f270 ("hwmon: (pmbus) add helpers for byte write and read modify write") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-28PCI/pwrctrl: tc9563: Move Integrated MAC Endpoint out of ↵Manivannan Sadhasivam
'tc9563_pwrctrl_ports' enum 'tc9563_pwrctrl_ports' is supposed to list only the internal ports of the switch. But it currently lists the integrated MAC Endpoint as well, which is wrong. Move it to a separate 'ep_cfg' struct and also configure/parse the ports and the MAC Endpoint separately. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Elder <elder@riscstar.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260725-tc9563-fix-v1-6-ec4286e31331@oss.qualcomm.com
2026-07-28PCI/pwrctrl: tc9563: Rename DSP3 to VDSPManivannan Sadhasivam
TC9563 Reference Manual calls DSP3 as VDSP (Virtual Downstream Port). Name it as such to avoid ambiguity. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Elder <elder@riscstar.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260725-tc9563-fix-v1-5-ec4286e31331@oss.qualcomm.com
2026-07-28PCI/pwrctrl: tc9563: Skip Tx amplitude and DFE tuning for DSP3Manivannan Sadhasivam
DSP3 doesn't support tuning Tx amplitude and DFE settings. Skip the setting if DT has passed the tuning properties. There is no need to error out the whole driver because of it. Fixes: 4c9c7be47310 ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> [bhelgaas: squash https://lore.kernel.org/all/oefxm7olagbd3dby2npgly7ausiz3g6cvls5igaxdzvlbr3wrv@rjlfebi2p36j] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Elder <elder@riscstar.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260725-tc9563-fix-v1-4-ec4286e31331@oss.qualcomm.com
2026-07-28KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUsWeiming Shi
Cancel (and flush) the I/O APIC's delayed EOI handling work during the "pre VM destroy" phase, before vCPUs are destroyed, as processing the EOI broadcast will inject another IRQ if the line is asserted, i.e. will try to deliver an IRQ to the target vCPU(s). Canceling the work after vCPUs are destroyed leads to UAF if the delayed work is processed after vCPUs are destroyed. BUG: KASAN: slab-use-after-free in __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 Read of size 8 at addr ffff8880499abea0 by task kworker/1:2/1218 CPU: 1 UID: 0 PID: 1218 Comm: kworker/1:2 Not tainted 7.1.0-rc7 #5 PREEMPT(lazy) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events kvm_ioapic_eoi_inject_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 __kvm_irq_delivery_to_apic_fast+0x9bf/0xa20 arch/x86/kvm/lapic.c:1250 __kvm_irq_delivery_to_apic+0xd8/0xbf0 arch/x86/kvm/lapic.c:1345 kvm_irq_delivery_to_apic arch/x86/kvm/lapic.h:129 ioapic_service+0x308/0x590 arch/x86/kvm/ioapic.c:492 kvm_ioapic_eoi_inject_work+0x13c/0x190 arch/x86/kvm/ioapic.c:532 process_one_work+0xa59/0x19a0 kernel/workqueue.c:3314 process_scheduled_works kernel/workqueue.c:3397 worker_thread+0x5eb/0xe50 kernel/workqueue.c:3478 kthread+0x370/0x450 kernel/kthread.c:436 ret_from_fork+0x72b/0xd30 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Note, the VM is unreachable once kvm_destroy_vm() starts, and scheduling new work via kvm_ioapic_send_eoi() can only be done via KVM_RUN, i.e. requires a live vCPU. Alternatively, KVM could simply destroy the I/O APIC during the "pre" phase of VM destruction, but that gets more than a bit sketchy as KVM expects the I/O APIC to exist if ioapic_in_kernel() is true, and nested virtualization in particular has a bad habit of touching VM-scope state during vCPU destruction. E.g. attempting to free the PIC during the pre phase would lead to a NULL pointer dereference in kvm_cpu_has_extint(), and it's not hard to imagine the I/O APIC having a similar flaw. Fixes: 17bcd7144263 ("KVM: x86: Free vCPUs before freeing VM state") Reported-by: <zdi-disclosures@trendmicro.com> Reported-by: Zhong Wang <wangzhong.c0ss4ck@bytedance.com> Reported-by: Xuanqing Shi <shixuanqing.11@bytedance.com> Cc: stable@vger.kernel.org Signed-off-by: Weiming Shi <bestswngs@gmail.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20260727171718.543491-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-28KVM: VMX: add memory clobber to asm for VMX instructionsPaolo Bonzini
VMCLEAR/VMREAD/VMWRITE/VMPTRLD access the internal VMCS cache, which is not visible to the compiler; without a memory clobber, the compiler can reorder them in troublesome ways because "asm volatile" and "asm goto" only protect against removal of the asm. For example, placing a VMWRITE before the corresponding VMCS pointer is loaded can lead to corruption. While none of this has been observed, it is better to prevent than cure. Likewise, INVEPT and INVVPID access the TLB and, even though in their case the effect is only visible to the next VMLAUNCH/VMRESUME, it is technically correct to add the clobber there too. So avoid any urge to special case them, and simply hardcode "memory" into the clobber list of vmx_asm1() and vmx_asm2(). __vmcs_readl() open-codes its own asm, so add the clobber there as well. Link: https://lore.kernel.org/kvm/CABgObfbL3t21yVeSwiLSjjOUER+rTYDPHYAH9YU4TWGRjx6XHg@mail.gmail.com/ Cc: Sean Christopherson <seanjc@google.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-28Merge tag 'kvmarm-fixes-7.2-3' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 7.2, take #3 - Fix a tiny buglet when propagating the deactivation of an interrupt from a nested guest, which happened to trigger a gold plated CPU bug on a particular implementation - Fix a race between LPI unmapping and mapping, resulting in leaked LPIs - Make LPI mapping more robust on memory allocation failure - Fix the handling of the EL2 tracing clock being disabled - A couple of Sashiko-driven fixes for corner cases in the EL2 tracing code - Add missing sysreg tracepoint for the EL2 code - Tidy-up the mutual exclusion of guest-memfd and MTE - Update Fuad's email address to point to @linux.dev
2026-07-28Merge tag 'kvm-s390-master-7.2-2' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD KVM: s390: Fixes for 7.2 - several fixes for PCI passthru in s390 kvm - fix a 7.2-rc regression in the adapter interrupt mapping code
2026-07-28Merge branch 'i2c/i2c' into i2c/i2c-nextAndi Shyti
2026-07-28i2c: qcom-geni: distinguish address-phase and data-phase NACKPraveen Talari
The M_GP_IRQ_1 interrupt signals a NACK condition, but does not distinguish whether it occurred during the address phase or the data phase. The driver always attempted cancel and DMA FSM reset on any NACK, which is incorrect for an address NACK since the DMA engine was never armed and the hardware requires no recovery. Add geni_i2c_check_addr_data_nack() to distinguish the two cases by reading SE_GENI_M_GP_LENGTH after the NACK event. A zero value means the address phase was NACKed (ADDR_NACK) and no DMA recovery is needed. A non-zero value on a write transfer means a data byte was NACKed (DATA_NACK) and the normal cancel and DMA FSM reset path must run. Co-developed-by: Naresh Maramaina <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Naresh Maramaina <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260716-fix_cancel_sequence_on_failure_for_i2c-v3-3-9091315a33a0@oss.qualcomm.com
2026-07-28i2c: qcom-geni: use dedicated completions for abort and reset eventsPraveen Talari
The driver uses a common completion event for transfer, abort and DMA reset operations. This allows unrelated completion events to prematurely wake abort and reset waiters, leading to incorrect synchronization. Introduce dedicated completions for abort, TX reset, and RX reset operations, and signal them only from their respective interrupt events. This removes the dependency on shared completion state and eliminates the abort_done flag-based synchronization. Co-developed-by: Naresh Maramaina <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Naresh Maramaina <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260716-fix_cancel_sequence_on_failure_for_i2c-v3-2-9091315a33a0@oss.qualcomm.com
2026-07-28i2c: qcom-geni: use cancel command before abort on transfer timeoutPraveen Talari
The GENI I2C driver currently invokes geni_se_abort_m_cmd() directly when a transfer times out. However, the GENI hardware command cancellation flow requires a cancel command to be issued first. An abort should only be used as a fallback when the cancel operation itself fails to complete. Introduce a dedicated cancel_done completion that is signaled when M_CMD_CANCEL_EN is received. The timeout recovery path waits for cancel completion and escalates to geni_i2c_abort_xfer() only if the cancel command does not complete within the expected time. Co-developed-by: Naresh Maramaina <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Naresh Maramaina <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260716-fix_cancel_sequence_on_failure_for_i2c-v3-1-9091315a33a0@oss.qualcomm.com
2026-07-28of/address: Fix NULL bus dereference in of_pci_range_parser_one()Carlo Caione
The bus matching rework made of_match_bus() return NULL for nodes with ranges/dma-ranges but no local #address-cells. parser_init() stored that NULL bus, and the range iterator later dereferenced it. Reject such nodes in parser_init(), leaving an explicit empty iterator for callers that ignore the init return, and make of_dma_get_max_cpu_address() honour the init failure so a rejected node cannot clamp the DMA limit. Fixes: 64ee3cf096ac ("of/address: Rework bus matching to avoid warnings") Cc: stable@vger.kernel.org Signed-off-by: Carlo Caione <ccaione@baylibre.com> Link: https://patch.msgid.link/20260727-of-range-parser-null-bus-v3-1-be01b708a4ce@baylibre.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-28isofs: validate directory records consistentlyYichong Chen
isofs_export_get_parent() assumes that the first two directory records are valid "." and ".." entries. A malformed image can provide an invalid length for the first entry, causing the computed ".." offset to point outside the received block. Add a shared directory record validator and use it in NFS get_parent, readdir and lookup. This keeps the basic directory record length checks consistent across all directory users before they consume the name field or use one record length to find the next entry. Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Link: https://patch.msgid.link/20260728074349.417508-1-chenyichong@uniontech.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-28Merge branch 'i2c/i2c-fixes' into i2c/i2c-nextAndi Shyti
2026-07-28i2c: imx: mark I2C adapter when hardware is powered downCarlos Song
On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available. Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()") Signed-off-by: Carlos Song <carlos.song@nxp.com> Cc: <stable@vger.kernel.org> # v6.14+ Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260525030400.3182911-1-carlos.song@oss.nxp.com
2026-07-28clk: tegra: set up proper EMC clock implementation for Tegra114Svyatoslav Ryhel
Remove current emc and emc_mux clocks and replace them with the proper EMC clock implementation for correct EMC driver support. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28Merge branch 'i2c/i2c-2' into i2c/i2c-nextAndi Shyti
2026-07-28i2c: imx-lpi2c: reset controller in probe stageCarlos Song
Reset I2C controller in probe stage to avoid unexpected LPI2C controller state left from previous stages and hang system boot. Per the LPI2C reference manual, section 7.1.4 "Controller Control (MCR)" and 7.1.20 Target Control (SCR), the RST bit (bit 1) description states: "The reset takes effect immediately and remains asserted until negated by software. There is no minimum delay required before clearing the software reset." Therefore, it is safe to write 0 to MCR and SCR immediately after asserting the RST bit without any additional delay. Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260716071957.2670263-3-carlos.song@oss.nxp.com
2026-07-28i2c: imx-lpi2c: properly unwind resources on probe failureCarlos Song
When probe fails at devm_clk_rate_exclusive_get() or clk_get_rate(), which occur before runtime PM is initialized, the clocks enabled by clk_bulk_prepare_enable() are never disabled. When probe fails after runtime PM is initialized, the previous error path called pm_runtime_put_sync(), which triggers the runtime suspend callback. However, due to different clock management strategies on different SoCs[1] (to avoid deadlocks between the global prepare_lock and runtime PM), the callback may only disable clocks without unpreparing them, causing an incomplete unwind. Introduce a new error label 'clk_disable' to explicitly invoke clk_bulk_disable_unprepare(). Replace pm_runtime_put_sync() with the sequence of pm_runtime_disable(), pm_runtime_set_suspended() and pm_runtime_put_noidle() to bypass the runtime suspend callback during error recovery. During the LPI2C driver probe phase, clock APIs are used exclusively to manage clocks. Once probing succeeds, clock management is handed over to the runtime PM core. [1] https://lore.kernel.org/all/20251125084718.2156168-1-carlos.song@nxp.com/ Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260716071957.2670263-2-carlos.song@oss.nxp.com
2026-07-29tracing/fprobe: Roll back on enable_trace_fprobe() failureRaushan Patel
enable_trace_fprobe() sets the file link or the TP_FLAG_PROFILE flag and then registers each trace_fprobe in the probe list. If __register_trace_fprobe() fails partway through, the function returns immediately without unregistering the trace_fprobes it already registered or undoing the file link / flag it set, leaving the event half-enabled and leaking the registered fprobe(s). enable_trace_kprobe() already handles this with a rollback path. Do the same for fprobe: on failure, unregister all probes and clear the file link or profile flag. Link: https://lore.kernel.org/all/20260724064208.480030-1-raushan.jhon@gmail.com/ Fixes: 334e5519c375 ("tracing/probes: Add fprobe events for tracing function entry and exit.") Cc: stable@vger.kernel.org Signed-off-by: Raushan Patel <raushan.jhon@gmail.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-28clk: clocking-wizard: remove 20kHz restrictionColin Foster
Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: clocking-wizard: optimize clock searchColin Foster
When an exact clock match is found, there is no need to continue searching. This process was optimized for versal as part of 'commit e0a94c6bb5b4 ("clk: xilinx: Optimize divisor search in clk_wzrd_get_divisors_ver()")' but that logic wasn't applied to the non-versal driver. Apply this fast-exit logic to the non-versal driver. Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: clocking-wizard: fix clock difference detectionColin Foster
Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Colin Foster <colin.foster@in-advantage.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: mediatek: mt8135: Fix inverted gate control for devapc_ckAkari Tsuyukusa
The devapc_ck (CLK_INFRA_DEVAPC) on MT8135 is currently using "mtk_clk_gate_ops_setclr". However, checking the downstream kernel reveals that this clock is configured with set:enable and clr:disable making "mtk_clk_gate_ops_setclr_inv" the appropriate choice. But, it is strange that some downstream kernels are not like that. Amazon: INV ChromiumOS (early): not INV ChromiumOS 3.16 to 3.18-revew-v2: INV ChromiumOS 3.18-review-v3 and later (sent to kernel.org): not INV Link: https://github.com/amazon-oss/android_kernel_amazon_mt8135/blob/e2b2163a8ec4a7c8d961c89003a15b4ba0f0e371/arch/arm/mach-mt8135/mt_clkmgr.c#L1022-L1028 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/4b624ee66e65d5dcd43fca36b313086efae8922a/arch/arm/boot/dts/mt8135-clocks.dtsi#L944-L948 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/decd80c01d0dbe9f3afa8ff72273b5618b418180/drivers/clk/mediatek/clk-mt8135.c#L881-L882 Link: https://github.com/mtk09422/chromiumos-third_party-kernel-mediatek/blob/9b6f06cb7637100aa1a42e1fc351b36b384a1c54/drivers/clk/mediatek/clk-mt8135.c#L450 Fixes: a8aede794843 ("clk: mediatek: Add basic clocks for Mediatek MT8135.") Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: clocking-wizard: Program PLL CP/RES and lock parameters on reconfigShubhrajyoti Datta
When dynamically reconfiguring the PLL multiplier, the charge pump (CP), loop filter resistance (RES), and lock timing parameters must be updated to match the new multiplier value. Without this, the PLL may fail to lock or exhibit jitter at certain multiply factors. Add lookup tables for CP/RES and lock timing values indexed by multiplier range, and program registers for chargepump and lock delay during dynamic reconfiguration. Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: tegra: support 48MHz clock for pll_p_out1Dmitry Osipenko
UEFI on Surface2 sets pll_p_out1 to 48MHz which is not supported by kernel and causes BUG() early on. Add 48MHz clock support for pll_p_out1. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: aspeed: add AST2700 PECI clockRyan Chen
Register the SoC1 PECI clock as a mux selected by SCU1_CLK_SEL2 bit 16, choosing between the 25MHz CLKIN and HPLL/4. Add the HPLL/4 fixed factor clock to serve as the second mux parent. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28dt-bindings: clock: ast2700: add PECI clockRyan Chen
Add SCU1_CLK_PECI for the SoC1 PECI controller clock source, and SCU1_CLK_HPLL_DIV4 which serves as one of the PECI clock mux parents. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: mediatek: Add mt8173-mfgtop driverChen-Yu Tsai
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP in the datasheet, that contains clock gates, some power sequence signal delays, and other unknown registers that get toggled when the GPU is powered on. The clock gates are exposed as clocks provided by a clock controller, while the power sequencing bits are exposed as one singular power domain. Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28dt-bindings: clock: mediatek: Add mt8173 mfgtopChen-Yu Tsai
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP in the datasheet, that contains clock gates, some power sequence signal delays, and other unknown registers that get toggled when the GPU is powered on. The clock gates are exposed as clocks provided by a clock controller, while the power sequencing bits are exposed as one singular power domain. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: tegra: clean-up simple provider misuse of the consumer APIJerome Brunet
Clock provider should not be using the consumer interface. In other words, a provider should not be dealing with struct clk. This change targets occurrences for which the provider uses the consumer interface and corresponding clk_hw interface exist. Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-28clk: st: clean-up simple provider misuse of the consumer APIJerome Brunet
Clock provider should not be using the consumer interface. In other words, a provider should not be dealing with struct clk. This change targets occurrences for which the provider uses the consumer interface and corresponding clk_hw interface exist. Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-21 23:03:33 +0000