linux-kernel - Re: CSC3551 and devices missing related

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]
Message-ID: <87jzx3zaf8.wl-tiwai@suse.de>
Date:   Sat, 20 May 2023 10:14:51 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Luke Jones <luke@...nes.dev>
Cc:     linux-kernel@...r.kernel.org, tiwai@...e.com,
        sbinding@...nsource.cirrus.com, perex@...ex.cz,
        tangmeng@...ontech.com, andy.chi@...onical.com, p.jungkamp@....net,
        kasper93@...il.com, yangyuchi66@...il.com, armas@...ux.tech,
        ealex95@...il.com, james.schulman@...rus.com,
        david.rhodes@...rus.com, tanureal@...nsource.cirrus.com,
        rf@...nsource.cirrus.com, patches@...nsource.cirrus.com,
        alsa-devel@...a-project.org
Subject: Re: CSC3551 and devices missing related _DSD bits

On Fri, 19 May 2023 00:26:22 +0200,
Luke Jones wrote:
> 
> Hi Takashi (and all others),
> 
> We're beginning to encounter more and more laptops from ASUS in the ROG range 
> where the bass speakers are connected to a cirrus amp, and the driver for 
> cirrus is unable to pick this up due to being missing a _DSD section in the 
> ACPI (SSDT). I've emailed engineers at ASUS I have contact with about this but 
> it is unlikely that we will see corrections for each and every model + variant 
> they have. The models we have seen so far are:
> - GX650P
> - GU604V
> - GA402X
> And there have been numerous forum postings in various places with the exact 
> same issue for other models from ASUS that are not in the ROG group I deal 
> with - oh and also some Lenovo and HP devices also.
> 
> Some of the logs are:
> 
> [    5.542312] Serial bus multi instantiate pseudo device driver CSC3551:00: 
> Instantiated 2 I2C devices.
> [    5.717261] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD 
> Properties are missing for HID CSC3551.
> [    5.717269] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL: 
> Platform not supported
> [    5.717286] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with 
> error -22
> [    5.717734] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD 
> Properties are missing for HID CSC3551.
> [    5.717737] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL: 
> Platform not supported
> [    5.717750] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with 
> error -22
> 
> and:
> 
> [    3.343851] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD 
> Properties are missing for HID CSC3551.
> [    3.343854] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: error -EINVAL: 
> Platform not supported
> [    3.343855] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.0 failed with 
> error -22
> [    3.345544] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD 
> Properties are missing for HID CSC3551.
> [    3.345546] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.1: error -EINVAL: 
> Platform not supported
> [    3.345548] cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.1 failed with 
> error -22
> 
> So there are SPI connected, and I2C connected.
> 
> Alex has already submitted the related patch_realtek work for the GU604V and 
> no doubt there will be some follow up patches from myself or others for the 
> other models. Alex has attempted to patch the Cirrus related parts in kernel 
> direct with:
> 1. https://github.com/bno1/linux-xanmod-gu604/blob/acpi-hack/
> patch03_gu604v_speaker_acpi_hack.patch
> 2. https://github.com/bno1/linux-xanmod-gu604/blob/acpi-hack/
> patch04_gu604v_spi_cs_gpio_hack.patch
> both of these patches have been tested and working for over a week.
> 
> >From what I see the patch04_gu604v_spi_cs_gpio_hack patch needs to shift to 
> the cirrus driver sound/pci/hda/cs35l41_hda.c, and that driver must now have a 
> quirk table - unless we can somehow add the cirrus related bits to the realtek 
> code? I've personally not played with this beyond keeping an eye on it all and 
> am reluctant to begin work on a solution until I've had some input on the 
> direction it should take.
> 
> In any case, this is not an isolated issue and we could benefit from putting 
> in place some quirk or similar to accommodate for laptops where the vendor for 
> some reason does not include the _DSD parts for use with the cirrus driver. 
> The trend is looking so far like this practice will continue regardless of the 
> vendor.
> 
> Known reports:
> - https://bugzilla.kernel.org/show_bug.cgi?id=216194
> - https://www.spinics.net/lists/alsa-devel/msg146434.html
> - https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff
> - https://forums.linuxmint.com/viewtopic.php?t=392762
> - https://h30434.www3.hp.com/t5/Notebook-Operating-System-and-Recovery/Envy-x360-2022-13-b0074TU-Audio-not-working-in-Linux-Fedora/td-p/8644641

The problem is that this can really easily blow up your machine if
some incorrect bit is applied.  And more easily applicable, more
chance to break by novice users, simply by believing what a chat bot
speaks :)
That's the very reason why this kind of change should be via ACPI
table officially set up by the vendor.  That said, the question is
only who and how can be responsible for this kind of change.  It's
no technical issue, per se.

If BIOS can't be updated, at least, the configuration change has to be
confirmed by ASUS people.  If ASUS still ignores the inquires and
requests, we may put the quirk but with a bit fat warning (and maybe
complaints to ASUS) to be shown in the log as a very last resort.

Let's see what happens.


thanks,

Takashi