Comment 761 for bug 1958019

The name doesn't matter, just the numeric ID. If I had a patch worth
submitting, I would fix the names but otherwise they don't matter.

Please share the following outputs with me:
uname -a

And mostly I need this:
dmesg | egrep -i '(csc3551|cs35l41|reset_gpio|short|adev|speaker)'

On 2/28/23 23:47, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #745 from Pierre Hébert (<email address hidden>) ---
> Yes, I confirm that the patch includes the slim 7 in the list of fixups, with
> the right "16IAH7" model number and right numeric id: 0x17aa:0x3803 (same as
> my
> alsa-info), so I thought there was some success for this computer. But
> rewinding the discussion to the top in this thread and the other one
> (https://bugzilla.kernel.org/show_bug.cgi?id=216194) doesn't show any
> evidence
> of success for the "slim" variant. Or maybe I missed it?
> I noticed that the clear text name for the entry in the patch is named
> "Legion
> 7" not "Legion S7". Maybe there's some mismatch here? I mean: could the slim
> references have been used in place of another model, maybe another 7 variant?
> Lenovo's naming scheme is confusing: there's the 7, the 7i, the 7 Pro and the
> S7 which is either named S7 (without "i" no matter Intel or AMD) or Slim 7
> (only AMD) or Slim 7i (only Intel).
>
> I understand the issue with DSD and why it's frustrating. This isn't by far
> the
> first frustration I get with this kind of issue... But fortunately these
> little
> issues are more than balanced by the benefits of running Linux :-)
>
> Using 6.2.1 on my slim 7i (16IAH7), the cs35l41 driver fails to load. If my
> understanding is correct, this will prevent code in the patch to be executed,
> even if some code paths in cs35l41 are bypassed by the patch, right? Please
> correct me if I'm wrong, as really I'm a newbie in this area.
>
> I'm 100% sure that the patch is applied though, but I don't see the related
> printk in the kernel log (in particular there is no "CSC3551: probing"). What
> I
> am trying to understand is whether this is because of the cs35l41 error, and
> in
> which case I should look into this issue first, or whether this is due to
> another problem.
>
> While unloading and reloading cs35l41 modules (snd_hda_scodec_cs35l41_i2c
> snd_hda_scodec_cs35l41_spi snd_hda_scodec_cs35l41 snd_soc_cs35l41_lib
> snd_hda_cs_dsp_ctls cs_dsp), there's no indication of the driver being
> initialized again in kernel logs, so my guess is that this is triggered by
> another sound module. Would you have any hint on a what should be done to
> unload/reload the sound subsystem and avoid reboot between each code
> modification/build?
>
> Thank you so far for the help and the patches. Even if I cannot ever hear
> sound
> from the speakers (and I can perfectly live with this), your work is really
> appreciated!
>
>
> (In reply to Cameron Berkenpas from comment #742)
>> You have the slim? I don't think I added slim support to the patch. I think
>> someone else did and it worked.
>>
>> It's not that hard to do. The numeric ID you need can be found in your
>> alsa-info.