Re: [PATCH 06/10] dt-bindings: ufs: Add compatibles for S32N79 Host Controller platform driver

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

On 8/28/2026 1:28 PM, Krzysztof Kozlowski wrote:
> On Wed, Aug 26, 2026 at 03:40:44PM +0200, Larisa Grigore wrote:
>> +  clocks:
>> +    maxItems: 1
>> +    description: UFS core clock
>> +
>> +  clock-names:
>> +    items:
>> +      - const: core_clk
> 
> _clk is redundant, just "core". Or skip names, not really useful in this
> case.
> 
Thank you for the review Krzysztof! I will remove clock-names.
>> +
>> +  nxp,mphy-boot-mode:
>> +    description: |
>> +      MPHY initialization mode. Defines how the MPHY firmware should be
>> +      initialized and executed during UFS controller startup.
>> +      If this property is not specified, MPHY initialization will be skipped.
> 
> Isn't this implied by the compatible?

Thank you! I will drop this property.

>> +    $ref: /schemas/types.yaml#/definitions/string
>> +    enum:
>> +      - rom
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +allOf:
>> +  - $ref: ufs-common.yaml
>> +  - if:
>> +      required:
>> +        - nxp,mphy-boot-mode
>> +    then:
>> +      properties:
>> +        reg:
>> +          minItems: 2
>> +        reg-names:
>> +          minItems: 2
>> +      required:
>> +        - reg-names
>> +        - clocks
>> +        - clock-names
>> +    else:
>> +      properties:
>> +        reg:
>> +          maxItems: 1
>> +        reg-names:
>> +          maxItems: 1
> 
> I don't get why for the SAME device diffeernt initialization means
> device has different address space or clocks. It's the same device, same
> wiring, same hardware setup.

Thank you, that makes sense.

My initial intention was to distinguish between two ownership models: 
one where Linux performs the complete UFS/MPHY initialization, and 
another where the UFS subsystem has already been initialized by firmware 
and Linux is not expected to configure the clocks or access the SCM 
registers.

Looking at it again, this does not seem to describe a property of the 
hardware itself. In the firmware-managed case, Linux would not be 
expected to touch the SCM area at all, so representing it via a DT 
property is probably not appropriate.

A separate compatible describing the firmware-managed interface may be a 
better fit. What do you think?

Best regards,
Larisa

> Best regards,
> Krzysztof
>