Re: [PATCH 2/2] dt-bindings: usb: add Rohm BM92TXX Type-C controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Bypassing standard `usb-c-connector` binding in favor of vendor-specific properties.
- [Low] DT schema naming violations and missing type definitions.
--

commit 186a26fac988413623e6d85b4dd282c2ff87f8bf
Author: Alexandre Hamamdjian <azkali.limited@gmail.com>

dt-bindings: usb: add Rohm BM92TXX Type-C controller

Add the device-tree binding documentation for the Rohm BM92TXX family
of USB Type-C and Power Delivery controllers. The device is controlled
over I2C and signals state changes through a dedicated interrupt line.

> diff --git a/Documentation/devicetree/bindings/usb/rohm,bm92t.yaml b/Documentation/devicetree/bindings/usb/rohm,bm92t.yaml
> new file mode 100644
> index 0000000000000..007f70a8f5bb1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/rohm,bm92t.yaml
[ ... ]
> +  vbus-source-supply:
> +    description: VBUS source (provider) regulator.
> +
> +  pd_bat_chg-supply:
> +    description: Battery charger regulator gated by Power Delivery state.

Does this violate the DT property naming convention by using underscores
instead of hyphens? Should this be named pd-bat-chg-supply?

> +
> +  rohm,vconn-en-gpio:
> +    maxItems: 1
> +    description: GPIO controlling the external VCONN switch.

This property uses the deprecated -gpio suffix instead of -gpios, which means
the dtschema core will not automatically assign it the phandle-array type.
Could this be renamed to rohm,vconn-en-gpios, or alternatively, could an
explicit type definition be provided?

[ ... ]
> +  rohm,dp-lanes:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [2, 4]
> +    default: 2
> +    description: Number of DisplayPort lanes to negotiate.

This isn't a bug, but should this binding use a connector child node with
compatible = "usb-c-connector" instead of defining custom vendor-specific
properties for USB Type-C and Power Delivery features like rohm,dp-lanes and
the current limits?

The standard approach is to use properties like source-pdos, sink-pdos, and
standard endpoints for data lanes.

[ ... ]
> +  rohm,dock-power-limit-disable:
> +    type: boolean
> +    description:
> +      Disable the lower power limit applied when a dock is detected.
> +
> +  rohm,pd-5v-current-limit-ma:
> +    description: Charging current limit in mA when 5V PD contract is active.

These current limit properties do not use a standard unit suffix recognized by
dtschema (such as -microamp or -milliamp) with auto-typing. Should they
include an explicit type definition like
$ref: /schemas/types.yaml#/definitions/uint32?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510-bm92t-v1-0-dff3c9d22426@gmail.com?part=2