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

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]

> 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
> index 000000000000..9a20a21cf70e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bpf.yaml
> @@ -0,0 +1,184 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dsi-bpf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +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.
> +
> +  Panel DT nodes use a fallback compatible so the generic driver matches on
> +  "panel-mipi-dsi-bpf" while the first compatible identifies the specific
> +  panel for BPF program matching.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +    items:
> +      - description: Panel-specific compatible string
> +      - const: panel-mipi-dsi-bpf

Rob Herring raised concerns about this dual compatible string design in
the v1 discussion: "If you need the 1st compatible anyways, what is the
point of the second one?"

He also pointed out a compatibility issue with existing panels: "I assume
there is at least some panel supported in the kernel you might want to
convert to this. That panel would not have the fallback (and the DT is
fixed)."

In the follow-up discussion, Rob stated: "What? You can't add a generic
compatible in these cases."

How does this binding handle the case where existing in-kernel panels are
converted to use this driver, given that their device trees are already
deployed without the panel-mipi-dsi-bpf fallback compatible?

Neil Armstrong also raised a fundamental concern about including BPF in the
hardware description: "I don't see how this can be a valid hardware
description, bfp is a software implementation and has nothing to do in the
bindings."

Should the binding be redesigned to avoid referencing the software
implementation mechanism (BPF) in what is meant to be a hardware
description?

> +
> +  reg:
> +    maxItems: 1
> +    description: DSI virtual channel
> +
> +  backlight: true
> +  enable-gpios: true
> +  height-mm: true
> +  port: true
> +  reset-gpios: true
> +  rotation: true
> +  width-mm: true
> +
> +  vcc-supply:
> +    description: IC core supply, typically 2.8-3.3V (charge pump input)
> +
> +  iovcc-supply:
> +    description: I/O interface supply, typically 1.8V (MIPI logic level)
> +
> +  avdd-supply:
> +    description: Positive analog supply for source/gate driver, typically +5V
> +
> +  avee-supply:
> +    description: Negative analog supply for source/gate driver, typically -5V
> +
> +  elvdd-supply:
> +    description: OLED EL positive supply
> +
> +  elvss-supply:
> +    description: OLED EL negative supply

Rob Herring questioned the approach of defining multiple optional supplies
to cover different panel types: "That one [panel-mipi-dbi-spi] defines a
single supply. Any other MIPI SPI panel with different supplies or GPIO
controls probably has its own binding. Trying to parameterize that in DT
doesn't work. We've rejected trying to do that in DT over and over. What's
your story here for that?"

How does this binding address the longstanding kernel policy against
parameterizing hardware variations through optional DT properties?

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/36644629998