linux-kernel - Re: [PATCH v2 09/29] dt-bindings: clock: mediatek: Describe MT8196 peripheral 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] [day] [month] [year] [list]

Message-ID: <ae478fd7-c627-433c-a614-b76dcd4164d2@collabora.com>
Date: Wed, 25 Jun 2025 14:48:39 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Laura Nao
 <laura.nao@...labora.com>, mturquette@...libre.com, sboyd@...nel.org,
 robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 matthias.bgg@...il.com, p.zabel@...gutronix.de, richardcochran@...il.com
Cc: guangjie.song@...iatek.com, wenst@...omium.org,
 linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, netdev@...r.kernel.org,
 kernel@...labora.com
Subject: Re: [PATCH v2 09/29] dt-bindings: clock: mediatek: Describe MT8196
 peripheral clock controllers

Il 25/06/25 13:06, Krzysztof Kozlowski ha scritto:
> On 25/06/2025 11:45, AngeloGioacchino Del Regno wrote:
>> Il 25/06/25 10:57, Krzysztof Kozlowski ha scritto:
>>> On 25/06/2025 10:20, AngeloGioacchino Del Regno wrote:
>>>> Il 24/06/25 18:02, Krzysztof Kozlowski ha scritto:
>>>>> On 24/06/2025 16:32, Laura Nao wrote:
>>>>>> +  '#reset-cells':
>>>>>> +    const: 1
>>>>>> +    description:
>>>>>> +      Reset lines for PEXTP0/1 and UFS blocks.
>>>>>> +
>>>>>> +  mediatek,hardware-voter:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>> +    description:
>>>>>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>>>>>> +      MCU manages clock and power domain control across the AP and other
>>>>>> +      remote processors. By aggregating their votes, it ensures clocks are
>>>>>> +      safely enabled/disabled and power domains are active before register
>>>>>> +      access.
>>>>>
>>>>> Resource voting is not via any phandle, but either interconnects or
>>>>> required opps for power domain.
>>>>
>>>> Sorry, I'm not sure who is actually misunderstanding what, here... let me try to
>>>> explain the situation:
>>>>
>>>> This is effectively used as a syscon - as in, the clock controllers need to perform
>>>> MMIO R/W on both the clock controller itself *and* has to place a vote to the clock
>>>> controller specific HWV register.
>>>
>>> syscon is not the interface to place a vote for clocks. "clocks"
>>> property is.
>>>
>>>>
>>>> This is done for MUX-GATE and GATE clocks, other than for power domains.
>>>>
>>>> Note that the HWV system is inside of the power domains controller, and it's split
>>>> on a per hardware macro-block basis (as per usual MediaTek hardware layout...).
>>>>
>>>> The HWV, therefore, does *not* vote for clock *rates* (so, modeling OPPs would be
>>>> a software quirk, I think?), does *not* manage bandwidth (and interconnect is for
>>>> voting BW only?), and is just a "switch to flip".
>>>
>>> That's still clocks. Gate is a clock.
>>>
>>>>
>>>> Is this happening because the description has to be improved and creating some
>>>> misunderstanding, or is it because we are underestimating and/or ignoring something
>>>> here?
>>>>
>>>
>>> Other vendors, at least qcom, represent it properly - clocks. Sometimes
>>> they mix up and represent it as power domains, but that's because
>>> downstream is a mess and because we actually (at upstream) don't really
>>> know what is inside there - is it a clock or power domain.
>>>
>>
>> ....but the hardware voter cannot be represented as a clock, because you use it
>> for clocks *or* power domains (but at the same time, and of course in different
>> drivers, and in different *intertwined* registers).
> 
> BTW:
> 
> git grep mediatek,hardware-voter
> 0 results
> 
> so I do not accept explanation that you use it in different drivers. Now
> is the first time this is being upstream, so now is the time when this
> is shaped.

I was simply trying to explain how I'm using it in the current design and nothing
else; and I am happy to understand what other solution could there be for this and
if there's anything cleaner.

You see what I do, and I'm *sure* that you definitely know that my goal is *not* to
just tick yet another box, but to make things right, - and with the best possible
shape and, especially, community agreement.

Cheers,
Angelo