Re: [PATCH v10 08/11] dt-bindings: ufs: Add NXP S32N79 UFS host controller
From: Larisa Ileana Grigore
Date: Wed Nov 11 2026 - 02:59:57 EST
On 11/9/2026 11:42 PM, Krzysztof Kozlowski wrote:
On 09/11/2026 21:47, Larisa Ileana Grigore wrote:Hi Krzysztof,
On 11/5/2026 8:28 PM, Krzysztof Kozlowski wrote:
On 04/11/2026 10:41, Larisa Ileana Grigore wrote:
On 11/4/2026 10:40 AM, Krzysztof Kozlowski wrote:
v8:
https://lore.kernel.org/all/20261013103003.373156-1-larisa.grigore@xxxxxxxxxxx/
v9:
https://lore.kernel.org/all/20261024122533.3609180-1-larisa.grigore@xxxxxxxxxxx/
v10:
https://lore.kernel.org/all/20261103133215.1385823-1-larisa.grigore@xxxxxxxxxxx
Regarding your comments on v9:
Frank's Reviewed-by was given publicly on v8 [1]. The series only looked
like a v1 because of the wrong version number.
The tag ordering was changed in v10 since the patch was changed.
The single 0 Hz OPP entry: as discussed on v8 [2][3], the clock rate is
set outside Linux and is not scaled. The OPP table lets the UFS core
That is not the purpose of OPP table. OPP defines performance point.
Performance point of 0 makes no sense. You cannot use Linux limitations
as reason to add some DTS, because answer is simple: fix your Linux
limitations.
Hi Krzysztof,
Thanks for the clarification. I understand that an OPP table is not
appropriate here.
Existing platform DTs, such as Hi3660 and MT8195, define freq-table-hz
containing only <0 0> pairs. This allows the UFS core to manage clock
enable/disable without setting their rates. With freq-table-hz
deprecated, there seems to be a gap for this use case, beyond S32N.
Instead of passing 0, properties should be rather missing and that would
be hint for Linux. Is there a difference between missing properties and
some non-valid state (like freq=0)?
You are right, this Linux-specific distinction should not be reflected in DT, even though missing both properties currently leaves clock management to the glue driver.
For v11, I will drop the OPP table and introduce ufshcd_pltfrm_init_flags(), with a flag indicating that the DT clocks have a fixed rate and should still be registered and managed by the UFS core. The existing ufshcd_pltfrm_init() will remain as a wrapper passing no flags, so existing drivers will retain their current behavior. The S32N79 driver will call the new function with this flag set.
Would this approach be acceptable?
Best regards,
Larisa
Best regards,
Krzysztof