Re: [PATCH 0/4] mtd: rawnand: qcom: Add MDM9607

[Krzysztof Kozlowski <krzk@kernel.org>]

On 06/07/2026 18:00, Manivannan Sadhasivam wrote:
> On Mon, Jul 06, 2026 at 04:42:21PM +0200, Miquel Raynal wrote:
> 
>>> and if the driver queries the frequency of
>>> RPM_SMD_QPIC_CLK, it would just return the same frequency. This is where the
>>> dummy clock comes handy as it atleast provides a valid clock frequency to the
>>> driver. But I'm not advocating for its usage here anymore.
>>>
>>> Hence IMO, assigning the same RPM_SMD_QPIC_CLK to all 3 clocks is not the right
>>> approach and we should be assigning a single RPM_SMD_QPIC_CLK to
>>> 'core' clk.
>>
>> You said using three times the same clock would be wrong because we
>> would get three times the same rate whereas in practice it's wrong. This
>> means the OS has access to these clocks somehow,
> 
> No, there is no way the OS can access these 3 clocks individually on the RPMh
> enabled platforms. But the OS indeed has access to these 3 clocks on non-RPMh
> platforms like the older IPQ ones.

I think RPMh is a bit different case than recently discussed SCMI
firmware layer, although maybe the true difference is irrelevant -
whoever implements the clock handling, it is not Linux. Anyway, in case
of SCMI this is the same die having either firmware or OS controlling
clocks.

Here the SoCs (IPO ones without RPMh and this one with RPMh) are different.

If this was some bus device (I2C, SPI etc), then I would argue that the
device pins matter.

However this is internal part of the SoC, so while it still has some
wirings, they are heavily hidden or abstracted, thus I am fine with
approach that clocks represent the clock interfaces available to the OS,
not the physical wires inside SoC.


Best regards,
Krzysztof