ALSA: hda: document state machine for hdac_streams
The code in this library is far from self-explanatory, hopefully this
state diagram reverse-engineered from the code will help others
understand the expected transitions.
Jaroslav Kysela [Mon, 19 Sep 2022 13:54:44 +0000 (15:54 +0200)]
ALSA: hda/hdmi: Fix the converter allocation for the silent stream
Track the converters handling the silent stream using a new
variable to avoid mixing of the open/close and silent stream
use. This change ensures the proper allocation of the converters.
Fixes: 5f80d6bd2b01 ("ALSA: hda/hdmi: Fix the converter reuse for the silent stream") Signed-off-by: Jaroslav Kysela <perex@perex.cz> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20220919135444.3554982-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jaroslav Kysela [Tue, 13 Sep 2022 07:02:16 +0000 (09:02 +0200)]
ALSA: hda/hdmi: Fix the converter reuse for the silent stream
When the user space pcm stream uses the silent stream converter,
it is no longer allocated for the silent stream. Clear the appropriate
flag in the hdmi_pcm_open() function. The silent stream setup may
be applied in hdmi_pcm_close() (and the error path - open fcn) again.
If the flag is not cleared, the reuse conditions for the silent
stream converter in hdmi_choose_cvt() may improperly share
this converter.
Luke D. Jones [Thu, 15 Sep 2022 08:09:21 +0000 (20:09 +1200)]
ALSA: hda/realtek: Add quirk for ASUS GA503R laptop
The ASUS G15 2022 (GA503R) series laptop has the same node-to-DAC pairs
as early models and the G14, this includes bass speakers which are by
default mapped incorrectly to the 0x06 node.
Just as with the 5570 (and the other Dell laptops), this enables the two
subwoofer speakers on the Dell Precision 5530 together with the main
ones, significantly increasing the audio quality. I've tested this
myself on a 5530 and can confirm it's working as expected.
ALSA: usb-audio: Fix last interface check for registration
The recent fix in commit 6392dcd1d0c7 ("ALSA: usb-audio: Register card
at the last interface") tried to delay the card registration until the
last found interface is probed. It assumed that the probe callback
gets called for those later interfaces, but it's not always true; as
the driver loops over the descriptor and probes the matching ones,
it's not separately called via multiple probe calls. This results in
the missing card registration, i.e. no sound device.
For addressing this problem, replace the check whether the last
interface is processed with usb_interface_claimed() instead of the
comparison with the probe interface number.
The Dell Precision 5570 uses the same 4-speakers-on-ALC289 just like the
previous Precision 5560. I replicated that patch onto this one, and can
confirm that the audio is much better (the woofers are now working);
I've tested it on my Dell Precision 5570.
Gaosheng Cui [Mon, 22 Aug 2022 03:51:33 +0000 (11:51 +0800)]
ASoC: Intel: fix unused-variable warning in probe_codec
In configurations with CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC=n,
gcc warns about an unused variable:
sound/soc/intel/skylake/skl.c: In function ‘probe_codec’:
sound/soc/intel/skylake/skl.c:729:18: error: unused variable ‘skl’ [-Werror=unused-variable]
struct skl_dev *skl = bus_to_skl(bus);
^~~
cc1: all warnings being treated as errors
Fixes: 3fd63658caed9 ("ASoC: Intel: Drop hdac_ext usage for codec device creation") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Acked-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220822035133.2147381-1-cuigaosheng1@huawei.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Nvidia HDA HW expects infoframe data bytes order same for both
HDMI and DP i.e infoframe data starts from 5th bytes offset. As
dp infoframe structure has 4th byte as valid infoframe data, use
hdmi infoframe structure for nvidia dp infoframe to match HW behvaior.
ALSA: hda: Fix hang at HD-audio codec unbinding due to refcount saturation
We fixed the potential deadlock at dynamic unbinding the HD-audio
codec at the commit 7206998f578d ("ALSA: hda: Fix potential deadlock
at codec unbinding"), but ironically, this caused another potential
deadlock. The current code uses refcount_dec() and waits for the
pending task with wait_event for dropping the refcount to 0. This
works fine when PCMs are assigned and actually waiting for the
refcount drop.
Meanwhile, when there was no PCM assigned, the refcount_dec() call
itself was supposed to drop to zero -- alas, it doesn't in reality;
refcount_dec() complains, spews kernel warning and it saturates
instead of dropping to 0, due to the nature of refcount_dec()
implementation. This eventually blocks the wait_event() wakeup and
the code get stuck there.
For avoiding the problem, we call refcount_dec_and_test() and skips
the sync-wait if it already reaches to zero.
The patch does a slight code reshuffling to make sure to invoke other
disconnect calls before the sync-wait, too.
ALSA: usb-audio: Clear fixed clock rate at closing EP
The recent commit c11117b634f4 ("ALSA: usb-audio: Refcount multiple
accesses on the single clock") tries to manage the clock rate shared
by several endpoints. This was intended for avoiding the unmatched
rate by a different endpoint, but unfortunately, it introduced a
regression for PulseAudio and pipewire, too; those applications try to
probe the multiple possible rates (44.1k and 48kHz) and setting up the
normal rate fails but only the last rate is applied.
The cause is that the last sample rate is still left to the clock
reference even after closing the endpoint, and this value is still
used at the next open. It happens only when applications set up via
PCM prepare but don't start/stop the stream; the rate is reset when
the stream is stopped, but it's not cleared at close.
This patch addresses the issue above, simply by clearing the rate set
in the clock reference at the last close of each endpoint.
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
The voice allocator sometimes begins allocating from near the end of the
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough
index so that first_voice + requested_voice_count > NUM_G (64).
The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced
by calling aplay multiple times with 16 channels:
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
index 65 is out of range for type 'snd_emu10k1_voice [64]'
CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
ubsan_epilogue+0x9/0x3f
__ubsan_handle_out_of_bounds.cold+0x44/0x49
snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
? exit_to_user_mode_prepare+0x35/0x170
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x26/0x50
? do_syscall_64+0x69/0x90
? exit_to_user_mode_prepare+0x35/0x170
snd_pcm_ioctl+0x27/0x40 [snd_pcm]
__x64_sys_ioctl+0x95/0xd0
do_syscall_64+0x5c/0x90
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Andy Shevchenko [Mon, 5 Sep 2022 16:58:25 +0000 (19:58 +0300)]
ALSA: hda: cs35l41: Call put_device() in the scope of get_device()
When put_device() is called in another function it's hard to realize
that and easy to "fix" the code in a wrong way. Instead, move
put_device() to be in the same scope as get_device(), so we prevent
appearance of any attempts to "fix" the code.
The recent fix for IDT codecs to keep the power up while the beep is
enabled can be better integrated into the beep helper code.
This patch cleans up the code with refactoring.
ALSA: usb-audio: Register card at the last interface
The USB-audio driver matches per interface, and as default, it
registers the card instance at the very first instance. This can be a
problem for the devices that have multiple interfaces to be probed, as
the udev rule isn't applied properly for the later appearing
interfaces. Although we introduced the delayed_register option and
the quirks for covering those shortcomings, it's nothing but a
workaround for specific devices.
This patch is an another attempt to fix the problem in a more generic
way. Now the driver checks the whole USB device descriptor at the
very first time when an interface is attached to a sound card. It
looks at each matching interface in the descriptor and remembers the
last matching one. The snd_card_register() is invoked only when this
last interface is probed.
After this change, the quirks for the delayed registration become
superfluous, hence they are removed along with the patch. OTOH, the
delayed_register option is still kept, as it might be useful for some
corner cases (e.g. a special driver overtakes the interface probe from
the standard driver, and the last interface probe may miss).
ALSA: hda: Once again fix regression of page allocations with IOMMU
The last fix for trying to recover the regression on AMD platforms,
unfortunately, leaded to yet another regression: it turned out that
IOMMUs don't like the usage of raw page allocations.
This is yet another attempt for addressing the log saga; at this time,
we re-use the existing buffer allocation mechanism with SG-pages
although we require only single pages. The SG buffer allocation
itself was confirmed to work for stream buffers, so it's relatively
easy to adapt for other places.
The only problem is: although the HD-audio code is accessing the
address directly via dmab->address field, SG-pages don't set up it.
For the ease of adaption, we now set up the dmab->addr field from the
address of the first page as default, so that it can run with the
HD-audio driver code as-is without the excessive call of
snd_sgbuf_get_addr() multiple times; that's the only change in the
memalloc helper side. The rest is nothing but a flip of the dma_type
field in the HD-audio side.
Dongxiang Ke [Tue, 6 Sep 2022 02:49:28 +0000 (10:49 +0800)]
ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface()
There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and
the number of it's interfaces less than 4, an out-of-bounds read bug occurs
when parsing the interface descriptor for this device.
AZA HW may send a burst read/write request crossing 4K memory boundary.
The 4KB boundary is not guaranteed by Tegra HDA HW. Make SW change to
include the flag AZX_DCAPS_4K_BDLE_BOUNDARY to align BDLE to 4K
boundary.
There is a small race window at snd_pcm_oss_sync() that is called from
OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls
snd_pcm_oss_make_ready() at first, then takes the params_lock mutex
for the rest. When the stream is set up again by another thread
between them, it leads to inconsistency, and may result in unexpected
results such as NULL dereference of OSS buffer as a fuzzer spotted
recently.
The fix is simply to cover snd_pcm_oss_make_ready() call into the same
params_lock mutex with snd_pcm_oss_make_ready_locked() variant.
ALSA: hda/sigmatel: Keep power up while beep is enabled
It seems that the beep playback doesn't work well on IDT codec devices
when the codec auto-pm is enabled. Keep the power on while the beep
switch is enabled.
ALSA: aloop: Fix random zeros in capture data when using jiffies timer
In loopback_jiffies_timer_pos_update(), we are getting jiffies twice.
First time for playback, second time for capture. Jiffies can be updated
between these two calls and if the capture jiffies is larger, extra zeros
will be filled in the capture buffer.
Change to get jiffies once and use it for both playback and capture.
ALSA: usb-audio: Clean up endpoint setups at PCM prepare
This patch cleans up the superfluous checks and calls for setting up
the endpoints at PCM prepare callback:
- Drop stop_endpoints() and sync_pending_stops() calls; the stream is
guaranteed to have been already stopped and synced at each PCM
prepare call by ALSA PCM core
- Call snd_usb_endpoint_prepare() unconditionally;
the check for endpoint->need_setup is done in
snd_pcm_hw_endpoint_prepare() itself
- Apply snd_usb_set_format_quirk() only when the endpoint is actually
set up (i.e. the return code from snd_usb_endpoint_prepare() > 0)
- Move a few lines back into snd_usb_pcm_prepare();
it's even easier to follow than a small useless function
ALSA: usb-audio: Split endpoint setups for hw_params and prepare
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
Takashi Iwai [Wed, 31 Aug 2022 13:00:21 +0000 (15:00 +0200)]
ALSA: usb-audio: Drop superfluous interface setup at parsing
We reset each interface that is being parsed for each stream, but this
is superfluous and even can lead to spurious errors. Since the
interface is set up properly at opening the endpoint for each actual
stream operation, let's drop the superfluous one.
Takashi Iwai [Wed, 31 Aug 2022 12:59:01 +0000 (14:59 +0200)]
ALSA: usb-audio: Register card again for iface over delayed_register option
When the delayed registration is specified via either delayed_register
option or the quirk, we delay the invocation of snd_card_register()
until the given interface. But if a wrong value has been set there
and there are more interfaces over the given interface number,
snd_card_register() call would be missing for those interfaces.
This patch catches up those missing calls by fixing the comparison of
the interface number. Now the call is skipped only if the processed
interface is less than the given interface, instead of the exact
match.
Takashi Iwai [Wed, 31 Aug 2022 12:59:00 +0000 (14:59 +0200)]
ALSA: usb-audio: Inform the delayed registration more properly
The info message that was added in the commit a4aad5636c72 ("ALSA:
usb-audio: Inform devices that need delayed registration") is actually
useful to know the need for the delayed registration. However, it
turned out that this doesn't catch the all cases; namely, this warned
only when a PCM stream is attached onto the existing PCM instance, but
it doesn't count for a newly created PCM instance. This made
confusion as if there were no further delayed registration.
This patch moves the check to the code path for either adding a stream
or creating a PCM instance. Also, make it simpler by checking the
card->registered flag instead of querying each snd_device state.
ALSA: hda/hdmi: Replace zero-length array with DECLARE_FLEX_ARRAY() helper
Zero-length arrays are deprecated and we are moving towards adopting
C99 flexible-array members, instead. So, replace zero-length array
declaration in union audio_infoframe with the new DECLARE_FLEX_ARRAY()
helper macro.
This helper allows for a flexible-array member in a union.
Takashi Iwai [Sun, 28 Aug 2022 07:41:43 +0000 (09:41 +0200)]
ALSA: usb-audio: Add quirk for LH Labs Geek Out HD Audio 1V5
The USB DAC from LH Labs (2522:0007) seems requiring the same quirk as
Sony Walkman to set up the interface like UAC1; otherwise it gets the
constant errors "usb_set_interface failed (-71)". This patch adds a
quirk entry for addressing the buggy behavior.
Dan Carpenter [Fri, 26 Aug 2022 15:01:10 +0000 (18:01 +0300)]
ALSA: control: Re-order bounds checking in get_ctl_id_hash()
These two checks are in the reverse order so it might read one element
beyond the end of the array. First check if the "i" is within bounds
before using it.
Fixes: 6ab55ec0a938 ("ALSA: control: Fix an out-of-bounds bug in get_ctl_id_hash()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YwjgNh/gkG1hH7po@kili Signed-off-by: Takashi Iwai <tiwai@suse.de>
Shengjiu Wang [Thu, 25 Aug 2022 12:27:39 +0000 (20:27 +0800)]
ASoC: fsl_aud2htx: register platform component before registering cpu dai
There is no defer probe when adding platform component to
snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
snd_soc_register_card()
-> snd_soc_bind_card()
-> snd_soc_add_pcm_runtime()
-> adding cpu dai
-> adding codec dai
-> adding platform component.
So if the platform component is not ready at that time, then the
sound card still registered successfully, but platform component
is empty, the sound card can't be used.
As there is defer probe checking for cpu dai component, then register
platform component before cpu dai to avoid such issue.
And the behavior of imx_pcm_dma_init() is same as common
devm_snd_dmaengine_pcm_register(), so use
devm_snd_dmaengine_pcm_register() instead
Zheyu Ma [Wed, 24 Aug 2022 08:16:54 +0000 (16:16 +0800)]
ALSA: control: Fix an out-of-bounds bug in get_ctl_id_hash()
Since the user can control the arguments provided to the kernel by the
ioctl() system call, an out-of-bounds bug occurs when the 'id->name'
provided by the user does not end with '\0'.
The following log can reveal it:
[ 10.002313] BUG: KASAN: stack-out-of-bounds in snd_ctl_find_id+0x36c/0x3a0
[ 10.002895] Read of size 1 at addr ffff888109f5fe28 by task snd/439
[ 10.004934] Call Trace:
[ 10.007140] snd_ctl_find_id+0x36c/0x3a0
[ 10.007489] snd_ctl_ioctl+0x6cf/0x10e0
Fix this by checking the bound of 'id->name' in the loop.
Takashi Iwai [Wed, 24 Aug 2022 06:03:46 +0000 (08:03 +0200)]
Merge branch 'topic/memalloc-cleanup' into for-next
ALSA: Drop hackish GFP giveaway for CONTINUOUS pages
This is a series of cleanup patches for dropping the current hackish
way of passing the GFP_* flags for CONTINOUS and VMALLOC memory
allocations. There are only three users for this legacy feature, and
all of them seem superfluous. And, if any driver requires the memory
restriction in future, it can now pass the proper device pointer for
specifying the DMA mask.
Takashi Iwai [Tue, 23 Aug 2022 11:57:40 +0000 (13:57 +0200)]
ALSA: doc: Drop snd_dma_continuous_data() usages
Update the documentation to follow the recent change of the memory
allocation helpers. The macro snd_dma_continuous_data() is gone, and
the driver needs to set up the coherent dma mask for allocating in the
lower memory addresses, instead.
Takashi Iwai [Tue, 23 Aug 2022 11:57:39 +0000 (13:57 +0200)]
ALSA: memalloc: Drop special handling of GFP for CONTINUOUS allocation
Now that all users of snd_dma_continuous_data() is gone, let's drop
this ugly (and dangerous) way.
After this commit, SNDRV_DMA_TYPE_CONTINUOUS may take the standard
device pointer instead of the hacked pointer by the macro above, and
the memalloc core refers to the coherent_dma_mask of the given
device like other SNDRV_DMA_TYPE. It's still allowed to pass NULL
there, and in that case, the allocation is performed always in the
normal zone.
For SNDRV_DMA_TYPE_VMALLOC, the device pointer is simply ignored.
Takashi Iwai [Tue, 23 Aug 2022 11:57:38 +0000 (13:57 +0200)]
ASoC: Intel: sst: Switch to standard device pages
ASoC Atom SST driver is using the continuous RAM pages with GFP_DMA
flag for its PCM buffer, but this should work fine with the standard
DMA pages. As a part of cleanup work, this patch replaces the buffer
allocation to the standard device pages with SNDRV_DMA_TYPE_DEV.
Takashi Iwai [Tue, 23 Aug 2022 11:57:37 +0000 (13:57 +0200)]
ALSA: pdaudiocf: Drop superfluous GFP setup
The extra setup with GFP_DMA32 is superfluous for this driver. The
whole operation is a simple copy loop, and there is no memory address
restriction at all. Drop the useless GFP setup.
Takashi Iwai [Tue, 23 Aug 2022 11:57:36 +0000 (13:57 +0200)]
ALSA: vx: Drop superfluous GFP setup
The extra setup with GFP_DMA32 is superfluous for this driver. The
whole operation is a simple copy loop, and there is no memory address
restriction at all. Drop the useless GFP setup.
Peter Ujfalusi [Tue, 23 Aug 2022 12:24:05 +0000 (15:24 +0300)]
ALSA: hda: intel-nhlt: Correct the handling of fmt_config flexible array
The struct nhlt_format's fmt_config is a flexible array, it must not be
used as normal array.
When moving to the next nhlt_fmt_cfg we need to take into account the data
behind the ->config.caps (indicated by ->config.size).
Takashi Iwai [Tue, 23 Aug 2022 07:27:17 +0000 (09:27 +0200)]
ALSA: seq: Fix data-race at module auto-loading
It's been reported that there is a possible data-race accessing to the
global card_requested[] array at ALSA sequencer core, which is used
for determining whether to call request_module() for the card or not.
This data race itself is almost harmless, as it might end up with one
extra request_module() call for the already loaded module at most.
But it's still better to fix.
This patch addresses the possible data race of card_requested[] and
client_requested[] arrays by replacing them with bitmask.
It's an atomic operation and can work without locks.
Mark Brown [Tue, 23 Aug 2022 18:36:36 +0000 (19:36 +0100)]
ASoC: nau8xxx: Implement hw constraint for rates
Merge series from Takashi Iwai <tiwai@suse.de>:
This is a series of patches to address the issues on nau8xxx codecs
I've stumbled upon while dealing with a bug report for Steam Deck.
Most of them are to implement the missing hw constraint for rate
restrictions while one patch is to fix the semaphore unbalance in
nau8824 driver.
A recent change in clang strengthened its -Wbitfield-constant-conversion
to warn when 1 is assigned to a 1-bit signed integer bitfield, as it can
only be 0 or -1, not 1:
sound/soc/atmel/mchp-spdiftx.c:505:20: error: implicit truncation from 'int' to bit-field changes value from 1 to -1 [-Werror,-Wbitfield-constant-conversion]
dev->gclk_enabled = 1;
^ ~
1 error generated.
The actual value of the field is never checked, just that it is not
zero, so there is not a real bug here. However, it is simple enough to
silence the warning by making the bitfield unsigned, which matches the
mchp-spdifrx driver.
Takashi Iwai [Tue, 23 Aug 2022 07:27:16 +0000 (09:27 +0200)]
ALSA: seq: oss: Fix data-race for max_midi_devs access
ALSA OSS sequencer refers to a global variable max_midi_devs at
creating a new port, storing it to its own field. Meanwhile this
variable may be changed by other sequencer events at
snd_seq_oss_midi_check_exit_port() in parallel, which may cause a data
race.
OTOH, this data race itself is almost harmless, as the access to the
MIDI device is done via get_mdev() and it's protected with a refcount,
hence its presence is guaranteed.
Though, it's sill better to address the data-race from the code sanity
POV, and this patch adds the proper spinlock for the protection.
Peter Ujfalusi [Tue, 23 Aug 2022 12:15:54 +0000 (15:15 +0300)]
ASoC: SOF: Kconfig: Make IPC_MESSAGE_INJECTOR depend on SND_SOC_SOF
Make sure that the IPC_MESSAGE_INJECTOR client can not be built in when
SND_SOC_SOF is built as module.
Fixes: cac0b0887e530 ("ASoC: SOF: Convert the generic IPC message injector into SOF client") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220823121554.4255-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Tue, 23 Aug 2022 12:15:53 +0000 (15:15 +0300)]
ASoC: SOF: Kconfig: Make IPC_FLOOD_TEST depend on SND_SOC_SOF
Make sure that the IPC_FLOOD client can not be built in when SND_SOC_SOF is
built as module.
Fixes: 6e9548cdb30e5 ("ASoC: SOF: Convert the generic IPC flood test into SOF client") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220823121554.4255-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Takashi Iwai [Tue, 23 Aug 2022 08:10:00 +0000 (10:10 +0200)]
ASoC: nau8540: Implement hw constraint for rates
nau8540 driver restricts the sample rate with over sampling rate, but
currently it barely bails out at hw_params with -EINVAL error (with a
kernel message); this doesn't help for user-space to recognize which
rate can be actually used.
This patch introduces the proper hw constraint for adjusting the
available range of the sample rate depending on the OSR setup, as well
as some code cleanup, for improving the communication with
user-space. Now applications can know the valid rate beforehand and
reduces the rate appropriately without errors.
Takashi Iwai [Tue, 23 Aug 2022 08:09:59 +0000 (10:09 +0200)]
ASoC: nau8825: Implement hw constraint for rates
nau8825 driver restricts the sample rate with over sampling rate, but
currently it barely bails out at hw_params with -EINVAL error (with a
kernel message); this doesn't help for user-space to recognize which
rate can be actually used.
This patch introduces the proper hw constraint for adjusting the
available range of the sample rate depending on the OSR setup, as well
as some code cleanup, for improving the communication with
user-space. Now applications can know the valid rate beforehand and
reduces the rate appropriately without errors.
Takashi Iwai [Tue, 23 Aug 2022 08:09:58 +0000 (10:09 +0200)]
ASoC: nau8824: Implement hw constraint for rates
nau8824 driver restricts the sample rate with over sampling rate, but
currently it barely bails out at hw_params with -EINVAL error (with a
kernel message); this doesn't help for user-space to recognize which
rate can be actually used.
This patch introduces the proper hw constraint for adjusting the
available range of the sample rate depending on the OSR setup, as well
as some code cleanup, for improving the communication with
user-space. Now applications can know the valid rate beforehand and
reduces the rate appropriately without errors.
Takashi Iwai [Tue, 23 Aug 2022 08:09:57 +0000 (10:09 +0200)]
ASoC: nau8824: Fix semaphore unbalance at error paths
The semaphore of nau8824 wasn't properly unlocked at some error
handling code paths, hence this may result in the unbalance (and
potential lock-up). Fix them to handle the semaphore up properly.
Takashi Iwai [Tue, 23 Aug 2022 08:09:56 +0000 (10:09 +0200)]
ASoC: nau8821: Implement hw constraint for rates
nau8821 driver restricts the sample rate with over sampling rate, but
currently it barely bails out at hw_params with -EINVAL error (with a
kernel message); this doesn't help for user-space to recognize which
rate can be actually used.
This patch introduces the proper hw constraint for adjusting the
available range of the sample rate depending on the OSR setup, as well
as some code cleanup, for improving the communication with
user-space. Now applications can know the valid rate beforehand and
reduces the rate appropriately without errors.
Jiaxin Yu [Sat, 20 Aug 2022 07:19:25 +0000 (15:19 +0800)]
ASoC: mediatek: mt8186: fix DMIC record noise
When the first DMIC recording is power down, mtkaif_dmic will be reset.
This will cause configuration error in the second DMIC recording. So do
not reset mtkaif_dmic except in "MTKAIF_DMIC Switch" kcontrol.
Takashi Iwai [Sun, 21 Aug 2022 15:59:11 +0000 (17:59 +0200)]
ALSA: memalloc: Revive x86-specific WC page allocations again
We dropped the x86-specific hack for WC-page allocations with a hope
that the standard dma_alloc_wc() works nowadays. Alas, it doesn't,
and we need to take back some workaround again, but in a different
form, as the previous one was broken for some platforms.
This patch re-introduces the x86-specific WC-page allocations, but it
uses rather the manual page allocations instead of
dma_alloc_coherent(). The use of dma_alloc_coherent() was also a
potential problem in the recent addition of the fallback allocation
for noncontig pages, and this patch eliminates both at once.
Linus Torvalds [Sun, 21 Aug 2022 22:09:55 +0000 (15:09 -0700)]
Merge tag 'irq-urgent-2022-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Ingo Molnar:
"Misc irqchip fixes: LoongArch driver fixes and a Hyper-V IOMMU fix"
* tag 'irq-urgent-2022-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/loongson-liointc: Fix an error handling path in liointc_init()
irqchip/loongarch: Fix irq_domain_alloc_fwnode() abuse
irqchip/loongson-pch-pic: Move find_pch_pic() into CONFIG_ACPI
irqchip/loongson-eiointc: Fix a build warning
irqchip/loongson-eiointc: Fix irq affinity setting
iommu/hyper-v: Use helper instead of directly accessing affinity
Linus Torvalds [Sun, 21 Aug 2022 22:01:51 +0000 (15:01 -0700)]
Merge tag 'perf-urgent-2022-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 kprobes fix from Ingo Molnar:
"Fix a kprobes bug in JNG/JNLE emulation when a kprobe is installed at
such instructions, possibly resulting in incorrect execution (the
wrong branch taken)"
* tag 'perf-urgent-2022-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/kprobes: Fix JNG/JNLE emulation
Linus Torvalds [Sun, 21 Aug 2022 21:49:42 +0000 (14:49 -0700)]
Merge tag 'trace-v6.0-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"Various fixes for tracing:
- Fix a return value of traceprobe_parse_event_name()
- Fix NULL pointer dereference from failed ftrace enabling
- Fix NULL pointer dereference when asking for registers from eprobes
- Make eprobes consistent with kprobes/uprobes, filters and
histograms"
* tag 'trace-v6.0-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Have filter accept "common_cpu" to be consistent
tracing/probes: Have kprobes and uprobes use $COMM too
tracing/eprobes: Have event probes be consistent with kprobes and uprobes
tracing/eprobes: Fix reading of string fields
tracing/eprobes: Do not hardcode $comm as a string
tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
tracing/perf: Fix double put of trace event when init fails
tracing: React to error return from traceprobe_parse_event_name()
tracing: Have filter accept "common_cpu" to be consistent
Make filtering consistent with histograms. As "cpu" can be a field of an
event, allow for "common_cpu" to keep it from being confused with the
"cpu" field of the event.
tracing/probes: Have kprobes and uprobes use $COMM too
Both $comm and $COMM can be used to get current->comm in eprobes and the
filtering and histogram logic. Make kprobes and uprobes consistent in this
regard and allow both $comm and $COMM as well. Currently kprobes and
uprobes only handle $comm, which is inconsistent with the other utilities,
and can be confusing to users.
tracing/eprobes: Have event probes be consistent with kprobes and uprobes
Currently, if a symbol "@" is attempted to be used with an event probe
(eprobes), it will cause a NULL pointer dereference crash.
Both kprobes and uprobes can reference data other than the main registers.
Such as immediate address, symbols and the current task name. Have eprobes
do the same thing.
For "comm", if "comm" is used and the event being attached to does not
have the "comm" field, then make it the "$comm" that kprobes has. This is
consistent to the way histograms and filters work.
Link: https://lkml.kernel.org/r/20220820134401.136924220@goodmis.org Cc: stable@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Currently when an event probe (eprobe) hooks to a string field, it does
not display it as a string, but instead as a number. This makes the field
rather useless. Handle the different kinds of strings, dynamic, static,
relational/dynamic etc.
Now when a string field is used, the ":string" type can be used to display
it:
tracing/eprobes: Do not hardcode $comm as a string
The variable $comm is hard coded as a string, which is true for both
kprobes and uprobes, but for event probes (eprobes) it is a field name. In
most cases the "comm" field would be a string, but there's no guarantee of
that fact.
Do not assume that comm is a string. Not to mention, it currently forces
comm fields to fault, as string processing for event probes is currently
broken.
Link: https://lkml.kernel.org/r/20220820134400.756152112@goodmis.org Cc: stable@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
While playing with event probes (eprobes), I tried to see what would
happen if I attempted to retrieve the instruction pointer (%rip) knowing
that event probes do not use pt_regs. The result was:
Move the testing for TPARG_FL_TPOINT which is only used for event probes
to the top of the "$" variable check, as all the other variables are not
used for event probes. Also add a check in the register parsing "%" to
fail if an event probe is used.
Link: https://lkml.kernel.org/r/20220820134400.564426983@goodmis.org Cc: stable@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com> Cc: Tom Zanussi <zanussi@kernel.org> Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events") Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Yang Jihong [Thu, 18 Aug 2022 03:26:59 +0000 (11:26 +0800)]
ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
ftrace_startup does not remove ops from ftrace_ops_list when
ftrace_startup_enable fails:
register_ftrace_function
ftrace_startup
__register_ftrace_function
...
add_ftrace_ops(&ftrace_ops_list, ops)
...
...
ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1
...
return 0 // ops is in the ftrace_ops_list.
When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:
unregister_ftrace_function
ftrace_shutdown
if (unlikely(ftrace_disabled))
return -ENODEV; // return here, __unregister_ftrace_function is not executed,
// as a result, ops is still in the ftrace_ops_list
__unregister_ftrace_function
...
If ops is dynamically allocated, it will be free later, in this case,
is_ftrace_trampoline accesses NULL pointer:
is_ftrace_trampoline
ftrace_ops_trampoline
do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!
tracing/perf: Fix double put of trace event when init fails
If in perf_trace_event_init(), the perf_trace_event_open() fails, then it
will call perf_trace_event_unreg() which will not only unregister the perf
trace event, but will also call the put() function of the tp_event.
The problem here is that the trace_event_try_get_ref() is called by the
caller of perf_trace_event_init() and if perf_trace_event_init() returns a
failure, it will then call trace_event_put(). But since the
perf_trace_event_unreg() already called the trace_event_put() function, it
triggers a WARN_ON().
WARNING: CPU: 1 PID: 30309 at kernel/trace/trace_dynevent.c:46 trace_event_dyn_put_ref+0x15/0x20
If perf_trace_event_reg() does not call the trace_event_try_get_ref() then
the perf_trace_event_unreg() should not be calling trace_event_put(). This
breaks symmetry and causes bugs like these.
Pull out the trace_event_put() from perf_trace_event_unreg() and call it
in the locations that perf_trace_event_unreg() is called. This not only
fixes this bug, but also brings back the proper symmetry of the reg/unreg
vs get/put logic.
Lukas Bulwahn [Thu, 11 Aug 2022 07:17:34 +0000 (09:17 +0200)]
tracing: React to error return from traceprobe_parse_event_name()
The function traceprobe_parse_event_name() may set the first two function
arguments to a non-null value and still return -EINVAL to indicate an
unsuccessful completion of the function. Hence, it is not sufficient to
just check the result of the two function arguments for being not null,
but the return value also needs to be checked.
Commit 95c104c378dc ("tracing: Auto generate event name when creating a
group of events") changed the error-return-value checking of the second
traceprobe_parse_event_name() invocation in __trace_eprobe_create() and
removed checking the return value to jump to the error handling case.
Reinstate using the return value in the error-return-value checking.
Link: https://lkml.kernel.org/r/20220811071734.20700-1-lukas.bulwahn@gmail.com Fixes: 95c104c378dc ("tracing: Auto generate event name when creating a group of events") Acked-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Linus Torvalds [Sun, 21 Aug 2022 18:18:33 +0000 (11:18 -0700)]
Merge tag 'i2c-for-6.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"A revert to fix a regression introduced this merge window and a fix
for proper error handling in the remove path of the iMX driver"
* tag 'i2c-for-6.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: imx: Make sure to unregister adapter on remove()
Revert "i2c: scmi: Replace open coded device_get_match_data()"
Linus Torvalds [Sun, 21 Aug 2022 17:21:16 +0000 (10:21 -0700)]
Merge tag '6.0-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs client fixes from Steve French:
- memory leak fix
- two small cleanups
- trivial strlcpy removal
- update missing entry for cifs headers in MAINTAINERS file
* tag '6.0-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
cifs: move from strlcpy with unused retval to strscpy
cifs: Fix memory leak on the deferred close
cifs: remove useless parameter 'is_fsctl' from SMB2_ioctl()
cifs: remove unused server parameter from calc_smb_size()
cifs: missing directory in MAINTAINERS file
Nick Desaulniers [Fri, 19 Aug 2022 19:06:40 +0000 (12:06 -0700)]
asm goto: eradicate CC_HAS_ASM_GOTO
GCC has supported asm goto since 4.5, and Clang has since version 9.0.0.
The minimum supported versions of these tools for the build according to
Documentation/process/changes.rst are 5.1 and 11.0.0 respectively.
Remove the feature detection script, Kconfig option, and clean up some
fallback code that is no longer supported.
The removed script was also testing for a GCC specific bug that was
fixed in the 4.7 release.
Also remove workarounds for bpftrace using clang older than 9.0.0, since
other BPF backend fixes are required at this point.
i2c: imx: Make sure to unregister adapter on remove()
If for whatever reasons pm_runtime_resume_and_get() fails and .remove() is
exited early, the i2c adapter stays around and the irq still calls its
handler, while the driver data and the register mapping go away. So if
later the i2c adapter is accessed or the irq triggers this results in
havoc accessing freed memory and unmapped registers.
So unregister the software resources even if resume failed, and only skip
the hardware access in that case.
Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
Wolfram Sang [Thu, 18 Aug 2022 20:31:13 +0000 (22:31 +0200)]
Revert "i2c: scmi: Replace open coded device_get_match_data()"
This reverts commit 9ae551ded5ba55f96a83cd0811f7ef8c2f329d0c. We got a
regression report, so ensure this machine boots again. We will come back
with a better version hopefully.