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

[Miquel Raynal]

On 06/07/2026 at 18:18:15 +02, Krzysztof Kozlowski <krzk at kernel.org> wrote:

> 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.

Thank you very much for this feedback. I understand the rationale, and
will keep that in mind for future reviews.

Best regards,
Miquèl