From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9C5C3F9F2E for ; Fri, 14 Aug 2026 07:16:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786691776; cv=none; b=kV5c3nyJS/1ZTxQptsWd9idTSNvtSD1Os5QzR3FeGKseiw4I76vrWobEQlQ5YX7Gij8o/brMhlAolIsWMi11W/Imw/ejVzGCg/wF3BUCEDpyvaZ9o0lUiV+YdVyusEpERJA4x6YnDiP8sNg18x16ZD+0A7H1fZ5rvTtqTV0APjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786691776; c=relaxed/simple; bh=E9CaKmu80WzLNW0pIDgymQDLhH1SIUPZwlcDxrvu310=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=hJ43DhSi16xMNTtIPW5cIrKTb8nRp8n3ig/ZuzEX7vuqCHrzj8gxCu6NUUWuHjGIjgnrI8qMKgHl1KNcI9iL3HZV3mZ4oRhgA0+aDn1y1Y2qjFYPHMsLAVjZ73wrR56EMIpG0KESeKmw5YPAd4Yd2/qYMfTcUr32RkeifEKu7Xk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Z3RB6I3S; arc=none smtp.client-ip=209.85.208.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Z3RB6I3S" Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-39c86ce9e29so4315971fa.3 for ; Fri, 14 Aug 2026 00:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786691770; x=1787296570; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=blT0MxqalZ5HOlImHasYYT1NLWsOkpcDnw9nq0AxdEo=; b=Z3RB6I3S061WDuEjUh/2wicGt0duu2kWt35R1yui13rJBicPB8ObO3IGx2zouLKNz5 PrcGpx/Wz6sLenuc+7Nb3MxiGtr56Dmih+pI5ObFDMpNi58J0SyIdSa66iub5Xoroc7u ioZS3IH6/Ztz44reNJsP7fN9a0eyl+QSzpsAH+cjaqU2P3zDWT7NSLZG5D6epC59dz0M Pco2qQRXhTmfZCbvAAeHeXymweznAC/Ykr9Xh4emvO+WPncwUvAzc9YUPGIJKHIAcdgJ FhJtzyPOuim6viiNT8pW2wvANIHikF/oVSZs/fdPnGfvKmzT6jQ2ltDWO0hMWak9RM1A C47A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786691770; x=1787296570; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=blT0MxqalZ5HOlImHasYYT1NLWsOkpcDnw9nq0AxdEo=; b=O/w8lSb9TMI+w0FBZnimk4Z9j6VswNKE2wIW4+5S4mkgeQhTfUsFem4GtY+7q7H/aV D8n7AQW10xfr5D04VZo24tMPfK7NXKHGzpY7dOiEKeRbWmQ8U0LZnv1Gf7mKKNYXJQ0x 5DjofU6ejirfXBa8rGL8augmo4fVBvLunEn4tGO/UWux47eyrezgw1BM55Trj3X8du/5 84LC16zYSDv/Iw+8WgGbVHV7jIMMVBI2iRipHOjphXcjGiZ76+T2HhZb2YxdTnub/z0j Nt/sno2uVC6A83hq41EjX0E65ic+ovsf4pzQQ/I1WjVX3ZuM7RGsoSLNgA3dUIuGe8Fs zJDA== X-Forwarded-Encrypted: i=1; AHgh+RpdJEvf1stOLnMWo3UU5EBzj8v978tmQcT+LL3jK+NZUUs/rOTzLY9PHG5SSYecq3XG/DPqbdlpZffuEIY=@vger.kernel.org X-Gm-Message-State: AOJu0YwdwHdqPlyCyCNl0uaPjqk4Op/qardqgflJiNee26h2VdC+3SHH UvEMYJw6YSC+bu2/hgGNqAkafBbGHLEVjrXUDtlAQCJLNsIVd9z3L/rp X-Gm-Gg: AR+sD13LVKBPPbpdk3MRg5fT1uZK7fVKdpluc442kUhiH6Gyx6LqPxtXb+KHuJ2mPuP j/5RTIxZN1Lxbr19KaB1qd5UTigV3w0i97yHcUbma7O1HdGfN/3m/7d++Unu9yoPgXQEvJjiH8C LQxMkgYnUN2bmzkacrAIxwEtgvXYDcwOl5nhVgjEWFcEu/u3Mb48d+DAQGuTVZKAVf228wey6GF Sq+/LK2Ibn+EQaBTWsNxvgrkHPHlHFLWx47tFKYBvGm895fBNUsLtO6aV5kIvSfM8zGXD5qQIVD Wp/dsNx9Y/PgOPP+27ZLwueNx5TLQYpuxHO2FhzaZFkNv/d8tUVnGqNU63GIWkmPFzyDrIIWYx2 uKWb/6S7OXXo8JvDQNrdOwGDkK4BkyWKY4lEg7fotiCTer7UyIiKe5VBJep1YpNc1QnAO1lohm5 Wec0tkaWlS1ondFudzjEv18WDAwtPkiFA4Cfps98ZZCWe1CFQuZirLR/gaIqIjO+sNBjcsAPBXS EHLPlZnLUy9YTdqOYcxsMTyGsEgF5MYiw== X-Received: by 2002:a05:651c:30ca:b0:39a:d587:ceaf with SMTP id 38308e7fff4ca-3a132408060mr3033751fa.8.1786691769649; Fri, 14 Aug 2026 00:16:09 -0700 (PDT) Received: from localhost (host-80-73-162-2.rev.as20985.net. [80.73.162.2]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3a130cfb752sm4439391fa.29.2026.08.14.00.16.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 00:16:09 -0700 (PDT) From: Andrey Golovko To: Shenghao Ding , Kevin Lu , Baojun Xu , Sen Wang , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai Cc: "Holalu Yogendra, Niranjan" , Pierre-Louis Bossart , Charles Keepax , Vijendar Mukunda , Antoine Monnet , Robin Everaars , Ville Saarinen , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/2] ASoC: tas2783-sdw: fix the read-only Control handling Date: Fri, 14 Aug 2026 09:40:00 +0300 Message-ID: <20260814094000.22118-1-andrey.golovko@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The two read-only Control patches from 13 August, resent together as a series because the second one depends on the first, and with the change Mark asked for. He pointed out that the XU22 Control 0x14 in the read-only list is SDCA_CTL_XU_FDL_STATUS, which sdca_fdl_process() writes. He is right, and the description I gave it - "firmware download status" - reads like a status the device owns, which it is not. It is a handshake: the device sets the bits it owns, and the host writes its response back into the same Control, keeping the device bits, which is exactly what sdca_fdl_process() does with response | (status & ~SDCA_CTL_XU_FDLH_MASK). So it is out of the list in 1/2. Whether the write is reachable on this device today: the driver registers no SDCA interrupts and never calls into sdca_fdl.c. It downloads its firmware itself, with request_firmware_nowait() and its own container format in tas2783_fw_ready(), and the machines I have describe no Smart Amp SDCA function in the BIOS at all, so nothing populates the interrupt that would drive the state machine. But the Function does implement the FDL Controls - the driver lists 0x10 and 0x12 through 0x16 in its defaults - so the state machine is a plausible thing for this driver to grow, and _regmap_write() answers -EIO for a register the callback refuses. That would break the handshake at the first response. Not a trap worth planting for one entry in a list. 2/2 still keeps the Control out of the cache, and now says why on its own: sdca_fdl_process() reads it to see what the device asked for, and a cached answer would hide the device half of the handshake. Writable and volatile, which is the normal shape for a handshake register. The two are otherwise unchanged. The behaviour I measured on an ASUS ProArt PX13 for v1 stands: the calibration data written at probe is byte for byte what it was before the series, and a read of the PDE23 actual power state answers 0x0 with the Function powered, where before it answered the 0x3 placeholder from the defaults. The only difference in v2 is that a write to the File Download Status is no longer rejected, and nothing in the driver issues one. The questions in 1/2 stand as well: the list is static because sdca_regmap_writeable() is not available to a driver running its fallback tables, so it would be good to have it confirmed against the documentation, and to know whether the read-only Controls were meant to be in tas2783_reg_default[] at all. Andrey Golovko (2): ASoC: tas2783-sdw: do not treat read-only Controls as writable ASoC: tas2783-sdw: do not cache read-only Controls sound/soc/codecs/tas2783-sdw.c | 99 +++++++++++++++++++++++----------- 1 file changed, 68 insertions(+), 31 deletions(-)