Repository navigation
No audio (other than HDMI/DP) on Lenovo Yoga 9i 11gen: part 0x105 not supported #5801
Description
Hi, I'm not really sure what's going on with my machine but it's pretty new so this was kinda expected, just hoping someone could maybe point me in the right direction.
Hardware:
- LENOVO_MT_83SE_BU_idea_FM_Yoga 9 2-in-1 14IPH11
- CPU: Intel Ultra 7 355 (Panther Lake)
Software:
- BIOS: TKCN25WW
- OS: Fedora 44
- Kernel: 7.0.10-201.fc44.x86_64
- sof-firmware: 2025.12.2
[ 13.884152] sof-audio-pci-intel-ptl 0000:00:1f.3: enabling device (0000 -> 0002)
[ 13.884284] sof-audio-pci-intel-ptl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[ 13.884340] sof-audio-pci-intel-ptl 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [xe])
[ 13.890724] sof-audio-pci-intel-ptl 0000:00:1f.3: use msi interrupt mode
[ 13.901507] acpi device:1d: SDCA function SmartAmp (type 1) at 0x1
[ 13.901569] acpi device:1f: SDCA function SmartAmp (type 1) at 0x1
[ 13.901617] acpi device:21: SDCA function SmartAmp (type 1) at 0x1
[ 13.901619] acpi device:22: SDCA function UAJ (type 6) at 0x3
[ 13.901622] acpi device:23: SDCA function HID (type 10) at 0x4
[ 13.901709] acpi device:25: invalid addr: 0xd011010500
[ 13.911722] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-p not found, using dummy regulator
[ 13.911748] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-d not found, using dummy regulator
[ 13.911755] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-a not found, using dummy regulator
[ 13.911765] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-io not found, using dummy regulator
[ 13.911770] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-cp not found, using dummy regulator
[ 13.914660] sof-audio-pci-intel-ptl 0000:00:1f.3: No SoundWire machine driver found for the ACPI-reported configuration:
[ 13.914664] sof-audio-pci-intel-ptl 0000:00:1f.3: link 0 mfg_id 0x01fa part_id 0x3557 version 0x3
[ 13.914665] sof-audio-pci-intel-ptl 0000:00:1f.3: link 0 mfg_id 0x01fa part_id 0x3557 version 0x3
[ 13.914666] sof-audio-pci-intel-ptl 0000:00:1f.3: link 0 mfg_id 0x01fa part_id 0x4243 version 0x3
[ 13.914667] sof-audio-pci-intel-ptl 0000:00:1f.3: link 0 mfg_id 0xd010 part_id 0x0105 version 0x0
[ 13.914673] sof-audio-pci-intel-ptl 0000:00:1f.3: part id 0x105 is not supported
[ 13.914674] sof-audio-pci-intel-ptl 0000:00:1f.3: hda codecs found, mask 4
[ 13.914675] sof-audio-pci-intel-ptl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
[ 13.914676] sof-audio-pci-intel-ptl 0000:00:1f.3: NHLT device BT(0) detected, ssp_mask 0x4
[ 13.914677] sof-audio-pci-intel-ptl 0000:00:1f.3: BT link detected in NHLT tables: 0x4
[ 13.914678] sof-audio-pci-intel-ptl 0000:00:1f.3: DMICs detected in NHLT tables: 4
[ 13.919422] cs42l43 sdw:0:0:01fa:4243:01: devid: 0x042a43, rev: 0xa1, otp: 0x03
[ 13.930202] cs35l56 sdw:0:0:01fa:3557:01:1: supply VDD_P not found, using dummy regulator
[ 13.930225] cs35l56 sdw:0:0:01fa:3557:01:1: supply VDD_IO not found, using dummy regulator
[ 13.930237] cs35l56 sdw:0:0:01fa:3557:01:1: supply VDD_A not found, using dummy regulator
[ 13.942255] sof-audio-pci-intel-ptl 0000:00:1f.3: Firmware paths/files for ipc type 1:
[ 13.942259] sof-audio-pci-intel-ptl 0000:00:1f.3: Firmware file: intel/sof-ipc4/ptl/sof-ptl.ri
[ 13.942261] sof-audio-pci-intel-ptl 0000:00:1f.3: Firmware lib path: intel/sof-ipc4-lib/ptl
[ 13.942262] sof-audio-pci-intel-ptl 0000:00:1f.3: Topology file: intel/sof-ipc4-tplg/sof-hda-generic-idisp-4ch.tplg
[ 13.950276] cs35l56 sdw:0:0:01fa:3557:01:1: Cirrus Logic CS35L57 Rev B2 OTP1 fw:4.2.1 (patched=0)
[ 13.955077] cs35l56 sdw:0:0:01fa:3557:01:0: supply VDD_P not found, using dummy regulator
[ 13.955099] cs35l56 sdw:0:0:01fa:3557:01:0: supply VDD_IO not found, using dummy regulator
[ 13.955108] cs35l56 sdw:0:0:01fa:3557:01:0: supply VDD_A not found, using dummy regulator
[ 13.959959] sof-audio-pci-intel-ptl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.14.1.1
[ 13.963521] cs35l56 sdw:0:0:01fa:3557:01:0: Cirrus Logic CS35L57 Rev B2 OTP1 fw:4.2.1 (patched=0)
[ 13.978967] Adding alias for supply vdd-amp,(null) -> vdd-amp,sdw:0:0:01fa:4243:01
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 3: HDMI1 (*) [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 4: HDMI2 (*) [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 5: HDMI3 (*) [HDMI 3]
Subdevices: 1/1
Subdevice #0: subdevice #0
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC Raw (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
Activity
charleskeepax commentedon Jun 4, 2026
Hello, yeah we are aware of this one and are pretty close to having it all working. The primary discussion has been going on here:
https://bugzilla.kernel.org/show_bug.cgi?id=221499
If you are comfortable building a kernel, the TL:DR is you need to take #5773 and the "Test Debug 1" patch from that ticket and apply them to your kernel. That should get things going (at least on the kernel side) all the stuff from #5773 is already upstream so should be working its way through the system. I am just hoping to confirm Test Debug 1 was the right fix but given you seem to be see the same issues as the person on that ticket that is very encouraging.
bardliao commentedon Jun 16, 2026
@realRobotix Could you try if below change help?
charleskeepax commentedon Jun 16, 2026
Do you have a reason to prefer that to the DMI quirk? At the moment the plan was to DMI quirk this laptop to disable that device, just waiting on any info on what the device was but soon I think we will just have to upstream the patch anyway (probably after the merge window closes).
bardliao commentedon Jun 16, 2026
@charleskeepax I prefer the DMI quirk for the rt722 codec. But, part id 0x0105 seems be a different issue to me. The part id doesn't belong to any codec. So that it will not impact any codecs if we add it to the codec_info_list[]. And I saw it in some devices. It seems be a common issue.
charleskeepax commentedon Jun 17, 2026
I guess using the match table like that means that we won't have to quirk for each laptop that has the device, although still for reasons I have not been able to work out this device is ignored on most laptops. Seems to only be this one laptop where it causes a problem. One slight concern with the codec info approach (apart from it being a bit sus to have codec info for non-functional/non-real devices) using a match table I don't think will stop the errors about the device address being invalid.
bardliao commentedon Jun 22, 2026
Yes, the purpose is not to have quirk for each laptop. I have the same question about why the ADR is ignored by some devices but not all. Note that it will not cause any issue if the default mach table is not used. In other words, we won't hit the issue even the ADR is not ignored in previous platforms.
I tested the approach in my local machine, and it works.
charleskeepax commentedon Jun 22, 2026
Does your machine show the invalid address error without the patch?
bardliao commentedon Jun 22, 2026
What I did is to remove the dai info of the rt713 and tested with ghost rt713 not 0x0105.
I added a ghost SDW rt713 to my acpi table manually. Without the patch, the driver tried creating the second jack pcm and then cause some unexpected error. And it worked like the ghost rt713 is not added with the patch.
charleskeepax commentedon Jun 22, 2026
So I think that will work for getting the soundcard probing, but one would still I believe get this error message:
[ 13.901709] acpi device:25: invalid addr: 0xd011010500
I don't think its fatal, but probably going to cause some tickets/questions. You wouldn't get this in your tests since you used a valid soundwire ID for your testing, not the weird invalid one this strange device has. One of the reasons it would be nice to know what this device is, would perhaps help us track down how likely this is to show up in the future. If it's just going to be this one laptop (so far I have seen several laptops with the device and this is the only one where it causes a problem) a DMI quirk is fine, if its going to be loads of laptops in the future then perhaps we want to consider something more like your solution.
bardliao commentedon Jun 22, 2026
@charleskeepax I can't see the acpi invalid addr error. My acpi ADR is
Name (_ADR, 0x000300d011010500)And my dmesg.txt with my patch.
realRobotix commentedon Jun 22, 2026
@bardliao works 👍
@charleskeepax the 0x000330025d072201ull dmi-quirk isn't actually needed on my device it's all just the 0x0105 part that's causing issues.
charleskeepax commentedon Jun 23, 2026
@realRobotix Could you attach a dmesg with the fix included please?
realRobotix commentedon Jun 23, 2026
dmesg.txt
mateo-cabrera commentedon Jun 23, 2026
Got the same thing on a Lenovo Yoga Pro 9 16IPH11 (DMI product 83SF, BIOS THCN31WW, Core Ultra 7 356H). Basically the bigger sibling of the 14IPH11 in this report. My SoundWire setup is a bit more loaded though and I run into two separate problems, so I figured I'd dump what I found here. The bit about what the 0xd010 device actually is might be useful.
SoundWire layout here:
CS42L43 feeds vdd-amp to the CS35L56 so it can't just be dropped.
On the 0xd010 mystery device: in the ACPI tables it's a Device (IDP0) with _ADR 0x000000D010010500, and there's a nested Device (IDPN) with _ADR 0x000000D011010500. The _DSD on it has:
So it reads like some phantom SDCA endpoint advertising lane 2/3 manager mappings, but 0xd010/0xd011 aren't real MIPI mfg IDs and nothing ever attaches to it. I can attach the SSDT or a full acpidump if that helps you figure out where it's coming from.
First problem is the same one this issue is about, the 0x0105 part kills the generic machine:
@bardliao's codec_info_list ghost entry (0xD010 / 0x0105) sorts that out here too.
Second problem is the RT722, which the 14IPH11 doesn't have iirc
. Once the ghost is dealt with and the generic machine actually builds, card registration blows up because CS42L43 and RT722 both expose an SDCA UAJ on link 3 and the DAI link names collide:
That looks like the "second jack pcm" thing @bardliao mentioned, so if it helps, this machine is real hardware that hits both the ghost and the rt722 dual jack at the same time.
For what it's worth, with the ghost handled and the RT722 left out, the card comes up as sof-soundwire, all four CS35L56 pull the Lenovo factory tuning (cs35l56-b0-dsp1-misc-17aa3806-*, "Calibration applied"), and the internal speakers work once I flip the Speaker switch on (defaults off with no UCM).
Happy to test the real ghost patch plus whatever rt722 quirk you land on, since I've got the actual RT722 hardware here, and I can attach full dmesg / acpidump / alsa-info if you want them.
journal-soundwire.txt
acpi-IDP0-phantom.txt
charleskeepax commentedon Jun 23, 2026
@realRobotix Thanks.
@bardliao Yeah the message is still there:
[ 15.184608] acpi device:25: invalid addr: 0xd011010500
I mean it's definitely not a deal breaker it is just an error message. I am also pretty sure this device is something Intel so happy to defer to you guys on the fix for it.
@mateo-cabrera Yeah the fix for the RT722 issue on your model is already working its way through upstream (https://lore.kernel.org/lkml/20260520163631.3300102-4-ckeepax@opensource.cirrus.com/) you can currently pull it in from the soundwire tree or from my branch of fixes (https://github.com/charleskeepax/linux/commits/v7.0-cs42l43/).
bardliao commentedon Jun 23, 2026
@charleskeepax I am trying to reach out the BIOS team for the issue. But to be honesty, I am not sure if they will fix the issue or not.
I am thinking about adding a global ghost remap that apply to all devices like below.
What do you think?
charleskeepax commentedon Jun 23, 2026
I would be fine with that as a solution as well. Although you have a slight typo in the _ADR (0x000000D010010500ull -> 0x000000D011010500ull)
cenk1cenk2 commentedon Jun 23, 2026
I also have the same machine, (Lenovo 83SF, Yoga Pro 9 16IPH11).
With the ghost handled and RT722 left out, the card registers as
sof-soundwireand uses function topologies. The loaded topology set issof-sdca-2amp-id2.tplg,sof-sdca-jack-id0.tplg,sof-ptl-dmic-4ch-id4.tplg,sof-hdmi-pcm5-id6.tplg.All four CS35L56 amps attach and load Lenovo factory tuning.
UCM is active here,
Speaker Switchis on, andAMP1..AMP4 Speaker Switchare all on. However, audibly I only get two physical speakers working out of the physical four so it sounds super odd. The PipeWire speaker sink is still 2-channel FL/FR, and the cs42l43 speaker routing shows onlyL Input 1 = DP6RX1andR Input 1 = DP6RX2; the other speaker inputs areNone.It is better than nothing still.
This was achieved by monkey patching what is going to upstream by @charleskeepax but I had to monkey/force patch @bardliao to get to this point.
Did you do anything additional @mateo-cabrera to get all the speakers working or am I just misunderstanding your reply?
bardliao commentedon Jun 24, 2026
I noticed that, too. But
The invalid addr message shows 0xd011, but the peripheral message shows 0xd010.
And the ACPI dump also shows 0xd010.
That's why I think the ADR is actually 0x000000D010010500ull.
@realRobotix @mateo-cabrera @cenk1cenk2 Could you replace #5801 (comment) with #5801 (comment) and test again? I will submit a PR if it works.
cenk1cenk2 commentedon Jun 24, 2026
You are the best thank you for guiding me.
I lost track of bit of what I did to get it to this point so enlisted help of the ai to summarize the patches (intended for linux-zen on ArchLinux) attached below if it is any help. But all the speakers works now which makes me ecstatic. Thank you again for sharing the progress and helping me out.
yoga-pro-9-83sf-working-audio-combined.patch
mateo-cabrera commentedon Jun 24, 2026
@bardliao I tested your global_ghost_adr patch on my 83SF. I dropped the codec_info_list ghost entry and used this instead, and it works here. The 0xd010 device gets remapped away, the "part id 0x105 is not supported" abort is gone, and the card comes up as sof-soundwire with all four CS35L56 attaching and loading the Lenovo tuning.
One note for the 16IPH11 specifically: this model still needs Charles's RT722 remap on top of yours, because of the second jack on link 3. With both in place the card builds cleanly and the speakers play. @realRobotix 's 14IPH11 has no RT722 so your patch on its own should be enough there.
Happy to retest if you change anything before the PR.
mateo-cabrera commentedon Jun 24, 2026
@cenk1cenk2 No, I didn't do anything special, and I don't think we're actually in the same state. Over here all four AMP1..AMP4 Speaker Switch are on and it plays full range, pretty much like Windows, so I'm fairly sure all four CS35L56 are actually driven.
A couple of things that confused me at first too. The 2-channel FL/FR sink is normal, laptop speakers show up as plain stereo even with four drivers (two per side), so a 2ch sink doesn't mean only two speakers. And the cs42l43 Speaker L/R Input = None you're looking at is the CS42L43's own speaker amp, which is a separate path. The four CS35L56 get their audio straight over SoundWire, so None there doesn't tell you anything about them.
The grille count is a red herring as well, this chassis only has two visible grilles but the woofers fire down through the bottom, so you can't count drivers by the grilles.
If you genuinely only hear two, I'd check that all four AMPn Speaker Switch are actually on and that UCM isn't only wiring two of them. Can compare alsa-info if it helps.
And to be upfront, my earlier "the speakers work" just meant sound came out. I hadn't actually checked all four at that point, my bad. They do work now that I've checked them though 👍
bardliao commentedon Jun 24, 2026
Thanks @mateo-cabrera @cenk1cenk2 for the feedback. I will submit a PR for it.
VastoLorde95 commentedon Jul 1, 2026
[Made with AI]
Confirmed on Lenovo Yoga 9i (DMI
83SE,14IPH11, Panther Lake).Heads-up for Ubuntu 26.04 (kernel 7.0.0-27): the posted patch doesn't compile here because
struct asoc_sdw_codec_infohas novendor_idyet. Match onpart_idalone:{ .part_id = 0x0105, .name_prefix = "ghost", .version_id = 0, .dai_num = 0, },Notes:
name_prefixis mandatory (find_acpi_adr_device()insof/intel/hda.cbails on NULL), anddai_num = 0is what keeps it safe —num_endpointsis derived fromdai_num, so the phantom builds zero DAI links. Thedmi-quirks.c_ADRremap had no effect (wrong path — the abort is in SOF machine-select, not the bus driver). No RT722 quirk needed.Write-up + DKMS package (survives kernel updates): https://gist.github.com/VastoLorde95/d585a85c70f25e49ce39ec5185038157
Speakers, headset and mic all working after reboot.
charleskeepax commentedon Sep 9, 2026
Everything needed here should be upstream so going to close this down.