Created attachment 300984 [details] Boot Dmesg Distribution: Manjaro CPU: Intel 12th gen i5-1240P Kernel version: 5.18-rc7 Problem Description: TLDR: I think ACPI device HID=CSC3551 should be supported with a new driver but dmesg shows: Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENODEV: failed to allocate SPI device CSC3551:00 from ACPI: -19 Is this a bug in the module? I've been working on getting internal speakers functional on Asus Zenbook UX3402ZA. After ruling out ALSA issues and ALC294 codec configuration, I found out this machine has two amp devices (Cirrus Logic CS35l41?) connected over SPI. These devices are declared under a single ACPI node with HID=CSC3551. I found a patch series for supporting this particular ACPI node in the LKML ( https://lore.kernel.org/lkml/20220121143254.6432-7-sbinding@opensource.cirrus.com/T/ ). It requires a special driver because declaring multiple SPI devices in one ACPI node was not previously supported. Looking at the Linux source, I believe this patch has been included in all the 5.18 release candidates. I've compiled rc7 and made sure to set the .config file to include the new module CONFIG_SERIAL_MULTI_INSTANTIATE=y. With this newly compiled kernel, I see this error in dmesg: Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENODEV: failed to allocate SPI device CSC3551:00 from ACPI: -19 Could this be a bug in the module? I'm not sure how to proceed from here. Any advice is appreciated. dmesg: Included as attachment ACPI dsdt.dsl Node: Scope (_SB.PC00.SPI0) { Device (SPK1) { Name (_HID, "CSC3551") // _HID: Hardware ID Name (_SUB, "10431E02") // _SUB: Subsystem ID Name (_UID, One) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (SBUF, ResourceTemplate () { SpiSerialBusV2 (0x0000, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x003D0900, ClockPolarityLow, ClockPhaseFirst, "\\_SB.PC00.SPI0", 0x00, ResourceConsumer, , Exclusive, ) SpiSerialBusV2 (0x0001, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x003D0900, ClockPolarityLow, ClockPhaseFirst, "\\_SB.PC00.SPI0", 0x00, ResourceConsumer, , Exclusive, ) GpioIo (Exclusive, PullUp, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPI0", 0x00, ResourceConsumer, , ) { // Pin list 0x0156 } GpioIo (Exclusive, PullDown, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPI0", 0x00, ResourceConsumer, , ) { // Pin list 0x0065 } GpioIo (Exclusive, PullDown, 0x0000, 0x0000, IoRestrictionInputOnly, "\\_SB.GPI0", 0x00, ResourceConsumer, , ) { // Pin list 0x0165 } GpioIo (Shared, PullUp, 0x0064, 0x0000, IoRestrictionInputOnly, "\\_SB.GPI0", 0x00, ResourceConsumer, , ) { // Pin list 0x0064 } GpioInt (Edge, ActiveBoth, Shared, PullUp, 0x0064, "\\_SB.GPI0", 0x00, ResourceConsumer, , ) { // Pin list 0x0064 } }) Return (SBUF) /* \_SB_.PC00.SPI0.SPK1._CRS.SBUF */ } Method (_STA, 0, NotSerialized) // _STA: Status { If ((AMPP == One)) { Return (0x0F) } Return (Zero) } Method (_DIS, 0, NotSerialized) // _DIS: Disable Device { } } }
*** Bug 216155 has been marked as a duplicate of this bug. ***
Guys, would you be able to test the latest vanilla (v5.19-rc5)? Just to be sure that the bug can be reproduced.
For the debugging, can you add these to lines #undef ENODEV #define ENODEV __LINE__ to drivers/spi/spi.c _after_ the inclusion block (all of those #include ...) and compile and try? It will set an error code to the line number, so we will see which one exactly failed.
Hi @Andy Shevchenko, I cannot boot with `v5.19-rc5`. Got black screen even with debug and without "rhgb quiet". But I try with `v5.19-rc4` and got this. [ 15.224358] Serial bus multi instantiate pseudo device driver CSC3551:00: error -2488: failed to allocate SPI device CSC3551:00 from ACPI: -2488 [ 15.228652] Serial bus multi instantiate pseudo device driver: probe of CSC3551:00 failed with error -2488
Okay, now you need in addition to the above replace -ENODEV by ret in line #2488 and try again. (I will send a patch upstream for that, but it won’t fix the issue, just helps us to debug)
Now it's like this [ 21.037999] Serial bus multi instantiate pseudo device driver CSC3551:00: error -2404: failed to allocate SPI device CSC3551:00 from ACPI: -2404 [ 21.038102] Serial bus multi instantiate pseudo device driver: probe of CSC3551:00 failed with error -2404
So, this line fails: https://elixir.bootlin.com/linux/v5.19-rc4/source/drivers/spi/spi.c#L2399 Can you double check that is true in your case? If so, it mean that by some reason we can't find registered SPI controller. You may add a debug print before this https://elixir.bootlin.com/linux/v5.19-rc4/source/drivers/spi/spi.c#L4224 dev_info(dev, "%s <--> %s\n", acpi_dev_name(ACPI_COMPANION(dev->parent)), acpi_dev_name(data)); Meanwhile can you attach file from `acpidump -o ux3402za.dat` or if there is known publicly available dump (GitHub?) share that link? P.S. Regarding booting v5.19-rc5, possible this thread will shed a light https://lore.kernel.org/all/272584304.305738.1657029005216@office.mailbox.org/
Created attachment 301369 [details] acpidump My `acpidump -o ux3402.dat`
Thanks, two more small files would be nice to have, i.e. output of: 1) lspci -nk -vv 2) grep -H 15 /sys/bus/acpi/devices/*/status
Created attachment 301371 [details] lspci -nk -vv lspci -nk -vv
Created attachment 301372 [details] grep -H 15 /sys/bus/acpi/devices/*/status grep -H 15 /sys/bus/acpi/devices/*/status
Couldn't get this line to work. dev_info(dev, "%s <--> %s\n", acpi_dev_name(ACPI_COMPANION(dev->parent)), acpi_dev_name(data)); I don't see any output of this line, tried with dev_err and dev_warn also nothing. May be it's not reach that function. or I miss something? P.S. Thanks for v5.19-rc5 link, I will have a look.
(In reply to Supasak Sutha from comment #12) > May be it's not reach that function. or I miss something? It maybe a clue actually. Can you replace this -ENODEV (should be failing line in your case, 2404) https://elixir.bootlin.com/linux/v5.19-rc4/source/drivers/spi/spi.c#L2401 with -EPROBE_DEFER and tell me if anything has been changed?
(In reply to Andy Shevchenko from comment #13) > (In reply to Supasak Sutha from comment #12) > > May be it's not reach that function. or I miss something? > It maybe a clue actually. Can you replace this -ENODEV (should be failing > line in your case, 2404) > https://elixir.bootlin.com/linux/v5.19-rc4/source/drivers/spi/spi.c#L2401 > with -EPROBE_DEFER and tell me if anything has been changed? [ 16.010854] i2c i2c-16: 8/8 memory slots populated (from DMI) [ 16.010860] i2c i2c-16: Systems with more than 4 memory slots not supported yet, not instantiating SPD [ 16.012665] spi_master spi0: device:79 <--> device:79 [ 16.013204] cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported -22 [ 16.013209] cs35l41-hda: probe of spi0-CSC3551:00-cs35l41-hda.0 failed with error -22 [ 16.013250] spi_master spi0: device:79 <--> device:79 [ 16.013614] cs35l41-hda spi0-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported -22 [ 16.013617] cs35l41-hda: probe of spi0-CSC3551:00-cs35l41-hda.1 failed with error -22 [ 16.013639] Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices. [ 16.030810] loop: module loaded [ 16.031498] loop0: detected capacity change from 0 to 228816 I also attached full dmesg.
Created attachment 301381 [details] dmesg after apply andy's comment#13 dmesg after apply andy's comment#13.
(In reply to Supasak Sutha from comment #15) > Created attachment 301381 [details] > dmesg after apply andy's comment#13 Thanks! I have three news, one bad and two good: 1) (good) I'm quite sure the above link will fix your boot issues on v5.19-rc5; 2) (good) The last change with error code fixes serial multi-instantiate driver to probe the codecs, but... 3) (bad) something else is still wrong (or missing).
(In reply to Supasak Sutha from comment #15) > dmesg after apply andy's comment#13 Okay, can you comment out these two lines: https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda.c#L423 (Note it should an incremental change to all others, as you have done that way already) P.S. The SPI fix is on its way to Linus tree (accepted by SPI maintainer): https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/commit/?h=for-5.20&id=cdb0cc9379f1b4fa5ea3e0492bacf8008f3f4e5a
(In reply to Andy Shevchenko from comment #17) > P.S. The SPI fix is on its way to Linus tree (accepted by SPI maintainer): > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/commit/ > ?h=for-5.20&id=cdb0cc9379f1b4fa5ea3e0492bacf8008f3f4e5a Oops, wrong commit, here is the correct one: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/commit/?h=for-5.20&id=9c22ec4ac27bcc5a54dd406da168f403327a5b55
(In reply to Andy Shevchenko from comment #17) > (In reply to Supasak Sutha from comment #15) > Okay, can you comment out these two lines: > https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda. > c#L423 > > (Note it should an incremental change to all others, as you have done that > way already) One more thing, you may need to replace cs35l41->index = id == 0x40 ? 0 : 1; by cs35l41->index = id; https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda.c#L462
Actually I have been try this patch https://lore.kernel.org/all/20220703053225.2203-1-xw897002528@gmail.com/ and get pass this line https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda.c#L423 but still got error (below). So, I revert that patch and try yours (remove those 2 lines and replace cs35l41->index = id). And still got same result which is: [15.94] cs35l41-hda spi0-CSC3551:00-cs35l41-hda.1: Failed waiting for OTP_BOOT_DONE: -110. from https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda.c#L488 ** I also inspect the out put of this line. https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda.c#L320 and got -22, but seem the section "no_acpi_dsd" said it's normal. ** And I also tried this quirk and not working. SND_PCI_QUIRK(0x1043, 0x1e02, "Asus Zenbook UX3402ZA", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
(In reply to Supasak Sutha from comment #20) > Actually I have been try this patch > > https://lore.kernel.org/all/20220703053225.2203-1-xw897002528@gmail.com/ > > and get pass this line > > https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda. > c#L423 > > but still got error (below). > > So, I revert that patch I believe that patch is legit and it's okay to have it. > and try yours (remove those 2 lines and replace > cs35l41->index = id). But you would still need the above change, because for SPI it's a chip select 0 or 1, and not an address (which is 0x40 in i2c case). > And still got same result which is: > > [15.94] cs35l41-hda spi0-CSC3551:00-cs35l41-hda.1: Failed waiting for > OTP_BOOT_DONE: -110. > > from > > https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda. > c#L488 A-ha, this may give another clue. The GPIOs are addressed by index from _CRS and it may be that the 0 is wrong (and actually it might be two different GPIOs for reset of each of the codecs). https://elixir.bootlin.com/linux/v5.19-rc4/source/sound/pci/hda/cs35l41_hda.c#L430 In this line, try to replace 0 by a) id or b) id + 1 and see if it helps anyhow. Ideally we need a PCB schematics of that laptop. With it at hand it will be 15 minutes work to understand GPIO mappings. Any possibility to get schematics? > ** > And I also tried this quirk and not working. That quirk is for a LED, I don't think it's anyhow critical right now.
> > In this line, try to replace 0 by a) id or b) id + 1 and see if it helps > anyhow. No luck, same result. > Ideally we need a PCB schematics of that laptop. With it at hand it will be > 15 minutes work to understand GPIO mappings. Any possibility to get > schematics? > Where can I find it? Is Asus normally share this schematics? I can open the bottom case and take some pictures if it's help.
I see. So it seems the best approach is to wait what Cirrus will do. I reassign this to the ALSA, because SPI issue has been fixed.
Have you tried the v6.0-rc3 Linux kernel? Does it have any improvements?
I can confirm the bug on an ASUS U6502ZD which also has the cs35l41. On kernel 6.0.11 (and any prior to that) I get in dmesg [ 26.864881] cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551. [ 26.864903] cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported [ 26.864909] cs35l41-hda: probe of spi0-CSC3551:00-cs35l41-hda.0 failed with error -22 and the same for -hda.1. There seems to be a bugfix attempt in place from the distro (fedora 36), as later in dmesg: [ 29.402397] sof-audio-pci-intel-tgl 0000:00:1f.3: Topology: ABI 3:22:1 Kernel ABI 3:23:0 [ 29.402825] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not yet available, widget card binding deferred [ 29.456276] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC294: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker [ 29.456284] snd_hda_codec_realtek ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 29.456286] snd_hda_codec_realtek ehdaudio0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 29.456288] snd_hda_codec_realtek ehdaudio0D0: mono: mono_out=0x0 [ 29.456289] snd_hda_codec_realtek ehdaudio0D0: inputs: [ 29.456291] snd_hda_codec_realtek ehdaudio0D0: Headset Mic=0x19 [ 29.911692] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten [ 29.911710] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten [ 29.912116] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 overwritten [ 29.912130] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi2 overwritten [ 29.912140] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi1 overwritten [ 29.912150] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Codec Output Pin1 overwritten [ 29.912162] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Codec Input Pin1 overwritten [ 29.912176] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Analog Codec Playback overwritten [ 29.912189] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Digital Codec Playback overwritten [ 29.912203] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Alt Analog Codec Playback overwritten [ 29.912219] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Analog Codec Capture overwritten [ 29.912232] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Digital Codec Capture overwritten [ 29.912246] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Alt Analog Codec Capture overwritten [ 29.912276] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI convert I found that Cirrus has uploaded a driver for ASUS in the meantime here: https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus/cs35l41 Maybe that can be included upstream?
(In reply to rene.sedmik from comment #25) > I can confirm the bug on an ASUS U6502ZD which also has the cs35l41. Thanks for the information! > I found that Cirrus has uploaded a driver for ASUS in the meantime here: > https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus/cs35l41 > > Maybe that can be included upstream? Not in that form, you need to contact Cirrus to push them harder to make them to update the upstream driver (they maintain it anyway).
I believe the recent cs35l41 firmware has been already merged into the upstream linux-firmware tree. But this won't help alone unless BIOS gets fixed to provide the proper _DSD. That is, if you get about the "missing _DSD" error, it still won't work. According to Cirrus, ASUS will ship the BIOS update addressing that, at least for some models.
Closing based on the comment #27, hopefully BIOS will be updated soon for your model.