10 Oct, 2022

2 commits


30 Sep, 2022

1 commit

  • This is the 5.15.71 stable release

    * tag 'v5.15.71': (144 commits)
    Linux 5.15.71
    ext4: use locality group preallocation for small closed files
    ext4: avoid unnecessary spreading of allocations among groups
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/net/phy/aquantia_main.c
    drivers/tty/serial/fsl_lpuart.c

    Jason Liu
     

28 Sep, 2022

11 commits

  • commit 1885ff13d4c42910b37a0e3f7c2f182520f4eed1 upstream.

    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.

    Signed-off-by: Callum Osmotherly
    Cc:
    Link: https://lore.kernel.org/r/YyMjQO3mhyXlMbCf@piranha
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Callum Osmotherly
     
  • commit ba1f818053b0668a1ce2fe86b840e81b592cc560 upstream.

    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.

    Add a quirk to use the same DAC pairs as the G14.

    Signed-off-by: Luke D. Jones
    Cc:
    Link: https://lore.kernel.org/r/20220915080921.35563-4-luke@ljones.dev
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Luke D. Jones
     
  • commit bc2c23549ccd7105eb6ff0d4f0ac519285628673 upstream.

    Fixes up the pincfg for ASUS ROG Strix G15 (G533Z) headphone combo jack

    [ Fixed the position in the quirk table by tiwai ]

    Signed-off-by: Luke D. Jones
    Cc:
    Link: https://lore.kernel.org/r/20220915080921.35563-3-luke@ljones.dev
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Luke D. Jones
     
  • commit c611e659044168e7abcbae8ba1ea833521498fbb upstream.

    Fixes up the pincfg for ASUS ROG Strix G513 headphone and mic combo jack

    [ Fixed the position in the quirk table by tiwai ]

    Signed-off-by: Luke D. Jones
    Cc:
    Link: https://lore.kernel.org/r/20220915080921.35563-2-luke@ljones.dev
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Luke D. Jones
     
  • commit b16c8f229a58eaddfc58aab447253464abd3c85e upstream.

    A few entries have been mistakenly inserted in wrong positions without
    considering the SSID ordering. Place them at right positions.

    Fixes: b7557267c233 ("ALSA: hda/realtek: Add quirk for ASUS GA402")
    Fixes: 94db9cc8f8fa ("ALSA: hda/realtek: Add quirk for ASUS GU603")
    Fixes: 739d0959fbed ("ALSA: hda: Add quirk for ASUS Flow x13")
    Cc:
    Link: https://lore.kernel.org/r/20220915154724.31634-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit bdc9b7396f7d4d6533e70fd8d5472f505b5ef58f upstream.

    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.

    Signed-off-by: Callum Osmotherly
    Cc:
    Link: https://lore.kernel.org/r/YyGbWM5wEoFMbW2v@piranha
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Callum Osmotherly
     
  • commit cbcdf8c4d35cd74aee8581eb2f0453e0ecab7b05 upstream.

    Fixes headphone and headset microphone detection on Huawei WRT-WX9.

    Signed-off-by: huangwenhui
    Cc:
    Link: https://lore.kernel.org/r/20220913054622.15979-1-huangwenhuia@uniontech.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    huangwenhui
     
  • commit 4d40ceef4745536289012670103c59264e0fb3ec upstream.

    Handle 0x3b57 variant with same AZX_DCAPS_INTEL_PCH_NOPM
    capabilities as 0x3b56. In practise this allow use of HDMI/DP
    display audio via i915.

    BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/2751
    Signed-off-by: Kai Vehmanen
    Cc:
    Link: https://lore.kernel.org/r/20220912183716.2126312-1-kai.vehmanen@linux.intel.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Kai Vehmanen
     
  • commit 3c4d8c24fb6c44f426e447b04800b0ed61a7b5ae upstream.

    Reduce the suspend time by setting depop delay to 10ms for
    tegra.

    Signed-off-by: Mohan Kumar
    Cc:
    Link: https://lore.kernel.org/r/20220913053641.23299-1-mkumard@nvidia.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Mohan Kumar
     
  • commit c3afa2a402d1ecefa59f88d55d9e765f52f75bd9 upstream.

    During the code change to add the support for devres-managed card
    instance, we put an explicit kfree(card) call at the error path in
    snd_card_new(). This is needed for the early error path before the
    card is initialized with the device, but is rather superfluous and
    causes a double-free at the error path after the card instance is
    initialized, as the destructor of the card object already contains a
    kfree() call.

    This patch fixes the double-free situation by removing the superfluous
    kfree(). Meanwhile we need to call kfree() explicitly for the early
    error path, so it's added there instead.

    Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation")
    Reported-by: Rondreis
    Cc:
    Link: https://lore.kernel.org/r/CAB7eexL1zBnB636hwS27d-LdPYZ_R1-5fJS_h=ZbCWYU=UPWJg@mail.gmail.com
    Link: https://lore.kernel.org/r/20220919123516.28222-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 79764ec772bc1346441ae1c4b1f3bd1991d634e8 upstream.

    This reverts commit ff878b408a03bef5d610b7e2302702e16a53636e.

    Unfortunately the recent fix seems bringing another regressions with
    PulseAudio / pipewire, at least for Steinberg and MOTU devices.

    As a temporary solution, do a straight revert. The issue for Android
    will be revisited again later by another different fix (if any).

    Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
    Cc:
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216500
    Link: https://lore.kernel.org/r/20220920113929.25162-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     

27 Sep, 2022

1 commit

  • This is the 5.15.70 stable release

    * tag 'v5.15.70': (2444 commits)
    Linux 5.15.70
    ALSA: hda/sigmatel: Fix unused variable warning for beep power change
    cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    arch/arm/boot/dts/imx6ul.dtsi
    arch/arm/mm/mmu.c
    arch/arm64/boot/dts/freescale/imx8mp-evk.dts
    drivers/gpu/drm/imx/dcss/dcss-kms.c
    drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
    drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h
    drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
    drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
    drivers/soc/fsl/Kconfig
    drivers/soc/imx/gpcv2.c
    drivers/usb/dwc3/host.c
    net/dsa/slave.c
    sound/soc/fsl/imx-card.c

    Jason Liu
     

23 Sep, 2022

4 commits

  • commit 51bdc8bb82525cd70feb92279c8b7660ad7948dd upstream.

    The newly added stac_check_power_status() caused a compile warning
    when CONFIG_SND_HDA_INPUT_BEEP is disabled. Fix it.

    Fixes: 414d38ba8710 ("ALSA: hda/sigmatel: Keep power up while beep is enabled")
    Reported-by: kernel test robot
    Link: https://lore.kernel.org/r/20220905130630.2845-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • [ Upstream commit 8d44e6044a0e885acdd01813768a0b27906d64fd ]

    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.

    Signed-off-by: Mohan Kumar
    Link: https://lore.kernel.org/r/20220905172420.3801-1-mkumard@nvidia.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Mohan Kumar
     
  • [ Upstream commit 414d38ba871092aeac4ed097ac4ced89486646f7 ]

    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.

    Link: https://bugzilla.suse.com/show_bug.cgi?id=1200544
    Link: https://lore.kernel.org/r/20220904072750.26164-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Takashi Iwai
     
  • [ Upstream commit 5628560e90395d3812800a8e44a01c32ffa429ec ]

    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.

    Signed-off-by: Takashi Iwai
    Link: https://lore.kernel.org/r/20220823081000.2965-3-tiwai@suse.de
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin

    Takashi Iwai
     

15 Sep, 2022

10 commits

  • commit 5c5c2baad2b55cc0a4b190266889959642298f79 upstream.

    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.

    Fixes: 06ca24e98e6b ("ASoC: mchp-spdiftx: add driver for S/PDIF TX Controller")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1686
    Link: https://github.com/llvm/llvm-project/commit/82afc9b169a67e8b8a1862fb9c41a2cd974d6691
    Signed-off-by: Nathan Chancellor
    Reviewed-by: Nick Desaulniers
    Link: https://lore.kernel.org/r/20220810010809.2024482-1-nathan@kernel.org
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Nathan Chancellor
     
  • commit 403fcb5118a0f4091001a537e76923031fb45eaf upstream.

    Remove references to struct mchp_i2s_caps as they are not used.

    Signed-off-by: Claudiu Beznea
    Link: https://lore.kernel.org/r/20220727090814.2446111-3-claudiu.beznea@microchip.com
    Signed-off-by: Mark Brown
    Cc: Nathan Chancellor
    Signed-off-by: Greg Kroah-Hartman

    Claudiu Beznea
     
  • [ Upstream commit 2027f114686e0f3f1f39971964dfc618637c88c2 ]

    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.

    Fixes: b70038ef4fea ("ALSA: usb-audio: Add delayed_register option")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082
    Link: https://lore.kernel.org/r/20220831125901.4660-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Takashi Iwai
     
  • [ Upstream commit 7e1afce5866e02b45bf88c27dd7de1b9dfade1cc ]

    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.

    Fixes: a4aad5636c72 ("ALSA: usb-audio: Inform devices that need delayed registration")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082
    Link: https://lore.kernel.org/r/20220831125901.4660-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Takashi Iwai
     
  • [ Upstream commit c6e14bb9f50df7126ca64405ae807d8bc7b39f9a ]

    Add missing module owner to able to build and load this driver as module.

    Fixes: aa2e2785545a ("ASoC: qcom: sm8250: add sound card qrb5165-rb5 support")
    Signed-off-by: Srinivas Kandagatla
    Link: https://lore.kernel.org/r/20220816165229.7971-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin

    Srinivas Kandagatla
     
  • commit e53f47f6c1a56d2af728909f1cb894da6b43d9bf upstream.

    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.

    Fix this by checking the number of interfaces.

    Signed-off-by: Dongxiang Ke
    Link: https://lore.kernel.org/r/20220906024928.10951-1-kdx.glider@gmail.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Dongxiang Ke
     
  • commit ff878b408a03bef5d610b7e2302702e16a53636e upstream.

    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.

    Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
    Cc:
    Reported-by: chihhao chen
    Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
    Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 3e48940abee88b8dbbeeaf8a07e7b2b6be1271b3 upstream.

    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.

    Signed-off-by: Pattara Teerapong
    Cc:
    Link: https://lore.kernel.org/r/20220901144036.4049060-1-pteerapong@chromium.org
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Pattara Teerapong
     
  • commit d29f59051d3a07b81281b2df2b8c9dfe4716067f upstream.

    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:

    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

    Signed-off-by: Tasos Sahanidis
    Cc:
    Link: https://lore.kernel.org/r/3707dcab-320a-62ff-63c0-73fc201ef756@tasossah.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Tasos Sahanidis
     
  • commit 8423f0b6d513b259fdab9c9bf4aaa6188d054c2d upstream.

    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.

    Reported-and-tested-by: butt3rflyh4ck
    Reviewed-by: Jaroslav Kysela
    Cc:
    Link: https://lore.kernel.org/r/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA@mail.gmail.com
    Link: https://lore.kernel.org/r/20220905060714.22549-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     

08 Sep, 2022

5 commits

  • commit 3e7e04b747adea36f349715d9f0998eeebf15d72 upstream.

    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.

    Reported-by: Abhishek Shah
    Cc:
    Link: https://lore.kernel.org/r/CAEHB24_ay6YzARpA1zgCsE7=H9CSJJzux618E=Ka4h0YdKn=qA@mail.gmail.com
    Link: https://lore.kernel.org/r/20220823072717.1706-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 22dec134dbfa825b963f8a1807ad19b943e46a56 upstream.

    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.

    Reported-by: Abhishek Shah
    Cc:
    Link: https://lore.kernel.org/r/CAEHB2493pZRXs863w58QWnUTtv3HHfg85aYhLn5HJHCwxqtHQg@mail.gmail.com
    Link: https://lore.kernel.org/r/20220823072717.1706-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit a2d57ebec1e15f0ac256eb8397e82b07adfaaacc upstream.

    Magic initialization sequence was extracted from Windows driver and
    cleaned up manually.

    Fixes internal speakers output.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=207423
    Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518
    Signed-off-by: Kacper Michajłow
    Cc:
    Link: https://lore.kernel.org/r/20220827203328.30363-1-kasper93@gmail.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Kacper Michajłow
     
  • [ Upstream commit 2e6481a3f3ee6234ce577454e1d88aca55f51d47 ]

    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).

    Fixes: a864e8f159b13 ("ALSA: hda: intel-nhlt: verify config type")
    Signed-off-by: Peter Ujfalusi
    Reviewed-by: Pierre-Louis Bossart
    Reviewed-by: Jaska Uimonen
    Link: https://lore.kernel.org/r/20220823122405.18464-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Peter Ujfalusi
     
  • [ Upstream commit 6376ab02374822e1e8758a848ee736a182786a2e ]

    The module and function information can be added with
    'modprobe foo dyndbg=+pmf'

    Suggested-by: Greg KH
    Signed-off-by: Pierre-Louis Bossart
    Reviewed-by: Ranjani Sridharan
    Reviewed-by: Péter Ujfalusi
    Reviewed-by: Bard Liao
    Link: https://lore.kernel.org/r/20220616220559.136160-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Pierre-Louis Bossart
     

05 Sep, 2022

2 commits

  • [ Upstream commit c75ed9f54ce8d349fee557f2b471a4d637ed2a6b ]

    We usually do cleanup in reverse order of init. Currently in case of
    error rz_ssi_release_dma_channels() done in the reverse order. This
    patch improves error handling in rz_ssi_probe() error path.

    While at it, use "goto cleanup" style to reduce code duplication.

    Reported-by: Pavel Machek
    Signed-off-by: Biju Das
    Link: https://lore.kernel.org/r/20220728092612.38858-1-biju.das.jz@bp.renesas.com
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin

    Biju Das
     
  • commit 5f3d9e8161bb8cb23ab3b4678cd13f6e90a06186 upstream.

    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.

    Reported-by: Lennert Van Alboom
    Cc:
    Link: https://lore.kernel.org/r/T3VPXtCc4uFws9Gfh2RjX6OdwM1RqfC6VqQr--_LMDyB2x5N3p9_q6AtPna17IXhHwBtcJVdXuS80ZZSCMjh_BafIbnzJPhbrkmhmWS6DlI=@vanalboom.org
    Link: https://lore.kernel.org/r/20220828074143.14736-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     

25 Aug, 2022

4 commits

  • [ Upstream commit 4a971e84a7ae10a38d875cd2d4e487c8d1682ca3 ]

    For avoiding the potential deadlock via kill_fasync() call, use the
    new fasync helpers to defer the invocation from the control API. Note
    that it's merely a workaround.

    Another note: although we haven't received reports about the deadlock
    with the control API, the deadlock is still potentially possible, and
    it's better to align the behavior with other core APIs (PCM and
    timer); so let's move altogether.

    Link: https://lore.kernel.org/r/20220728125945.29533-5-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Takashi Iwai
     
  • [ Upstream commit 95cc637c1afd83fb7dd3d7c8a53710488f4caf9c ]

    For avoiding the potential deadlock via kill_fasync() call, use the
    new fasync helpers to defer the invocation from PCI API. Note that
    it's merely a workaround.

    Reported-by: syzbot+1ee0910eca9c94f71f25@syzkaller.appspotmail.com
    Reported-by: syzbot+49b10793b867871ee26f@syzkaller.appspotmail.com
    Reported-by: syzbot+8285e973a41b5aa68902@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20220728125945.29533-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Takashi Iwai
     
  • [ Upstream commit ef34a0ae7a2654bc9e58675e36898217fb2799d8 ]

    Currently the call of kill_fasync() from an interrupt handler might
    lead to potential spin deadlocks, as spotted by syzkaller.
    Unfortunately, it's not so trivial to fix this lock chain as it's
    involved with the tasklist_lock that is touched in allover places.

    As a temporary workaround, this patch provides the way to defer the
    async signal notification in a work. The new helper functions,
    snd_fasync_helper() and snd_kill_faync() are replacements for
    fasync_helper() and kill_fasync(), respectively. In addition,
    snd_fasync_free() needs to be called at the destructor of the relevant
    file object.

    Link: https://lore.kernel.org/r/20220728125945.29533-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Takashi Iwai
     
  • [ Upstream commit ef30911d3c39fd57884c348c29b9cbff88def155 ]

    Before, ssiu.c didn't care SSI5-8, thus,
    commit b1384d4c95088d0 ("ASoC: rsnd: care default case on
    rsnd_ssiu_busif_err_status_clear()") cares it for status clear.

    But we should care it for error irq handling, too.
    This patch cares it.

    Reported-by: Nguyen Bao Nguyen
    Reported-by: Nishiyama Kunihiko
    Signed-off-by: Kuninori Morimoto
    Link: https://lore.kernel.org/r/871quocio1.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin

    Kuninori Morimoto