linux-kernel - Re: [PATCH 1/2] ALSA: hda: cs35l41: Add fixups 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] [day] [month] [year] [list]

Message-ID: <SY4P282MB183523435D04E3075195C003E035A@SY4P282MB1835.AUSP282.PROD.OUTLOOK.COM>
Date:   Sat, 15 Jul 2023 10:40:36 +0800
From:   David Xu <xuwd1@...mail.com>
To:     luke@...nes.dev
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,
        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 1/2] ALSA: hda: cs35l41: Add fixups for machines without a valid ACPI _DSD

Hi Luke,

Thank you for replying. 

> I tried with the patch applied and what I thought was correct setup 
> (in driver):
> 1. without my DSD table additions (in acpi)
> 2. With the CS part added (in acpi)
> 3. With my full DSD table added (in acpi)
> 
> all 3 instances failed with:
> 
> cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: OTP Boot status 80000000 
> error: 0
> cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.0 failed with error 
> -5

I see that you have some problem on making a working fixup table entry,
with your key concern being the three fields you pointed out:

> The key thing I am concerned about is how the values for the 
> following are gained:
> + .reset_gpio_idx = {0, 0},
> + .reset_gpio_flags = {GPIOD_OUT_LOW, GPIOD_OUT_LOW},
> + .spkid_gpio_idx = {1, 1},

As I could see you have written an incorrect fixup entry when compared 
with the ACPI patch you provided:

1. For the .reset_gpio_idx field, from your ACPI patch:
>  Package () { "reset-gpios", Package () {
>      SPK1, One, Zero, Zero,
>      SPK1, One, Zero, Zero
>  } },
for your machine, the index of the reset GpioIo resource is 1, which 
means the correct form would be .reset_gpio_idx = {1, 1}. You could 
find this index by looking for the GpioIo resource descriptor that has 
a "IoRestrictionOutputOnly" IORestriction argument in your ACPI 
CSC3551 _CRS method, and I suppose this reset gpio should has the only 
GpioIo descriptor with this "IoRestrictionOutputOnly" argument. 
Besides, having taking this into consideration, the error you get is
probably due to a incorrect reset.

2. For the value of .reset_gpio_flags, it needs more or less some 
guessing: it's common for chips to have their reset to be pin active 
low and this polarity can also be checked by reading the gpio resource
buffer with kernel acpica infrastructures. Anyway, I think for most 
cases, .reset_gpio_flags = {GPIOD_OUT_LOW, GPIOD_OUT_LOW} is good.

3. For the value of .spkid_gpio_idx, by investigating the CSC3551 
ACPI _CRS method and the driver code, my shallow thought is that it 
has 3 pins, with one being the reset pin which we have dealt with, 
one being the interrupt pin, which usually is declared with "GpioInt"
if the pin is connected to PCH GPIO and is considered to be one of 
the cs35l41's configurable GPIO, and another one configurable GPIO 
whose function is usually assigned with "VSPK_SWITCH". For the 
spkid to be honest I still have not figured out how it was designed.
I suspect that the spkid gpio is acually a reused funcion of one 
of the three gpios I mentioned. From the driver implementation, 
the .spkid_gpio_idx field should be the index of the GpioIo
resource descriptor in the _CRS returned buffer. However also from
the implementation of the driver, whether this field is configured
correctly should not be the major factor affecting if the speakers
would work, it only affects the selection of the cs35l41 firmware.
Anyway, from your working ACPI patch:

>  Package () { "spk-id-gpios", Package () {
>      SPK1, 0x02, Zero, Zero,
>      SPK1, 0x02, Zero, Zero
>  } },

you may try setting .spkid_gpio_idx = {2, 2}. If that still does
not work you could try setting .spkid_gpio_idx = {-1, -1}, and this 
would make the driver try to find the "spk-id-gpios" package from
the ACPI table. (however even though you did not provide this by
patching the ACPI table and it fails to get it, the driver still
should not fail.)

Please try to modify the fixup entry as the advice above to see if
it works. If still not, feel free to futher reply me, and I think
it would be very beneficial for me to help solving your problem 
if you could post your orignial CSC3551 ACPI table.