ASoC: simple-card-utils.c: enable multi Component support
If CPU/Codec driver keeps its DAI node, we can directly identify actual
DAI by using snd_soc_get_dai_via_args().
This means we can use multi Component.
This patch enables multi Component support on Audio Graph Card/Card2.
To use multi Component support, we need to check dai_args whether
Card could get DAI from args (CPU/Codec needs set dai_args on DAI driver).
If it could, we need to allocate dai_args for dlc.
This patch adds snd_soc_copy_dai_args() for it.
This is helper function for multi Component support.
Current snd_soc_is_matching_component() checks "of_node" or "dai_args".
Thus coping "of_node" only is not enough to use CPU as Platform.
This patch adds snd_soc_dlc_use_cpu_as_platform() and help it.
This is helper function for multi Component support.
Current ASoC Card is using dlc (snd_soc_dai_link_component) to find
target DAI / Component to be used.
Current dlc has below 3 items to identify DAI / Component
(a) name for Component
(b) of_node for Component
(c) dai_name for DAI
(a) or (b) is used to identify target Component, and (c) is used
to identify DAI.
One of the biggest issue on it today is dlc needs "name matching"
for "dai_name" (c).
It was not a big deal when we were using platform_device, because we
could specify nessesary "dai_name" via its platform_data.
But we need to find DAI name pointer from whole registered datas and/or
each related driver somehow in case of DT, because we can't specify it.
Therefore, Card driver parses DT and assumes the DAI, and find its name
pointer. How to assume is based on each Component and/or Card.
Next biggest issue is Component node (a)/(b).
Basically, Component is registered when CPU/Codec driver was
probed() (X). Here, 1 Component is possible to have some DAIs.
int xxx_probe(struct platform_device *pdev)
{
...
(X) ret = devm_snd_soc_register_component(pdev->dev,
&component_driver,
&dai_driver, dai_driver_num);
...
}
The image of each data will be like below.
One note here is "driver" is included for later explanation.
But below image which we can register today doesn't allow it,
because the same Component will be connected to both Card0/1,
but it will be rejected by (Z).
static int snd_soc_is_matching_component(...)
{
...
(B) if (dlc->of_node && component_of_node != dlc->of_node)
...
}
dlc checkes "of_node" to identify target component (B),
but this "of_node" came from component->dev (A) which is added
by snd_soc_register_component() (X) on probe().
This means we can have different "component->card", but have same
"component->dev" in this case.
Even though we calls snd_soc_register_component() (= X) multiple times,
all Components have same driver's dev, thus it is impossible to
identified the Component.
And if it was impossible to identify Component, it is impossible to
identify DAI on current implementation.
So, how to handle above complex HW image today is 2 patterns.
One is handles it as "1 big sound card".
The SW image is like below.
It handles as "2 Cards", but CPU part needs to be probed as 2 drivers.
It is also not intuitive.
To solve this issue, we need to have multi Component support.
In current implementation, we need to identify Component first
to identify DAI, and it is using name matching to identify DAI.
But how about to be enable to directly identify DAI by unique way
instead of name matching ? In such case, we can directly identify DAI,
then it can identify Component from DAI.
For example Simple-Card / Audio-Graph-Card case, it is specifying DAI
via its node.
Simple-Card
sound-dai = <&cpu-sound>;
Audio-Graph-Card
dais = <&cpu-sound>;
If each CPU/Codec driver keeps this property when probing,
we can identify DAI directly from Card.
Being able to identify DAI directly means being able to identify its
Component as well even though Component has same dev (= B).
This patch adds new "dai_node" for it.
To keeping compatibility, it checks "dai_node" first if it has,
otherwise, use existing method (name matching).
Current ASoC is specifying and checking DAI name.
But where it came from and how to check was ambiguous.
This patch adds snd_soc_dai_name_get() / snd_soc_dlc_dai_is_match()
and makes it clear.
Zhu Ning [Fri, 14 Jul 2023 03:24:49 +0000 (11:24 +0800)]
ASoC: codecs: ES8326: Add es8326_mute function
The internal analog power and hp Vref of es8326 should always be on to
reduce pop noise. The HP_VOL and HP_CAL are moved to es8326_mute function
so they are turned on at last and turned off at first.
Also, the calibration should be done manually once during start-up
to reduce DC offset on headphone.
Mark Brown [Thu, 13 Jul 2023 20:23:23 +0000 (21:23 +0100)]
ASoC: ad: Update Analog Devices drivers to maple tree
Merge series from Mark Brown <broonie@kernel.org>:
The maple tree register cache has now got to feature parity with the
rbtree cache, there are some different tradeoffs made and it should be a
better choice for most modern systems. Convert the Analog Devices
drivers to use the more modern data structure.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Mark Brown (10):
ASoC: ad1836: Update to use maple tree register cache
ASoC: ad1980: Update to use maple tree register cache
ASoC: adau1372: Update to use maple tree register cache
ASoC: adau1373: Update to use maple tree register cache
ASoC: adau1701: Update to use maple tree register cache
ASoC: adau1761: Update to use maple tree register cache
ASoC: adau1781: Update to use maple tree register cache
ASoC: adau1977: Update to use maple tree register cache
ASoC: adau7118: Update to use maple tree register cache
ASoC: adav80x: Update to use maple tree register cache
Mark Brown [Wed, 12 Jul 2023 23:13:59 +0000 (00:13 +0100)]
ASoC: adav80x: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adav80x driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:58 +0000 (00:13 +0100)]
ASoC: adau7118: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adau7118 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:57 +0000 (00:13 +0100)]
ASoC: adau1977: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adau1977 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:56 +0000 (00:13 +0100)]
ASoC: adau1781: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adau1781 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:55 +0000 (00:13 +0100)]
ASoC: adau1761: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adau1761 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:54 +0000 (00:13 +0100)]
ASoC: adau1701: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adau1701 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:53 +0000 (00:13 +0100)]
ASoC: adau1373: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adau1373 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:52 +0000 (00:13 +0100)]
ASoC: adau1372: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the adau1382 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:51 +0000 (00:13 +0100)]
ASoC: ad1980: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the ad1980 driver to use the more modern data structure.
Mark Brown [Wed, 12 Jul 2023 23:13:50 +0000 (00:13 +0100)]
ASoC: ad1836: Update to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache. In
v6.5 it has also acquired the ability to generate multi-register writes in
sync operations, bringing performance up to parity with the rbtree cache
there.
Update the ad1836 driver to use the more modern data structure.
This configuration supports JSL boards which implement ALC5650 dual
I2S interface codec. Two DAI links are added: AIF1 (on codec side) for
headphone and AIF2 for speakers.
Mark Brown [Wed, 12 Jul 2023 11:38:07 +0000 (12:38 +0100)]
ASoC: Another set of platform remove conversions
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
Two more drivers were added during the current merge window that
are users of the original .remove callback that I plan to get rid of.
Convert them to .remove_new.
Mark Brown [Wed, 12 Jul 2023 11:37:59 +0000 (12:37 +0100)]
ASoC: rt5677: Refactor GPIO and use
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
The code can be simplified with refactored GPIO parts and with use of
device_get_match_data(). Besides that couple of additional changes,
one for maintenance and one for making IRQ domain agnostic (not being
pinned to OF).
Mark Brown [Wed, 12 Jul 2023 11:37:30 +0000 (12:37 +0100)]
AMD Vangogh support for NAU8821/MAX98388
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:
This patch series extends the Vangogh machine driver to support a variant
based on the Nuvoton NAU88L21 Codec and the Analog Devices MAX98388
Speaker Amplifier.
Mark Brown [Wed, 12 Jul 2023 11:37:23 +0000 (12:37 +0100)]
ASoC: Intel: avs: New boards and fixes to existing
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
Series adds support for two boards: es8336 and rt5663. The former is
utilized by some KBL-based tablets whereas the latter unlocks
Chromebooks with rt5663 i2c codecs.
As existing implementation of es8336 (es8316.c) codec driver is not
prepared to cope with KBL-based platforms, couple of small,
clock-related changes precede anything avs-driver related.
The tail of patchset cleans up existing implementation of rt5682.
Mark Brown [Wed, 12 Jul 2023 11:37:15 +0000 (12:37 +0100)]
ASoC: remove copy of intlog10()
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
The first three patches moves intlog10() to be available in entire
kernel. The last one removes copy of it in one driver. Besides already
good Lines of Code (LoC) statistics the upcoming users, if any, can
utilize the exported functions.
The series can be routed via ASoC tree (as Mauro suggested).
Note, int_log.h is separated from math.h due to licensing.
I dunno if we can mix two in a single header file. In any
case we may do it later on.
Mark Brown [Wed, 12 Jul 2023 11:37:07 +0000 (12:37 +0100)]
Add support for IIO devices in ASoC
Merge series from Herve Codina <herve.codina@bootlin.com>:
Several weeks ago, I sent a series [1] for adding a potentiometer as an
auxiliary device in ASoC. The feedback was that the potentiometer should
be directly handled in IIO (as other potentiometers) and something more
generic should be present in ASoC in order to have a binding to import
some IIO devices into sound cards.
The series related to the IIO potentiometer device is already applied.
This series introduces audio-iio-aux. Its goal is to offer the binding
between IIO and ASoC.
It exposes attached IIO devices as ASoC auxiliary devices and allows to
control them through mixer controls.
On my system, the IIO device is a potentiometer and it is present in an
amplifier design present in the audio path.
Maxim Kochetkov [Thu, 22 Jun 2023 20:00:29 +0000 (23:00 +0300)]
ASoC: dwc: Add TDM mode support
Depending on hardware implementaion of DWC I2S controller may support
TDM mode if enabled in SoC at design time.
Unfortunately there is no way to detect TDM capability for DWC by
reading registers. Anyway, if such capability enabled, TDM mode
can be enabled and configured by dai-tdm-slot-* DT options.
Chancel Liu [Sun, 25 Jun 2023 06:54:12 +0000 (14:54 +0800)]
ASoC: imx-pcm-rpmsg: Set PCM hardware parameters separately
Different PCM devices may have different PCM hardware parameters. It
requires PCM hardware parameters set separately if there is more than
one rpmsg sound card.
Required CPU/Codec/Platform dlc (snd_soc_dai_link_component) are similar
but not same, and very complex. Current implementation is very confusable
and it will be more complex if multi Component was supported.
This patch cleanup it.
ASoC: soc-core.c: initialize dlc on snd_soc_get_dai_id()
Current snd_soc_get_dai_id() is initializing dlc *manually*,
but it will might be a problem if dlc had new extra parameter.
This patch uses default initialization, otherwise, non initialized
part will be strange value.
This is prepare for multi Component support.
Herve Codina [Fri, 23 Jun 2023 08:58:29 +0000 (10:58 +0200)]
ASoC: codecs: Add support for the generic IIO auxiliary devices
Industrial I/O devices can be present in the audio path.
These devices needs to be used as audio components in order to be
fully integrated in the audio path.
This support allows to consider these Industrial I/O devices as
auxiliary audio devices and allows one to control them using mixer
controls.
Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/20230623085830.749991-13-herve.codina@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
Herve Codina [Fri, 23 Jun 2023 08:58:28 +0000 (10:58 +0200)]
ASoC: soc-dapm.h: Convert macros to return a compound literal
The SND_SOC_DAPM_* helpers family are used to build widgets array in a
static way.
Convert them to return a compound literal in order to use them in both
static and dynamic way.
With this conversion, the different SND_SOC_DAPM_* parameters can be
computed by the code and the widget can be built based on this parameter
computation.
static int create_widget(char *input_name)
{
struct snd_soc_dapm_widget widget;
char name*;
...
name = input_name;
if (!name)
name = "default";
widget = SND_SOC_DAPM_INPUT(name);
...
}
Signed-off-by: Herve Codina <herve.codina@bootlin.com> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/20230623085830.749991-12-herve.codina@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
Herve Codina [Fri, 23 Jun 2023 08:58:27 +0000 (10:58 +0200)]
iio: inkern: Add a helper to query an available minimum raw value
A helper, iio_read_max_channel_raw() exists to read the available
maximum raw value of a channel but nothing similar exists to read the
available minimum raw value.
This new helper, iio_read_min_channel_raw(), fills the hole and can be
used for reading the available minimum raw value of a channel.
It is fully based on the existing iio_read_max_channel_raw().
Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/20230623085830.749991-11-herve.codina@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
Herve Codina [Fri, 23 Jun 2023 08:58:20 +0000 (10:58 +0200)]
iio: inkern: Check error explicitly in iio_channel_read_max()
The current implementation returns the error code as part of the
default switch case.
This can lead to returning an incorrect positive value in case of
iio_avail_type enum entries evolution.
In order to avoid this case, be more strict in error checking.
Signed-off-by: Herve Codina <herve.codina@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/20230623085830.749991-4-herve.codina@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
The additional-devs subnode allows to declared some virtual devices
as sound card children.
These virtual devices can then be used by the sound card and so be
present in the audio path.
The first virtual device supported is the audio IIO auxiliary device
in order to support an IIO device as an audio auxiliary device.
Herve Codina [Fri, 23 Jun 2023 08:58:18 +0000 (10:58 +0200)]
ASoC: dt-bindings: Add audio-iio-aux
Industrial I/O devices can be present in the audio path.
These devices needs to be viewed as audio components in order to be
fully integrated in the audio path.
audio-iio-aux allows to consider these Industrial I/O devices as
auxliary audio devices.
ASoC: amd: vangogh: Use dmi_first_match() for DMI quirk handling
In preparation for supporting ACPI probing, move DMI quirk handling
logic at the probe's top, to be able to return as quickly as possible in
case there is no DMI matching.
Additionally, simplify the code by replacing dmi_check_system() and
related callback with dmi_first_match(). While at it, also drop a few
unnecessary empty lines.
Syed Saba Kareem [Mon, 26 Jun 2023 13:55:11 +0000 (19:25 +0530)]
ASoC: amd: acp: export config_acp_dma() and config_pte_for_stream() symbols
Export config_acp_dma() and config_pte_for_stream() functions.
These functions will be used to restore stream configuration during
system level resume.
Syed Saba Kareem [Mon, 26 Jun 2023 13:55:10 +0000 (19:25 +0530)]
ASoC: amd: acp: store xfer_resolution of the stream
Store the 'xfer_resolution' of the stream in private data structure,
it will be used to reprogram the xfer_resolution for the active stream
during system level resume.
Syed Saba Kareem [Mon, 26 Jun 2023 13:55:07 +0000 (19:25 +0530)]
ASoC: amd: acp: remove the redundant acp enable/disable interrupts functions
Instead of having individual acp enable/disable interrupts functions for
each platform, implement common place holder to handle the same for all
AMD platforms.
Syed Saba Kareem [Mon, 26 Jun 2023 13:55:05 +0000 (19:25 +0530)]
ASoC: amd: acp: refactor the acp init and de-init sequence
Remove the individual acp init and de-init functions from different
variants of acp pci driver(for renoir/rembrandt platforms) and use a
common file to define callbacks and refactor the callbacks to support
existing platforms.
Trevor Wu [Thu, 29 Jun 2023 07:43:47 +0000 (15:43 +0800)]
ASoC: mediatek: mt8188: add memory-region support
In certain projects, it is necessary to utilize the reserved memory
region for audio dma. The patch takes into account the dts property
'memory-region', allowing for the specification of memory for afe memif
through device tree.
Cezary Rojewski [Thu, 29 Jun 2023 11:24:49 +0000 (13:24 +0200)]
ASoC: Intel: avs: rt5682: Tidy up hw_params()
To improve readability, reword several local variables to better match
their counterparts in declarations of soc-dai.h. For similar reasons,
wording for few comments is streamlined while redundant comments are
removed.
Cezary Rojewski [Thu, 29 Jun 2023 11:24:48 +0000 (13:24 +0200)]
ASoC: Intel: avs: rt5682: Add missing components
Align with what's done for all other boards and allocate jacks pins
dynamically and explicitly specify ->dai_fmt for the DAI link.
The latter clears any ambiguity - given the current implementation
of the codec driver, specifying format is optional but should the
implementation change, the sound card behaviour may be undesired.
Cezary Rojewski [Thu, 29 Jun 2023 11:24:43 +0000 (13:24 +0200)]
ASoC: codecs: es8316: Add support for S24_3LE format
Codec supports words that are 16/18/20/24/32 bits long. In case of 24,
it should be treated as 24/24 not 24/32 i.e.: 24 valid bit-depth in 24
bit-depth container.
ASoC: starfive: jh7110_tdm: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
ASoC: amd: ps-sdw-dma: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Andy Shevchenko [Fri, 30 Jun 2023 17:21:52 +0000 (20:21 +0300)]
ASoC: rt5677: Refactor GPIO support code
After compiler complains:
sound/soc/codecs/rt5677.c:4748:30: warning: dubious: x | !y
I looked into the code and realized that we can refactor it
for better reading and fixing above issue at the same time.
Hence this change. It does not imply any functional changes.
We just sorted the entries and fields last release, so just out of a
perverse sense of curiosity, I decided to see if we can keep things
ordered for even just one release.
The answer is "No. No we cannot".
I suggest that all kernel developers will need weekly training sessions,
involving a lot of Big Bird and Sesame Street. And at the yearly
maintainer summit, we will all sing the alphabet song together.
I doubt I will keep doing this. At some point "perverse sense of
curiosity" turns into just a cold dark place filled with sadness and
despair.
Repeats: 80e62bc8487b ("MAINTAINERS: re-sort all entries and fields") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'dma-mapping-6.5-2023-07-09' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping fixes from Christoph Hellwig:
- swiotlb area sizing fixes (Petr Tesarik)
* tag 'dma-mapping-6.5-2023-07-09' of git://git.infradead.org/users/hch/dma-mapping:
swiotlb: reduce the number of areas to match actual memory pool size
swiotlb: always set the number of areas before allocating the pool
Merge tag 'x86-core-2023-07-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Thomas Gleixner:
"A single fix for the mechanism to park CPUs with an INIT IPI.
On shutdown or kexec, the kernel tries to park the non-boot CPUs with
an INIT IPI. But the same code path is also used by the crash utility.
If the CPU which panics is not the boot CPU then it sends an INIT IPI
to the boot CPU which resets the machine.
Prevent this by validating that the CPU which runs the stop mechanism
is the boot CPU. If not, leave the other CPUs in HLT"
* tag 'x86-core-2023-07-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/smp: Don't send INIT to boot CPU
projects / thirdparty / linux.git / log
