Fix a corner case between PCI device driver remove callback and
runtime PM idle callback.
Following sequence of events can happen:
- at azx_create, context is allocated with devm_kzalloc() and
stored as pci_set_drvdata()
- user-space requests to unbind audio driver
- dd.c:__device_release_driver() calls PCI remove
- pci-driver.c:pci_device_remove() calls the audio
driver azx_remove() callback and this is completed
- pci-driver.c:pm_runtime_put_sync() leads to a call
to rpm_idle() which again calls azx_runtime_idle()
- the azx context object, as returned by dev_get_drvdata(),
is no longer valid
-> access fault in azx_runtime_idle when executing
struct snd_card *card = dev_get_drvdata(dev);
chip = card->private_data;
if (chip->disabled || hda->init_failed)
This was discovered by i915_module_load test with 5.15.0 based
linux-next tree.
Example log caught by i915_module_load test with linux-next
https://intel-gfx-ci.01.org/tree/linux-next/
<4> [264.038232] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b73f0: 0000 [#1] PREEMPT SMP NOPTI
<4> [264.038248] CPU: 0 PID: 5374 Comm: i915_module_loa Not tainted 5.15.0-next-20211109-gc8109c2ba35e-next-20211109 #1
[...]
<4> [264.038267] RIP: 0010:azx_runtime_idle+0x12/0x60 [snd_hda_intel]
[...]
<4> [264.038355] Call Trace:
<4> [264.038359] <TASK>
<4> [264.038362] __rpm_callback+0x3d/0x110
<4> [264.038371] rpm_idle+0x27f/0x380
<4> [264.038376] __pm_runtime_idle+0x3b/0x100
<4> [264.038382] pci_device_remove+0x6d/0xa0
<4> [264.038388] device_release_driver_internal+0xef/0x1e0
<4> [264.038395] unbind_store+0xeb/0x120
<4> [264.038400] kernfs_fop_write_iter+0x11a/0x1c0
Fix the issue by setting drvdata to NULL at end of azx_remove().
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211110210307.1172004-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change in hda-intel driver to allow repeated probes
surfaced a problem that has been hidden until; the probe process in
the work calls azx_free() at the error path, and this skips the card
free process that eventually releases codec instances. As a result,
we get a kernel WARNING like:
snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up
------------[ cut here ]------------
WARNING: CPU: 14 PID: 186 at sound/hda/hdac_bus.c:73
....
For fixing this, we need to call snd_card_free() instead of
azx_free(). Additionally, the device drvdata has to be cleared, as
the driver binding itself is still active. Then the PM and other
driver callbacks will ignore the procedure.
Fixes: c0f1886de7 ("ALSA: hda: intel: Allow repeatedly probing on codec configuration errors")
Reported-and-tested-by: Scott Branden <scott.branden@broadcom.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/063e2397-7edb-5f48-7b0d-618b938d9dd8@broadcom.com
Link: https://lore.kernel.org/r/20211110194633.19098-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recently introduced non-contiguous page allocation support helpers
are using the simplified code to calculate the page and DMA address
based on the vmalloc helpers, but this isn't quite right as the vmap
is valid only for the direct DMA.
This patch corrects those accessors to use the proper SG helpers
instead.
Fixes: a25684a956 ("ALSA: memalloc: Support for non-contiguous page allocation")
Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Link: https://lore.kernel.org/r/20211108151059.31898-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent fix for setting up the DMA buffer type on RME drivers tried
to address the non-standard memory managements and changed the DMA
buffer information to the standard snd_dma_buffer object that is
allocated at the probe time. However, I overlooked that the RME
drivers handle the buffer addresses based on 64k alignment, and the
previous conversion broke that silently.
This patch is an attempt to fix the regression. The snd_dma_buffer
objects are copied to the original data with the correction to the
aligned accesses, and those are passed to snd_pcm_set_runtime_buffer()
helpers instead. The original snd_dma_buffer objects are managed by
devres, hence they'll be released automagically.
Fixes: 0899a7a230 ("ALSA: pci: rme: Set up buffer type properly")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211108145752.30572-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mark of the Unicorn designed Track 16 2011 as one of models in third
generation of its FireWire series. The model is already discontinued.
It consists of below ICs:
* Texas Instruments TSB41AB1
* Microchip (SMSC) USB3300
* Xilinx Spartan-3A FPGA, XC3S700A
* Texas Instruments TMS320C6722
* Microchip (Atmel) AT91SAM SAM7S512
It supports sampling transfer frequency up to 192.0 kHz. The packet
format differs depending on both of current sampling transfer frequency
and the type of signal in optical interfaces. The model supports
transmission of PCM frames as well as MIDI messages.
The model supports command mechanism to configure internal DSP. Hardware
meter information is available in the first 2 chunks of each data block
of tx packet.
This commit adds support for it.
$ cd linux-firewire-tools/src
$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04107d95 bus_info_length 4, crc_length 16, crc 32149
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000a83c4 device_id 00000a83c4 | EUI-64 0001f200000a83c4
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 00035b04 directory_length 3, crc 23300
42c 120001f2 specifier id
430 13000039 version
434 17102800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 0002b25f leaf_length 2, crc 45663
43c 0001f200 company_id 0001f2 |
440 000a83c4 device_id 00000a83c4 | EUI-64 0001f200000a83c4
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211107110644.23511-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent refactoring of mmap handling caused Oops on some devices
that don't use the standard memory allocations. This patch addresses
it by allowing snd_dma_buffer_mmap() helper to receive the NULL
pointer dmab argument (and return an error appropriately).
Fixes: a202bd1ad8 ("ALSA: core: Move mmap handler into memalloc ops")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211107163911.13534-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Although we've covered all calls with NULL dma buffer pointer, so far,
there may be still some else in the wild. For catching such a case
more easily, add a WARN_ON_ONCE() in snd_dma_get_ops().
Fixes: 37af81c599 ("ALSA: core: Abstract memory alloc helpers")
Link: https://lore.kernel.org/r/20211105102103.28148-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 2d9ea39917.
We've got a regression report showing that the audio got broken the
device over AMD IOMMU. The conversion assumed the wrong pointer /
page mapping for the indirect mapping case, and we need to correct
this urgently, so let's revert it for now.
Fixes: 2d9ea39917 ("ALSA: memalloc: Convert x86 SG-buffer handling with non-contiguous type")
Reported-and-tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Link: https://lore.kernel.org/r/20211104180846.16340-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mark of the Unicorn (MOTU) shipped Traveler mk3 as one of models in third
generation of its FireWire series, and discontinued it already. The model
consists of below ICs:
* Texas Instruments TSB41AB2
* Phillips Semiconductors PDI1394L40
* Altera cyclone EP1C3
* Texas Instruments TMS320VC5402
It supports sampling transfer frequency up to 192.0 kHz. The packet
format differs depending on both of current sampling transfer frequency
and whether to enable ADAT channels in rx/tx packets. The model supports
transmission of PCM frames as well as MIDI messages.
The model supports command mechanism to configure internal DSP. Hardware
meter information is available in the first 2 chunks of each data block
of tx packet.
This commit adds support for it.
$ cd linux-firewire-tools/src
$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0410af0a bus_info_length 4, crc_length 16, crc 44810
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 00090911 device_id 0000090911 | EUI-64 0001f20000090911
root directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438
unit directory at 428
-----------------------------------------------------------------
428 00031733 directory_length 3, crc 5939
42c 120001f2 specifier id
430 1300001b version
434 17102800 model
eui-64 leaf at 438
-----------------------------------------------------------------
438 00028484 leaf_length 2, crc 33924
43c 0001f200 company_id 0001f2 |
440 00090911 device_id 0000090911 | EUI-64 0001f20000090911
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211104110627.94469-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Clevo NH77HJ, NH77HP, and their 15" variants, there is a headset
microphone input attached to 0x19 that does not have a jack detect. In
order to get it working, the pin configuration needs to be set
correctly, and a new ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE fixup is
applied. This is similar to the existing System76 quirk for ALC293, but
for ALC256.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211102172104.10610-1-tcrawford@system76.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When the timer instance was add into ack_list but was not currently in
process, the user could stop it via snd_timer_stop1() without delete it
from the ack_list. Then the user could free the timer instance and when
it was actually processed UAF occurred.
This issue could be reproduced via testcase snd_timer01 in ltp - running
several instances of that testcase at the same time.
What I actually met was that the ack_list of the timer broken and the
kernel went into deadloop with irqoff. That could be detected by
hardlockup detector on board or when we run it on qemu, we could use gdb
to dump the ack_list when the console has no response.
To fix this issue, we delete the timer instance from ack_list and
active_list unconditionally in snd_timer_stop1().
Signed-off-by: Wang Wensheng <wangwensheng4@huawei.com>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211103033517.80531-1-wangwensheng4@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ASoC: Updates for v5.16
This is an unusually large set of updates, mostly a large crop of
unusually big drivers coupled with extensive overhauls of existing code.
There's a SH change here for the DAI format terminology, the change is
straightforward and the SH maintainers don't seem very active.
- A new version of the audio graph card which supports a wider range of
systems.
- Move of the Cirrus DSP framework into drivers/firmware to allow for
future use by non-audio DSPs.
- Several conversions to YAML DT bindings.
- Continuing cleanups to the SOF and Intel code.
- A very big overhaul of the cs42l42 driver, correcting many problems.
- Support for AMD Vangogh and Yelow Cap, Cirrus CS35L41, Maxim
MAX98520 and MAX98360A, Mediatek MT8195, Nuvoton NAU8821, nVidia
Tegra210, NXP i.MX8ULP, Qualcomm AudioReach, Realtek ALC5682I-VS,
RT5682S, and RT9120 and Rockchip RV1126 and RK3568
Adding the Line6 HX-Stomp XL USB_ID as it needs this fixed frequency
quirk as well.
The device is basically just the HX-Stomp with some more buttons on
the face. I've done some recording with it after adding it, and it
seems to function properly with this fix. The Midi features appear to
be working as well.
[ a coding style fix and patch reformat by tiwai ]
Signed-off-by: Jason Ormes <skryking@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211030200405.1358678-1-skryking@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Support multiple headphone drivers in same machine driver. In this
case, both rt5682 and rt5682s are supported and enumerated by different
ACPI HID "10EC5682" and "RTL5682".
V2 Changes:
- remove useless 'NULL', 'false' in if-condition
- can use 'comp_ids' field alone to enumerate driver
- add comma to the end of entry in structure initialization
- keep the table of byt/cht/cml/icl untouched
V3 Changes:
- upstreamd from SOF github, PR#3200
- use new compatiable IDs to shrink the enumerate table of BYT and CHT
- add 'const' to snd_soc_acpi_codecs structures
V4 Changes:
- add signoff to patch 4~6
V5 Changes:
- none, just rebase for patch 3 conflict
Brent Lu (3):
ASoC: soc-acpi: add comp_ids field for machine driver matching
ASoC: Intel: sof_rt5682: detect codec variant in probe function
ASoC: Intel: sof_rt5682: use comp_ids to enumerate rt5682s
Pierre-Louis Bossart (3):
ASoC: Intel: soc-acpi-byt: shrink tables using compatible IDs
ASoC: Intel: soc-acpi-cht: shrink tables using compatible IDs
ASoC: Intel: soc-acpi: use const for all uses of snd_soc_acpi_codecs
include/sound/soc-acpi.h | 3 +
sound/soc/intel/boards/sof_rt5682.c | 34 ++-------
.../intel/common/soc-acpi-intel-adl-match.c | 11 ++-
.../intel/common/soc-acpi-intel-bxt-match.c | 2 +-
.../intel/common/soc-acpi-intel-byt-match.c | 68 +++++++-----------
.../intel/common/soc-acpi-intel-cht-match.c | 69 +++++++------------
.../intel/common/soc-acpi-intel-cml-match.c | 8 +--
.../intel/common/soc-acpi-intel-glk-match.c | 2 +-
.../intel/common/soc-acpi-intel-jsl-match.c | 43 ++++--------
.../intel/common/soc-acpi-intel-kbl-match.c | 12 ++--
.../intel/common/soc-acpi-intel-skl-match.c | 2 +-
.../intel/common/soc-acpi-intel-tgl-match.c | 11 ++-
sound/soc/soc-acpi.c | 24 ++++++-
13 files changed, 119 insertions(+), 170 deletions(-)
--
2.25.1
Couple of soc-topology related changes and a use-after-free fix. Said fix
and two sanity checks for soc-topology lead the way. While the
use-after-free is quite obvious, the sanity checks are here to cover for
cases where user malformed the topology file -or- access to filesystem
somehow got interrupted during copy operation. We shouldn't be reading
outside the file boundary.
Afterward a change to soc_tplg_add_kcontrol(): device being passed to
soc_tplg_add_dcontrol() from comp->dev to tplg->dev which corrects
dev_xxx() invoked later on.
Also, device used for topology memory allocations from component->dev to
component->card->dev so memory gets freed each time card device (usually
platform device) is removed rather than the component device what may
happen less frequently.
Dummy component gets smarter and no longer overrides hw_params if
there are other components accociated with related struct
snd_soc_pcm_runtime instance.
Amadeusz Sławiński (5):
ASoC: core: Remove invalid snd_soc_component_set_jack call
ASoC: topology: Check for dapm widget completeness
ASoC: topology: Use correct device for prints
ASoC: topology: Change topology device to card device
ASoC: Stop dummy from overriding hwparams
Cezary Rojewski (1):
ASoC: topology: Add header payload_size verification
sound/soc/soc-core.c | 3 ---
sound/soc/soc-topology.c | 34 ++++++++++++++++++++++++++++++----
sound/soc/soc-utils.c | 13 +++++++++++++
3 files changed, 43 insertions(+), 7 deletions(-)
--
2.25.1
A machine driver needs to be enumerated by more than one ACPI HID if
it supports second headphone driver (i.e. rt5682 and rt5682s).
However, the id field in snd_soc_acpi_mach structure could contain
only one HID. By adding a 'comp_ids' field which can contain several
HIDs, we can enumerate a machine driver by multiple ACPI HIDs.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Link: https://lore.kernel.org/r/20211029171409.611600-2-brent.lu@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In case that there are other components assigned to runtime device,
depending on order dummy component can override their params with its
own, which shouldn't happen. Check if there are any other components
assigned to rtd and if so, skip setting hwparams.
Occurs when using topology where 'snd-soc-dummy' gets assigned by
default as codec and platform component.
Alternative approach would be to copy whole dummy handling and rename it
to "snd-soc-null" or something similar. And remove hwparams assignment
to make it really do nothing.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20211015161257.27052-7-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Topology needs device for prints and resource allocation. So far,
component->dev is used. However, this may lead to high memory use in
model where card is an independent driver which can be reloaded and
topology is loaded from component's probe() method. Every time machine
driver is reloaded topology is being loaded anew, each time allocating
new memory. Said memory will only be freed when component itself is
being freed.
Address the problem by tying topology to component->card->dev instead,
so memory occupied by the topology is freed whenever related machine
device gets removed.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20211015161257.27052-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The acp-platform driver now needs the ACPI helpers:
ld.lld: error: undefined symbol: snd_soc_acpi_find_machine
>>> referenced by acp-platform.c
>>> soc/amd/acp/acp-platform.o:(acp_machine_select) in archive sound/built-in.a
ld.lld: error: undefined symbol: snd_soc_acpi_codec_list
>>> referenced by acp-renoir.c
>>> soc/amd/acp/acp-renoir.o:(snd_soc_acpi_amd_acp_machines) in archive sound/built-in.a
Other drivers using this interface, select SND_SOC_ACPI, so do the
same thing here.
Fixes: e646b51f5d ("ASoC: amd: acp: Add callback for machine driver on ACP")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211029113714.966823-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Summary: The driver applied the opposite of the DT setting to the
wrong register bit.
The jack plug detect hardware in cs42l42 is somewhat confusing,
compounded by an unclear description in the datasheet. This is most
likely the reason that the driver implemented a DT property for the
wrong register bit, that had the opposite effect of what was
described in the binding.
Changing the meaning of the property values isn't feasible; the
driver dates from 2016 and the risk of breaking out-of-tree configs
is too high (the property is also available to ACPI systems).
So the fix is to make the binding doc match the actual behaviour and
then fix the driver to apply it to the correct register bit.
As a bonus, patch #3 converts the binding to yaml.
Richard Fitzgerald (3):
ASoC: dt-bindings: cs42l42: Correct description of ts-inv
ASoC: cs42l42: Correct configuring of switch inversion from ts-inv
ASoC: dt-bindings: cs42l42: Convert binding to yaml
.../devicetree/bindings/sound/cirrus,cs42l42.yaml | 225 +++++++++++++++++++++
.../devicetree/bindings/sound/cs42l42.txt | 114 -----------
MAINTAINERS | 1 +
sound/soc/codecs/cs42l42.c | 9 +-
4 files changed, 230 insertions(+), 119 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/cs42l42.txt
--
2.11.0
The setting from the cirrus,ts-inv property should be applied to the
TIP_SENSE_INV bit, as this is the one that actually affects the jack
detect block. The TS_INV bit only swaps the meaning of the PLUG and
UNPLUG interrupts and should always be 1 for the interrupts to have
the normal meaning.
Due to some misunderstanding the driver had been implemented to
configure the TS_INV bit based on the jack switch polarity. This made
the interrupts behave the correct way around, but left the jack detect
block, button detect and analogue circuits always interpreting an open
switch as unplugged.
The signal chain inside the codec is:
SENSE pin -> TIP_SENSE_INV -> TS_INV -> (invert) -> interrupts
|
v
Jack detect,
button detect and
analog control
As the TIP_SENSE_INV already performs the necessary inversion the
TS_INV bit never needs to change. It must always be 1 to yield the
expected interrupt behaviour.
Some extra confusion has arisen because of the additional invert in the
interrupt path, meaning that a value applied to the TS_INV bit produces
the opposite effect of applying it to the TIP_SENSE_INV bit. The ts-inv
property has therefore always had the opposite effect to what might be
expected (0 = inverted, 1 = not inverted). To maintain the meaning of
the ts-inv property it must be inverted when applied to TIP_SENSE_INV.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 2c394ca796 ("ASoC: Add support for CS42L42 codec")
Link: https://lore.kernel.org/r/20211028140902.11786-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
