From nobody Fri Oct 2 05:30:07 2026 Received: from mail-05.mail-europe.com (mail-05.mail-europe.com [85.9.206.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 275F53DA7CA for ; Tue, 4 Aug 2026 22:59:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.9.206.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785884387; cv=none; b=FTUJBvGRcFC90BNuVeUR9pIn6pNiEye+2pWDHJWK1Nv96Wj7BIe96zFYvXoflwvtmZNwAFoBvDDU6E0cc/iCC+Z942gwVoyzTVCjtM+pIKupPdzesQFwIABC2t9V1d5S3omwb0XRiG7xqBC2+LSnBX/8DZ6D4c7YsRH03n72tFE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785884387; c=relaxed/simple; bh=H4e7Ps1XtiKH4TO/3BjbXXc8kP7dZkzLPOEI7twRvAk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HO+f9zN2g/UYWxYBYjuqLEnhO/EsGJePqySPeHnvNJv12FjTc7yfoJSEV9j0fl8xJtJPLMPUodzyZeGXJiXJo1Um18cmCA72uM2hVKyFbr4VRdxHtTXwRtk1L3uWwm5RVoRuh5A/UJmEPV3smzT9LJzod33v5mskUKRC09yQ4iE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=FS1RuTdQ; arc=none smtp.client-ip=85.9.206.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="FS1RuTdQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1785884370; x=1786143570; bh=rAjpVHNOuKzbCe4ywlmfVDM0tSDIwLDF//f7jRQKZz8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=FS1RuTdQMds8FLF7ZMDs+hT/qJ/nge5jcHTivoOjphsdcNJCYXAaGEyKjPwUSi+Gw X69JeruZD5jXUyEg1p4x6GJGZa8NdPuK4oitWcUc+vod4phXpxdYrFI02GHl1Zmnr6 jzjyC6V5u0fQz8Nv0tlOwz7yLyuTNmYf6rR+CY/NsWM+pgWpKLnhStRg77tfQWbpvY Vfsoy+aRO4e98vy7rfZ6E+UufYRn09BWigKtRibNuaJkMOVDa4BIY+VL8uNedTqPys X+rwEmAJQP0guy9NsRsORBD5mToe+FjfKfsNyfNbCkGJgZS8YIQP1SoDIJzdDYJvMo dRxt968OJpcsw== Date: Tue, 04 Aug 2026 22:59:24 +0000 To: Mark Brown , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Oder Chiou , Bard Liao , Peter Ujfalusi , Kai Vehmanen , Ranjani Sridharan , Pierre-Louis Bossart , Daniel Baluta , Vijendar Mukunda From: Sergey Lebedev Cc: linux-sound@vger.kernel.org, sound-open-firmware@alsa-project.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/3] ASoC: rt1320: run the initialisation preset on the first hardware init Message-ID: <20260804225853.31585-2-lsa.uz@pm.me> In-Reply-To: <20260804225853.31585-1-lsa.uz@pm.me> References: <20260804225853.31585-1-lsa.uz@pm.me> Feedback-ID: 113843758:user:proton X-Pm-Message-ID: b39d5585c53af84ae802257a66e0d5e0bc0ab80b Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rt1320_io_init() applies the vendor initialisation preset only when the amplifier's SDCA function status has FUNCTION_NEEDS_INITIALIZATION set: if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION)) { Its two sibling drivers guard the same write differently, also running the preset on the first hardware init: rt712-sdca.c: if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) || (!rt712->first_hw_init)) { rt722-sdca.c: if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) || (!rt722->first_hw_init)) { On the Microsoft Surface Pro 11 (Intel) the RT1320 never sets that bit. Its function status reads back 0x41 on every boot, cold or warm: rt1320-sdca sdw:0:0:025d:1320:01: rt1320_io_init amp func_status=3D0x41 which is NEWLY_ATTACHED | FUNCTION_HAS_BEEN_RESET: the function reports that it has been reset and does not consider itself in need of initialisation. Bit 5 is never set, so the preset never runs, rt1320_vc_preset() and the MCU patch load are skipped, and the amplifier is left unprogrammed. rt712 and rt722 would have run it via their first_hw_init fallback. Add the same fallback. With it rt1320_vc_preset() executes and the amplifier reports RT1320_KR0_INT_READY=3D0x1f where previously it did not. Signed-off-by: Sergey Lebedev --- sound/soc/codecs/rt1320-sdw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt1320-sdw.c b/sound/soc/codecs/rt1320-sdw.c index 13493b85f..d1f3b160a 100644 --- a/sound/soc/codecs/rt1320-sdw.c +++ b/sound/soc/codecs/rt1320-sdw.c @@ -1900,7 +1900,7 @@ static int rt1320_io_init(struct device *dev, struct = sdw_slave *slave) dev_dbg(dev, "%s amp func_status=3D0x%x\n", __func__, amp_func_status); =20 /* initialization write */ - if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION)) { + if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) || !rt1320->first_h= w_init) { switch (rt1320->dev_id) { case RT1320_DEV_ID: if (rt1320->version_id < RT1320_VC) --=20 2.50.1 (Apple Git-155) From nobody Fri Oct 2 05:30:07 2026 Received: from mail-244121.protonmail.ch (mail-244121.protonmail.ch [109.224.244.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B20E141E6A8; Tue, 4 Aug 2026 22:59:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.121 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785884389; cv=none; b=YgoeAGG72dyw++gjil4cebV2GAVSD9tNndWALD8YLDmaeqV9x2bkOjuMeg3wytzSCIuq3juGYKiS9C4HGzRu28OpbRetGEtSMYzXUBY/YANvaT/xlYv8PFvlICWw94jZeDJIxKfwogSS7ZacmVettSkVuMnma4KryOHeFLAIzOY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785884389; c=relaxed/simple; bh=t8d4uKou6G+tMLFCmjLjpyA4UZfkG1yzPZEN5enrpjQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qk/YZpmwXbswGOEUNJ9XlhbC4YRocaHqEP7qK3KpE1N7UqT8zYrdIApqftnq34V9Tw4tdMeTTfPuiLBkfBCNOdWYWWA12DPQt0eNcCla8DEHWUL+LUKdS2olUiOAsNQfPCxZU5uTJb+UDteb4n/YvaS8KAkn+f20t2L11os6r3g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=hL4WtNaG; arc=none smtp.client-ip=109.224.244.121 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="hL4WtNaG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1785884378; x=1786143578; bh=h0ldZ3M4T+Y2V2+nIOJQnksyEUH6FXCznnKgGiPZ0Kc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hL4WtNaGuL/SpMeCJaWul1pEepO3q4MPmRHHno8lt5j4gSgjh5pdpy/GWqOAenx2u LHXyMB0uae2jrEr3EWkTQiA7Chn+P/3IuqgmQHq2niV9nD3yMLB4AIyV70fe3zgQuh eHDUWGoRsDDF9rriNZ+tjEy/2EEVHMPorR2HRUSVIdP2TxVVdFDVNPeMJBARgLKGpC LPowvmc42Fw5sSN98vdF3EYulx7MMNnDIYHEwcvt5T+tOXU/fe3JJIoecq/Kyli9IU XfoC2PR2WU2/4oN9UB5DcHj4gjG4LQzw6nbLv93sUYOfr3+Rr/gICMcygbkf4VOtMP be4/l35xA1WtQ== Date: Tue, 04 Aug 2026 22:59:34 +0000 To: Mark Brown , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Oder Chiou , Bard Liao , Peter Ujfalusi , Kai Vehmanen , Ranjani Sridharan , Pierre-Louis Bossart , Daniel Baluta , Vijendar Mukunda From: Sergey Lebedev Cc: linux-sound@vger.kernel.org, sound-open-firmware@alsa-project.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/3] ASoC: sdw_utils: skip endpoints of a peripheral that is not on the bus Message-ID: <20260804225853.31585-3-lsa.uz@pm.me> In-Reply-To: <20260804225853.31585-1-lsa.uz@pm.me> References: <20260804225853.31585-1-lsa.uz@pm.me> Feedback-ID: 113843758:user:proton X-Pm-Message-ID: eb3d61e3ec59c6436c2c263369dd81862a8c3319 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" asoc_sdw_parse_sdw_endpoints() builds DAI links for every endpoint of every _ADR entry the firmware declares. If a declared peripheral never enumerates, its links are still created and later fail to prepare, which takes the whole link down rather than degrading it: sof_sdw sof_sdw: ASoC: error at snd_soc_link_startup on SDW0-Playback-SmartAmp: -61 The Microsoft Surface Pro 11 (Intel) declares one physical RT1320 twice, as two _ADR entries on link 0 differing only in SDCA class id: SWRA _ADR 0x000030025D132000 class 0 SWRB _ADR 0x000030025D132001 class 1 Same link, same manufacturer, part and version, same unique id 0. The part reports class 1, so only SWRB enumerates. SWRA is a phantom and stays UNATTACHED across every boot and every firmware version tested, including the November 2025 bundle. The existing is_sdca_endpoint_present() check cannot filter it out. Setting aside that it is gated on a non-zero class id and the phantom is the class-0 entry, the deeper problem is that the BIOS describes both entries identically: each declares the same two SDCA functions, so the check matches for either. Bus presence is what distinguishes them, so test that. The check is by nature a runtime one, and its correctness depends on the peripheral having enumerated by the time the card probes. That holds here: the real device is Attached and the phantom has no device number at all whenever this runs. It is a weaker property than the surrounding BIOS-driven checks, and a suggestion for something stronger would be welcome, but the firmware offers nothing else to key on. Signed-off-by: Sergey Lebedev --- sound/soc/sdw_utils/soc_sdw_utils.c | 46 +++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/sound/soc/sdw_utils/soc_sdw_utils.c b/sound/soc/sdw_utils/soc_= sdw_utils.c index d8db8fc53..12ca4bdd4 100644 --- a/sound/soc/sdw_utils/soc_sdw_utils.c +++ b/sound/soc/sdw_utils/soc_sdw_utils.c @@ -1909,6 +1909,46 @@ int asoc_sdw_get_dai_type(u32 type) } EXPORT_SYMBOL_NS(asoc_sdw_get_dai_type, "SND_SOC_SDW_UTILS"); =20 +/* + * Some firmware describes one physical peripheral with two _ADR entries t= hat + * differ only in SDCA class id, on the same link and with the same unique= id. + * Only the entry whose class id matches the part ever enumerates; the oth= er is + * a phantom. Building DAI links for it fails the whole link rather than + * degrading it, so the endpoints have to be skipped. + * + * This cannot be decided from the BIOS description: on the machine that + * prompted this, both entries declare an identical set of SDCA functions,= so + * is_sdca_endpoint_present() below matches for either. Bus presence is th= e only + * thing that distinguishes them. + */ +static bool is_peripheral_attached(struct device *dev, + const struct snd_soc_acpi_link_adr *adr_link, + int adr_index) +{ + const char *sdw_codec_name; + struct device *sdw_dev; + struct sdw_slave *slave; + bool attached; + + sdw_codec_name =3D _asoc_sdw_get_codec_name(dev, adr_link, adr_index); + if (!sdw_codec_name) + return true; + + sdw_dev =3D bus_find_device_by_name(&sdw_bus_type, NULL, sdw_codec_name); + if (!sdw_dev) + return true; + + slave =3D dev_to_sdw_dev(sdw_dev); + attached =3D slave->status !=3D SDW_SLAVE_UNATTACHED; + if (!attached) + dev_dbg(dev, "%s not present on the bus, skipping its endpoints\n", + sdw_codec_name); + + put_device(sdw_dev); + + return attached; +} + /** * is_sdca_endpoint_present - Check if an SDCA endpoint is present on the = SDW peripheral * @dev: Device pointer @@ -2065,6 +2105,12 @@ int asoc_sdw_parse_sdw_endpoints(struct snd_soc_card= *card, dai_info =3D &codec_info->dais[adr_end->num]; soc_dai =3D asoc_sdw_find_dailink(soc_dais, adr_end); =20 + /* skip a peripheral that is not on the bus at all */ + if (!is_peripheral_attached(dev, adr_link, i)) { + (*num_devs)--; + continue; + } + /* * quirk should have higher priority than the sdca properties * in the BIOS. We can't always check the DAI quirk because we --=20 2.50.1 (Apple Git-155) From nobody Fri Oct 2 05:30:07 2026 Received: from mail-43102.protonmail.ch (mail-43102.protonmail.ch [185.70.43.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8ADD642EEB8; Tue, 4 Aug 2026 22:59:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.102 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785884390; cv=none; b=odCRhx3cTWj9HfRW8Drdg6GL7hVOMHLHf2nHlUKknjKcTREnq01DxrldzycolkXf9iwj6zU10wX5kB8IFt5d5rV2VdtWx143/R3P3DhXKeGeeuagBkuDt89GS8CgFU0RepENRTScz+YLQTzMzqV0xioG6LiYplonlIfesAqzm2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785884390; c=relaxed/simple; bh=FcbSU32HWtanz0g3Aaz6ifgzIzsGFmbIrtF4/I8f284=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=E2Bv23c9jcoFrM7t9fv8B2fOZ/wwz2P82rGJxL9O+3o2jeR7YkTg4URgJL2Eext4uF8bY2oD9dKvPa6Sm7Py1sSxHvRmOsMGMP1pWevBbWDH+nSohkMcxcK/LT7fK8iVO0LneuBJk3YrSP2AvMXhluhZrzUz4aOHG0cdQy8EQWY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=r+tIFsbl; arc=none smtp.client-ip=185.70.43.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="r+tIFsbl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1785884386; x=1786143586; bh=yfolc3ZlNCq8gEtauC/hqP00hwhlIABG8aeAys6n9gs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=r+tIFsbl7FvRsX/vgPgPKQA5bgjdjMmkBrOT1nK4oq1C1ESSGip5eQ5FYHeLQ3602 k3MANwzUxl5etx2yzFKXmckgAeWI6DvtrPONJJw6vF2pynitvLdxSl5i053cbuhUYs nQUcu1MLchk6uZwwGfRpKxfTRNN9WoyhndY3Pd0DEUnH3PBPbny5u/U+fMMht4u5er vG+FtyqNWUNNTGJI+chdgpEKbLi2kJtu0blCQFkYn6r8pB9t3iXzJRTN6SnIapj2wt ey3JhnuOcETd9vRhzQnCjz61cu5KRiaP1UU7Vnv3Qku7hSiMgYfweLmc1RZO3TXt7f LgKC4veP31m7Q== Date: Tue, 04 Aug 2026 22:59:42 +0000 To: Mark Brown , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Oder Chiou , Bard Liao , Peter Ujfalusi , Kai Vehmanen , Ranjani Sridharan , Pierre-Louis Bossart , Daniel Baluta , Vijendar Mukunda From: Sergey Lebedev Cc: linux-sound@vger.kernel.org, sound-open-firmware@alsa-project.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] ASoC: SOF: Intel: hda: duplicate _ADR entries share one amp index Message-ID: <20260804225853.31585-4-lsa.uz@pm.me> In-Reply-To: <20260804225853.31585-1-lsa.uz@pm.me> References: <20260804225853.31585-1-lsa.uz@pm.me> Feedback-ID: 113843758:user:proton X-Pm-Message-ID: ae50e10455b4ff3fa86e218e5b40f6248c74a87d Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" find_acpi_adr_device() assigns each amplifier a name prefix carrying an index ("rt1320-1", "rt1320-2", or Left/Right) and advances that index once per _ADR entry. Firmware that describes one physical part with two _ADR entries therefore consumes two indices for one device. The Microsoft Surface Pro 11 (Intel) does exactly that. Link 0 carries: SWRA _ADR 0x000030025D132000 SDCA class 0 SWRB _ADR 0x000030025D132001 SDCA class 1 identical but for the class id: same link, same manufacturer, part and version, same unique id 0. The part reports class 1, so SWRB is the one that enumerates and SWRA never attaches on any boot or firmware version tested. Both still reach this function, so SWRA takes index 1 and the real amplifier is named "rt1320-2". Its controls appear as "rt1320-2 OT23 L/R Switch". The stock sof-soundwire UCM profile expects the first amplifier, so it enables switches on a device that is not present, and the speakers stay silent while everything else reports success. Compare entries that differ only in class id and give the later one the earlier one's name prefix, jumping past the amplifier-index increment so a repeated description consumes one index rather than several. Testing the peripheral's attach status instead does not work here, and was tried: at machine-select time neither entry has attached yet, so a status test finds both unattached, no amplifier is matched at all, and the card falls back to the HDMI-only HDA machine driver. Comparing addresses needs no runtime state. Signed-off-by: Sergey Lebedev --- sound/soc/sof/intel/hda.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 4dbba9186..1d60a8caa 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -1245,6 +1245,22 @@ static struct snd_soc_acpi_adr_device *find_acpi_adr= _device(struct device *dev, ((u64)(sdw_device->id.sdw_version & 0xF) << 44) | ((u64)(sdw_device->bus->link_id & 0xF) << 48); =20 + /* + * Firmware may describe a single physical part with more than one _ADR + * entry, differing only in SDCA class id. Those entries are the same + * device: they must share a name prefix, and only the first of them may + * consume an amp index. Otherwise the part that actually enumerates is + * named as though it were the second amplifier, and UCM profiles + * written for the first one address a device that is not there. + */ + for (j =3D 0; j < index; j++) { + if ((adr_dev[j].adr & ~SDW_CLASS_ID_MASK) =3D=3D + (adr_dev[index].adr & ~SDW_CLASS_ID_MASK)) { + adr_dev[index].name_prefix =3D adr_dev[j].name_prefix; + goto done_name_prefix; + } + } + if (!codec_info_list[i].is_amp) { /* For non-amp codecs, get name_prefix from codec_info_list[] */ adr_dev[index].name_prefix =3D devm_kasprintf(dev, GFP_KERNEL, "%s", nam= e_prefix); --=20 2.50.1 (Apple Git-155)