linux-kernel - Re: [PATCH v3 09/27] dt-bindings: clock: mediatek: Describe MT8196 clock controllers

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: <ed0884fc-e43a-4f5b-8701-3645c406b37d@kernel.org>
Date: Mon, 4 Aug 2025 16:19:10 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Laura Nao <laura.nao@...labora.com>, wenst@...omium.org
Cc: conor+dt@...nel.org, devicetree@...r.kernel.org,
 guangjie.song@...iatek.com, kernel@...labora.com, krzk+dt@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
 matthias.bgg@...il.com, mturquette@...libre.com, netdev@...r.kernel.org,
 nfraprado@...labora.com, p.zabel@...gutronix.de, richardcochran@...il.com,
 robh@...nel.org, sboyd@...nel.org
Subject: Re: [PATCH v3 09/27] dt-bindings: clock: mediatek: Describe MT8196
 clock controllers

On 04/08/2025 15:58, Krzysztof Kozlowski wrote:
>>
>> So, what should we do then?
>>
>> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
>> saying that this is called "Hardware Voter (HWV)" in the datasheets?
>>
>> Or is using the "interconnect" property without any driver in the interconnect API
>> actually legit? - Because to me it doesn't look like being legit (and if it is, it
>> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
>> when encountering an "interconnect" property in DT), and if so, we should just add
> 
> Why you would not add any interconnect driver for interconnect API?
> Look, the current phandle allows you to poke in some other MMIO space
> for the purpose of enabling the clock FOO? So interconnect or power
> domains or whatever allows you to have existing or new driver to receive
> xlate() and, when requested resources associated with clock FOO.

Something got here cut. Last sentence is supposed to be:

"So interconnect or power
domains or whatever allows you to have existing or new driver to receive
xlate() and, when requested, toggle the resources associated with clock
FOO."

> 
> Instead of the FOO clock driver poking resources, you do
> clk_prepare_enable() or pm_domain or icc_enable().

I looked now at the driver and see your clock drivers poking via regmap
to other MMIO. That's exactly usecase of syscon and exactly the pattern
*we are usually discouraging*. It's limited, non-scalable and vendor-driven.

If this was a power domain provider then:
1. Your clock drivers would only do runtime PM.
2. Your MCU would be the power domain controller doing whatever is
necessary - toggling these set/clr bits - when given clock is enabled.
And it really looks like what you described...


Best regards,
Krzysztof