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

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>,
	 Stephan Gerhold <stephan.gerhold@linaro.org>,
	 Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	 Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	 linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org,
	 devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] mtd: rawnand: qcom: Add MDM9607
Date: Tue, 07 Jul 2026 08:31:15 +0200	[thread overview]
Message-ID: <8733xvjop8.fsf@bootlin.com> (raw)
In-Reply-To: <47bd85c0-f015-4c43-b616-c249596d7537@kernel.org> (Krzysztof Kozlowski's message of "Mon, 6 Jul 2026 18:18:15 +0200")

On 06/07/2026 at 18:18:15 +02, Krzysztof Kozlowski <krzk@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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/