Vijendar Mukunda <Vijendar.Mukunda@amd.com> says:
This series adds initial AMD ACP 7.x support for ACP7.D / 7.E / 7.F
platforms.
Compared to earlier ACP generations, ACP7.x includes substantial design
changes, including an updated register set/layout. For that reason,
the ACP7.x implementation is placed under a separate sound/soc/amd/acp7x/
directory instead of extending older-generation code paths,
keeping ACP7.x-specific logic and register definitions cleanly separated
and easier to maintain.
This initial version is intentionally focused on the core PCI driver
bring-up: register definitions, probe/remove, basic helper wiring, and
system sleep + runtime PM integration. A follow-up series will add support
for additional Audio I/O blocks, including SoundWire and the ACP PDM
controller.
The primary goal of this series is to unblock power validation, since the
ACP IP currently does not have a driver available with PM ops support on
these platforms.
Link: https://patch.msgid.link/20260507181251.20594-1-Vijendar.Mukunda@amd.com
Add ACP7.x PM callbacks and hook up system sleep and runtime PM ops for
the PCI driver.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260507181251.20594-6-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ACP7.x drivers can be built by selecting necessary
kernel config option.
The patch enables build support of the same.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260507181251.20594-5-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add ACP7.x init/deinit helper routines and wire up PCI hw ops for
ACP7.D/7.E/7.F variants.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260507181251.20594-4-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> says:
This series is a preparation for
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 23ff24080dfd..aebd3a5e90af 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -477,7 +477,11 @@ struct rpmsg_device_id {
struct i2c_device_id {
char name[I2C_NAME_SIZE];
- kernel_ulong_t driver_data; /* Data private to the driver */
+ union {
+ /* Data private to the driver */
+ kernel_ulong_t driver_data;
+ const void *driver_data_ptr;
+ };
};
/* pci_epf */
and this requires that .driver_data is assigned via a named initializer
for static data. This requirement isn't a bad one because named
initializers are also much better readable than list initializers.
The union added to struct i2c_device_id enables further cleanups like:
diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
index 8a082ff034dd..b2aac7348d22 100644
--- a/drivers/iio/accel/kxcjk-1013.c
+++ b/drivers/iio/accel/kxcjk-1013.c
@@ -1429,7 +1429,7 @@ static int kxcjk1013_probe(struct i2c_client *client)
if (id) {
name = id->name;
- data->info = (const struct kx_chipset_info *)(id->driver_data);
+ data->info = id->driver_data_ptr;
} else {
name = iio_get_acpi_device_name_and_data(&client->dev, &ddata);
data->info = ddata;
@@ -1630,11 +1630,11 @@ static const struct dev_pm_ops kxcjk1013_pm_ops = {
};
static const struct i2c_device_id kxcjk1013_id[] = {
- { .name = "kxcjk1013", .driver_data = (kernel_ulong_t)&kxcjk1013_info },
- { .name = "kxcj91008", .driver_data = (kernel_ulong_t)&kxcj91008_info },
- { .name = "kxtj21009", .driver_data = (kernel_ulong_t)&kxtj21009_info },
- { .name = "kxtf9", .driver_data = (kernel_ulong_t)&kxtf9_info },
- { .name = "kx023-1025", .driver_data = (kernel_ulong_t)&kx0231025_info },
+ { .name = "kxcjk1013", .driver_data_ptr = &kxcjk1013_info },
+ { .name = "kxcj91008", .driver_data_ptr = &kxcj91008_info },
+ { .name = "kxtj21009", .driver_data_ptr = &kxtj21009_info },
+ { .name = "kxtf9", .driver_data_ptr = &kxtf9_info },
+ { .name = "kx023-1025", .driver_data_ptr = &kx0231025_info },
{ }
};
MODULE_DEVICE_TABLE(i2c, kxcjk1013_id);
that are an improvement for readability (again!) and it keeps some
properties of the pointers (here: being const) without having to pay
attention for that. (I didn't find a good example in sound/soc, so an
iio driver was used to demonstrate the gain.)
My additional motivation for this effort is CHERI[1]. This is a hardware
extension that uses 128 bit pointers but unsigned long is still 64 bit.
So with CHERI you cannot store pointers in unsigned long variables.
The first patch drops a few empty remove callbacks that I found while
working on patch #2. The second converts all hwmon drivers to use named
initializers.
Link: https://patch.msgid.link/cover.1778692164.git.u.kleine-koenig@baylibre.com
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
While touching all these arrays, unify indention and usage of commas.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/ae2ff4898eb340bd8bcafb7b75443eb4a0ce3e76.1778692164.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A remove callback that does nothing has the same semantic (apart from a
debug output) as no such callback at all as i2c_device_remove() just does:
if (driver->remove) {
dev_dbg(dev, "remove\n");
driver->remove(client);
}
Remove these useless callbacks.
While touching the driver structs, unify indention.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/3afd8230634dd68ac7c1885ee2b01da377349f89.1778692164.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If a kcontrol update comes to a control right at the same time when the
PCM containing the control is started up then there is a small window when
a race can happen:
while the widget is set up the swidget->setup_mutex is taken in topology
level and if the control update comes at this point, it will be stopped
within sof_ipc4_set_get_kcontrol_data() with the mutex and it will be
blocked until the swidget setup is done, which will clear the control's
IPC message payload.
To avoid such race, use local copy of the template IPC message instead of
the template directly. This will ensure data integrity in case of
concurrent updates during initialization.
Link: https://github.com/thesofproject/linux/issues/5734
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260520141349.9625-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
The series address developer facing issues regarding to how the DSP core
count is handled:
IPC4 code ignored the DISABLE_MULTICORE flag, fixed by the first patch.
The second patch does a validation of the core index from topology
against the number of DSP cores available on the booted device, which makes
generic development topologies usable among different DSP variants without
failure.
Link: https://patch.msgid.link/20260520135514.32720-1-peter.ujfalusi@linux.intel.com
Generic development topologies can reference core id outside of the range
of the number of DSP cores the device might have.
Product families have different number of cores, for example:
Intel TGL has 4, TGL-H has 2, ADL has 4, ADL-S has 2, etc
The development topologies are tuned for the higher end devices and in this
case they will fail on DSP with less number of cores.
Override the out of range core id from topology to primary core and inform
the user about it.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20260520135514.32720-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SOF_DBG_DISABLE_MULTICORE is handled for swidgets in topology.c but the
pipeline's core is not changed to primary core if the flag is set.
Check the flag and if it is set, force the pipeline core to primary core.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20260520135514.32720-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
This is v3 to move card->pop_time to soc-dapm.
card->pop_time is used only on TI, and Janusz posted patch which will stop
using it. It was posted at 12 Apr 2026, and [1/2] is it as-is.
[2/2] will move card->pop_time to soc-dapm. We can use it via debugfs.
I have added [RFC] on Subject.
Link: https://patch.msgid.link/87wlx9wj1h.wl-kuninori.morimoto.gx@renesas.com
Card has pop_time which have used only from TI, and it is now stop using
it. This pop_time is used for debug, and can be access from debugfs.
Let's move it from Card to soc-dapm.c local.
This patch renames it as asoc/${card}/pop_time to asoc/dapm_pop_time.
This patch moves it from Card to soc-dapm.c, tidyup soc-dapm.c
accordingly, and remove card->pop_time from cx20442.c which is no longer
needed.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87tssdwj0p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A flag is needed that tells the card driver if the codec has been
initialized successfully over the modem's line discipline. Initially,
codec->hw_write was used as the flag, but it was then dropped and the
flag function associated with card->pop_time, already managed by the
codec driver for diagnostic purposes. Since now the card->pop_time is
going to be killed, stop abusing foreign fields in favor of an own one.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87v7ctwj0w.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
They require a PPC platform to compile but that's it.
Allow the Freescale PowerPC ASoC menu in PowerPC compile-test builds
and let the MPC5200 PSC I2S and AC97 drivers depend on PPC_BESTCOMM
directly. This keeps native platform builds unchanged while extending
compile-test coverage.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260518051706.1027500-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Realtek CAE requires specific tuning parameters based on
the system vendor and SKU.
This patch adds a kcontrol to trigger the firmware loading process.
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://patch.msgid.link/20260520053243.3645180-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Richard Fitzgerald <rf@opensource.cirrus.com> says:
This series replaces the entirely custom SoundWire regmap with the generic
regmap-sdw. The reasons for doing this are:
- Avoid code duplication
- Avoid effort of keeping custom implementation up-to-date
- Prepare for supporting BRA
Link: https://patch.msgid.link/20260519135435.479949-1-rf@opensource.cirrus.com
Use the regmap_sdw implementation for SoundWire instead of
re-implementing the low-level bus transactions in cs35l56-sdw.c
The cs35l56 registers are big-endian on I2C and SPI but little-endian
over SoundWire. The firmware files are all big-endian and contain opaque
blobs in big-endian order. So these must be endian-swapped to transfer
over SoundWire. A custom regmap bus implementation is used to do this
endian-swapping.
The original implementation of this custom regmap bus was a complete bus
backend, performing the endian swapping and low-level SoundWire bus
read/write.
This commit changes the custom regmap bus to only perform the endian-swap.
It uses an underlying simple uncached regmap_sdw bus to deal with
transferring the 32-bit registers over the SoundWire bus. Although this
adds a small amount of overhead, from passing through the regmap APIs
twice, it avoids having a local duplicate implementation of what regmap_sdw
already does.
The slow-read handling for OTP registers must access 8-bit SoundWire
registers so it still uses low-level SoundWire bus reads.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260519135435.479949-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the reg_base member of regmap_config for SoundWire so that
the regmap core will apply the 0x8000 offset to addresses, instead
of doing it within our low-level regmap read/write callbacks.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260519135435.479949-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Subtract the value of cs35l56 regmap_config->reg_base from addresses
passed into the mock regmap bus.
Chip register addresses transferred over SoundWire are offset by 0x8000
to move them after the address range reserved in the SoundWire spec.
This commit prepares for changing the cs35l56-sdw driver to use
regmap_config->reg_base to add this offset. When that is done the
addresses passed into the mock regmap_bus will include this offset.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260519135435.479949-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DURATION_INV_N3 is computed from BIT_ULL(31 + prescalar) divided
by the configured duration, and then written as a 32-bit RAM value.
Durations of 32 samples or less overflow that value, so reject them
and advertise the valid range through the fade duration control.
Validate the ALSA integer control value as a long before storing it in
the driver's u32 duration field. Use a u32 temporary for duration RAM
writes because the largest valid inverse value can still exceed INT_MAX.
Fixes: 36645381b8 ("ASoC: tegra: Add per-stream Mixer Fade controls")
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260519094858.1426057-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Herve Codina <herve.codina@bootlin.com> says:
On some embedded system boards, audio amplifiers are designed using
discrete components such as op-amp, several resistors and switches to
either adjust the gain (switching resistors) or fully switch the
audio signal path (mute and/or bypass features).
Those switches are usually driven by simple GPIOs.
This kind of amplifiers are not handled in ASoC and the fallback is to
let the user-space handle those GPIOs out of the ALSA world.
In order to have those kind of amplifiers fully integrated in the audio
stack, this series introduces the audio-gpio-amp to handle them.
This new ASoC component allows to have the amplifiers seen as ASoC
auxiliarty devices and so it allows to control them through audio mixer
controls.
In order to ease the review, I choose to split modifications related
to the merge of the gpio-audio-amp part into the simple-amplfier driver
in several commits.
Link: https://patch.msgid.link/20260513081702.317117-1-herve.codina@bootlin.com
After reworking the simple-amplifier driver and adding support for
gpio-audio-amp in the driver, add myself as the author of the
gpio-audio-amp part of the driver and add a related copyright.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-17-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The possible gain values can be described using labels instead of gain
values in dB.
Those different labels are attached to a gpio values using the
gain-labels property.
Using the gain-labels description is mutually exclusive with gain-ranges
description used to describe the relationship between gpios values and
gain values.
Handle the gain-labels description and the related kcontrol.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-16-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The mapping between physical gain values and gpio values can be
expressed using ranges described in the gain-ranges property.
This gain-ranges property is an array of ranges.
Each range in the array is defined by the first point and last point in
the range. Those points are a pair of values, the gpios value and the
related gain (dB) value.
With that, a given range defines N possible items (from the first point
gpios value to the last point gpios value) in order to set a gain from
the first point gain value to the last point gain value.
Handle this description and the related kcontrol.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-15-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Several gpios can be used to control the amplifier gain.
Add basic support for those gpios.
This basic support doesn't include any mapping between the GPIOs value
and the physical gain value (dB).
The support for this kind of mapping will be added later on.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-14-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A gpio can be used to control the amplifier bypass feature.
Add support for this bypass gpio in the same way as it has been done for
the mute gpio.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-13-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The gpio-audio-amp devices can use additional power supplies:
- vddio,
- vdda1,
- vdda2
Add support for those additional power supplies.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-11-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Improve the simple-amplifier introducing preliminary support for
gpio-audio-amp.
Those amplifiers are amplifiers driven by gpios.
This support introduction doesn't handle any GPIO yet but introduces
the compatible strings and the related DAPM table.
Two gpio-audio-amp are available: A mono and a stereo version.
The mono version has only one audio channel and gpio settings impact
features such as the gain or mute of this sole channel.
The stereo version has two channels (left and right). Gpio settings
impact both channels in the same manner and at the same time. For
instance, the gain setting set the gain of both channels as well as
the mute setting mutes both channels.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-10-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The simple-amplifier set the DAPM wigets and routes table in the ASoC
component driver. This is perfectly fine when the component has well
known DAPM tables.
The simple-amplifier is going to handle several kind of components based
on the driver compatible string. The DAPM table will not be the same for
all components supported by the driver.
In order to have different DAPM table based on matching compatible
strings, move those tables from the ASoC component driver to the device
compatible string matching data.
Add those DAPM widgets and routes dynamically during the ASoC component
probe operation.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-9-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The simple-amplifier driver use 'priv' as variable name for its private
data (struct simple_amp).
With the support for gpio-audio-amp, more functions and data
structures will be added.
Those future additions will add more complexity in data manipulation and
will make the 'priv' term error prone.
In order to clearly identify the struct simple_amp private data, use
'simple_amp' as variable name when this structure is involved.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-8-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The drv_event() is used to handle power events related to the DRV item.
Later, with the support for gpio-audio-amp, this function will be
also used to handle power events related to the PGA item.
Also, more functions will be added in the driver and it is a common
usage to prefix functions based on the driver name.
Rename the drv_event() function to simple_amp_power_event() to follow
common usage and get rid of the 'drv' term.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-7-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The simple-amplifier Use CONFIG_OF flag for its of_device_id table
and of_match_ptr() when it assigns the table in the driver declaration.
This is no more needed. Drop them.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-6-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The simple-amplifier driver is a platform device driver.
Add missing include files related to this kind of driver.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-5-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DRV_NAME is defined and used only in the simple-amplifier driver
declaration.
Remove the useless defined and use directly the value in the driver
declaration itself.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/20260513081702.317117-4-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some amplifiers based on analog switches and op-amps can be present in
the audio path and can be driven by GPIOs in order to control their gain
value, their mute and/or bypass functions.
Those components needs to be viewed as audio components in order to be
fully integrated in the audio path.
gpio-audio-amp allows to consider these GPIO driven amplifiers as
auxiliary audio devices.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260513081702.317117-3-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed integers can be read from single value properties using
of_property_read_s32() but nothing exist to read signed integers
from multi-value properties.
Fix this lack adding of_property_read_s32_index().
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260513081702.317117-2-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT8196 AFE probe assigns reserved memory with
of_reserved_mem_device_init(), but never releases it.
This leaks the reserved memory assignment on driver
removal and on later probe failures.
The same probe path also uses unchecked pm_runtime_get_sync() calls.
A failure while resuming the device can leave the runtime PM usage
count in an unexpected state.
The regmap error path returns directly while the device is still
runtime active, and the remove path drops a runtime PM reference even
though successful probe has already released its temporary reference.
Register a devm cleanup action for the reserved memory assignment,
use pm_runtime_resume_and_get(), and only drop runtime PM references
on paths where they are actually held.
Fixes: 57513aabfe ("ASoC: mediatek: mt8196: add platform driver")
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260517-asoc-mt8196-probe-cleanup-v1-1-a5d26949d7fe@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- Add more functions to the remote allowed list
randconfig found more functions that are allowed for the remote code for
s390 and arm. Add them to the allowed list.
- Fix remote_test error path
If one of the simple ring buffers fails to load, the code is supposed to
rollback its initialized buffers. Instead of rolling back the buffers for
the failed load, it uses the global variable and rolls back all the
successfully loaded buffers.
-----BEGIN PGP SIGNATURE-----
iIoEABYKADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCagm9FRQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qn0xAP0WSYmbUAGYnrq1o5L4EEM61ManFBfp
ta7dmx1Q5SYw6AEAtqbiH42VJZviAmajguyuL0cs9i9exFl+j4SaneejNwg=
=CLqK
-----END PGP SIGNATURE-----
Merge tag 'trace-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Add more functions to the remote allowed list
randconfig found more functions that are allowed for the remote code
for s390 and arm. Add them to the allowed list.
- Fix remote_test error path
If one of the simple ring buffers fails to load, the code is supposed
to rollback its initialized buffers. Instead of rolling back the
buffers for the failed load, it uses the global variable and rolls
back all the successfully loaded buffers.
* tag 'trace-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing: Fix desc in error path for the trace remote test module
ring-buffer remote: Avoid unexpected symbol warnings (arm, s390)
When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST),
get_ext_report() allocates a buffer to retrieve a certificate blob from the
host, keeping track of its size in report_req->certs_len.
However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating
an invalid buffer size, as well as the expected length of such buffer.
get_ext_report() subsequently updates report_req->certs_len with the
host-controlled value, and cleans up the buffer by computing a page order
from such value. This is incorrect, as the host-provided length may not
match the page order of the original allocation, potentially resulting
in corruption in the page allocator.
Fix this by using alloc_pages_exact() instead, and reusing @npages to
compute the size passed to free_pages_exact(). For consistency, also
use @npages to compute the size when allocating the pages, even though
this last change has no functional effect.
Fixes: 3e385c0d6c ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex")
Signed-off-by: Carlos López <clopez@suse.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Michael Roth <michael.roth@amd.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
