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 <[email protected]> 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 <[email protected]> > + > +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/[email protected]?part=1
