> 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 <[email protected]> > + > +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
