IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Currently us428ctls_shmem pages are allocated dynamically upon the
mmap call, but this is quite racy. Since the shared memory itself is
mandatory for the mmap, let's allocate it at the beginning of the card
initialization. Also, fix the initialization of the wait queue, too.
Link: https://lore.kernel.org/r/20210517131545.27252-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PCM shmem pages are allocated in snd_usx2y_usbpcm_prepare().
Theoretically the prepare callback may be called simultaneously for
both playback and capture, hence this allocation can be racy.
Make sure that the allocation is performed exclusively by extending
the pcm_mutex lock to cover the allocation code, too.
Link: https://lore.kernel.org/r/20210517131545.27252-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Theoretically the initialization functions in usx2y drivers may be
called multiple times as the driver gets initialized via hwpdep
ioctl. Meanwhile, those functions including memory allocations don't
check whether they are called twice, and they forget the old
resources, which would lead to memory leaks.
This patch adds the sanity checks about the doubly initializations to
give kernel WARNING, and returns an error in such a case. Also, each
allocation assures to release the resources at its error path
properly.
Link: https://lore.kernel.org/r/20210517131545.27252-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The initialization os usx2y driver is multi-staged, and the PCM and
other device creations are done after the DSP is loaded and
initialized. Upon the initialization, when an error happens, the
driver tries to call snd_card_free(). But this is dangerous, and in
general, the driver cannot kill itself during its operation.
Hence better to drop the snd_card_free() call from there.
Link: https://lore.kernel.org/r/20210517131545.27252-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
usx2y drivers may expose the allocated pages via mmap, but it performs
zero-clear only for the struct size, not aligned with the page size.
This leaves out some uninitialized trailing bytes.
This patch fixes the clearance to cover all memory that are exposed to
user-space.
Link: https://lore.kernel.org/r/20210517131545.27252-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch fixes various trivial coding-style issues in usx2y code,
such as:
* the assginments in if condition
* comparison order with constants
* NULL / zero checks
* unsigned -> unsigned int
* addition of braces in control blocks
* debug print with function names
* move local variables in block into function head
* reduction of too nested indentations
No functional changes.
Link: https://lore.kernel.org/r/20210517131545.27252-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch corrects merely the spaces in the usx2y code, including the
superfluous trailing space in the debug prints and a slight reformat
of some comment lines. Nothing really touches about the code itself.
Link: https://lore.kernel.org/r/20210517131545.27252-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For improving readability, convert camelCase fields, variables and
functions to the plain names with underscore. Also align the macros
to be capital letters.
All done via sed, no functional changes.
Note that you'll still see many coding style issues even after this
patch; the fixes will follow.
Link: https://lore.kernel.org/r/20210517131545.27252-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recently introduced MIDI endpoint parser code has an access to the
field without the size validation, hence it might lead to
out-of-bounce access. Add the sanity checks for the descriptor
sizes.
Fixes: eb596e0fd1 ("ALSA: usb-audio: generate midi streaming substream names from jack names")
Link: https://lore.kernel.org/r/20210511090500.2637-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent endpoint management change for implicit feedback mode added
a clearance of ep->sync_sink (formerly ep->sync_slave) pointer at
snd_usb_endpoint_stop() to assure no leftover for the feedback from
the already stopped capture stream. This turned out to cause a
regression, however, when full-duplex streams were running and only a
capture was stopped. Because of the above clearance of ep->sync_sink
pointer, no more feedback is done, hence the playback will stall.
This patch fixes the ep->sync_sink clearance to be done only after all
endpoints are released, for addressing the regression.
Reported-and-tested-by: Lucas Endres <jaffa225man@gmail.com>
Fixes: bf6313a0ff ("ALSA: usb-audio: Refactor endpoint management")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210426063349.18601-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Through the examinations and experiments with lots of Roland and BOSS
USB-audio devices, we found out that the recently introduced
full-duplex operations with the implicit feedback mode work fine for
quite a few devices, while the others need only the capture-side quirk
to enforce the full-duplex mode. The recent commit d86f43b17e
("ALSA: usb-audio: Add support for many Roland devices' implicit
feedback quirks") tried to add such quirk entries manually in the
lists, but this turned out to be too many and error-prone, hence it
was reverted again.
This patch is another attempt to cover those missing Roland/BOSS
devices but in a more generic way. It matches the devices with the
vendor ID 0x0582, and checks whether they are with both ASYNC sync
types or ASYNC is only for capture device. In the former case, it's
the device with the implicit feedback mode, and applies accordingly.
In both cases, the capture stream requires always the full-duplex
mode, and we apply the known capture quirk for that, too.
Basically the already existing BOSS device quirk entries become
redundant after this generic matching, so those are removed. Although
the capture_implicit_fb_quirks[] table became empty and superfluous, I
keep it for now, so that people can put a special device easily at any
time later again.
Link: https://lore.kernel.org/r/CAOsVg8rA61B=005_VyUwpw3piVwA7Bo5fs1GYEB054efyzGjLw@mail.gmail.com
Link: https://lore.kernel.org/r/20210414083255.9527-1-tiwai@suse.de
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212519
Tested-by: Lucas Endres <jaffa225man@gmail.com>
Link: https://lore.kernel.org/r/20210422120413.457-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit d86f43b17e ("ALSA: usb-audio: Add support for
many Roland devices' feedback quirks").
It turned out that many quirk entries there don't contain the proper
EP values and/or the quirk types, which lead to the broken
operations.
As we're going to cover all Roland/BOSS devices in a more generic way
rather the explicit lists, let's revert the previous additions at
first.
Fixes: d86f43b17e ("ALSA: usb-audio: Add support for many Roland devices' implicit feedback quirks")
Link: https://lore.kernel.org/r/20210422120413.457-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently when the call to usb_urb_ep_type_check fails (returning -EINVAL)
the error return path returns -ENOMEM via the exit label "error". Other
uses of the same error exit label set the err variable to -ENOMEM but this
is not being used. I believe the original intent was for the error exit
path to return the value in err rather than the hard coded -ENOMEM, so
return this rather than the hard coded -ENOMEM.
Addresses-Coverity: ("Unused value")
Fixes: 738d9edcfd ("ALSA: usb-audio: Add sanity checks for invalid EPs")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210420134719.381409-1-colin.king@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pioneer devices are supposed to be working with the implicit feedback
mode, but so far the attempt to apply the implicit feedback caused
issues, hence we explicitly skipped the implicit feedback mode for
them. Recently, Geraldo discovered that the device actually works if
you skip the generic matching of the sync EPs for the capture stream.
That is, we should apply the implicit feedback setup for the playback
like other similar devices, while we need to return 1 from
audioformat_capture_quirk() so that no further matching will be done.
And, later on, Olivia reported later that the fiddling with the
capture quirk alone doesn't suffice for the test with speaker-test
program. This seems to be a similar case like the recently fixed BOSS
devices. Indeed, the problem could be addressed by setting
playback_first flag, which indicates that the playback URBs have to be
sent out at first even in the implicit feedback mode.
This patch implements the application of the implicit feedback to
Pioneer devices as described in the above. The former
skip_pioneer_sync_ep() was dropped, and instead we provide
is_pioneer_implicit_fb() to check the Pioneer devices that need the
implicit feedback. In the audioformat_implicit_fb_quirk(), simply
apply the implicit fb for playback and set chip->playback_first flag
if matching, and in audioformat_capture_quirk()(), it returns 1 for
skipping the generic EP sync handling.
Reported-by: Geraldo <geraldogabriel@gmail.com>
Tested-by: Olivia Mackintosh <livvy@base.nu>
Link: https://lore.kernel.org/r/s5ha6pygqfz.wl-tiwai@suse.de
Link: https://lore.kernel.org/r/20210419153918.450-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
During the recent rewrite of the implicit feedback support, we've
tested to apply the implicit fb on BOSS devices, but it failed, as the
capture stream didn't start without the playback. As the end result,
it got another type of quirk for tying both streams but starts
playback always (commit 6234fdc1ce "ALSA: usb-audio: Quirk for BOSS
GT-001").
Meanwhile, Mike Oliphant has tested the real implicit feedback mode
for the playback again with the latest code, and found out that it
actually works if the initial feedback sync is skipped; that is, on
those BOSS devices, the playback stream has to be started at first
without waiting for the capture URB completions. Otherwise it gets
stuck. In the rest operations after the capture stream processed, we
can take them as the implicit feedback source.
This patch is an attempt to improve the support for BOSS devices with
the implicit feedback mode in the way described above. It adds a new
flag to snd_usb_audio, playback_first, indicating that the playback
stream starts without sync with the initial capture completion. This
flag is set in the quirk table with the new IMPLICIT_FB_BOTH type.
Reported-and-tested-by: Mike Oliphant <oliphant@nostatic.org>
Link: https://lore.kernel.org/r/20210414083255.9527-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
UA-101 device and co are supported by another driver, snd-ua101, but
the USB audio class driver (snd-usb-audio) catches all and this
resulted in the lack of functionality like missing MIDI devices.
This patch introduces a sort of deny-listing for those devices to just
return -ENODEV at probe in snd-usb-audio driver, so that it falls back
to the probe by snd-ua101.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212477
Link: https://lore.kernel.org/r/20210408075656.30184-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There are a few calls of usb_driver_claim_interface() but all of those
miss the proper error checks, as reported by Coverity. This patch
adds those missing checks.
Along with it, replace the magic pointer with -1 with a constant
USB_AUDIO_IFACE_UNUSED for better readability.
Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1475943 ("Error handling issues")
Addresses-Coverity-ID: 1475944 ("Error handling issues")
Addresses-Coverity-ID: 1475945 ("Error handling issues")
Fixes: b1ce7ba619 ("ALSA: usb-audio: claim autodetected PCM interfaces all at once")
Fixes: e5779998bf ("ALSA: usb-audio: refactor code")
Link: https://lore.kernel.org/r/202104051059.FB7F3016@keescook
Link: https://lore.kernel.org/r/20210406113534.30455-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: control - add generic LED API
This patchset tries to resolve the diversity in the audio LED
control among the ALSA drivers. A new control layer registration
is introduced which allows to run additional operations on
top of the elementary ALSA sound controls.
A new control access group (three bits in the access flags)
was introduced to carry the LED group information for
the sound controls. The low-level sound drivers can just
mark those controls using this access group. This information
is not exported to the user space, but user space can
manage the LED sound control associations through sysfs
(last patch) per Mark's request. It makes things fully
configurable in the kernel and user space (UCM).
The actual state ('route') evaluation is really easy
(the minimal value check for all channels / controls / cards).
If there's more complicated logic for a given hardware,
the card driver may eventually export a new read-only
sound control for the LED group and do the logic itself.
The new LED trigger control code is completely separated
and possibly optional (there's no symbol dependency).
The full code separation allows eventually to move this
LED trigger control to the user space in future.
Actually it replaces the already present functionality
in the kernel space (HDA drivers) and allows a quick adoption
for the recent hardware (ASoC codecs including SoundWire).
snd_ctl_led 24576 0
The sound driver implementation is really easy:
1) call snd_ctl_led_request() when control LED layer should be
automatically activated
/ it calls module_request("snd-ctl-led") on demand /
2) mark all related kcontrols with
SNDRV_CTL_ELEM_ACCESS_SPK_LED or
SNDRV_CTL_ELEM_ACCESS_MIC_LED
Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rear Mic on Lenovo P620 cannot record after S3, despite that there's no
error and the other two functions of the USB audio, Line In and Line
Out, work just fine.
The mic starts to work again after running userspace app like "alsactl
store". Following the lead, the evidence shows that as soon as connector
status is queried, the mic can work again.
So also check connector value on resume to "wake up" the USB audio to
make it functional.
This can be device specific, however I think this generic approach may
benefit more than one device.
Now the resume callback checks connector, and a new callback,
reset_resume, to also restore switches and volumes.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20210325165918.22593-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull sound fixes from Takashi Iwai:
"The majority of changes are various ASoC device/platform-specific
small fixes (including a removal of stale file) while the only common
change is a clk management fix in ASoC simple-card driver.
The rest are the usual HD-audio quirks"
* tag 'sound-5.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (44 commits)
ALSA: usb-audio: Fix unintentional sign extension issue
ALSA: hda/realtek: fix mute/micmute LEDs for HP 850 G8
ASoC: dt-bindings: fsl_spdif: Add compatible string for new platforms
ASoC: rt711: add snd_soc_component remove callback
ASoC: rt5659: Update MCLK rate in set_sysclk()
ASoC: simple-card-utils: Do not handle device clock
ALSA: hda/realtek: fix mute/micmute LEDs for HP 440 G8
ALSA: hda/realtek: fix mute/micmute LEDs for HP 840 G8
ALSA: hda/realtek: apply pin quirk for XiaomiNotebook Pro
ALSA: hda/realtek: Apply headset-mic quirks for Xiaomi Redmibook Air
ASoC: mediatek: mt8192: fix tdm out data is valid on rising edge
ALSA: dice: fix null pointer dereference when node is disconnected
ALSA: hda: generic: Fix the micmute led init state
ASoC: qcom: lpass-cpu: Fix lpass dai ids parse
spi: cadence: set cqspi to the driver_data field of struct device
ASoC: SOF: intel: fix wrong poll bits in dsp power down
ASoC: codecs: wcd934x: add a sanity check in set channel map
ASoC: qcom: sdm845: Fix array out of range on rx slim channels
ASoC: qcom: sdm845: Fix array out of bounds access
ASoC: remove remnants of sirf prima/atlas audio codec
...
The shifting of the u8 integer device by 24 bits to the left will
be promoted to a 32 bit signed int and then sign-extended to a
64 bit unsigned long. In the event that the top bit of device is
set then all then all the upper 32 bits of the unsigned long will
end up as also being set because of the sign-extension. Fix this
by casting device to an unsigned long before the shift.
Addresses-Coverity: ("Unintended sign extension")
Fixes: a07df82c79 ("ALSA: usb-audio: Add DJM750 to Pioneer mixer quirk")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210318132008.15266-1-colin.king@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
MODULE_SUPPORTED_DEVICE was added in pre-git era and never was
implemented. We can safely remove it, because the kernel has grown
to have many more reliable mechanisms to determine if device is
supported or not.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Other Plantronics headset models seem requiring the same workaround as
C320-M to add the 20ms delay for the control messages, too. Apply the
workaround generically for devices with the vendor ID 0x047f.
Note that the problem didn't surface before 5.11 just with luck.
Since 5.11 got a big code rewrite about the stream handling, the
parameter setup procedure has changed, and this seemed triggering the
problem more often.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1182552
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210304085009.4770-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rear audio on Lenovo ThinkStation P620 stops working after commit
1965c4364b ("ALSA: usb-audio: Disable autosuspend for Lenovo
ThinkStation P620"):
[ 6.013526] usbcore: registered new interface driver snd-usb-audio
[ 6.023064] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x0, type = 1
[ 6.023083] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, wIndex = 0x0, type = 4
[ 6.023090] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x0, type = 1
[ 6.023098] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, wIndex = 0x0, type = 4
[ 6.023103] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x0, type = 1
[ 6.023110] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, wIndex = 0x0, type = 4
[ 6.045846] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x0, type = 1
[ 6.045866] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, wIndex = 0x0, type = 4
[ 6.045877] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x0, type = 1
[ 6.045886] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, wIndex = 0x0, type = 4
[ 6.045894] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x0, type = 1
[ 6.045908] usb 3-6: cannot get ctl value: req = 0x81, wValue = 0x202, wIndex = 0x0, type = 4
I overlooked the issue because when I was working on the said commit,
only the front audio is tested. Apology for that.
Changing supports_autosuspend in driver is too late for disabling
autosuspend, because it was already used by USB probe routine, so it can
break the balance on the following code that depends on
supports_autosuspend.
Fix it by using usb_disable_autosuspend() helper, and balance the
suspend count in disconnect callback.
Fixes: 1965c4364b ("ALSA: usb-audio: Disable autosuspend for Lenovo ThinkStation P620")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210304043419.287191-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A number of devices have named substreams which are hard to remember /
decypher from <device> MIDI n names. Eg. Korg puts a pass through on
one substream and iConnectivity devices name the connections.
This makes it easier to connect to the correct device. Devices which
handle naming through quirks are unaffected by this change.
Addresses TODO comment in sound/usb/midi.c
Signed-off-by: George Harker <george@george-graphics.co.uk>
Link: https://lore.kernel.org/r/20210226212617.24616-1-george@george-graphics.co.uk
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent fix for the hw constraints for implicit feedback streams
via commit e4ea77f8e5 ("ALSA: usb-audio: Always apply the hw
constraints for implicit fb sync") added the check of the matching
endpoints and whether those EPs are already opened. This is needed
and correct, per se, even for the normal streams without the implicit
feedback, as the endpoint setup is exclusive.
However, it's reported that there seem applications that behave in
unexpected ways to update the hw_params without clearing the previous
setup via hw_free, and those hit a problem now: then hw_params is
called with still the previous EP setup kept, hence it's restricted
with the previous own setup. Although the obvious fix is to call
snd_pcm_hw_free() API in the application side, it's a kind of
unwelcome change.
This patch tries to ease the situation: in the endpoint check, we add
a couple of more conditions and now skip the endpoint that is being
used only by the stream in question itself. That is, in addition to
the presence check of ep (ep->cur_audiofmt is non-NULL), when the
following conditions are met, we skip such an ep:
- ep->opened == 1, and
- ep->cur_audiofmt == subs->cur_audiofmt.
subs->cur_audiofmt is non-NULL only if it's a re-setup of hw_params,
and ep->cur_audiofmt points to the currently set up parameters. So if
those match, it must be this stream itself.
Fixes: e4ea77f8e5 ("ALSA: usb-audio: Always apply the hw constraints for implicit fb sync")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211941
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210228080138.9936-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some USB audio firmware seem to report broken dB values for the volume
controls, and this screws up applications like PulseAudio who blindly
trusts the given data. For example, Edifier G2000 reports a PCM
volume from -128dB to -127dB, and this results in barely inaudible
sound.
This patch adds a sort of sanity check at parsing the dB values in
USB-audio driver and disables the dB reporting if the range looks
bogus. Here, we assume -96dB as the bottom line of the max dB.
Note that, if one can figure out that proper dB range later, it can be
patched in the mixer maps.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211929
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210227105737.3656-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
