Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
This series makes some improvements to the code that searches for firmware
files.
Patch 1 is a trivial patch to remove an unused function argument, before
adding any new code that uses this API.
Patches 2..4 add KUnit testing to prove that the subsequent changes don't
break anything.
The remaining patches remove duplicated code and clean up some of the
implementation.
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>:
The SAI and XCVR have the timestamp counters and bit counters, which can
be used by software to track the progress of the transmitter and receiver.
They can also be used to calculate the relative frequency of the bit clock
against the bus interface clock.
Report the ability to support SoundWire clock-stop mode 1 if this is
enabled in ACPI. Mode 1 allows the device to lose state, so it can
reduce power consumption in clock-stop. Also add the necessary
handling to wait for re-enumeration on resume.
This does not use sdw_slave_read_prop(), because that also fills in
other properties from ACPI that were not previously set by the driver
and this has been observed to break some systems. Instead, the
"mipi-sdw-clock-stop-mode1-supported" property is checked directly.
When a SoundWire peripheral has been put into clock-stop mode 1 it
must be re-enumerated after the clock is restarted. A new flag
sdw_in_clock_stop_1 is set to true in cs35l56_sdw_clk_stop() if the
SoundWire core notifies that it is entering clock-stop 1.
cs35l56_sdw_handle_unattach() will wait for re-enumeration if
sdw_in_clock_stop_1 is true.
sdw_in_clock_stop_1 will be reset to false when an ATTACH notification
is received in cs35l56_sdw_update_status().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260311142153.2201761-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Cezary Rojewski <cezary.rojewski@intel.com> says:
ASoC: Intel: catpt: Overhaul volume and mute control operations
Short summary first, longer description later:
- fix the return code for kctl->put() - currently the driver returns
'0' even if changes were done
- lower power consumption for kctl operations by waking the DSP only
when some streaming is done. No streaming? Cache the values and
inform the AudioDSP firmware later.
- drop the existing code duplication between individual and master
volume controls
The very first patch addresses synchronization problem that exists when
an individual control and its paired stream are manipulated by a user
simultaneously. As the refactor integrates the fix in its new code,
most of it gets shuffled but in case of a "refactor problem" I've
decided to have it separated and leading the series. This way the
problem is fixed even if refactor, for whatever reason, would be
reverted.
--
More of in-depth explanation for the refactor, taken from commit 2:
The catpt-driver's volume and mute control operations always return '0'
regardless if a change occurred or not. To conform to ALSA's interface,
value '1' shall be returned when a change occurred.
The second major point is power consumption. Existing control
operations always wake the DSP even if no streams are running. In such
case waking the DSP just for the sake of updating the volume (or mute)
settings on the firmware side is a waste of power. The provided
implementation caches the values and updates the settings only when
streams are being opened for streaming or are already running.
As changing existing code is non-trivial, provide new operations
instead. The put() operation, which interests us the most, takes the
following shape:
// two values provided to put():
// @pin_id - which stream given control relates to
// @value_to_apply - the value from user
if (control->existing_val == value_to_apply)
return 0;
runtime_stream = get_running_stream(pin_id);
if (runtime_stream != NULL) {
ret = send_ipc();
if (ret)
return ret;
}
control->existing_val = value_to_apply;
return 1;
Adheres to ALSA's expectation and avoids sending IPCs if there is no
change to be made.
Switch to the new implementation and remove all unused code. The change
effectively causes the control put() operations to return '1' if a
change occurred, '0' if no change was made or error otherwise.
The second effect of the update is reducing the power consumption. With
the new control-operations in place, the controls no longer wake the DSP
just for the sake of updating volume (or mute) settings on the firmware
side. The values are cached and actual update occurs only when streams
are being opened for streaming or are already running.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With the new control-operations in place, the controls no longer wake
the DSP just for the sake of updating volume (or mute) settings on the
firmware side. The values are cached and actual update occurs only when
streams are being opened for streaming or are already running. In those
cases the DSP must already be woken up and we avoid unnecessary power
consumption.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-5-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Existing catpt_dai_apply_usettings() applies all the individual control
settings but why-what is covered behind if-statements. Refactor the
operation into:
catpt_apply_controls()
|__ catpt_apply_volume()
|__ catpt_apply_mute()
to make it easy to understand why and what is going on. The update also
enlists snd_ctl_find_id_mixer() for the query purpose, removing code
duplication.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The catpt-driver's volume and mute control operations always return '0'
regardless if a change occurred or not. To conform to ALSA's interface,
value '1' shall be returned when a change occurred.
The second major point is power consumption. Existing control operations
always wake the DSP even if no streams are running. In such case waking
the DSP just for the sake of updating the volume (or mute) settings on
the firmware side is a waste of power. The provided implementation
caches the values and updates the settings only when streams are being
opened for streaming or are already running.
As changing existing code is non-trivial, provide new operations
instead. The put() operation, which interests us the most, takes the
following shape:
// two values provided to put():
// pin_id - which stream given control relates to
// value_to_apply - the value from user
if (control->existing_val == value_to_apply)
return 0;
runtime_stream = get_running_stream(pin_id);
if (runtime_stream != NULL) {
ret = send_ipc();
if (ret)
return ret;
}
control->existing_val = value_to_apply;
return 1;
Adheres to ALSA's expectation and avoids sending IPCs if there is no
change to be made.
Two helpers which are part of the patch, catpt_stream_hw_id() and
catpt_stream_volume_regs(), help differentiate between individual
streams and the general MIXER stream. Translates to one pair of
get()/put() instead of two pairs as done currently.
PIN_ID_INVALID is returned if given stream is not currently running -
the constant is part of the firmware's API but remained unused by the
driver.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Streams may have individual controls assigned to them e.g.: volume
control in case of offload streams.
If such a stream is running and simultaneously its controls are being
manipulated, both processes are touching the exact same descriptors -
access to these must be synchronized. Replace spinlock with mutex as
IPCs are non-atomic operations and add proper locking for all
->stream_list users.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260309091605.896307-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In current linux.git, da7219_aad_suspend() and
da7219_aad_resume() are defined and declared unconditionally. However,
their only in-tree callers are the component PM callbacks in da7219.c,
which are already guarded by #ifdef CONFIG_PM.
This inconsistency leads to unnecessary code inclusion and potential
compiler warnings when CONFIG_PM is disabled. Match the helper
declarations and definitions to the callers' scope and provide no-op
!CONFIG_PM stubs in the header.
Signed-off-by: Pengpeng Hou <pengpeng.hou@isrc.iscas.ac.cn>
Link: https://patch.msgid.link/20260310082348.743716-1-pengpeng.hou@isrc.iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Rework the way that kernel log messages are rate-limited or suppressed
while running the cs_dsp KUnit tests.
Under normal conditions cs_dsp doesn't produce an unreasonable number of
log messages, and state changes are relatively infrequent. But the KUnit
tests run through a very large number of test cases, especially error
cases, and this produces an unusually large amount of log output from
cs_dsp.
The original fix for this in commit 10db9f6899 ("firmware: cs_dsp:
rate-limit log messages in KUnit builds") was effective but not pretty.
It involved different definitions of the log macros for KUnit and
not-KUnit builds, and exported variables for the KUnit tests to disable
log messages. I would have preferred to turn the log macros into real
functions that can contain a KUNIT_STATIC_STUB_REDIRECT(), but the
dev_xxx() macros don't have a version that take va_args, so they can't
be wrapped by a function.
This patch enables the use of a KUNIT_STATIC_STUB_REDIRECT() instead
of exported variables, and avoids the need for different definitions of
the debug macros in KUnit and not-KUnit builds.
- A new function cs_dsp_can_emit_message() returns true if the
messages can be emitted to the kernel log. In a normal not-KUnit build
this function collapses to simply returning true. In KUnit builds it
will rate-limit output, and this uses a single static rate limiter so
it limits the overall rate across all cs_dsp log messages. The KUnit
test can redirect it to change the suppression behavior.
- The cs_dsp debug message macros are changed to only call the dev_xxx()
if cs_dsp_can_emit_message() returns true. These are still macros so
there is no problem wrapping the dev_xxx(). For a normal not-KUnit
build cs_dsp_can_emit_message() always returns true so these macros
simplify down to being identical to calling dev_xxx() directly.
- The KUnit tests that cause a lot of cs_dsp messages now redirect
cs_dsp_can_emit_message() to a local function. This returns false
to suppress cs_dsp messages, unless DEBUG is defined for that test.
I have checked that for a x86_64 production (non-KUnit) build the
disassembled cs_dsp.o is identical to what was generated from the
original code. So the complier is correctly simplifying the
cs_dsp_can_emit_message() and macros down to only the call to dev_xxx().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310130343.1791951-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The pcm_id value is __le32 so convert it before passing to the dev_dbg
function to be printed. Also fixup some other uses of __le32 data and
a couple of places where %u should have been used instead of %d
Picked up by sparse prototype for variadic and printf
function checking. Fixes a large number of sparse warnings, such as:
sound/soc/sof/pcm.c:84:25: warning: incorrect type in argument 4 (different base types)
sound/soc/sof/pcm.c:84:25: expected unsigned int
sound/soc/sof/pcm.c:84:25: got restricted __le32 [usertype] pcm_id
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260310125106.178944-1-ben.dooks@codethink.co.uk
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't preserve '/' in firmware filename fields - convert it to '-' like
other punctuation characters.
The code originally normalized the entire string, including the
directory prefix. To prevent breaking the directory it had to preserve
'/' characters in the name, but this meant that the system name and ALSA
prefix must not contain those characters.
It's trivial to skip the directory name prefix and start the
normalization after it, and that means the normalization does not need
to make a special case for '/'.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-8-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use a consistent pattern of error checking in
wm_adsp_request_firmware_files().
- The integer return value of wm_adsp_request_firmware_file() reports
unrecoverable errors, for example -ENOMEM.
- A NULL struct firmware pointer is a valid result. This not an error,
not all DSPs require both files, some may not require any files.
Previously wm_adsp_request_firmware_files() was using a mix of checking
the return value and checking the struct firmware pointer to determine
whether a file was found. It wasn't checking for unrecoverable errors.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-7-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add KUnit testing of the wm_adsp code that searches for firmware files.
Also make the SND_SOC_WM_ADSP Kconfig symbol visible if KUNIT is enabled
so that wm_adsp can be manually included for KUnit testing.
The firmware filename is composed of several fields, some of which are
optional, and there is a search algorithm to fallback from specific to
generic versions of firmware for a device. This KUnit test verifies that
wm_adsp is searching for the correct sequence of filenames.
The are two ways of testing this, and both are used in this KUnit test.
1. Trap the calls to firmware_request_nowarn() and test that the sequence
of filenames request is correct.
This is the most thorough test because it proves that exactly the
expected filenames are requested, in the correct order.
But it doesn't fully cover regression testing. If a change to the search
algorithm changes the expected sequence of requested files, the test
must also be changed to expect that new sequence. If the expectation is
wrong, the tests can pass (because the search order is as expected)
while picking a different file in some cases from what it did before the
change.
2. Test which file is picked from a simulated directory of files.
This is better for regression testing because it is independent of the
search algorithm. It does not need to change if the search algorithm
changes. It is not testing exactly which files the algorithm searches
for, only which file it eventually picks from a given set of available
files.
In other words, the regression test is: does it still pick the same file
from the same directory of files?
But it is impractical for thorough testing. It doesn't prove that
exactly the correct files were searched for, unless it was to test with
every possible combination of file names and directory content that
could ever exist. Clearly this is impossible to implement, since the
number of combations of possible valid filenames in a directory and
number of files in a directory is astronomically large.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make some of the firmware file search functions redirectable for KUnit
testing.
- The call to firmware_request_nowarn() is factored out into a wrapper
function so that it can be redirected.
- wm_adsp_request_firmware_files() and wm_adsp_release_firmware_files()
are made visible and exported if KUNIT is enabled.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The transmitter and receiver implement separate timestamp counters and
bit counters. The bit counter increments at the end of each bit in a
frame whenever the transmitter or receiver is enabled. The bit counter
can be reset by software. The timestamp counter increments on the bus
interface clock whenever it is enabled. The current value of the
timestamp counter is latched whenever the bit counter increments.
Reading the bit counter register will cause the latched timestamp
value to be saved in the bit counter timestamp register. The timestamp
counter can be reset by software, this also resets the latched timestamp
value and the bit counter timestamp register.
The timestamp counter and bit counter can be used by software to track
the progress of the transmitter and receiver. It can also be used to
calculate the relative frequency of the bit clock against the bus
interface clock.
As there are three regmap handlers defined in this driver, explicitly
call the snd_soc_component_init_regmap() to init regmap handler for the
component.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260310104235.1234569-4-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The transmitter and receiver implement separate timestamp counters and
bit counters. The bit counter increments at the end of each bit in a
frame whenever the transmitter or receiver is enabled. The bit counter
can be reset by software. The timestamp counter increments on the bus
interface clock whenever it is enabled. The current value of the
timestamp counter is latched whenever the bit counter increments.
Reading the bit counter register will cause the latched timestamp
value to be saved in the bit counter timestamp register. The timestamp
counter can be reset by software, this also resets the latched timestamp
value and the bit counter timestamp register.
The timestamp counter and bit counter can be used by software to track
the progress of the transmitter and receiver. It can also be used to
calculate the relative frequency of the bit clock against the bus
interface clock.
These bitcount and timestamp registers are volatile, and supported when
the module has timestamp features.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260310104235.1234569-3-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are some registers which are volatile, at pm runtime suspend state,
the regmap cache only is enabled, regmap will return -EBUSY when trying to
access these registers.
static int _regmap_read(struct regmap *map, unsigned int reg,
unsigned int *val)
{
int ret;
void *context = _regmap_map_get_context(map);
if (!map->cache_bypass) {
ret = regcache_read(map, reg, val);
if (ret == 0)
return 0;
}
if (map->cache_only)
return -EBUSY;
if (!regmap_readable(map, reg))
return -EIO;
When exporting these registers by amixer interface to user space, there
will be -EBUSY errors in mixer-test when the cpu dai is in idle. In order
to avoid such error, needs to define FSL own functions to take a pm
runtime reference before calling snd_soc_get_xr_sx(),
snd_soc_get_enum_double(), snd_soc_get_volsw(), and so on.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260310104235.1234569-2-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Sen Wang <sen@ti.com>:
Just two minor patches that aim to tidy up the code a little bit,
as well as fix the aux_div selection in davinci_mcasp_calc_clk_div()
for mid-range dividers (33 <= div <= 4096).
Sen Wang (2):
ASoC: ti: davinci-mcasp: extract mcasp_is_auxclk_enabled() helper
ASoC: ti: davinci-mcasp: improve aux_div selection for mid-range dividers
sound/soc/ti/davinci-mcasp.c | 45 +++++++++++++++++++++++++-----------
1 file changed, 31 insertions(+), 14 deletions(-)
--
2.43.0
Merge series from Maciej Strozek <mstrozek@opensource.cirrus.com>:
Introducing CS42L43B, a variant of the CS42L43 codec with changes to
PDM (DMIC) inputs, RAM/ROM memory and extra channels to two SoundWire
ports and ISRCs, and can be supported by the existing CS42L43 driver
with some modifications.
If 'port_id' is negative, the shift counts in wcd9335_slimbus_irq() also
become negative, resulting in undefined behavior due to shift out of
bounds.
That appears to be not possible, but with UBSAN enabled, Clang's range
analysis isn't always able to determine that and generates undefined
behavior.
As a result the code generation isn't optimal, and undefined behavior
should be avoided regardless. Improve code generation and remove the
undefined behavior by converting the signed variables to unsigned.
Fixes the following warning:
sound/soc/codecs/wcd9335.o: warning: objtool: wcd9335_slimbus_irq() falls through to next function __cfi_wcd9335_set_channel_map()
This is very similar to a previous fix to wcd934x with commit
060aed9c00 ("objtool, ASoC: codecs: wcd934x: Remove potential
undefined behavior in wcd934x_slim_irq_handler()").
Cc: Srinivas Kandagatla <srini@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://patch.msgid.link/08dbb63519ef31a5457e07673b7b256fecb5989b.1773071992.git.jpoimboe@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In addition to the digital volume adjustment, infineon peb2466 codec
has an analog adjustment which can be set to either 0dB or +/-6dB.
At the time being it is defined as a switch and appears in 'alsamixer'
like a 'mute'.
This adjustment isn't a mute, change it to a 'volume' with an
associated dB range.
With this change, this adjustment now appears in 'alsamixer' as a
standard volume slider which can have two positions.
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Acked-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/418fe76d1c9efc8182ab57b6b426a8c723e025fe.1773056714.git.chleroy@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Introducing CS42L43B codec, a variant of CS42L43 which can be driven by
the same driver.
Changes in CS42L43 driver specific for CS42L43B:
- Decimator 1 and 2 are dedicated to ADC, can't be selected for PDM
- Decimators 3 and 4 are connected to PDM1
- Added Decimator 5 and 6 for PDM2
- Supports SoundWire Clock Gearing
- Updated ROM requiring no patching
- Reduced RAM space
- Each ISRC has 4 decimators now
Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260306152829.3130530-5-mstrozek@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Introducing CS42L43B codec, a variant of CS42L43 which can be driven by
the same driver.
Changes in CS42L43 driver specific for CS42L43B:
- Decimator 1 and 2 are dedicated to ADC, can't be selected for PDM
- Decimators 3 and 4 are connected to PDM1
- Added Decimator 5 and 6 for PDM2
- Supports SoundWire Clock Gearing
- Updated ROM requiring no patching
- Reduced RAM space
- Each ISRC has 4 decimators now
Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Acked-by: Lee Jones <lee@kernel.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260306152829.3130530-4-mstrozek@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When the ideal total divider (sysclk/bclk) is between 33 and 4096 and
AUXCLK is enabled, the driver computes aux_div as ceil(div/32) and then
recomputes bclk_div from the truncated sysclk.
This two-step integer division loses precision due to truncation and can
sometimes produce PPM errors large enough for ALSA's hw_rule_format to
reject otherwise valid sample formats.
For example, on AM62D-EVM (auxclk-fs-ratio=2177, tdm-slots=2, fck=96 MHz),
playing S16_LE at 44100 Hz gives BCLK = 1,411,200 Hz and an ideal total
divider of 68. The old code picks aux_div = ceil(68/32) = 3,
then bclk_div = (96005700/3) / 1411200 = 22, for a total of 3 x 22 =
66 -- two steps from ideal. The resulting error exceeds the PPM threshold
and causes S16_LE, S24_LE to be rejected.
Therefore when the total divider fits in the AHCLKXDIV register alone
(<=4096), use it directly as aux_div with bclk_div=1, and compare floor
and ceil to pick the closer match, to ensure the best ideal total dividers.
Dividers at or below 32 never enter this path, and dividers above 4096
still fall through to the existing DIV_ROUND_UP path, so previously
working configurations remains unaffected.
Signed-off-by: Sen Wang <sen@ti.com>
Link: https://patch.msgid.link/20260305195825.9998-3-sen@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull EFI fix from Ard Biesheuvel:
"Fix for the x86 EFI workaround keeping boot services code and data
regions reserved until after SetVirtualAddressMap() completes:
deferred struct page initialization may result in some of this memory
being lost permanently"
* tag 'efi-fixes-for-v7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
x86/efi: defer freeing of boot services memory
Pull i2c fix from Wolfram Sang:
"A revert for the i801 driver restoring old locking behaviour"
* tag 'i2c-for-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: i801: Revert "i2c: i801: replace acpi_lock with I2C bus lock"
Pull x86 fixes from Ingo Molnar:
- Fix SEV guest boot failures in certain circumstances, due to
very early code relying on a BSS-zeroed variable that isn't
actually zeroed yet an may contain non-zero bootup values
Move the variable into the .data section go gain even earlier
zeroing
- Expose & allow the IBPB-on-Entry feature on SNP guests, which
was not properly exposed to guests due to initial implementational
caution
- Fix O= build failure when CONFIG_EFI_SBAT_FILE is using relative
file paths
- Fix the various SNC (Sub-NUMA Clustering) topology enumeration
bugs/artifacts (sched-domain build errors mostly).
SNC enumeration data got more complicated with Granite Rapids X
(GNR) and Clearwater Forest X (CWF), which exposed these bugs
and made their effects more serious
- Also use the now sane(r) SNC code to fix resctrl SNC detection bugs
- Work around a historic libgcc unwinder bug in the vdso32 sigreturn
code (again), which regressed during an overly aggressive recent
cleanup of DWARF annotations
* tag 'x86-urgent-2026-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/entry/vdso32: Work around libgcc unwinder bug
x86/resctrl: Fix SNC detection
x86/topo: Fix SNC topology mess
x86/topo: Replace x86_has_numa_in_package
x86/topo: Add topology_num_nodes_per_package()
x86/numa: Store extra copy of numa_nodes_parsed
x86/boot: Handle relative CONFIG_EFI_SBAT_FILE file paths
x86/sev: Allow IBPB-on-Entry feature for SNP guests
x86/boot/sev: Move SEV decompressor variables into the .data section
Pull timer fix from Ingo Molnar:
"Make clock_adjtime() syscall timex validation slightly more permissive
for auxiliary clocks, to not reject syscalls based on the status field
that do not try to modify the status field.
This makes the ABI behavior in clock_adjtime() consistent with
CLOCK_REALTIME"
* tag 'timers-urgent-2026-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
timekeeping: Fix timex status validation for auxiliary clocks
Pull scheduler fix from Ingo Molnar:
"Fix a DL scheduler bug that may corrupt internal metrics during PI and
setscheduler() syscalls, resulting in kernel warnings and misbehavior.
Found during stress-testing"
* tag 'sched-urgent-2026-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting
Pull SCSI fixes from James Bottomley:
"Two core changes and the rest in drivers, one core change to quirk the
behaviour of the Iomega Zip drive and one to fix a hang caused by tag
reallocation problems, which has mostly been seen by the iscsi client.
Note the latter fixes the problem but still has a slight sysfs memory
leak, so will be amended in the next pull request (once we've run the
fix for the fix through our testing)"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: target: Fix recursive locking in __configfs_open_file()
scsi: devinfo: Add BLIST_SKIP_IO_HINTS for Iomega ZIP
scsi: mpi3mr: Clear reset history on ready and recheck state after timeout
scsi: core: Fix refcount leak for tagset_refcnt
Pull fbdev fix from Helge Deller:
"Silence build error in au1100fb driver found by kernel test robot"
* tag 'fbdev-for-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev:
fbdev: au1100fb: Fix build on MIPS64
Pull parisc fixes from Helge Deller:
"While testing Sasha Levin's 'kallsyms: embed source file:line info in
kernel stack traces' patch series, which increases the typical kernel
image size, I found some issues with the parisc initial kernel mapping
which may prevent the kernel to boot.
The three small patches here fix this"
* tag 'parisc-for-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Fix initial page table creation for boot
parisc: Check kernel mapping earlier at bootup
parisc: Increase initial mapping to 64 MB with KALLSYMS
Mark Brown
Krzysztof Kozlowski
Richard Fitzgerald
Cezary Rojewski
Pengpeng Hou
Ben Dooks
Shengjiu Wang
Josh Poimboeuf
Christophe Leroy (CS GROUP)
Maciej Strozek
Sen Wang
Linus Torvalds
Eric Dumazet