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: <2567a939-4938-4c92-8893-83d03ff8767f@kernel.org>
Date: Mon, 1 Sep 2025 09:48:19 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Tudor Ambarus <tudor.ambarus@...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>,
 André Draszik <andre.draszik@...aro.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...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 v2 4/5] firmware: exynos-acpm: register ACPM clocks dev

On 01/09/2025 08:56, Tudor Ambarus wrote:
> 
> 
> On 8/31/25 11:50 AM, Krzysztof Kozlowski wrote:
>> On 27/08/2025 14:42, Tudor Ambarus wrote:
>>> +
>>> +static const struct acpm_clk_variant gs101_acpm_clks[] = {
>>> +	ACPM_CLK(CLK_ACPM_DVFS_MIF, "mif"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_INT, "int"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_CPUCL0, "cpucl0"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_CPUCL1, "cpucl1"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_CPUCL2, "cpucl2"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_G3D, "g3d"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_G3DL2, "g3dl2"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_TPU, "tpu"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_INTCAM, "intcam"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_TNR, "tnr"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_CAM, "cam"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_MFC, "mfc"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_DISP, "disp"),
>>> +	ACPM_CLK(CLK_ACPM_DVFS_BO, "b0"),
>>> +};
>>
>> I don't understand why clocks are defined in the firmware driver, not in
>> the clock driver.
> 
> I chose to define the clocks in the firmware driver and pass them as 
> platform data to the clock platform device for extensibility. In case
> other SoCs have different clock IDs, they'll be able to pass the

You will have to modify firmware driver, so still at least one driver
has to be changed. Having clocks defined in non-clock driver is really
unusual.

This solution here creates also dependency on clock bindings and makes
merging everything unnecessary difficult.

> clock data without needing to modify the clock driver. GS201 defines
> the same ACPM clocks as GS101, but I don't have access to other newer
> SoCs to tell if the ACPM clocks differ or not.
> 
> The alternative is to define the clocks in the clock driver and
> use platform_device_register_simple() to register the clock platform
> device. The clock driver will be rigid in what clocks it supports.
> 
> I'm fine either way for now. What do you prefer?

Please move them to the driver.

> 
>>
>> This creates dependency of this patch on the clock patch, so basically
>> there is no way I will take it in one cycle.
> 
> Would it work to have an immutable tag for the clock and samsung-soc
> subsytems to use?

No, just try yourself. Patch #3 depends on patch #2, so that's the cross
tree merge. It's fine, but now patch #4 depends on patch #3, so you need
two merges.

Or how do you actually see it being merged with immutable tag? What goes
where?


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ