linux-stable.git/sound, branch v5.4.280 Linux kernel stable tree ALSA: hda/realtek: Limit mic boost on VAIO PRO PX 2024-07-18T09:40:55+00:00 Edson Juliano Drosdeck edson.drosdeck@gmail.com 2024-07-05T14:10:12+00:00 2b59187cf0461eeb9076191d9abafd454b3798ba commit 6db03b1929e207d2c6e84e75a9cd78124b3d6c6d upstream. The internal mic boost on the VAIO models VJFE-CL and VJFE-IL is too high. Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine to limit the gain. Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20240705141012.5368-1-edson.drosdeck@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6db03b1929e207d2c6e84e75a9cd78124b3d6c6d upstream.

The internal mic boost on the VAIO models VJFE-CL and VJFE-IL is too high.
Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine
to limit the gain.

Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240705141012.5368-1-edson.drosdeck@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda/realtek: Enable headset mic of JP-IK LEAP W502 with ALC897 2024-07-18T09:40:52+00:00 Jian-Hong Pan jhp@endlessos.org 2024-05-20T05:50:09+00:00 88f5c27988447455a2b3af6b0751d5bab26c60d0 [ Upstream commit 45e37f9ce28d248470bab4376df2687a215d1b22 ] JP-IK LEAP W502 laptop's headset mic is not enabled until ALC897_FIXUP_HEADSET_MIC_PIN3 quirk is applied. Here is the original pin node values: 0x11 0x40000000 0x12 0xb7a60130 0x14 0x90170110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x411111f0 0x18 0x411111f0 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x03211020 0x1c 0x411111f0 0x1d 0x4026892d 0x1e 0x411111f0 0x1f 0x411111f0 Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> Link: https://lore.kernel.org/r/20240520055008.7083-2-jhp@endlessos.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 45e37f9ce28d248470bab4376df2687a215d1b22 ]

JP-IK LEAP W502 laptop's headset mic is not enabled until
ALC897_FIXUP_HEADSET_MIC_PIN3 quirk is applied.

Here is the original pin node values:

0x11 0x40000000
0x12 0xb7a60130
0x14 0x90170110
0x15 0x411111f0
0x16 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x03211020
0x1c 0x411111f0
0x1d 0x4026892d
0x1e 0x411111f0
0x1f 0x411111f0

Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
Link: https://lore.kernel.org/r/20240520055008.7083-2-jhp@endlessos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ALSA: emux: improve patch ioctl data validation 2024-07-05T07:08:28+00:00 Oswald Buddenhagen oswald.buddenhagen@gmx.de 2024-04-06T06:48:20+00:00 79d9a000f0220cdaba1682d2a23c0d0c61d620a3 [ Upstream commit 89b32ccb12ae67e630c6453d778ec30a592a212f ] In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-8-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 89b32ccb12ae67e630c6453d778ec30a592a212f ]

In load_data(), make the validation of and skipping over the main info
block match that in load_guspatch().

In load_guspatch(), add checking that the specified patch length matches
the actually supplied data, like load_data() already did.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Message-ID: <20240406064830.1029573-8-oswald.buddenhagen@gmx.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: fsl-asoc-card: set priv->pdev before using it 2024-07-05T07:08:26+00:00 Elinor Montmasson elinor.montmasson@savoirfairelinux.com 2024-06-20T13:25:03+00:00 8896e18b7c366f8faf9344abfd0971435f1c723a [ Upstream commit 90f3feb24172185f1832636264943e8b5e289245 ] priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations. Fixes: 708b4351f08c ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support") Signed-off-by: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com> Link: https://patch.msgid.link/20240620132511.4291-2-elinor.montmasson@savoirfairelinux.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 90f3feb24172185f1832636264943e8b5e289245 ]

priv->pdev pointer was set after being used in
fsl_asoc_card_audmux_init().
Move this assignment at the start of the probe function, so
sub-functions can correctly use pdev through priv.

fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the
dev struct, used with dev_err macros.
As priv is zero-initialised, there would be a NULL pointer dereference.
Note that if priv->dev is dereferenced before assignment but never used,
for example if there is no error to be printed, the driver won't crash
probably due to compiler optimisations.

Fixes: 708b4351f08c ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support")
Signed-off-by: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
Link: https://patch.msgid.link/20240620132511.4291-2-elinor.montmasson@savoirfairelinux.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: ti: davinci-mcasp: Fix race condition during probe 2024-07-05T07:08:13+00:00 Joao Paulo Goncalves joao.goncalves@toradex.com 2024-04-17T18:41:38+00:00 71a0cb1ba6cc8d876b924744f88b35fb97edbfdd [ Upstream commit d18ca8635db2f88c17acbdf6412f26d4f6aff414 ] When using davinci-mcasp as CPU DAI with simple-card, there are some conditions that cause simple-card to finish registering a sound card before davinci-mcasp finishes registering all sound components. This creates a non-working sound card from userspace with no problem indication apart from not being able to play/record audio on a PCM stream. The issue arises during simultaneous probe execution of both drivers. Specifically, the simple-card driver, awaiting a CPU DAI, proceeds as soon as davinci-mcasp registers its DAI. However, this process can lead to the client mutex lock (client_mutex in soc-core.c) being held or davinci-mcasp being preempted before PCM DMA registration on davinci-mcasp finishes. This situation occurs when the probes of both drivers run concurrently. Below is the code path for this condition. To solve the issue, defer davinci-mcasp CPU DAI registration to the last step in the audio part of it. This way, simple-card CPU DAI parsing will be deferred until all audio components are registered. Fail Code Path: simple-card.c: probe starts simple-card.c: simple_dai_link_of: simple_parse_node(..,cpu,..) returns EPROBE_DEFER, no CPU DAI yet davinci-mcasp.c: probe starts davinci-mcasp.c: devm_snd_soc_register_component() register CPU DAI simple-card.c: probes again, finish CPU DAI parsing and call devm_snd_soc_register_card() simple-card.c: finish probe davinci-mcasp.c: *dma_pcm_platform_register() register PCM DMA davinci-mcasp.c: probe finish Cc: stable@vger.kernel.org Fixes: 9fbd58cf4ab0 ("ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller") Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Reviewed-by: Jai Luthra <j-luthra@ti.com> Link: https://lore.kernel.org/r/20240417184138.1104774-1-jpaulo.silvagoncalves@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d18ca8635db2f88c17acbdf6412f26d4f6aff414 ]

When using davinci-mcasp as CPU DAI with simple-card, there are some
conditions that cause simple-card to finish registering a sound card before
davinci-mcasp finishes registering all sound components. This creates a
non-working sound card from userspace with no problem indication apart
from not being able to play/record audio on a PCM stream. The issue
arises during simultaneous probe execution of both drivers. Specifically,
the simple-card driver, awaiting a CPU DAI, proceeds as soon as
davinci-mcasp registers its DAI. However, this process can lead to the
client mutex lock (client_mutex in soc-core.c) being held or davinci-mcasp
being preempted before PCM DMA registration on davinci-mcasp finishes.
This situation occurs when the probes of both drivers run concurrently.
Below is the code path for this condition. To solve the issue, defer
davinci-mcasp CPU DAI registration to the last step in the audio part of
it. This way, simple-card CPU DAI parsing will be deferred until all
audio components are registered.

Fail Code Path:

simple-card.c: probe starts
simple-card.c: simple_dai_link_of: simple_parse_node(..,cpu,..) returns EPROBE_DEFER, no CPU DAI yet
davinci-mcasp.c: probe starts
davinci-mcasp.c: devm_snd_soc_register_component() register CPU DAI
simple-card.c: probes again, finish CPU DAI parsing and call devm_snd_soc_register_card()
simple-card.c: finish probe
davinci-mcasp.c: *dma_pcm_platform_register() register PCM  DMA
davinci-mcasp.c: probe finish

Cc: stable@vger.kernel.org
Fixes: 9fbd58cf4ab0 ("ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller")
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Reviewed-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20240417184138.1104774-1-jpaulo.silvagoncalves@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: ti: davinci-mcasp: Handle missing required DT properties 2024-07-05T07:08:13+00:00 Peter Ujfalusi peter.ujfalusi@ti.com 2020-11-06T07:25:51+00:00 808d885740b5c37216c2ba74a624a7fab76e8a8f [ Upstream commit 1b4fb70e5b28a477478417a7958e0228460ffe68 ] McASP needs three required properties to be usable for audio: op-mode, tdm-slots and the serial-dir array. Instead of probing the driver even without the needed information we should make sure that all the parameters are provided for operation. The fact that McASP can act as a GPIO controller for it's pins complicates this a bit, but as a general rule we can: - we fail the probe if McASP is not configured to be used as gpiochip - we will not register the DAI (and PCM) if gpiochip is defined Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201106072551.689-5-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 1b4fb70e5b28a477478417a7958e0228460ffe68 ]

McASP needs three required properties to be usable for audio:
op-mode, tdm-slots and the serial-dir array.

Instead of probing the driver even without the needed information we should
make sure that all the parameters are provided for operation.

The fact that McASP can act as a GPIO controller for it's pins complicates
this a bit, but as a general rule we can:
- we fail the probe if McASP is not configured to be used as gpiochip
- we will not register the DAI (and PCM) if gpiochip is defined

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201106072551.689-5-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe")
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: ti: davinci-mcasp: Simplify the configuration parameter handling 2024-07-05T07:08:13+00:00 Peter Ujfalusi peter.ujfalusi@ti.com 2020-11-06T07:25:50+00:00 84d923099eaf3e61835f4e65d251f5f009397da5 [ Upstream commit 1125d925990b8d8166c45396c9281e2a705c97f8 ] Replace the davinci_mcasp_set_pdata_from_of() function which returned a pdata pointer with davinci_mcasp_get_config() to return an actual error code and handle all pdata validation and private mcasp struct setup in there. Drop the unused ram-size-playback and sram-size-capture query from DT at the same time. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201106072551.689-4-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 1125d925990b8d8166c45396c9281e2a705c97f8 ]

Replace the davinci_mcasp_set_pdata_from_of() function which returned a
pdata pointer with davinci_mcasp_get_config() to return an actual error
code and handle all pdata validation and private mcasp struct setup in
there.

Drop the unused ram-size-playback and sram-size-capture query from DT at
the same time.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201106072551.689-4-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe")
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: ti: davinci-mcasp: Remove legacy dma_request parsing 2024-07-05T07:08:13+00:00 Peter Ujfalusi peter.ujfalusi@ti.com 2020-11-06T07:25:49+00:00 6405101177e63898e974d9cf0911a25a1a04f72c [ Upstream commit db8793a39b293d5a8983e1713a70a76cb039c2fe ] The legacy dma_request (which was holding the DMA request number) is no longer in use for a long time. All legacy platforms has been converted to dma_slave_map. Remove it along with the DT parsing to get tx_dma_channel and rx_dma_channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201106072551.689-3-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit db8793a39b293d5a8983e1713a70a76cb039c2fe ]

The legacy dma_request (which was holding the DMA request number) is no
longer in use for a long time.
All legacy platforms has been converted to dma_slave_map.

Remove it along with the DT parsing to get tx_dma_channel and
rx_dma_channel.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201106072551.689-3-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe")
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: ti: davinci-mcasp: Use platform_get_irq_byname_optional 2024-07-05T07:08:13+00:00 Peter Ujfalusi peter.ujfalusi@ti.com 2020-11-06T07:25:48+00:00 1e2fbb5e1ada8752fedac85b7041a459a270a1c2 [ Upstream commit 372c4bd11de1793667e11d19c29fffc80495eeca ] Depending on the integration of McASP either the 'common' or the 'rx' and 'tx' or only the 'tx' interrupt number is valid, provided. By switching to platform_get_irq_byname_optional() we can clean up the bootlog from messages like: davinci-mcasp 2ba0000.mcasp: IRQ common not found The irq number == 0 is not valid, fix the check at the same time. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201106072551.689-2-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 372c4bd11de1793667e11d19c29fffc80495eeca ]

Depending on the integration of McASP either the 'common' or the
'rx' and 'tx' or only the 'tx' interrupt number is valid, provided.

By switching to platform_get_irq_byname_optional() we can clean up the
bootlog from messages like:

davinci-mcasp 2ba0000.mcasp: IRQ common not found

The irq number == 0 is not valid, fix the check at the same time.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201106072551.689-2-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe")
Signed-off-by: Sasha Levin <sashal@kernel.org>
ASoC: ti: davinci-mcasp: remove always zero of davinci_mcasp_get_dt_params 2024-07-05T07:08:13+00:00 Zhang Qilong zhangqilong3@huawei.com 2020-11-02T10:34:28+00:00 6daaf36291931cf2a5bf49a8b3378186e990cdb2 [ Upstream commit 19f6e424d6150b5eede2277dbc6dfd3bf42e994f ] davinci_mcasp_get_dt_params alway return zero, and its return value could be ignored by the caller. So make it 'void' type to avoid the check its return value. Fixes: 764958f2b5239 ("ASoC: ti: davinci-mcasp: Support for auxclk-fs-ratio") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201102103428.32678-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 19f6e424d6150b5eede2277dbc6dfd3bf42e994f ]

davinci_mcasp_get_dt_params alway return zero, and its return value
could be ignored by the caller. So make it 'void' type to avoid the
check its return value.

Fixes: 764958f2b5239 ("ASoC: ti: davinci-mcasp: Support for auxclk-fs-ratio")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20201102103428.32678-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Stable-dep-of: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe")
Signed-off-by: Sasha Levin <sashal@kernel.org>