Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support

["Alexey Klimov" <alexey.klimov@linaro.org>]

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 >= 0)
>> 		return 0;
>> 
>> 	pr_debug_ratelimited("ACPM tmu call returned: %x\n", fw_err);
>> 	or pr_debug(...);
>> 
>> 	if (fw_err == -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 any
>> 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 == -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.

Maybe we can utilise build info date from SRAM initdata base to
distinguish between different version of ACPM firmware implementations.
Sadly I was told that specs doesn't provide any version info.
Or probe for implemented calls but that may break ACPM firmware
potentially.

You also mentioned that there are capabilities returned by TMU init
call. Maybe that one can be used somehow.

Thanks,
Alexey