summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-10ASoC: stm: stm32_adfsdm: set debugfs_prefix via Component driverKuninori Morimoto
We can set component->debugfs_prefix via component_driver->debugfs_prefix. Use it. Now it no longer need to use snd_soc_component_initialize() / snd_soc_component_add(). Use snd_soc_component_register() instead. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87fr35k5vs.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: soc-generic-dmaengine: set debugfs_prefix via Component driverKuninori Morimoto
We can set component->debugfs_prefix via component_driver->debugfs_prefix. Use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87h5nlk5vx.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: fsl: imx-pcm-rpmsg: set debugfs_prefix via Component driverKuninori Morimoto
We can set component->debugfs_prefix via component_driver->debugfs_prefix. Use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87ik81k5w2.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: soc-component: remove CONFIG_DEBUG_FS for debugfs_prefixKuninori Morimoto
Both (A) and (B) have debugfs_prefix, but (B) is using CONFIG_DEBUG_FS (C) (A) struct snd_soc_component { ... const char *debugfs_prefix; }; (B) struct snd_soc_component_driver { ... (C) ifdef CONFIG_DEBUG_FS const char *debugfs_prefix; endif }; Remove (C) which makes code cleanup difficult. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87jyshk5wc.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10platform/x86/amd/pmc: Add PMC driver support for AMD 1Ah M80H SoCShyam Sundar S K
The 1Ah M80H SoC uses a different set of SMU mailbox register offsets compared to the existing 1Ah variants: message at 0xA10, argument at 0xA18, and response at 0xA14. Add amd_1ah_m80_cpu_info with these offsets, wire it into the PCI ID table via PCI_DEVICE_DATA(), populate scratch_reg field with AMD_PMC_SCRATCH_REG_1AH and add the corresponding ACPI ID AMDI000C. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260609143952.2999707-3-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10platform/x86/amd/pmc: Use per-SoC cpu_info struct for SMU mailbox and IP infoShyam Sundar S K
Replace the scattered per-field assignments in amd_pmc_get_ip_info() with a single amd_pmc_cpu_info struct capturing all SoC-specific parameters such as SMU offsets, IP block table, and OS hint. Define static const instances per SoC variant and embed them as driver_data in the PCI ID table via PCI_DEVICE_DATA(). Consolidate pci_match_id() into amd_pmc_set_cpu_info(), which assigns driver_data directly to cpu_info, the switch falls through only for 1Ah M20H/M60H variants requiring boot_cpu_data.x86_model detection to distinguish the M70 sub-variant. Add scratch_reg to amd_pmc_cpu_info and populate it for each SoC variant, allowing amd_pmc_idlemask_read() to drop its cpu_id switch in favour of a single cpu_info->scratch_reg lookup. Move dev->cpu_id assignment into amd_pmc_set_cpu_info() so it is valid before the switch statement. Handle SP/SHP directly in the switch since their NULL driver_data bypasses the early return, and remove the duplicate check from probe. Remove amd_pmc_get_os_hint() and use cpu_info->os_hint directly at call sites and rename AMD_CPU_ID_* to PCI_DEVICE_ID_AMD_CPU_ID_* with backward compatibility aliases. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260609143952.2999707-2-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10ASoC: dt-bindings: everest,es8389: Document audio graph portDiederik de Haas
Provide an endpoint for binding with the other side of the audio link, which is achieved via the 'port' property. Signed-off-by: Diederik de Haas <diederik@cknow-tech.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260607105913.355966-1-diederik@cknow-tech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10platform/x86: intel-hid: Add HP ProBook x360 440 G1 to button_array_tableNikolay Metchev
The volume rocker buttons on the HP ProBook x360 440 G1 convertible emit events 0xc4-0xc7 via the intel-hid ACPI device (INT33D5). These codes are only present in intel_array_keymap, which is used when the "5 button array" input device exists. On this machine button_array_present() returns false because the firmware does not advertise the array through the HEBC method, so notify_handler() routes the events to a NULL priv->array and they are dropped as "unknown event 0xc4". As a result the side volume keys do nothing. Add the machine to button_array_table so the array device is created and the volume rocker emits KEY_VOLUMEUP / KEY_VOLUMEDOWN. This is equivalent to booting with the enable_5_button_array=1 module parameter, which was used to confirm the fix on the affected hardware. Signed-off-by: Nikolay Metchev <nikolaymetchev@gmail.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260609213309.445019-1-nikolaymetchev@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-10spi: dt-bindings: nuvoton,npcm750-fiu: Convert to DT schemaTomer Maimon
Convert the Nuvoton NPCM FIU binding to DT schema format. Document the required control registers and the optional direct- mapped flash window separately, matching the driver behavior when the direct mapping is not described. Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260609163919.3321228-4-tmaimon77@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: SOF: topology: validate vendor array size before parsingCássio Gabriel
sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available. Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size. The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has type size_t, so comparing them directly promotes negative asize values to unsigned and lets them pass the check, as reported in the stable review thread reference below. Cast sizeof(*array) to int when validating the declared array size. This rejects negative, zero and otherwise too-small sizes before the parser dispatches to the tuple-specific code. Link: https://lore.kernel.org/stable/CANiDSCsjR5NHqu_Ui5cOqWdJgFqmYsQ9WR8O7m0WOhngaYXFpw@mail.gmail.com/t/#m9b3be379221e79327cc13fd71009287368ef4f23 Fixes: 215e5fe75881 ("ASoC: SOF: topology: reject invalid vendor array size in token parser") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260603-sof-topology-array-size-signed-v1-1-84f97879a4ef@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: Use codec_info_list.is_amp directly in find_acpi_adr_device()Mark Brown
Bard Liao <yung-chuan.liao@linux.intel.com> says: This series sets is_amp to all amp type codecs in codec_info_list[]. So that we can use the flag directly instead of using a local flag to check if the codec is an AMP type. The flag will be used to set different name_prefix for amp and non-amp codecs. Link: https://patch.msgid.link/20260605101805.121428-1-yung-chuan.liao@linux.intel.com
2026-06-10ASoC: SOF: Intel: Use codec_info_list.is_amp directlyBard Liao
Now we set is_amp to all amp type codecs. We can use the flag directly instead of using a local flag to check if the codec is an AMP type. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260605101805.121428-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: soc_sdw_utils: add is_amp flag to all ampsBard Liao
The is_amp flag will be used for the codec name_prefix. We detect it by checking if the codec support endpoints other than amp. However, it is not accurate. Currently, the is_amp flag is only set to the amps that include other types of endpoints. But it can't cover the case that a monolithic codec that only the amp endpoint is present. Add the is_amp flag to all amp type codecs and will set the name_prefix by the flag in the follow up commit. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260605101805.121428-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend failsRichard Fitzgerald
In cs35l56_system_suspend() re-enable the parent IRQ if the call to pm_runtime_force_suspend() returns an error. Fixes: f9dc6b875ec0 ("ASoC: cs35l56: Add basic system suspend handling") Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260610105556.612830-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC/sh: roll back Ecovec24/7724se Sound supportMark Brown
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: Hi Mark, Adrian Due to a communication miss, the Ecovec24/7724se Sound support were removed. We need to keep them for a while, until they will support "DT-style". Roll back Ecovec24/7724se "platform data style", and its necessary header. Link: https://patch.msgid.link/87wlw743x2.wl-kuninori.morimoto.gx@renesas.com
2026-06-10ASoC: renesas: fsi: remove platform data style supportKuninori Morimoto
Renesas FSI driver has created for "platform data style" first, and expanded to "DT style". SuperH Ecovec24/7724se are the last user of "platform data style", but its sound should not work during almost 10 years, because Simple-Card's "platform data style" is broken, but no one reported it. SuperH is planning to switch to "DT style", "platform data style" is no longer working, and it seems there is no user. Let's remove "platform data style", because keeping compatibility is difficult. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87tsrb43u3.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10sh: roll back Ecovec24/7724se Sound supportKuninori Morimoto
Due to a communication miss, the Ecovec24/7724se Sound support were removed. We need to keep them for a while, until they will support "DT-style". Roll back Ecovec24/7724se "platform data style", and its necessary header. Fixes: deadb855b694d ("sh: 7724se: remove FSI/AK4642/Simple-Audio-Card support") Fixes: 9cc93ebc85e71 ("sh: ecovec24: remove FSI/DA7210/Simple-Audio-Card support") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87v7br43vk.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPUWill Deacon
Commit fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata") states that Microsoft Azure Cobalt 100 CPU "is a Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore suffers from all the same errata.". So enable the workaround for the latest broadcast TLB invalidation bug on these parts. Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10ASoC: tas2783A: remove unused tas25xx_(de)register_misc() functionsEthan Nelson-Moore
The tas2783 driver defines two functions tas25xx_register_misc and tas25xx_deregister_misc which have stub implementations. It uses external implementations if CONFIG_SND_SOC_TAS2783_UTIL is enabled, but that symbol has never been present in the kernel. Therefore, these functions are entirely unused. Remove them. Discovered while searching for CONFIG_* symbols referenced in code but not defined in any Kconfig file. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260610013534.30762-1-enelsonmoore@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPUShanker Donthineni
NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLBMarc Zyngier
VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case. Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer. Solve this by introducing a new iterator built on top of the usual kvm_for_each_vcpu() that checks for both of the above conditions, and convert the two users to it. Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://lore.kernel.org/r/aiUvSbrWndQeUPc8@v4bel Fixes: 4ffa72ad8f37 ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2") Cc: stable@vger.kernel.org Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260607175745.297793-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-10arm64: errata: Mitigate TLBI errata on various Arm CPUsMark Rutland
A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10arm64: cputype: Add C1-Premium definitionsMark Rutland
Add cputype definitions for C1-Premium. These will be used for errata detection in subsequent patches. These values can be found in the C1-Premium TRM: https://developer.arm.com/documentation/109416/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10arm64: cputype: Add C1-Ultra definitionsMark Rutland
Add cputype definitions for C1-Ultra. These will be used for errata detection in subsequent patches. These values can be found in the C1-Ultra TRM: https://developer.arm.com/documentation/108014/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10Merge branch 'intel-sst' of https://github.com/spandruvada/linux-kernel into ↵Ilpo Järvinen
review-ilpo-next
2026-06-10Revert "arm64: mm: Unmap kernel data/bss entirely from the linear map"Will Deacon
This reverts commit 63e0b6a5b6934d6a919d1c65ea185303200a1874. Unmapping the kernel '.bss' appears to break KVM initialisation on some devices, breaking the boot on popular platforms such as RaspberryPi3 and 4. Revert this change for now so that we can revisit it in future. Reported-by: Mark Brown <broonie@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/all/aicVyebkEMs6w6UV@sirena.co.uk Link: https://lore.kernel.org/r/a1b27e97-182c-485d-a448-56c19c5de2c2@samsung.com Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10Revert "arm64: mm: Defer remap of linear alias of data/bss"Will Deacon
This reverts commit 53205d56212cbff880a77497e25a0e44036d490a. Unmapping the kernel '.bss' appears to break KVM initialisation on some devices, breaking the boot on popular platforms such as RaspberryPi3 and 4. Revert this change for now so that we can revisit it in future. Reported-by: Mark Brown <broonie@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/all/aicVyebkEMs6w6UV@sirena.co.uk Link: https://lore.kernel.org/r/a1b27e97-182c-485d-a448-56c19c5de2c2@samsung.com Signed-off-by: Will Deacon <will@kernel.org>
2026-06-10ntfs3: reject direct userspace writes to reserved $LX* xattrsKonstantin Komarov
NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. Signed-off-by: Zhen Yan <sdjasjbuaa@gmail.com> [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users] Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-06-10fs/ntfs3: resize log->one_page_buf when adopting on-disk page sizeJamie Nguyen
log_replay() allocates log->one_page_buf using the page size that was chosen from the host PAGE_SIZE: log->one_page_buf = kmalloc(log->page_size, GFP_NOFS); Later, when a restart area is found, the log page size recorded on disk is adopted: t32 = le32_to_cpu(log->rst_info.r_page->sys_page_size); if (log->page_size != t32) { log->l_size = log->orig_file_size; log->page_size = norm_file_page(t32, &log->l_size, t32 == DefaultLogPageSize); } If the on-disk page size is larger than the size used for the initial allocation, log->page_size grows but one_page_buf is left at its original, smaller size. A subsequent unaligned read_log_page() then reads log->page_size bytes into the undersized scratch buffer: page_buf = page_off ? log->one_page_buf : *buffer; err = ntfs_read_run_nb_ra(ni->mi.sbi, &ni->file.run, page_vbo, page_buf, log->page_size, NULL, &log->read_ahead); overflowing the allocation. This is reachable when mounting a dirty NTFS volume whose log was formatted with a page size larger than the buffer initially allocated on the mounting host (for example a 64K-log volume mounted on a host that allocated a 4K scratch buffer). Grow one_page_buf when the adopted on-disk page size exceeds the size used for the initial allocation. On krealloc() failure the original buffer is left intact and freed by the existing error path. Fixes: b46acd6a6a627 ("fs/ntfs3: Add NTFS journal") Reported-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-06-10fs/ntfs3: prevent potential lcn remains uninitializedEdward Adam Davis
The target VCN being sought was not found within runs[0], causing run_lookup() to return false. This causes run_lookup_entry() to return false, which in turn results in a len value of 0, and the new parameter passed to attr_data_get_block() is NULL. Collectively, these factors ultimately cause attr_data_get_block_locked() to exit prematurely without initializing lcn, thereby triggering [1]. To prevent [1], the clen check within ni_seek_data_or_hole() has been moved to occur before the lcn check. [1] BUG: KMSAN: uninit-value in ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ntfs_llseek+0x22a/0x4a0 fs/ntfs3/file.c:1530 vfs_llseek fs/read_write.c:391 [inline] Fixes: c61326967728 ("fs/ntfs3: implement llseek SEEK_DATA/SEEK_HOLE by scanning data runs") Reported-by: syzbot+c2cfe997245202e46f10@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c2cfe997245202e46f10 Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-06-10Merge tag 'usb-serial-7.1-rc8' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB serial fixes for 7.1-rc8 Here is one more buffer overflow fix. This one has been in linux-next overnight with no reported issues. * tag 'usb-serial-7.1-rc8' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: kl5kusb105: fix bulk-out buffer overflow
2026-06-10ASoC: cs35l56: Fix some cleanup memory leaksMark Brown
Richard Fitzgerald <rf@opensource.cirrus.com> says: These are for-next. They are not urgent because it only leaks memory if the driver failed to component_probe or is removed, which wouldn't happen in normal use. This series fixes some memory leaks: - The memory allocated by wm_adsp/cs_dsp was not freed. - If component_probe() failed it didn't clean up. The addition of this cleanup in patch #3 exposes an existing possible double-free of the debugfs, which is fixed in patch #2. Link: https://patch.msgid.link/20260610093432.557375-1-rf@opensource.cirrus.com
2026-06-10ASoC: cs35l56: Cleanup if component_probe failsRichard Fitzgerald
If cs35l56_component_probe() fails, call cs35l56_component_remove() to clean up. All the cleanup in cs35l56_component_remove() is the same cleanup that would need to be done (at least partially) if cs35l56_component_probe() fails. So calling cs35l56_component_remove() avoids convoluted cleanup gotos and duplicated code in cs35l56_component_probe(). The only action in cs35l56_component_remove() that is nominally dependent on having completed the component_probe() action is the call to wm_adsp2_component_remove(). Though it is currently safe to call that even if wm_adsp2_component_probe() was not called. However, wm_adsp2_component_probe() has been trivially updated to check itself whether it needs to cleanup. Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260610093432.557375-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: cs35l56: Prevent double-free of debugfsRichard Fitzgerald
Invalidate the debugfs pointer after debugfs_remove_recursive() in cs35l56_remove_cal_debugfs(). This prevents a double-free situation when a future commit adds proper failure cleanup in cs35l56_component_probe(). As described by Sashiko (including the future cs35l56_component_probe() cleanup commit): During a normal component unbind, cs35l56_component_remove() calls cs35l56_remove_cal_debugfs() which removes the directory but leaves a dangling pointer. If the component is later bound again, but _cs35l56_component_probe() fails early (for example, if the init_completion times out), this new error path will call cs35l56_component_remove(). This causes cs35l56_remove_cal_debugfs() to be called again with the dangling cs35l56_base->debugfs pointer from the previous lifecycle, resulting in a use-after-free in debugfs_remove_recursive(). Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration") Reported-by: sashiko <sashiko@sashiko.dev> Link: https://sashiko.dev/#/patchset/20260609120738.284770-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260610093432.557375-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()Richard Fitzgerald
Call wm_adsp2_remove() in cs35l56_remove() and the error path of cs35l56_common_probe(). Depends on commit 7d3fb78b5503 ("ASoC: wm_adsp: Fix NULL dereference when removing firmware controls"). The call to wm_halo_init() during driver probe should be paired with a call to wm_adsp2_remove() but this was missing. The consequence would be a memory leak of the control lists in the cs_dsp driver. Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260610093432.557375-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-10xfs: cleanup xfs_growfs_compute_deltasChristoph Hellwig
xfs_growfs_compute_deltas has an odd calling conventions, and looks very convoluted due to the use of do_div and strangely named and typed variables. Rename it, make it return the agcount and let the caller calculate the delta. The internally use the better div_u64_rem helper and descriptive variable names and types. Also add a comment describing what the function is used for. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-06-10xfs: pass back updated nb from xfs_growfs_compute_deltasChristoph Hellwig
xfs_growfs_compute_deltas can update nb for corner cases like a number of blocks that would create a less the minimal sized AG, or running past the max AG limit. Pass back the calculated value to the caller, as it relies on to calculate the new number of perag structures. Note that the grown file system size is not affected by this miscalculation as it uses the passed back delta value. Fixes: a49b7ff63f98 ("xfs: Refactoring the nagcount and delta calculation") Cc: stable@vger.kernel.org # v7.0 Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-06-10xfs: fix pointer arithmetic error on 32-bit systemsDarrick J. Wong
The translation of the old XFS_BMBT_KEY_ADDR macro into a static function is not correct on 32-bit systems because the sizeof() argument went from being a xfs_bmbt_key_t (i.e. a struct) to a (struct xfs_bmbt_key *) (i.e. a pointer to the same struct). On 64-bit systems this turns out ok because they are the same size, but on 32-bit systems this is catastrophic because they are not the same size. So far there have been no complaints, most likely because the xfs developers urge against running it on 32-bit systems. But this needs fixing asap. Cc: stable@vger.kernel.org # v6.12 Fixes: 79124b37400635 ("xfs: replace shouty XFS_BM{BT,DR} macros") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-06-10xfs: initialize iomap->flags earlier in xfs_bmbt_to_iomapChristoph Hellwig
Otherwise we lose the IOMAP_IOEND_BOUNDARY assingment for writes to the first block in a realtime group, and could cause incorrect merges for such writes. Fixes: b91afef72471 ("xfs: don't merge ioends across RTGs") Cc: <stable@vger.kernel.org> # v6.13 Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-06-10xfs: only log freed extents for the current RTG in zoned growfsChristoph Hellwig
Otherwise a power fail or crash during growfs could lead to an elevated sb_rblocks counter. Note that the step function is much simpler compared to the classic RT allocator as zoned RT sections must be aligned to real time group boundaries. Fixes: 01b71e64bb87 ("xfs: support growfs on zoned file systems") Cc: <stable@vger.kernel.org> # v6.15 Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-06-10drm/amd/display: use plane color_mgmt_changed to track colorop changesMelissa Wen
Ensure the driver tracks changes in any colorop property of a plane color pipeline by using the same mechanism of CRTC color management and update plane color blocks when any colorop property changes. It fixes an issue observed on gamescope settings for night mode which is done via shaper/3D-LUT updates. Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patch.msgid.link/20260609110420.1298352-5-mwen@igalia.com
2026-06-10drm/atomic: track individual colorop updatesMelissa Wen
As we do for CRTC color mgmt properties, use color_mgmt_changed flag to track any value changes in the color pipeline of a given plane, so that drivers can update color blocks as soon as plane color pipeline or individual colorop values change. Since we're here, only announce and track changes to plane COLOR_PIPELINE prop if its value is actually changing. Fixes: 8c5ea1745f4c ("drm/colorop: Add BYPASS property") Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation") Fixes: 41651f9d42eb ("drm/colorop: Add 1D Curve subtype") Fixes: 3410108037d5 ("drm/colorop: Add multiplier type") Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline") Fixes: e5719e7f1900 ("drm/colorop: Add 3x4 CTM type") Fixes: 99a4e4f08abe ("drm/colorop: Add 1D Curve Custom LUT type") Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property") Reviewed-by: Harry Wentland <harry.wentland@amd.com> #v1 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patch.msgid.link/20260609110420.1298352-4-mwen@igalia.com
2026-06-10drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutableMelissa Wen
As interpolation props are actually mutable props, any changes should be handled by drm_colorop_state. Move their enum and make it correctly behaves as mutable. Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation") Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline") Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patch.msgid.link/20260609110420.1298352-3-mwen@igalia.com
2026-06-10drm/colorop: Remove read-only comments from interpolation fieldsAlex Hung
The lut1d_interpolation and lut3d_interpolation fields and their associated properties were marked as read-only, but userspace can set them via drm_atomic_colorop_set_property(). Fixes: 7fa3ee8c0a79 ("drm/colorop: Define LUT_1D interpolation") Fixes: db971856bbe0 ("drm/colorop: Add 3D LUT support to color pipeline") Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Fixes: 9ba25915efba ("drm/amd/display: Add support for sRGB EOTF in DEGAM block") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patch.msgid.link/20260609110420.1298352-2-mwen@igalia.com
2026-06-10ata: libata-pmp: add JMicron JMS562 quirkXu Rao
JMicron JMS562, as used in QNAP QDA-A2AR RAID1 adapters, may keep the exported ATA device not ready while the array is rebuilding. In this state, libata may repeatedly try to softreset and classify the fan-out link. On the affected adapter, this can time out, make PMP/SCR access fail, and eventually disable the fan-out link before the RAID volume is exported. A failing boot shows the fan-out link failing SRST, PMP access timing out, SCR read failing, and the link being disabled: ata4.00: softreset failed (device not ready) ata4.15: qc timeout after 3000 msecs (cmd 0xe4) ata4.00: failed to read SCR 0 (Emask=0x4) ata4.00: failed to recover link after 3 tries, disabling After that, the root filesystem on the exported RAID volume cannot be found. Add JMS562 to the existing JMicron PMP quirk that disables LPM, avoids softreset on fan-out links, and assumes an ATA device. This prevents libata from dropping the exported RAID volume during rebuild recovery. Signed-off-by: Xu Rao <raoxu@uniontech.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-06-10fanotify: allow reporting pidfds for reaped tasksAnonymeMeow
Fanotify used to refuse to report pidfds for reaped tasks by applying a pid_has_task() check before calling pidfd_prepare(). This prevented userspace from obtaining information about the task. Register the event pid with pidfs when creating the fanotify event if pidfd reporting was requested, so pidfd_prepare() can later create a pidfd for the reaped task. Suggested-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/linux-fsdevel/20260528-schmuckvoll-heilen-garen-be77b4208671@brauner/ Signed-off-by: AnonymeMeow <anonymemeow@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> Link: https://patch.msgid.link/20260607003343.425939-3-anonymemeow@gmail.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-06-10fanotify: report thread pidfds for FAN_REPORT_TIDAnonymeMeow
The FAN_REPORT_PIDFD and FAN_REPORT_TID flags used to be mutually exclusive because by the time the pidfd support was introduced to fanotify, pidfds could only be created for thread group leaders. Now that the pidfd API supports thread-specific pidfds via PIDFD_THREAD, this restriction can be lifted. Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: AnonymeMeow <anonymemeow@gmail.com> Link: https://patch.msgid.link/20260607003343.425939-2-anonymemeow@gmail.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-06-10ARM: remove the last few uses of do_bad_IRQ()Ethan Nelson-Moore
The do_bad_IRQ() macro simply calls handle_bad_irq() with a lock around it. It also carries a comment stating that uses of it should be replaced. According to commit aec0095653cd ("irqchip: gic: Call handle_bad_irq() directly"), which replaced another use of do_bad_IRQ(), locking the IRQ descriptor is not necessary for error reporting. Therefore, replace all uses of do_bad_IRQ() with calls to handle_bad_irq() and remove do_bad_IRQ(). Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://lore.kernel.org/r/20260610045626.248643-1-enelsonmoore@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-06-10b43: add RF power offset for N-PHY r8 + radio 2057 r8Alessio Ferri
Add the 2.4 GHz RF power offset table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher. b43_ntab_get_rf_pwr_offset_table() currently dispatches on phy->rev == 17 (radio_rev 14) and phy->rev == 16 (radio_rev 9) for 2.4 GHz. phy->rev == 8 falls through and the function logs: b43-phyX ERROR: No 2GHz RF power table available for this device Add a phy->rev == 8 / radio_rev == 8 case returning the new table. The values are sourced from the proprietary Broadcom wl driver's nphy_papd_padgain_dlt_2g_2057rev5 array. Reusing the rev 5 values is structurally appropriate: the IPA TX gain table added by the preceding patch in this series shares the low 24 bits of every entry with rev 5 - same gain step amplitudes, only the PAD-gain selector byte differs. b43's pad_gain extraction in b43_nphy_tx_pwr_ctl_init() reads bits 19..23 of the gain entry, which sit in the shared low-24-bit range; the same gain index therefore maps to the same physical PAD gain code on both revisions and warrants the same per-index dB offset. Note that b43_nphy_tx_gain_table_upload() currently has a "TODO: Enable this once we have gains configured" early-return for phy->rev >= 7. With that early-return in place, this table is fetched (silencing the b43err that would otherwise abort PHY init) but its values are not yet written to MMIO. Resolving the TODO is a future, separate task. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-7-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: add channel info table for N-PHY r8 + radio 2057 r8Alessio Ferri
Add the 2.4 GHz channel info table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher in r2057_get_chantabent_rev7(). The dispatcher's case 8 currently handles radio_rev == 5 only. For radio_rev == 8 both output pointers stay NULL, b43_nphy_set_channel() returns an error and channel switch to the default channel fails. The new b43_nphy_chantab_phy_rev8_radio_rev8[] is 14 entries covering the standard 2.4 GHz channel set (2412..2472 in 5 MHz steps, plus 2484 for channel 14). Values extracted from an MMIO dump of the proprietary Broadcom wl driver running on BCM6362 silicon (wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-6-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-17 10:13:48 +0000