linux-kernel - Re: [PATCH 0/2] Fix CSC3551 speaker sound problem for machines without a valid ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 17 Jul 2023 22:14:17 +0800
From:   David Xu <xuwd1@...mail.com>
To:     tiwai@...e.de
Cc:     alsa-devel@...a-project.org, andy.chi@...onical.com,
        david.rhodes@...rus.com, james.schulman@...rus.com,
        kasper93@...il.com, linux-kernel@...r.kernel.org, luke@...nes.dev,
        p.jungkamp@....net, patches@...nsource.cirrus.com, perex@...ex.cz,
        rf@...nsource.cirrus.com, ruinairas1992@...il.com,
        sbinding@...nsource.cirrus.com, tcrawford@...tem76.com,
        tiwai@...e.com, xuwd1@...mail.com, yangyingliang@...wei.com,
        yangyuchi66@...il.com
Subject: Re: [PATCH 0/2] Fix CSC3551 speaker sound problem for machines without a valid ACPI _DSD

Hi Takashi,

On Sun, 16 Jul 2023 14:49:18 +0200 you wrote:

> Thanks for the patches.
> 
> I've seen the lots of pains with CS35L41 codec stuff on the recent
> machines.  But, first of all, it still needs to be agreed by Cirrus
> people whether this approach is acceptable.  Judging from the current 
> situation, such workaround appears inevitable, but we need a
> consensus.
> 
> So, Cirrus people, please check this.

Agreed.
 
> Also, some ideas about the current patch set:
> 
> - Do we need yet another listing and check of each ID in another
>   place?  The existing entry in the SSID quirk table is already unique
>   enough to identify which configuration is taken, I suppose.
>
> - The quirk entries can be gathered in patch_realtek.c, and the hw_cfg
>   and other items are overwritten in cs35l41_no_acpi_dsd() when no
>   _DSD is found.  In that way, we can avoid fixing two places for each
>   update.

I do have noticed that the existing entries in patch_realtek.c are enough
for locating the right quirk. However I'm unsure if these entries can 
be moved to that file since the cs35l41 i2c/spi devices are instantiated
by the serial-multi-instantiate driver, and if no proper _DSD is found 
the cs35l41 driver would just fail with no corresponding i2c/spi devices.
I don't know if it is possible for the hda driver to intervene this 
probing process.


> - The workaround is a workaround, and it's fundamentally dangerous.
>   We should warn it in a kernel message.

Agreed. I will update my patches to emit a warning message, however as
Stuart has replied, a patch series which is cleaner is on its way in few 
weeks and I would not submit a new version for now. I am looking forward 
to Cirrus's work. 

Regards,

David.