Re: [PATCH v1 3/6] dt-bindings: display: tegra: Document 8-bit CPU parallel interface

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dt-bindings: tegra: internal DC engine modeled as standalone bridge
--

commit 01a8f6463a12799df86627d43eafd7a2899a713e
Author: Svyatoslav Ryhel <clamor95@gmail.com>

dt-bindings: display: tegra: Document 8-bit CPU parallel interface
    
Introduces a device tree binding for the 8-bit CPU parallel MIPI DBI Type B
interface provided by the Tegra20/30 SoCs display controller.

> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra-8bit-cpu.yaml
[ ... ]
> +description: The display controller in Tegra20/30 SoCs features an
> +  8-bit SPI interface that closely resembles the MIPI DBI Type B
> +  protocol and is referred to as '8-bit CPU'. Each display controller
> +  provides two such interfaces, which can be used to send MIPI DCS
> +  commands to initialize and control the panel while image data is
> +  transmitted via 16/18/24-line RGB.
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra-8bit-cpu

[Severity: High]
Does this modeling break Devicetree hardware hierarchy principles? By
defining a separate compatible string and standalone top-level node for what
is fundamentally an internal engine of the display controller, the driver is
forced to traverse the OF graph to its remote endpoint's parent and blindly
cast its drvdata to struct tegra_dc *. 

If the Devicetree incorrectly connects this bridge to a non-Tegra DC node,
can the driver perform invalid memory writes and corrupt memory?

> +
> +  dc-gpios:
> +    description: Data/command selection pin.
> +    maxItems: 1
[ ... ]
> +  data-gpios:
> +    description: Specifies a set of 8 gpio pins used to transfer data.
> +    minItems: 8
> +    maxItems: 8
> +
> +  nvidia,init-sequence:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description: Device specific set of values used in DC DISP_SPI_INIT_SEQ
> +      registers.

[Severity: High]
Does this property confirm the node programs the display controller's
internal registers? Lacking a reg property or a strict parent-child
relationship to map them seems to further indicate this should not be
modeled as a standalone bridge.

> +    minItems: 4
> +    maxItems: 4
> +
> +  panel:
[ ... ]
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for DBI output (panel or connector).
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +required:
> +  - compatible
> +  - ports

[Severity: High]
Should data-gpios and the control GPIOs be marked as required? If the driver
unconditionally accesses priv->data_gpios->ndescs during MIPI DCS
transmission, omitting these bit-banged pins in the device tree allows
incomplete nodes to pass schema validation but causes a NULL pointer
dereference crash at runtime.

> +
> +unevaluatedProperties: false
> +
> +examples:

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