| Age | Commit message (Collapse) | Author |
|---|
|
__cpuinfo_store_cpu() stores ID_AA64PFR0_EL1 and ID_AA64PFR1_EL1 with
their overrides applied and every other register raw. Store the rest
the same way. Everything read with read_cpuid() goes through
read_cpuid_with_overrides(). CTR_EL0 and CNTFRQ_EL0, which are read
otherwise, go through arm64_ftr_reg_override(). It returns a register
with no override unchanged, so an override added to one later takes
effect without a change here.
init_cpu_ftr_reg() then gets values that already carry every valid
override, so its code to apply one is dead. Remove that code.
init_cpu_ftr_reg() still removes an unsafe override, so the same
overrides are rejected and sys_val is unchanged. Only its log changes.
The raw value is gone, so it logs an override equal to that value as
"forced" rather than "already set".
Secondaries are compared with the boot CPU on their stored values, so
CPUs that differ only in a field the command line turned off no longer
taint the kernel.
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Signed-off-by: Will Deacon <will@kernel.org>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
MPAMIDR_EL1 is the one ID register __cpuinfo_store_cpu() doesn't read.
Its read was deferred to init_cpu_features() and update_cpu_features()
because it traps on firmware that fails to enable MPAM. Only the
sanitised ID_AA64PFR0_EL1 and ID_AA64PFR1_EL1 carried the arm64.nompam
override for such firmware.
Store ID_AA64PFR0_EL1 through read_cpuid_with_overrides() as well. Then
read MPAMIDR_EL1 in __cpuinfo_store_cpu() again, beside GMID_EL1, gated
on this CPU's overridden ID_AA64PFR0_EL1 and ID_AA64PFR1_EL1. cpu_data
is then complete before init_cpu_features() runs.
Other readers of the stored ID_AA64PFR0_EL1 see the override too. With
arm64.no32bit_el0, __cpuinfo_store_cpu() no longer reads the AArch32 ID
registers. Adding allow_mismatched_32bit_el0 no longer enables 32-bit
EL0 either.
detect_ftr_has_mpam(), a system-wide test on the sanitised values,
stays for the ARM64_MPAM capability.
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
__cpuinfo_store_cpu() stores the ID registers raw. Its gates on reading
a feature's register test those raw values. The exception is
gmid_el1_accessible(), which open-codes MTE's command-line override. It
checks the override with arm64_ftr_safe_value(), since
init_cpu_features() hasn't yet removed an unsafe one. The other gates
still read a feature's register when the command line disabled it. That's
the read that trapped on GMID_EL1.
Add read_cpuid_with_overrides(), which applies every valid override to
any register in arm64_ftr_regs[]. An override is valid when
arm64_ftr_safe_value() returns it unchanged. validate_ftr_regs() has
checked the table by the first store, so the lookup is safe there.
arm64_apply_feature_override() can't do this: it takes one field and no
descriptor to check the override against.
Store ID_AA64PFR1_EL1 through it, and replace gmid_el1_accessible()
with a test on the stored value at its three callers, as for SME.
Other readers of the stored value see the override too. With
arm64.nosme, __cpuinfo_store_cpu() no longer reads SMIDR_EL1. CPUs that
differ only in an ID_AA64PFR1_EL1 field the command line turned off no
longer taint the kernel. init_cpu_ftr_reg() logs a valid override as
"already set" rather than "forced".
The helper is Suzuki's override_cpu_ftr_reg(), without its other two
call sites.
Co-developed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Suggested-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/all/afc5bd00-28ca-413b-b047-ee53589c285d@arm.com/
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Signed-off-by: Will Deacon <will@kernel.org>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
sort_ftr_regs() sorts nothing. It checks that arm64_ftr_regs[] is in
sys_id order, which the binary search in get_arm64_ftr_reg() relies on,
and that no register's fields overlap. It runs at the top of
init_cpu_features(), after the boot CPU's __cpuinfo_store_cpu(). A
subsequent patch makes __cpuinfo_store_cpu() look registers up in the
table.
Rename it validate_ftr_regs() and call it from smp_prepare_boot_cpu(),
ahead of cpuinfo_store_boot_cpu().
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
HyeongJun An <sammiee5311@gmail.com> says:
These are more fixes found by the overlap scan from the first series
[1]. In each driver a control writes bits that belong to another
control, or writes the left channel bits for a right channel control.
[1] https://lore.kernel.org/all/20261008130953.2446692-1-sammiee5311@gmail.com/
Link: https://patch.msgid.link/cover.1791959026.git.sammiee5311@gmail.com
|
|
ADC polarity is bit 0 of WM8510_ADC, not bit 0 of WM8510_COMP, which
is the loopback enable. wm8974, which has the same register layout,
already uses WM8974_ADC for this control.
Fixes: 5d421516670e ("[ALSA] ASoC: Add WM8510 driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/6ada61df8c8fc97ffb1623e74f6742ca498032fa.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The noise gate type is wm8750_enum[7], bit 1 of WM8750_NGATE, not
wm8750_enum[4], which is the 3D upper cut-off.
Fixes: abadfc928a27 ("[ALSA] ASoC codecs: WM8750 support")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/ce530dfb932d9e8def75059ab9d669360adc76e8.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The EQ3 band 1 gain is in WM5100_EQ3_1, not in WM5100_EQ1_1, which
holds the EQ1 band 1 gain.
Fixes: 6d4baf084f4d ("ASoC: Add WM5100 driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/d7f690e391feda7a6d8f38d0b238b165bc1f4fe2.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The mic (xMZC) and PGA (xPZC) zero cross bits are bits 3 and 2 of each
channel's Audio Path register. SOC_DOUBLE takes one register and two
shifts, so both controls only write the left register. Use
SOC_DOUBLE_R, as the Mic Boost Switch next to them does.
Fixes: 2a9ae13a2641 ("ASoC: Add initial WM8737 driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/36cab58287bd24955e73bfe3a6fb24cae8fad7b8.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The Right Output Mixer Right Input Volume (MIXINR_MIXOUTR_VOL) is at
bits 2:0 of Output Mixer6, not at bits 8:6, which hold the IN2LN volume
(IN2LN_MIXOUTR_VOL).
Fixes: 942c435ba79f ("ASoC: Add WM8993 CODEC driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/1ea1d115cea5b183dd51bba5cd9e38157b3482ee.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Treble cutoff (TC) is at bit 6 of Treble Control, not at bit 2, which
is part of the treble volume (TRBL[3:0]).
Fixes: 54db41c116c3 ("ASoC: wm8955: Use SOC_ENUM_SINGLE_DECL()")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/b398bc6dcf8dc2b93504608cdf952823ca238cd5.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The noise gate hold time (NG_HLD) is at bits 6:5 of each WM8958 DAC
noise gate register, not at bits 3:1, which hold the threshold
(NG_THR).
Fixes: 1ddc07d0f13a ("ASoC: Add WM8958 noise gate support")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/8acff0f7314eef9eb3d290ca7855a87052d7e706.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ADC 128x oversampling (ADCOSR128) is at bit 3 of ADC Control, not at
bit 8, which is the high pass filter enable (HPFEN).
Fixes: 6d6f8b832705 ("ASoC: WM8985: Initial driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/00ae032401aaad740b61d664c861b72d2e5ed520.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ADC 128x oversampling (ADCOSR128) is at bit 3 of ADC Control, not at
bit 8, which is the high pass filter enable (HPFEN).
Fixes: 6b3860b0a20a ("ASoC: WM8983: Initial driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/d6a5bbab35e1fd2bec5b13d30951546080d493a8.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The LOMIX AINLMUX bypass volume (LLBLOVOL) is at bits 2:0 of Output
Mixer5, not at bits 5:3, which hold the AINRMUX bypass volume
(LRBLOVOL).
Fixes: 203db220718c ("ASoC: WM8991: Add initial WM8991 driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/c6e230b0e7d7e3db2136cc751e0b563030dbc16d.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The right input PGA boost (R12MNBST, R34MNBST) and routing (R12MNB,
R34MNB) bits are in Input Mixer4 (R42), not in Input Mixer3 (R41),
where these controls write the left channel bits.
Fixes: 203db220718c ("ASoC: WM8991: Add initial WM8991 driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/5c0196e45dff1769682d885fc26e613648e05436.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The LOMIX AINLMUX bypass volume (LLBLOVOL) is at bits 2:0 of Output
Mixer5, not at bits 5:3, which hold the AINRMUX bypass volume
(LRBLOVOL).
Fixes: f10485e79882 ("[ALSA] ASoC: Add WM8990 driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/87b3bfa7711b61d89c21044d02fb3242dd934385.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The right input PGA boost (R12MNBST, R34MNBST) and routing (R12MNB,
R34MNB) bits are in Input Mixer4 (R42), not in Input Mixer3 (R41),
where these controls write the left channel bits.
Fixes: f10485e79882 ("[ALSA] ASoC: Add WM8990 driver")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/818cf8d7ae81fa46c67cd5b4d01291a63f44c9a1.1791959026.git.sammiee5311@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
PCIE_ESWIN is tristate and eswin_pcie_driver uses an OF match table, but
the table is not exported. The resulting module lacks the OF alias
needed for automatic loading on an ESWIN PCIe host controller.
Export the OF table. Keep builtin_platform_driver() and the intentional
absence of an unregister path unchanged; module alias publication does
not require making this interrupt-controller driver unloadable.
The issue was found by our static-analysis tool.
Assisted-by: LLM
Fixes: b593c26d081a ("PCI: eswin: Add ESWIN PCIe Root Complex driver")
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260920033737.13957-1-hppiscas@163.com
|
|
pmz_status_handle() sets PMACZILOG_FLAG_BREAK from RR0, and
pmz_receive_chars() clears it on the null character that ends the
break without marking that character, then tests BRK_ABRT in RR1,
where the SCC does not set it in asynchronous mode. Breaks therefore
arrive as plain NULs: brk is never counted and BRKINT, PARMRK and SysRq
never see them.
Set BRK_ABRT in r1 for that character, as sunzilog does.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Assisted-by: LLM
Signed-off-by: Tim Douglas <me@timdoug.com>
Link: https://patch.msgid.link/20261013013541.4535-3-me@timdoug.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
pmz_interrupt() drains both channels but, since commit 2e124b4a390c
("TTY: switch tty_flip_buffer_push"), pushes the flip buffer of the
port whose handler is running rather than the port that was drained.
With both ports open, data received on the other port can be left in
its flip buffer until something else pushes it, so its reader may not
see it.
Fixes: 2e124b4a390c ("TTY: switch tty_flip_buffer_push")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Tim Douglas <me@timdoug.com>
Link: https://patch.msgid.link/20261013013541.4535-2-me@timdoug.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Disabling RS485 on an open port calls pl011_rs485_tx_stop(), which
turns off the transmitter. Only the RS485 TX path turns it back on, so
any later output stays queued and tcdrain() hangs until the port is
closed.
pl011_rs485_tx_stop() also checks only the hardware FIFO. If a DMA
transfer has started but has not filled the FIFO yet, the transmitter
is turned off under the transfer and the DMA channel never recovers.
When leaving RS485 mode, cancel pending deferred starts and stops, leave
the transmitter enabled and start any TX that was still waiting for
delay_rts_before_send.
Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support")
Cc: stable@kernel.org
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261012-fix-pl011-rs485-txe-v2-1-e9bf7d218389@tipi-net.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When another console is selected and there is no matching ttyNVT console
argument, the core accepts the MA35D1 console without calling its setup
function because it has CON_ENABLED set before registration. Its index
remains -1 and printk repeatedly reports an invalid port, flooding the
console and preventing boot.
Let the console core enable it after successful setup.
Fixes: 930cbf92db01 ("tty: serial: Add Nuvoton ma35d1 serial driver support")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20261012055340.16719-1-kmehltretter@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
While the driver waits out delay_rts_before_send, another write calls
pl011_start_tx() again. pl011_rs485_tx_start() then switches straight
to SEND, and the data goes out before the delay has passed.
Leave the start to the trigger_start_tx timer while it is pending.
Fixes: 2c1fd53af21b ("serial: amba-pl011: Fix RTS handling in RS485 mode")
Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261011-fix-pl011-rs485-rts-delay-v1-1-5078e61bc408@tipi-net.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 7885af04df6e4efd72910200c1bfc079d61202e4.
Commit 7885af04df6e ("serial: 8250_port: Drop duplicate NULL check")
added `up->dma = NULL;` to serial8250_release_dma(), with the stated
intent of making sure DMA would not be used again after release.
However, up->dma is assigned once at probe time. serial8250_do_startup()
only calls serial8250_request_dma() when up->dma is non-NULL, so after
the first close the pointer stays NULL and DMA is never re-acquired.
On Intel Tangier (Edison) with HSU DMA this causes a regression: the
first port open uses TX DMA, the second and later opens transmit in PIO
mode, producing 64-byte FIFO bursts with ~50us gaps between them.
Fixes: 7885af04df6e ("serial: 8250_port: Drop duplicate NULL check")
Cc: stable@kernel.org
Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20261010193755.187706-2-ftoth@exalondelft.nl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
serial8250_register_8250_port() returns a line number and the other
port operations (serial8250_unregister_port(), serial8250_suspend_port(),
serial8250_resume_port()) accept it. Many drivers then convert the line
back to the port using serial8250_get_port() anyway.
Switch the interface to struct uart_8250_port:
* serial8250_register_8250_port() now returns the registered port, or
an ERR_PTR() on failure.
* serial8250_unregister_port(), serial8250_suspend_port() and
serial8250_resume_port() accept the port.
Convert all users accordingly. Drivers store the port pointer instead
of the line number. Several drivers kept a private struct only to hold
the line (airoha, dfl, em, fsl, ioc3); these are dropped and the port
is stored as drvdata directly.
This also fixes two latent issues:
* For a CIR port, serial8250_register_8250_port() used to return 0.
Callers stored this as the line, so a later unregister/suspend/resume
operated on ttyS0. Now the CIR port itself is returned.
* 8250_acorn checked ports[i] > 0 on removal, so a port registered as
line 0 was never unregistered.
There are no more users of serial8250_get_port() outside of the 8250
core, so drop its EXPORT.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Assisted-by: LLM
Link: https://patch.msgid.link/c59fa203f325e0fe7601ea0fbc0d222c8b37f9eb.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
omap8250_irq() is requested in omap8250_probe() with IRQ_NOAUTOEN and
enabled only in omap_8250_startup(). The handler obtains the port by
serial8250_get_port(priv->line), but probe stores priv->line only after
serial8250_register_8250_port() returns.
The port becomes visible to userspace already inside
serial8250_register_8250_port() (uart_add_one_port()). So it can be
opened -- and the IRQ enabled -- before probe stores the line. An
interrupt in that window makes the handler call
serial8250_get_port(-ENODEV) and dereference a pointer outside of
serial8250_ports[].
Store the line in omap_8250_startup() before enable_irq(), so the
handler never runs with an unset line. Keep the assignment in probe
too, as remove and the system PM callbacks rely on it even when the
port was never opened.
Fixes: fef4f600319e ("serial: 8250: omap: Fix life cycle issues for interrupt handlers")
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Assisted-by: LLM
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/3b3a642f7df2285f49a7bbbe5d1c23fa442c7d94.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
lpss8250_probe() calls lpss->board->exit() on its error path. For the
EHL board, that is ehl_serial_exit() and it does:
serial8250_get_port(lpss->data.line)->dma = NULL;
But when lpss8250_dma_setup() or serial8250_register_8250_port() fails,
lpss->data.line was never assigned. As lpss is kzalloc()ed, line is 0
and ehl_serial_exit() clears the dma pointer of an unrelated port --
serial8250_ports[0], i.e. ttyS0, which is often the console.
Initialize lpss->data.line to -1 in probe and skip the clearing in
ehl_serial_exit() if no port was registered.
Fixes: 5318f70da7e8 ("serial: 8250_lpss: Balance reference count for PCI DMA device")
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Assisted-by: LLM
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: stable@kernel.org
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-serial@vger.kernel.org
Link: https://patch.msgid.link/f389df34aaa538270313ebd4cea75c2baaf46b95.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Svyatoslav Ryhel <clamor95@gmail.com> says:
Add Wolfson Microelectronics WM8994 codec support to the Tegra ASoC
machine driver. The WM8994 codec is found on devices like LG Optimus 2X
(P990/star) and Samsung Captivate Glide (SGH-i927).
Link: https://patch.msgid.link/20261014120148.126160-1-clamor95@gmail.com
|
|
Add Wolfson Microelectronics WM8994 codec support to the Tegra ASoC
machine driver. The WM8994 codec is found on devices like LG Optimus 2X
(P990/star) and Samsung Captivate Glide (SGH-i927).
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20261014120148.126160-3-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add dt-binding for WM8994 CODEC.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20261014120148.126160-2-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On a desktop debug kernel (PROVE_LOCKING, KASAN, LOCKDEP_CHAINS_BITS=19)
lockdep switches itself off after about two days of uptime with
"BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!", and locking is not validated
until the next reboot. In the last such boot the pool ran out after 46.6
hours, and a fifth of it, 533509 of 2621431 chain hlocks in 63838 of
344717 chains, had been created by the deferred hrtimer rearm on return
from interrupt.
Make lockdep account that rearm as part of the timer interrupt it
belongs to.
Commit 15dd3a948855
("hrtimer: Push reprogramming timers into the interrupt return path")
moved the reprogramming of the clock event device out of the timer
interrupt into the interrupt return path. On return to kernel mode
irqentry_exit_to_kernel_mode_after_preempt() performs it after
irq_exit_rcu() has already left lockdep's hardirq context. lockdep
therefore records hrtimer_bases.lock and the timekeeper sequence count
as taken by the interrupted context, on top of the locks that context
holds, and every distinct held-lock stack an interrupt hits adds two
lock chains. When the rearm runs from irq_enter_rcu() or
__irq_exit_rcu() it is still inside lockdep's hardirq context, and there
the same acquisitions reuse one pair of chains.
The dependencies recorded on the return path are "lock held with
interrupts enabled -> hrtimer_bases.lock". Such a lock is hardirq-unsafe
and hrtimer_bases.lock is hardirq-safe, so a path in the reverse
direction is already reported by the irq-safety checks without these
edges.
Re-enter lockdep's hardirq context around the rearm on the kernel return
path. The return to user mode path holds no locks and is left alone, as
is the rearm in __schedule(), which runs under the runqueue lock.
With the same kernel tree, configuration and workload, one hour of
uptime including a full kernel build, the chains of this shape, with
hrtimer_bases.lock and optionally the timekeeper sequence count on top
of a held-lock stack outside the scheduler, go from 13266 (96187 chain
hlocks, 15.9% of those in use) to 4. Those 4 come from clock_was_set(),
which takes cpus_read_lock() and each CPU's hrtimer_bases.lock and reads
the clock under it.
Fixes: 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path")
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20261013071318.33300-1-mikhail.v.gavrilov@gmail.com
|
|
A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM.
It is possible for a process to wait on a shared futex with a different MM
because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED
futex by another process.
This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume
wakeups intended for a newly allocated MM at the same address.
Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID.
Leave private futexes as before to avoid influencing the performance of the
hotpath.
(Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by
setting clear_child_tid such that it points into anonymous memory, which
causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.)
Fixes: 222993395ed3 ("futex: Remove pointless mmgrap() + mmdrop()")
Closes: https://lore.kernel.org/r/CAG48ez0dLBpc3QtbAhMMVNHwHL94iHh2G+h-=BVFR4dDuzZr1g@mail.gmail.com/
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260929-futex-mmshared-fix-v1-1-262b1ffeb3d0@google.com
Cc: stable@vger.kernel.org
|
|
Paul reported recent RCU changes exposed a lost resched where CPU idles
with a rcutorture thread waiting while being completely runnable.
Dumping the rq state at the time of idling with runnable tasks showed
the following:
rq->next_class = &fair_sched_class
rq->nr_running = 1
rq->cfs.h_nr_queued = 0
rq->rt.rt_nr_running = 1
Although the waiting task was an RT task, "rq->next_class" did not point
to rt_sched_class and was stuck at the lower priority fair_sched_class.
Inspecting sched_change_end() revealed the following race with
__sched_setscheduler() for queued, but non-running tasks:
CPU0 CPU1
==== ====
__schedule()
/*
* rq->donor is a fair task that blocks.
* rq->next_class = &fair_sched_class
*/
rq_lock(rq0)
pick_next_task()
/* nr_running = 0 */
pick_task_fair()
sched_balance_newidle()
raw_spin_rq_unlock(rq0)
rq_lock(rq0)
activate_task(rq0, p)
/* p is a fair task */
rq0->nr_running++;
rq0->cfs.h_nr_queued++;
wakeup_preempt(rq, p)
rq->next_class = &fair_sched_class
resched_curr()
rq_unlock(rq0)
__sched_setscheduler(p)
/* p is moved to SCHED_RR */
task_rq_lock(p)
sched_change_begin()
rq0->cfs.h_nr_queued--;
rq0->rt.rt_nr_running++;
sched_change_end()
/*
* p->on_rq = 1 (ctx->queued)
* but p is not rq->donor
* (!ctx->running) hence
* resched_curr() is and
* rq->next_class upgrade is
* skipped.
*/
task_rq_unlock()
raw_spin_rq_lock(rq0)
/*
* rq->nr_running = 1
* rq->cfs.h_nr_queued = 0
* rq->rt.rt_nr_running = 1
* rq->next_class = &fair_sched_class
*/
if (rq->cfs.h_nr_queued && ...)
/* Above is false */
if (rq_modified_above(this_rq, &fair_sched_class))
/* Also false since rq->next_class is still fair */
/*
* sched_balance_newidle() is considered to
* have failed to pull any fair tasks and no
* other wakeups were detected.
*/
return NULL; /* pick_task_fair() */
pick_task_idle()
return rq->idle;
next = rq->idle;
/* Preemption indicators are lost */
clear_tsk_need_resched(prev);
clear_preempt_need_resched();
rq->curr = rq->idle;
!!! rq->idle switches in with rq->running == 1 but !need_resched() !!!
In simple words, enqueue, followed by a class change of the newly queued
task goes unnoticed in rq->next_class indicator and
sched_balance_newidle() sees no fair task, nor any higher priority task
enqueued.
The above sequence will lead to CPU idling with a runnable task on the
CPU.
Call wakeup_preempt() for ctx->queued cases in sched_change_end() to
re-evaluate rq->next_class after class change (ENQUEUE_CLASS) and set
the NEED_RESCHED indicator accordingly.
Newidle balance will correctly see an enqueue of a higher priority
task if a queued task was upgraded when the rq_lock() was dropped and
will retry the pick.
Closes: https://lore.kernel.org/lkml/8fa7f795-518c-4507-b684-60b0c1cac2c5@paulmck-laptop/
Fixes: 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()")
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Tested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Link: https://patch.msgid.link/20261013152455.9039-1-kprateek.nayak@amd.com
|
|
hp_populate_integer_elements_from_buffer() ignores the return value of
hp_get_string_from_buffer(). When fewer than 2 bytes are left in the
buffer, dst_size is 0, kcalloc() returns ZERO_SIZE_PTR and
hp_get_string_from_buffer() fails without writing to it, so
kstrtoint() faults on address 0x10.
Return the error instead.
Compile tested only.
Fixes: 6f2c06d5a467 ("platform/x86: hp-bioscfg: int-attributes")
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/
Link: https://patch.msgid.link/20261007134711.473857-10-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
auth_token_store() copies the token with kmemdup(), which does not NUL
terminate it, but hp_calculate_security_buffer() and
hp_populate_security_buffer() use it as a C string and read past the
allocation.
A lone newline (echo > auth_token) is worse: kmemdup() of 0 bytes
returns ZERO_SIZE_PTR, which passes the NULL checks, so a later
attribute write passes it to strlen().
A userspace replica of the two helpers under ASan reports a heap
buffer overflow in hp_calculate_security_buffer() for the unterminated
token and a fault at address 0x10 for the lone newline, and is clean
with this change.
The token is a string, so copy it with kstrndup(), which always NUL
terminates and allocates at least one byte.
Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20261007134711.473857-9-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
status_show() indexes the 3-entry spm_state_types[] with the state byte
returned by firmware. update_spm_state() stores the same byte, which
key_mechanism_show() uses to index the 3-entry spm_mechanism_types[].
Neither is range checked, so a state above 2 makes the world-readable
status and key_mechanism files print a string from a pointer read past
the array.
Return -EIO for an out of range state.
Compile tested only.
Fixes: b2715aa2e135 ("platform/x86: hp-bioscfg: spmobj-attributes")
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20261007134711.473857-8-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
current_password and new_password hold MAX_PASSWD_SIZE bytes including
the NUL, but validate_password_input() accepts a password of exactly
MAX_PASSWD_SIZE characters when the firmware limits allow it.
strscpy() then truncates it and fails with -E2BIG, which
store_password_instance() ignores, so the write reports success with a
truncated password stored.
For example, with a max_password_length of 64 or more, writing 64
characters succeeds but only 63 are stored.
Reject lengths of MAX_PASSWD_SIZE or more.
Compile tested only.
Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes")
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/
Link: https://patch.msgid.link/20261007134711.473857-6-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The ABI documents echo "" > current_password as the way to end a
session, but validate_password_input() rejects an empty string when
min_password_length is nonzero, so the password stays cached.
Skip the length check for an empty current_password so the write
clears it.
Compile tested only.
Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/
Link: https://patch.msgid.link/20261007134711.473857-5-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
validate_password_input() returns the positive INVALID_BIOS_AUTH on
rejection. store_password_instance() skips the store on nonzero ret,
but its final "return ret < 0 ? ret : count" treats the positive value
as success, so userspace sees count instead of an error.
Return -E2BIG for an invalid password length.
Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7): writing 999
bytes to current_password returned 999 before this change.
Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/
Link: https://patch.msgid.link/20261007134711.473857-4-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
hp_get_string_from_buffer()
utf16s_to_utf8s() writes into dst, but the loop that follows
overwrites dst from the raw UTF-16 code units with truncating casts,
so any character above U+007F is mangled. For example, U+00E9 is
stored as 0xe9 instead of 0xc3 0xa9.
Convert into a scratch buffer first, then escape '\\', '\r', '\n' and
'\t' into dst with string_escape_mem(). Quotes are not escaped, so the
existing strreplace() still handles them.
Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7).
Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg")
Cc: stable@vger.kernel.org
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://lore.kernel.org/all/20261007134711.473857-1-meatuni001@gmail.com/
Link: https://patch.msgid.link/20261007134711.473857-3-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The escape prescan loop uses 'size' as both its bound and its
accumulator, so each escape character found extends the loop and
reads past the end of src[].
Use the original u16 count as the loop bound. Also include the 2-byte
length prefix in the bounds check, pass the u16 count instead of the
byte count to utf16s_to_utf8s(), and advance the buffer by the bytes
actually consumed instead of the escape-inflated count.
Tested on HP EliteBook 840 G2 (Fedora 44, Linux 7.2.7).
Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20261007134711.473857-2-meatuni001@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Mapping one MMIO dma-buf for many RDMA importers overflows dma-debug's
cacheline overlap counter and triggers a warning. DMA_ATTR_MMIO mappings
must never be CPU-cacheable, so CPU cacheline overlap tracking does not
apply to them.
Skip MMIO entries in both cacheline insertion and removal. Keep them in
the DMA entry hash so mapping and unmapping checks still run.
The reported warning was:
------------[ cut here ]------------
DMA-API: exceeded 7 overlapping mappings of cacheline 0x000000e040000400
WARNING: kernel/dma/debug.c:465 at add_dma_entry+0x3b5/0x470, CPU#58: dtr/5264
Modules linked in: xt_conntrack xt_MASQUERADE ip6table_nat ip6table_filter ip6_tables iptable_nat nf_nat xt_addrtype rpcsec_gss_krb5 krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm nvidia(O) mlx5_fwctl nvidia_drm(O) mlx5_ib ib_uverbs_support ib_core zram zsmalloc fuse mlx5_core
CPU: 58 UID: 0 PID: 5264 Comm: dtr Tainted: G O J 7.3.0-rc6_for_upstream_debug_2026_10_08_13_46 #1.fc40 PREEMPTLAZY
Tainted: [O]=OOT_MODULE, [J]=FWCTL
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:add_dma_entry+0x3bf/0x470
Code: ac e8 f5 89 6e 00 e9 47 fe ff ff 41 f7 c6 00 18 00 00 75 9f 83 fb 07 7e 9a 48 8d 3d eb 02 5f 04 be 07 00 00 00 48 8d 54 24 30 <67> 48 0f b9 3a eb 82 0f 0b 48 c7 c7 80 d3 2a 85 4c 89 e6 e8 a9 1f
RSP: 0018:ff110001bcb7f230 EFLAGS: 00010002
RAX: 0000000000000006 RBX: 0000000000000008 RCX: 0000000000000000
RDX: ff110001bcb7f260 RSI: 0000000000000007 RDI: ffffffff85cfd070
RBP: 000000e040000400 R08: 0000000000000000 R09: ffe21c0044b8abf5
R10: ff11000225c55faf R11: 0000000000000000 R12: 0000000000000246
R13: 1fe220003796fe48 R14: 0000000000000400 R15: 00000000ffffffff
FS: 00007fa8f91e6b80(0000) GS:ff11000eb81cc000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa8f5ca80f0 CR3: 0000000164871004 CR4: 0000000000373eb0
Call Trace:
<TASK>
? check_sync+0x2070/0x2070
? find_held_lock+0x2b/0x80
? debug_dma_map_phys+0x588/0x840
debug_dma_map_phys+0x267/0x840
? dma_debug_add_bus+0xd0/0xd0
? __sg_alloc_table+0x2b7/0x4d0
dma_map_phys+0x10a/0x330
? sg_miter_start+0x130/0x130
dma_buf_phys_vec_to_sgt+0x565/0xed0
uverbs_dmabuf_map+0x158/0x340 [ib_uverbs]
? uverbs_dmabuf_unpin+0x10/0x10 [ib_uverbs]
dma_buf_map_attachment+0x138/0x690
ib_umem_dmabuf_map_pages+0x249/0xc90 [ib_core]
pagefault_dmabuf_mr+0x172/0xf80 [mlx5_ib]
? do_raw_spin_unlock+0x54/0x210
mlx5_ib_init_dmabuf_mr+0x13e/0x200 [mlx5_ib]
[... '?' frames and user-space registers omitted ...]
reg_user_mr_dmabuf+0x3bf/0x760 [mlx5_ib]
mlx5_ib_reg_user_mr_dmabuf+0x2dd/0x13b0 [mlx5_ib]
ib_uverbs_handler_UVERBS_METHOD_REG_MR+0x76d/0xd90 [ib_uverbs]
ib_uverbs_cmd_verbs+0x2337/0x31c0 [ib_uverbs]
ib_uverbs_ioctl+0x1c7/0x350 [ib_uverbs]
__x64_sys_ioctl+0x72c/0x11f0
do_syscall_64+0xa1/0x4f0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
---[ end trace 0000000000000000 ]---
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine")
Link: https://lore.kernel.org/r/20261013-dma-debug-fixes-v1-1-1ad1f471cc61@nvidia.com
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
|
|
Use the function name in the kerneldoc description.
Fixes: c83e3d291243 ("braille: nbcon: Allow to use a serial console with NBCON API as Braille console")
Signed-off-by: Muhammad Mahdi Amirpour <ampr.mhd@gmail.com>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Link: https://patch.msgid.link/20261013151300.75966-1-ampr.mhd@gmail.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
|
|
Hardware refinement must reject disconnected streams before entering
their runtime constraint rules. The native ioctl checks the state at
the outer dispatch, before copying the parameters, while the compat
HW_REFINE32 path only checks that the runtime exists. Both call the
unlocked refinement helper without the buffer access lock used by
HW_PARAMS.
The BUFFER_BYTES rule keeps a substream pointer as its private payload.
A compat request can still enter that rule after component disconnect.
If component free overlaps its execution, the following order permits
a use-after-free read of buffer_bytes_max:
Component cleanup Compat HW_REFINE
----------------- ----------------
snd_pcm_dev_disconnect()
Runtime -> DISCONNECTED
Enter compat ioctl
snd_pcm_hw_refine()
Enter BUFFER_BYTES rule
snd_device_free()
snd_pcm_free_stream()
Free substream
Read buffer_bytes_max
Add a wrapper that acquires the existing buffer access lock and checks
the same allowed states and mmap conditions as HW_PARAMS before running
the refinement rules. Share the state checker with snd_pcm_hw_params()
and use the wrapper for native, compat and legacy PCM HW_REFINE ioctls.
This rejects the described entry after disconnect and serializes these
refinement calls with other buffer-locked parameter operations.
Keep the original snd_pcm_hw_refine() helper for existing internal
callers, including snd_pcm_hw_params() which already holds the buffer
lock, to avoid locking that mutex recursively.
KASAN report as below:
BUG: KASAN: slab-use-after-free in snd_pcm_hw_rule_buffer_bytes_max+0x276/0x2a0
Read of size 8 at addr ffff888111b36870 by task pmbd_alsa_reade/486
CPU: 2 UID: 0 PID: 486 Comm: pmbd_alsa_reade Tainted: G O 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)
Tainted: [O]=OOT_MODULE
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x93/0xd0
print_report+0xce/0x630
? snd_pcm_hw_rule_buffer_bytes_max+0x276/0x2a0
? srso_alias_return_thunk+0x5/0xfbef5
? __virt_addr_valid+0x20d/0x410
? snd_pcm_hw_rule_buffer_bytes_max+0x276/0x2a0
kasan_report+0xe0/0x110
? snd_pcm_hw_rule_buffer_bytes_max+0x276/0x2a0
snd_pcm_hw_rule_buffer_bytes_max+0x276/0x2a0
? snd_pcm_hw_rule_div+0x16b/0x200
? __pfx_snd_pcm_hw_rule_buffer_bytes_max+0x10/0x10
? constrain_params_by_rules+0x17a/0xfe0
constrain_params_by_rules+0x506/0xfe0
? __pfx_constrain_params_by_rules+0x10/0x10
? __ia32_compat_sys_ioctl+0x289/0x2f0
? do_int80_emulation+0x14a/0x5e0
? srso_alias_return_thunk+0x5/0xfbef5
? lock_release+0xc8/0x280
? srso_alias_return_thunk+0x5/0xfbef5
? snd_interval_refine+0x284/0x470
snd_pcm_hw_refine+0x768/0xcc0
? __pfx_snd_pcm_hw_refine+0x10/0x10
? _copy_from_user+0x51/0xa0
snd_pcm_ioctl_hw_params_compat+0x138/0x280
snd_pcm_ioctl_compat+0x4c5/0x7c0
? __pfx_snd_pcm_ioctl_compat+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? selinux_file_ioctl+0xaa/0x280
? ksys_write+0x16b/0x200
? __pfx_snd_pcm_ioctl_compat+0x10/0x10
__ia32_compat_sys_ioctl+0x289/0x2f0
? srso_alias_return_thunk+0x5/0xfbef5
do_int80_emulation+0x14a/0x5e0
asm_int80_emulation+0x1a/0x20
RIP: 0023:0x8049084
Code: 80 b8 04 00 00 00 bb 01 00 00 00 b9 43 a0 04 08 ba 2b 00 00 00 cd 80 b8 36 00 00 00 89 f3 b9 10 41 5c c2 ba b8 b0 04 08 cd 80 <85> c0 78 6c b8 04 00 00 00 bb 01 00 00 00 b9 27 a0 04 08 ba 1c 00
RSP: 002b:00000000ffd35e40 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000c25c4110
RDX: 000000000804b0b8 RSI: 0000000000000003 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Allocated by task 486:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
__kmalloc_cache_noprof+0x251/0x610
snd_pcm_new_stream+0x98f/0x1350
_snd_pcm_new+0x1d1/0x310
snd_pcm_new+0x43/0x60
0xffffffffc0401115
do_one_initcall+0xf3/0x4e0
do_init_module+0x281/0x8e0
load_module+0x658c/0x7cc0
init_module_from_file+0x15b/0x180
idempotent_init_module+0x22d/0x770
__x64_sys_finit_module+0xd2/0x160
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 494:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x5f/0x80
kfree+0x307/0x580
snd_pcm_free_stream+0xcf/0x290
snd_pcm_free+0xb1/0xf0
__snd_device_free+0x1a1/0x490
snd_device_free+0xcf/0x190
case_owner_ioctl+0xb8/0x160 [pmbd_alsa_fixture]
__x64_sys_ioctl+0x163/0x1d0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888111b36800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 112 bytes inside of
freed 1024-byte region [ffff888111b36800, ffff888111b36c00)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888111b35800 pfn:0x111b30
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x200000000000240(workingset|head|node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000240 ffff888100042dc0 ffffea0004218610 ffffea00042c6810
raw: ffff888111b35800 000000000010000f 00000000f5000000 0000000000000000
head: 0200000000000240 ffff888100042dc0 ffffea0004218610 ffffea00042c6810
head: ffff888111b35800 000000000010000f 00000000f5000000 0000000000000000
head: 0200000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888111b36700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888111b36780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888111b36800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888111b36880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888111b36900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Assisted-by: LLM
Link: https://patch.msgid.link/pm-pmb-b3f7b3445bb11aaa9a7b-v3-371faafc2599ec7fa136@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
A closing PCM substream can remain in its linked group after the
driver close callback has freed its private data. With two configured
dummy capture substreams on the same PCM device, linked with LINK,
PREPARE on the surviving substream can still visit the closing member:
Final close of A PREPARE on linked B
---------------- -------------------
snd_pcm_drop(): group -> SETUP
do_hw_free(A)
dummy_pcm_close(A): free dpcm
Take snd_pcm_link_rwsem for reading
Walk the group, including A
dummy_pcm_prepare(A)
Read freed timer_ops
pcm_release_private(A)
snd_pcm_unlink(A)
Unlink at the start of final substream release, before dropping the
stream or releasing driver resources. The link write lock waits for
an existing group PREPARE, and unlink removes the closing member from
later group actions. Keep the existing stop synchronization in
do_hw_free() before the driver resources are freed.
Make unlink independent of the pcm_release callback so OSS substreams
are covered too. Remove the native-only unlink callback and its
registration, while retaining the callback hook for OSS cleanup.
The existing KASAN report below records the freed timer_ops read in
dummy_pcm_prepare().
KASAN report as below:
BUG: KASAN: slab-use-after-free in dummy_pcm_prepare+0xb7/0xc0
Read of size 8 at addr ffff888106b35f00 by task alsa_pcm_fixtur/491
Call Trace:
<TASK>
dump_stack_lvl+0x93/0xd0
print_report+0xce/0x630
? dummy_pcm_prepare+0xb7/0xc0
? srso_alias_return_thunk+0x5/0xfbef5
? __virt_addr_valid+0x20d/0x410
? dummy_pcm_prepare+0xb7/0xc0
kasan_report+0xe0/0x110
? dummy_pcm_prepare+0xb7/0xc0
dummy_pcm_prepare+0xb7/0xc0
snd_pcm_do_prepare+0x71/0xb0
snd_pcm_action_group+0x505/0xb30
snd_pcm_action_nonatomic+0xab/0x150
snd_pcm_common_ioctl+0x1bf5/0x3a50
? srso_alias_return_thunk+0x5/0xfbef5
? do_vfs_ioctl+0x1f5/0x1280
? __pfx_do_vfs_ioctl+0x10/0x10
? ioctl_has_perm.constprop.0.isra.0+0x34f/0x500
? __pfx_snd_pcm_common_ioctl+0x10/0x10
? __fput+0x5ba/0xa60
? srso_alias_return_thunk+0x5/0xfbef5
snd_pcm_ioctl+0x76/0xb0
? __pfx_snd_pcm_ioctl+0x10/0x10
__x64_sys_ioctl+0x163/0x1d0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x41ee8d
Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
RSP: 002b:00007ffcfa72fb60 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 000000000041ee8d
RDX: 0000000000000000 RSI: 0000000000004140 RDI: 0000000000000004
RBP: 00007ffcfa72fbb0 R08: 00007ffcfa72fb98 R09: 0000000000000110
R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfa72fcd8
R13: 00007ffcfa72fcf0 R14: 00000000004a8f28 R15: 0000000000000001
</TASK>
Allocated by task 488:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0xaa/0xb0
__kmalloc_cache_noprof+0x251/0x610
dummy_hrtimer_create+0x4a/0x170
dummy_pcm_open+0xe7/0x730
snd_pcm_open_substream+0x926/0x1580
snd_pcm_open+0x28d/0x6d0
snd_pcm_capture_open+0x82/0xe0
snd_open+0x1ec/0x3e0
chrdev_open+0x21f/0x660
do_dentry_open+0x5c8/0x1300
vfs_open+0x87/0x390
path_openat+0x2460/0x3cd0
do_file_open+0x21e/0x470
do_sys_openat2+0xf4/0x1b0
__x64_sys_openat+0x136/0x1e0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 490:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x5f/0x80
kfree+0x307/0x580
dummy_hrtimer_free+0x72/0xe0
dummy_pcm_close+0x9f/0xd0
snd_pcm_release_substream.part.0+0x104/0x310
snd_pcm_release+0x106/0x240
__fput+0x39f/0xa60
fput_close_sync+0xff/0x200
__x64_sys_close+0x8c/0xf0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
==================================================================
Fixes: 1576274d3028 ("[ALSA] Fix Oops of PCM OSS emulation")
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Link: https://patch.msgid.link/pm-pmb-9c80f858ccc13b3de84d-v7-fcd8c7aa0e837bf0b036@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ins->code.offset and code->size are measured in 32-bit words, while
DSP_CODE_BYTE_SIZE is the size of the DSP code area in bytes. The
check ins->code.offset + code->size > DSP_CODE_BYTE_SIZE in
cs46xx_dsp_load_module() therefore allowed up to four times more code
than the code area can hold.
The shadow buffer ins->code.data is allocated with
kmalloc(DSP_CODE_BYTE_SIZE), i.e. it holds DSP_CODE_BYTE_SIZE/4
words. A firmware file with a code segment larger than
DSP_CODE_BYTE_SIZE/4 words (28 KiB) passed the check and caused an
out-of-bounds write in shadow_and_reallocate_code() and an
out-of-bounds read in snd_cs46xx_download().
Compare the sum in words against DSP_CODE_BYTE_SIZE/4 and cast it to
u64 so that the sum cannot wrap for large code->size values.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Denis Arefev <arefev@swemel.ru>
Link: https://patch.msgid.link/20261014102619.16415-1-arefev@swemel.ru
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ACP7X_PDM_DMIC0 and ACP7X_PDM_DMIC1 identify the active PDM controller
on ACP7.B/7.F platforms. They are carried in amd_pdm_pdata.pdm_sel,
which is defined in acp-mach-common.h, and in amd_mc_ctx.pdm_sel, which
is defined in soc_amd_sdw_common.h.
Move the constants to acp-mach-common.h so there is a single shared
location for all PDM types and values, accessible to every AMD ACP
machine driver (I2S, SoundWire, and SOF paths) without driver-specific
header duplication. Remove the duplicate definition from
sound/soc/sof/amd/acp.h.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Remove the spurious blank line at the end of acp_asp_mailbox.c.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The speaker and microphone mute LEDs on the IdeaPad Pro 5 14IAH10
do not follow the ALSA mute state. This machine has an ALC287 codec
with SSID 17aa:3914, but shares PCI SSID 17aa:3843 with the Yoga
Book 9i and currently gets its fixup.
Add a codec SSID quirk that runs the IdeaPad ACPI LED fixup. Chain
the existing bass speaker amp fixup so the audio setup is retained.
Tested on the IdeaPad Pro 5 14IAH10: muting and unmuting the
headphone sink toggled the physical speaker mute LED. Muting both
microphone controls changed the ALSA mic LED state from 0 to 1.
Signed-off-by: Aayush Kumar <aayushkmx@gmail.com>
Link: https://patch.msgid.link/20261014072505.60358-1-aayushkmx@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
