[PATCH v1 5/6] dt-bindings: phy: tegra: Document Nvidia Tegra XMM6260 PHY

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The binding models an external USB/HSIC modem as a standalone, virtual 'PHY' node instead of representing it accurately in the hardware hierarchy.
- [Medium] The `nvidia,usb-bus` property groups two unrelated phandles (USB controller and USB PHY) and introduces a reverse-dependency.
- [Low] The compatible string `nvidia,tegra-xmm6260` uses the incorrect vendor prefix for the hardware it represents.
- [Low] The `nvidia,usb-bus` property is defined as a `phandle-array` but lacks the necessary `items` description to define the cell count, leading to a `dt_binding_check` validation failure.
--

commit 9a3c0eae039eb5a94c2d0ec7ecce7c586c326f99
Author: Svyatoslav Ryhel <clamor95 at gmail.com>

dt-bindings: phy: tegra: Document Nvidia Tegra XMM6260 PHY

This commit documents the XMM6260 PHY binding, a hardware configuration
used in Tegra SoCs to control power sequencing and manage the USB lines
for the modem.

> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> new file mode 100644
> index 0000000000000..0346433c97725
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/nvidia,tegra-xmm6260.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nvidia Tegra PHY for XMM6260 modem
> +
> +description:
> +  A hardware configuration used in Tegra SoCs to provide proper interaction
> +  between the application processor and the modem, as well as control over
> +  one of the SoC's USB lines for the modem.

Is modeling this external modem as a standalone virtual PHY node the best
approach for representing the hardware topology?

The device tree should describe physical hardware hierarchy. Since the
XMM6260 is an external modem connected to the host via a USB or HSIC bus,
it would traditionally be modeled as a child node of the USB controller.

Handling power sequencing by creating a virtual PHY node is a known
anti-pattern. Power requirements are typically managed by the USB subsystem's
device tree bindings or a generic power sequencing framework.

> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95 at gmail.com>
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra-xmm6260

This isn't a bug, but the XMM6260 is a modem manufactured by Infineon/Intel.
Should the compatible string use a vendor prefix corresponding to the actual
manufacturer (e.g., "infineon" or "intel") instead of "nvidia", since this
represents an external component rather than a Tegra-specific SoC block?

> +
> +  enable-gpios:
> +    description: GPIO connected to the EINT1 pin
> +    maxItems: 1
> +
> +  nvidia,usb-bus:
> +    description:
> +      Contains two phandles; the first is pointing to the Host's USB controller
> +      and the second linking to the controller's PHY.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    minItems: 2
> +    maxItems: 2

Does this custom property introduce an unnecessary reverse-dependency in the
device tree?

Standard bus hierarchy dictates that relationships are established naturally
via parent-child nodes. Pointing an external device back to its host
controller via a custom phandle is a non-standard way to represent a bus
connection. Additionally, grouping two distinct hardware components (a host
controller and its PHY) into a single phandle array mixes unrelated
references.

Can this property definition cause a validation failure during
dt_binding_check?

Because this is typed as a phandle-array, the dtschema validation framework
will attempt to parse the array elements by looking for a
"#nvidia,usb-bus-cells" property on the referenced target nodes (the USB
controller and PHY). Since those target nodes won't define that custom cells
property, the example schema validation is likely to fail.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511135703.62470-1-clamor95@gmail.com?part=5