On 04/08/2025 15:58, Krzysztof Kozlowski wrote:

quoted

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