[SRU][jammy][pull-request v3] alsa: enable the cirrus-logic side-codec to make the speaker output sound

Andrea Righi andrea.righi at canonical.com
Wed Mar 30 13:22:21 UTC 2022

On Thu, Mar 24, 2022 at 09:00:19PM +0800, Hui Wang wrote:
> In the v3:
> Dropped 17 patches which are fixing build errors for
> sound/asoc/codec/cs35l41*.c. Without those 17 patches, I did some change in
> the sound/asoc/codec/cs35l41*.c to make sure there are no failures when
> building them, and change the cherry-pick to backport in some patches.
> After dropping the 17 patches, this SRU is pretty clean now, it nearly
> doesn't change the existing APIs or functions, it only introduces new files
> or new functions in the existing files. It is safe to merge to jammy kernel
> And I also cleaned the annotations to fix the errors like "check-config:
> FAIL (m != -):..."
> BugLink: https://bugs.launchpad.net/bugs/1965496
> [Impact]
> We have a couple of lenovo latops models which have cirrus-logic side
> codec between realtek codec and speaker, it plays a role as amplifier,
> we need to enable this side-codec, otherwise the speaker can't output
> sound.
> [Fix]
> Backport codec patches and some i2c and acpi detection patches from
> mainline kernel and linux-next
> [Test]
> boot the patched kernel, run speaker test, both left and right channel
> could work well.
> [Where problems could occur]
> If it could introduce regression, it will be on soc wm_adsp codec
> drivers, since most of patch are adding new codec drivers, it will
> not touch existing codec drivers. If a machine with wm_adsp codec
> can't output sound or record sound, it means this SRU introduce
> the regression on wm_adsp driver, but this possibility is very
> low, since all patches are picked from mainline kernel.

Overall the code looks good, all the patches are pretty much clean
upstream cherry-picks (except for few backports, that are just context

However, this patch set is quite big:

  27 files changed, 5234 insertions(+), 222 deletions(-)

Even if it's mostly stand-alone code my question is... who is going to
maintain this code? Because we're not getting fixes via stable updates,
so I guess we should actively track the upstream changes for this codec
(especially potential security-related fixes).

Mostly for this reason I'm a bit skeptical about maintaining this code
directly in jammy/linux. However, if someone is taking care of actively
checking for upstream changes in this code and post backports to the
mailing list then I can definitely send my ACK.


More information about the kernel-team mailing list