Re: [PATCH v2 5/9] dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller

[Marek Vasut <marex@nabladev.com>]

On 8/18/26 10:15 AM, Krzysztof Kozlowski wrote:
> On Sun, Aug 16, 2026 at 11:37:07PM +0200, Marek Vasut wrote:
>> +properties:
>> +  compatible:
>> +    const: st,stm32mp25-dwc3
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  access-controllers:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    minItems: 3
>> +    maxItems: 3
>> +
>> +  clock-names:
>> +    items:
>> +      - const: ref
>> +      - const: bus_early
>> +      - const: suspend
>> +
>> +  dr_mode:
>> +    $ref: /schemas/types.yaml#/definitions/string
>> +    enum: [host, peripheral, otg]
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  phys:
>> +    minItems: 1
>> +    maxItems: 2
>> +
>> +  phy-names:
>> +    minItems: 1
>> +    items:
>> +      - const: usb2-phy
>> +      - const: usb3-phy
>> +
>> +  resets:
>> +    minItems: 1
> 
> Hm? You keep coming with some odd style, not present in any other files.
> Where do you see such code - property followed by minItems alone? This
> applies to other places as well.

This should clearly be maxItems: 1, fixed, thanks .

>> +
>> +  st,syscfg:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +    description: Phandle to system configuration controller.
>> +    items:
>> +      - items:
>> +          - description: phandle to syscfg
>> +          - description: USB3DR control offset within syscfg
>> +
>> +  st,enable-port-power-control:
>> +    type: boolean
>> +    description: Enable Host-Mode Port Power Control (bit-3 of capability param HCCPARAMS)
> 
> Why wouldn't this be enavled always? Why is this a board-level property?

A board can have external USB power controller chip like TCPP02/TCPP03 
and the DWC3 IP does not control the port power directly. This seems to 
be common on the STM32MP2 . Hence this property, which disables the port 
power control functionality in DWC3 IP and lets the chip do it instead.

>> +
>> +  st,ovrcur-active-low:
> 
> Don't re-invent stuff:
> st,over-current-active-low

It seems I can even use generic "over-current-active-low" .

>> +    type: boolean
>> +    description: Over-Current signal polarity is active-low
>> +
>> +  st,vbusen-active-low:
>> +    type: boolean
>> +    description: VBUS-ENABLE signal polarity is active-low
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +  - interrupts
>> +  - phys
>> +  - phy-names
>> +  - resets
>> +  - st,syscfg
>> +
>> +unevaluatedProperties: false
> 
> So where did you reference any other schema - for properties here and
> for this unevaluatedProps?

I seem to be getting this one wrong all the time, so let me ask -- when 
do I use unevaluatedProperties:false and when additionalProperties:false 
, what is the rule of thumb here ?

>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/st,stm32mp25-rcc.h>
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +    #include <dt-bindings/reset/st,stm32mp25-rcc.h>
>> +
>> +    usb3dr: usb@48300000 {
> 
> Drop unused label
Done, thanks.