Re: [PATCH v10 08/11] dt-bindings: ufs: Add NXP S32N79 UFS host controller

[Larisa Ileana Grigore <larisa.grigore@oss.nxp.com>]

On 11/9/2026 11:42 PM, Krzysztof Kozlowski wrote:
> On 09/11/2026 21:47, Larisa Ileana Grigore wrote:
>> 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@oss.nxp.com/
>>>> v9:
>>>> https://lore.kernel.org/all/20261024122533.3609180-1-larisa.grigore@oss.nxp.com/
>>>> v10:
>>>> https://lore.kernel.org/all/20261103133215.1385823-1-larisa.grigore@oss.nxp.com
>>>>
>>>> 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)?
> 
Hi Krzysztof,

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