From nobody Sat Sep 26 21:13:53 2026 Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch [79.135.106.28]) (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 3D8523A453F; Sun, 30 Aug 2026 08:45:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.28 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788079522; cv=none; b=FAFKREy5fHn5GoWR6pnhKaixaGNqZ/jjvvXYgymVO38M0/Hld0hDkfUBMGQGWXO5GjFG80n6NhVc5OTmtQDeuLwPMjl0khX+wFNBUO0p8PB88olS7Y0XdgtYHA+uiiHekaLyk2RgszveFgIKE25U75vvPTFxc3/yamQKX2ESUQA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788079522; c=relaxed/simple; bh=M+2CzBP2SNCXi23pIvjDvhBtCBLYWz+s0iHo3NWVAwA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dyv52kk0/vAQEP2OyW0K74nHj14/644nClC9WQBmA1EmWmSjHJh28TjwyYePVvUHt2oyIVlRhT2hjAHGz0QpPQbA9ZAnmddl2plsfb9On5ctS3SmzhsgyjXedu0okqFnYCC5LmfwhEACHsX1aYRMPIXltMxICsKi0ML6XLniS8A= 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=jPc2a7js; arc=none smtp.client-ip=79.135.106.28 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="jPc2a7js" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1788079518; x=1788338718; bh=48SIRkyGAVLzfF/HnjP4LMKuskjW5PPU88cEiXQ7lUk=; 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=jPc2a7jsUzNUB3W11crKg/wla0mo0wdvivrO4Wl2W4K7jJgBydFB/j4SJfvTSB9lt llzen1wFqBc7IBM1CCHbRkWmZ2YN/qQZriTq3NbJxPIn8Th4OZtr8P6V/P2R/ey+nD WeJU4s5zlAnHrnEUW+ZYZTpr0JQsVpwpdhkTqY1UarUANgvfxOiZ6xaQ4JwP8hIKAk wbXzEm6cqKHSQ/0dbxYwEBLJ41nBOCxPmkSFuARtGDWDFJ3VmFtCRyP352NwXowy0P pz05sCY0MgcQgumwf+GSQ7oO28iHTDL2IaG3apRTIHvROB17PU87mntyrfJzLSJs1s pi6vVxqULXLEw== Date: Sun, 30 Aug 2026 08:45:13 +0000 To: Vinod Koul , Bard Liao , Pierre-Louis Bossart , Oder Chiou , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai From: Sergey Lebedev Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/2] ASoC: rt1320: run the initialisation preset on the first hardware init Message-ID: <20260830084500.6123-2-lsa.uz@pm.me> In-Reply-To: <20260830084500.6123-1-lsa.uz@pm.me> References: <20260804225853.31585-1-lsa.uz@pm.me> <20260830084500.6123-1-lsa.uz@pm.me> Feedback-ID: 113843758:user:proton X-Pm-Message-ID: 5ef8b422a69b8e1b459b6d11ad5bb78896b7ec8c 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 --- v2: unchanged from v1's 1/3. 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 Sat Sep 26 21:13:53 2026 Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch [109.224.244.16]) (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 12BEE3A1683 for ; Sun, 30 Aug 2026 08:45:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788079527; cv=none; b=qjidgOpsnirLVihVzKaHFaQ9e8likGlC10+lAuXnsNLgXnU3Z5iE/cDlopCGAEaw7sxUOHJNjZ73JRHcyadjFtwJC6rDak+29ch0ToT8/ZAt8dBS89Qlu2WhXUBmYrIMUR266x4cY3fKdsZTtr/7yRPPRF851/anq978eWZPCTM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788079527; c=relaxed/simple; bh=lcs4zcrgdLIT3JD+m7JIIvdFU0tstU3E/FP3fDCC6aM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=o4TVwnZXtMVI9XkPFHQfeadGoXakJ2KLLi8FZaqE8nzvt9bn/azOBPD0dJPgxvVOvkVOLUVCG+z6xB3onk3f1M+GJoIft+ZEG3uI6C8Jx78BBwvfn3GfNEV0aCyAVRN7vs2pLQKG/9dyjd6q/MUU/BNSwzdHuPt9jMUY8mUXCFc= 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=oIQeFc4P; arc=none smtp.client-ip=109.224.244.16 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="oIQeFc4P" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1788079523; x=1788338723; bh=qLEuIV9WXMF8WA2Og6nH2usoaxxRB7X4vIDz5I7QZmU=; 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=oIQeFc4PK+OexnYPkcAATKV809YRpWFF2dBNDX3Xq9IM5zVwyMtu4bQa9g87Sb1vR XOuBTbZHNy1dxb/aMy4to85hRLEyaDFinyzgORPNZTGbS7yP8EFJPdRdWZFCWko2Ux mmpOHrrIDMccwTb+a1CIOTG3mN0td+P5pKLR1V8PxlyqTSwxid9zVO4fTH2nsgvq34 WKEMm5xkaXIRBXoOv2nwmhoLC6FTarZeR4+t1s1nvGgN2M2CvqEql58yfQ8J9D9tbe U7KuGnpZsN/o1laIsb4hKHHL5K7owGNtKTHym2k6tgI1pv4c909ebdjJY6i5eq5Zq3 6HrqoFxvJQPEQ== Date: Sun, 30 Aug 2026 08:45:20 +0000 To: Vinod Koul , Bard Liao , Pierre-Louis Bossart , Oder Chiou , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai From: Sergey Lebedev Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/2] soundwire: dmi-quirks: drop the ghost RT1320 on the Surface Pro 11 (Intel) Message-ID: <20260830084500.6123-3-lsa.uz@pm.me> In-Reply-To: <20260830084500.6123-1-lsa.uz@pm.me> References: <20260804225853.31585-1-lsa.uz@pm.me> <20260830084500.6123-1-lsa.uz@pm.me> Feedback-ID: 113843758:user:proton X-Pm-Message-ID: c887decb40059c5d4142f26eb1a2606818aca2dc 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" The Microsoft Surface Pro 11 for Business (Intel, Lunar Lake) carries a single physical RT1320 amplifier on link 0 and describes it twice: SWRA _ADR 0x000030025D132000 SDCA class 0 SWRB _ADR 0x000030025D132001 SDCA class 1 Identical apart from the class id: same link, same manufacturer, part and version, same unique id 0. The part reports class 1, so only SWRB enumerates. SWRA never attaches on any boot or firmware version tested, including the November 2025 bundle. The ghost is not harmless. It consumes an amplifier index in find_acpi_adr_device(), so the real part is named "rt1320-2" and the stock sof-soundwire UCM profile enables switches on a device that is not there. Its endpoints also reach create_sdw_dailink(), which builds DAI link names from link id and function type alone; the ghost declares the same SmartMic function as the real part, so the card fails to register at all: sysfs: cannot create duplicate filename '.../sof_sdw/SDW0-Capture-SmartMic' kobject_add_internal failed for SDW0-Capture-SmartMic with -EEXIST sof_sdw sof_sdw: probe with driver sof_sdw failed with error -12 Remap its _ADR to zero so sdw_acpi_find_slaves() never creates the peripheral, which is how ghost devices are handled already - see ghost_realtek and global_ghost_adr in this file. Both failures then disappear, because neither path is reached. Matched on DMI_PRODUCT_SKU rather than the product name. A later batch of the same model could carry a different RT1320 version, which would change the _ADR; keying on the SKU keeps this remap to the hardware it was verified on, and follows dell_sku_0A3E above. Suggested-by: Pierre-Louis Bossart Suggested-by: Bard Liao Signed-off-by: Sergey Lebedev --- v2: - new in v2. Replaces v1's 2/3 (sdw_utils runtime presence test) and 3/3 (SOF/Intel amp-index dedup) with a single remap at enumeration, per Pierre-Louis Bossart's suggestion. - matched on DMI_PRODUCT_SKU rather than the product name, per Bard Liao: a later batch could carry a different RT1320 version and therefore a different _ADR. drivers/soundwire/dmi-quirks.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/soundwire/dmi-quirks.c b/drivers/soundwire/dmi-quirks.c index d75037558..8b3c5c8d1 100644 --- a/drivers/soundwire/dmi-quirks.c +++ b/drivers/soundwire/dmi-quirks.c @@ -111,6 +111,25 @@ static const struct adr_remap ghost_realtek[] =3D { {} }; =20 +/* + * The Microsoft Surface Pro 11 (Intel) describes its single physical RT13= 20 + * amplifier twice on link 0, as two _ADR entries differing only in SDCA c= lass + * id and sharing the same unique id. Only the class 1 entry enumerates; t= he + * class 0 entry is a ghost. + * + * Matched on the product SKU rather than the product name: a later batch = of the + * same model could carry a different RT1320 version, which would change t= he + * _ADR. Keying on the SKU keeps this remap to the hardware it was verifie= d on. + */ +static const struct adr_remap microsoft_sp11_intel[] =3D { + /* ghost rt1320 on link0 */ + { + 0x000030025d132000ull, + 0x0000000000000000ull + }, + {} +}; + static const struct dmi_system_id adr_remap_quirk_table[] =3D { /* TGL devices */ { @@ -207,6 +226,15 @@ static const struct dmi_system_id adr_remap_quirk_tabl= e[] =3D { }, .driver_data =3D (void *)ghost_realtek, }, + /* LNL devices */ + { + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"), + DMI_EXACT_MATCH(DMI_PRODUCT_SKU, + "Surface_Pro_11th_Edition_With_Intel_For_Business_2103") + }, + .driver_data =3D (void *)microsoft_sp11_intel, + }, {} }; =20 --=20 2.50.1 (Apple Git-155)