From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 069AF3ED12B for ; Thu, 21 May 2026 13:37:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779370656; cv=none; b=Do0ZC9tY8uAWhQrLc0cBi6fPhpXw2vh2z9ZHYCLOLqDycGdlfrpnqfPa2Q+x/+V15hD9Z0Jdr/EyDxRv0XY/DpPtpuwbdY0Pck99sBID2+C+WqtqHHmWvOLrg066eXmFad1CfFfDGyE9uwiP2eOrO5GTuIG3dKRv/A6g7kL+Lns= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779370656; c=relaxed/simple; bh=Ks3+rpy46FU5SfeZckGpUYKSWPJ7B/Tafw2dsVlfXZ8=; h=Mime-Version:Content-Type:Date:Message-Id:To:Cc:Subject:From: References:In-Reply-To; b=n62gGdhFnz5ersL0/Cq7R1JVDE5DA8I+c4dRzcWeqclN9yN1xPNtk/xfTD0F6wASOr15/ApQ1lWwWsG00/rtyBwVyO6xQ6XJZ1XPt9DuC6enfFa8Qiv9IqP9c3cNXBR+jVf776nG6DpUzSSBWPqp+jr5MgR5jzCaf7nabWuIamw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=j9g4oMDl; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="j9g4oMDl" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-45297094718so4921684f8f.3 for ; Thu, 21 May 2026 06:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1779370653; x=1779975453; darn=vger.kernel.org; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BMlAK2z/O8nXAXVGpgv2TVPDYvKc2M33iVdUjIQEOVI=; b=j9g4oMDlPTX1vmuxUA2/wDDvpem+0BSJlHdFpIGuuWpsbTyEwJlznC79mKi1N1Tb5i RcztslsP95zC0710ovVdm7Cm9jJ+pCPvmmZKiHxv37x9kWpZZKlZCMmBznz7bX4QUFOk UIP6RgBriCsV8tIU5pFW7uE84GZW52pr9V/ze3dFsk7WwtI0PzunqRL+nbcUEDFdJak5 YUibK0af/CZqGd+bkQ4YrDgG0LcMRPcTQVquFNoX4YxXARLgibm5h85h5n97/2YzzFbW 4KGnuOffL5CtfO/mYiF8nn8E/y4/EslhQ8tJqbQyWZteFjXDmPWLNSxLH8JozS9ADxyv 3k9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779370653; x=1779975453; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BMlAK2z/O8nXAXVGpgv2TVPDYvKc2M33iVdUjIQEOVI=; b=ILz2S10byeRTpz8SnSnULMb6M+QnTPOTTGEocUlOqRvJODoNyxFaMkVS/N+PRFnD/h CtLiApeWnvUy4ndhGLPGl35TUZZLFzhL6GYF4Nt4LfYeI+c525/4IXuNZtEUcsAYM+09 EtUHGpgKBlEF0GKuci2ct4C72nvmcDUywBtN/euT5BEiP0xOssLMHjFwyn4n7TOwo/rO jRt0yMl67aJATFraxUoR08g1wYXhV3tmMZoZQg2QUUjQRd3ARGPzEmF7bjPCRhRbDTXg YhjL7Pe0zZQ/m6QUAldfXSb5AVqtvAcsAEXHkwvSYwGjrhGHSRQjYG6u+0bSNvAjKFpS Ls8w== X-Forwarded-Encrypted: i=1; AFNElJ+pMUnI8XPMl0Z0M1aJI9tH6CJPP9iScl+E4fOnbNlUg/GQoi5/paPDcn05g15e0IEaL5TF7IrEqJg9rDg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6ZsdPBUOESaC50CMtzqXXgk7swA7IS1gGuKbK4h+fIO0x2gHr 8WR1cYoK+FT/Ue2SNBQAyqleSczI4f76ftT4J9qNc/FbZOycB+jMhb+9xJ4X67//E3Egli+Taob UawuhVOw= X-Gm-Gg: Acq92OHc2kTzXuBv7mXPwbhs9iNS9rLp00eSVeWCMatNugp6ydL+S23NZNa394Q7VEz Eb9X7fRn1N9MAVQN9o0gvFRPG/XRtACnKFTS+OqeNGpQKuKHXJsvaEtLn1SGSthyT7wAyqu9lMn +ewi8/zW61UuX3XLChq148ntICxU59f9dyNaMcC9495zUv6RRPUnflYO6EXwYm1Vhhde2n2rIAf o+LTxeb0ftbx7ipwqLAJfAS5OzYmkc04jVKoDjJrQm8XtWyONriwOonWRSk9gH963GUW8kSRZub MGgIhC3BnY6kBUUPubd7iYex4HrFfhYlUl85nW+b+T/3G3FUrUCT08UN0v7ILVErM2SzYGNlylj mbBWpaC+k8/jY3rbeOOdHmp8dxqroX4VMTsdqdDNr/558W7IxXMYA/8QzHboT+7ohFlsmk9oUR0 ELSUXTf4+sSz5aO4i7fMy5n/j1kd/mkCfl52NtbOT2HuSQsycIuhoJTK0eor4TI0NuMTzTEu+37 SAjZZAEhrqtohcYag== X-Received: by 2002:a05:6000:41fc:b0:45e:739b:3e43 with SMTP id ffacd0b85a97d-45ea344aedbmr4835322f8f.0.1779370653284; Thu, 21 May 2026 06:37:33 -0700 (PDT) Received: from localhost ([2a00:2381:fd67:101:7fde:b714:8ff7:ea6e]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45eaa7cd815sm4331310f8f.6.2026.05.21.06.37.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2026 06:37:32 -0700 (PDT) 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 Date: Thu, 21 May 2026 14:37:31 +0100 Message-Id: To: "Peter Griffin" Cc: "Tudor Ambarus" , "Krzysztof Kozlowski" , "Michael Turquette" , "Stephen Boyd" , "Lee Jones" , "Alim Akhtar" , "Sylwester Nawrocki" , "Chanwoo Choi" , =?utf-8?q?Andr=C3=A9_Draszik?= , , , , , , , "Krzysztof Kozlowski" Subject: Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support From: "Alexey Klimov" X-Mailer: aerc 0.20.0 References: <20260506-acpm-tmu-helpers-v1-0-a9cd5daf8355@linaro.org> <20260506-acpm-tmu-helpers-v1-5-a9cd5daf8355@linaro.org> <806da86b-45b7-43cc-b364-97bade8f4041@linaro.org> <73f18a2c-e729-45d7-9376-7c0e60ed35c7@linaro.org> In-Reply-To: On Thu May 21, 2026 at 9:25 AM BST, Peter Griffin wrote: > Hi Alexey, > > On Wed, 20 May 2026 at 22:01, Alexey Klimov wr= ote: >> >> Hi Tudor, >> >> On Tue May 19, 2026 at 4:46 PM BST, Tudor Ambarus wrote: >> > Hi, Alexey, >> > >> > On 5/18/26 2:24 PM, Alexey Klimov wrote: >> >> Thinking further about this I'd humbly suggest that even >> >> >> >> if (fw_err >=3D 0) >> >> return 0; >> >> >> >> pr_debug_ratelimited("ACPM tmu call returned: %x\n", fw_err); >> >> or pr_debug(...); >> >> >> >> if (fw_err =3D=3D -1) >> >> return -EACCES; >> >> >> >> some debug message would do. >> >> Perhaps we need some convertation, for instance as it is done in scmi >> >> code (scmi_to_linux_errno(), scmi_linux_errmap[]). But I don't have a= ny >> >> data for mapping acpm errors to some human meanings. >> > >> > I did that for the pmic helpers. I don't need any debug prints for >> > gs101 TMU as I have clear instructions from firmware: 0 for success, >> > -1 for error. >> >> This doesn't look like a right approach for upstreaming a ACPM TMU >> framework. >> >> You are trying to submit a gs101-specific implementation masquerading >> it as a generic ACPM TMU framework, while explicitly pushing the >> refactoring work onto the next developer to add support for other >> SoCs in this generic ACPM code. >> >> The ACPM TMU protocol implementation on Exynos850 is different: it uses >> different error codes, and half of the calls in this 'generic' driver >> are not even implemented in the Exynos850 firmware. Relying on a >> hardcoded if (fw_err =3D=3D -1) in a driver named generic ACPM is broken >> by design and may silently swallow critical firmware errors on other >> SoCs. >> >> What about such options below? >> - rename the driver to reflect reality: rename this specifically to >> gs101-acpm-tmu-something to reflect that it is tailored for gs101-s; >> >> or >> - abstract the firmware error handling paths through driver_data or >> a dedicated ops structure now, so that other SoCs can cleanly hook into >> it without having to rewrite the logic later. > > AFAIK it's pretty normal not to add new hooks before they are > required. I think the approach taken in this series makes sense, as > it's the developer adding support for SoC #2 who best knows what the > differences are on their platform versus what exists upstream. > Similarly, the developer adding support for SoC #3 may have different > requirements to e850 and gs101 and that developer is best placed to > refactor and add hooks or quirks that are required for that platform. > > Let's not try to boil the ocean with this series, it's targeting GS101 > support. We can evolve it for future SoCs as those requirements and > differences become clear. Peter, I agree we shouldn't bother about hypothetical SoCs. However, Exynos850 is not hypothetical (I guess SoC #2 in this text). It is possible to take set of patches from maillist, copy acpm DT node from gs101 (minimal compatible rename) and it will be Exynos SoC with enabled ACPM. I am also actively working on it. Hooks or whatever other way of handling firmware error codes are required now. We actually already know the differences: different error codes and only 4 ACPM TMU calls are implemented on e850: TMU init, TMU read temperature, TMU suspend/resume. Extra TMU calls are fine since we can just do not use them from thermal driver but hiding correct error codes, well, that's another story. We already know this way of handling firmware codes is not ACPM TMU generic. The ACPM TMU part of gs101 ACPM firmware might be a vendor-specific fork. We shouldn't assume it strictly adheres to the reference Samsung ACPM TMU design. Alexey