Re: [PATCH 1/3] dt-bindings: soc: realtek: Add Realtek DHC I/O level detector

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The binding models a software routine as a virtual hardware node, improperly hijacking pin control from disjoint peripherals.
--

commit fcf36e305148fab2c941a519260634bf6fcea792
Author: Tzuyi Chang <tychang@realtek.com>

dt-bindings: soc: realtek: Add Realtek DHC I/O level detector

This commit adds device tree binding documentation for the Realtek DHC
I/O level detector. The block detects I/O signaling levels and applies
pad configurations via pinctrl states.

> diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml

[ ... ]

> +properties:
> +  compatible:
> +    const: realtek,rtd1625-io-detect
> +
> +  pinctrl-names:
> +    items:
> +      - const: rgmii_1v8
> +      - const: rgmii_3v3
> +      - const: sdio_1v8
> +      - const: sdio_3v3
> +      - const: csi_1v8
> +      - const: csi_3v3
> +      - const: sd_1v8
> +      - const: sd_3v3
> +      - const: uart1_1v8
> +      - const: uart1_3v3
> +      - const: aio_1v8
> +      - const: aio_3v3
> +      - const: emmc_1v8
> +      - const: emmc_3v3

[Severity: High]
Does this centralized approach prevent the actual peripheral drivers from
managing their own pins dynamically?

For example, MMC/SDHCI drivers typically need to switch between 1.8V and
3.3V pinctrl states during UHS enumeration. By statically claiming all
these disjoint states (RGMII, SDIO, eMMC, etc.) in a single node, does
this strip the individual peripheral drivers of their pin ownership and
break standard subsystem-level pin management?

> +
> +  realtek,iso-pinctrl:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      Pinctrl phandle containing I/O detection registers.

[Severity: High]
Does this binding describe a software routine rather than actual
hardware topology?

Since there is no reg property and the node accesses registers via the
realtek,iso-pinctrl phandle, this appears to model a virtual device node.
Device tree principles typically require describing hardware topology.

Could the I/O detection logic be modeled within the actual pinctrl
hardware node or peripheral nodes instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604111821.975624-1-eleanor.lin@realtek.com?part=1