linux-kernel - Re: [PATCH v5 2/5] firmware: exynos-acpm: add DVFS protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <586c85d8-7638-4e52-8f96-1aa4640afe64@linaro.org>
Date: Fri, 26 Sep 2025 10:15:05 +0100
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: André Draszik <andre.draszik@...aro.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Peter Griffin
 <peter.griffin@...aro.org>, Michael Turquette <mturquette@...libre.com>,
 Stephen Boyd <sboyd@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
 Alim Akhtar <alim.akhtar@...sung.com>,
 Sylwester Nawrocki <s.nawrocki@...sung.com>,
 Chanwoo Choi <cw00.choi@...sung.com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-clk@...r.kernel.org, willmcvicker@...gle.com, kernel-team@...roid.com
Subject: Re: [PATCH v5 2/5] firmware: exynos-acpm: add DVFS protocol

Hi, André!

On 9/24/25 4:24 PM, André Draszik wrote:
>> +	unsigned long (*get_rate)(const struct acpm_handle *handle,
>> +				  unsigned int acpm_chan_id,
>> +				  unsigned int clk_id, u32 dbg_val);
> Everything seems self-explanatory except this dbg_val. What are API users meant
> to put there? Maybe some kerneldoc could explain it?

I don't really know, there's no documentation. I can guess by reading the
downstream code.

Grepping the downstream sources reveals that this field has a value
other than zero just for the edgetpu driver.

Looking there I see:
#define TPU_DEBUG_REQ (1 << 31)
#define TPU_VDD_TPU_DEBUG (0 << 27)
#define TPU_VDD_TPU_M_DEBUG (1 << 27)
#define TPU_VDD_INT_M_DEBUG (2 << 27)
#define TPU_CLK_CORE_DEBUG (3 << 27)
#define TPU_CLK_CTL_DEBUG (4 << 27)
#define TPU_CLK_AXI_DEBUG (5 << 27)
#define TPU_CLK_APB_DEBUG (6 << 27)
#define TPU_CLK_UART_DEBUG (7 << 27)
#define TPU_CORE_PWR_DEBUG (8 << 27)
#define TPU_DEBUG_VALUE_MASK ((1 << 27) - 1)

And then I see methods like:
static int edgetpu_ctl_rate_get(void *data, u64 *val)
{
        *val = exynos_acpm_get_rate(TPU_ACPM_DOMAIN,
                                    TPU_DEBUG_REQ | TPU_CLK_CTL_DEBUG);
        return 0;
}

or:
static int edgetpu_vdd_tpu_m_get(void *data, u64 *val)
{                                                                                                                                                                                              
        *val = exynos_acpm_get_rate(TPU_ACPM_DOMAIN,
                                    TPU_DEBUG_REQ | TPU_VDD_TPU_M_DEBUG);
        return 0;   
}

These methods are used only to be exposed for debugfs.

So it seems it's used to __get__ clock rates or voltages, and that the dbg_val
acts as a debug command that also specifies a secondary ID, TPU_ACPM_DOMAIN
being the first.

I find this a little ambiguous, so I refrained myself from adding a description.
Since I can't tell what it is, and whether TPU is really the only user or not,
I propose drop the argument or not describe it, as I already did. What's your
preference?

Thanks!
ta