Re: [PATCH 1/6] dt-bindings: display: Add panel-mipi-dsi-bpf generic panel binding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] drm/panel: userspace BPF requirement breaks early boot panic display
- [Low] dt-bindings: display: non-standard dsi-lanes instead of endpoint data-lanes
- [Low] dt-bindings: display: missing gpio.h include causes DTC syntax error
- [Low] dt-bindings: display: examples fail validation against legacy schemas
--

commit e9b8b6539dfc465519559ca54cf48b580b394bd1
Author: Maxime Ripard <mripard@kernel.org>
Subject: dt-bindings: display: Add panel-mipi-dsi-bpf generic panel binding

This commit introduces a generic MIPI-DSI panel binding where power sequencing
and DSI init commands are handled by BPF programs loaded from userspace. It
defines standard regulator supplies and DSI parameters while using a fallback
compatible string to match the generic driver.

> diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bpf.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bpf.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bpf.yaml
> @@ -0,0 +1,184 @@
[ ... ]
> +title: Generic MIPI-DSI panel with BPF init sequences
> +
> +maintainers:
> +  - Maxime Ripard <mripard@kernel.org>
> +
> +description: |
> +  A generic MIPI-DSI panel driver where the panel-specific power sequencing
> +  and DSI init commands are provided by BPF programs.

[Severity: High]
Does this architectural requirement to rely on userspace-loaded BPF programs
result in the loss of early boot display capabilities? If the system crashes
during early boot, before userspace can mount the rootfs and load the BPF
objects, it appears the kernel would be unable to autonomously initialize the
display to render the framebuffer console, splash screens, or kernel panic
messages.

[ ... ]
> +  elvss-supply:
> +    description: OLED EL negative supply
> +
> +  dsi-lanes:
> +    description: Number of DSI data lanes
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [1, 2, 3, 4]
> +    default: 4

[Severity: Low]
Could this lead to fragmentation of device tree standards? Standard devicetree
practice for DSI and CSI typically describes lane configurations using the
data-lanes property within the port or endpoint graph node, rather than
introducing a custom property like dsi-lanes at the root level.

[ ... ]
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    dsi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        panel@0 {
> +            compatible = "elida,kd35t133", "panel-mipi-dsi-bpf";

[Severity: Low]
Will this trigger schema validation errors during make dt_binding_check? The
dt-schema tool automatically evaluates examples against existing legacy
schemas, such as the one for elida,kd35t133. Because legacy schemas typically
expect exactly one const compatible string and enforce additionalProperties:
false, they might reject the dual-compatible array and the generic
BPF-specific properties used in this example.

[ ... ]
> +  - |
> +    /* OLED panel using avdd/avee and elvdd/elvss supplies */
> +
> +    dsi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        panel@0 {
> +            compatible = "boe,bf060y8m-aj0", "panel-mipi-dsi-bpf";

[Severity: Low]
Similar to the previous example, will dt-schema reject this dual-compatible
array and the generic properties when evaluated against the existing
boe,bf060y8m-aj0 schema?

[ ... ]
> +            vcc-supply = <&vreg_l14a>;
> +            iovcc-supply = <&vreg_l12a>;
> +            elvdd-supply = <&vreg_oled_pos>;
> +            elvss-supply = <&vreg_oled_neg>;
> +            reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;

[Severity: Low]
Will the dt-extract-example tool cause a DTC syntax error here? This second
example block seems to be missing the include for dt-bindings/gpio/gpio.h
which is required for the GPIO_ACTIVE_LOW macro.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-drm-mipi-dsi-panel-ebpf-v1-0-5244926aace4@kernel.org?part=1