Hi,

I'll merge the two discussions in that thread.

On Mon, Sep 28, 2026 at 03:40:59PM -0500, Rob Herring wrote:
> On Mon, Sep 28, 2026 at 06:22:01PM +0200, Maxime Ripard wrote:
> > Most MIPI-DSI panel drivers follow an identical pattern: acquire
> > regulators and GPIOs, perform a reset pulse with specific timing,
> > send a vendor-supplied sequence of DSI commands, then enable the
> > display. The only truly panel-specific part is the init sequence
> > and power-on/off timing.
> > 
> > The panel-mipi-dsi-bpf driver replaces per-panel kernel modules
> > with a single generic driver whose panel-specific behavior is
> > provided by BPF programs loaded from userspace at runtime,
> > following the HID-BPF model. This enables new panel support
> > without kernel patches.
> > 
> > Panel DT nodes use a two-entry compatible with the panel-specific
> > string first and "panel-mipi-dsi-bpf" as fallback. The generic
> > driver matches on the fallback, while the first compatible is used
> > to identify which BPF program to load.
> 
> If you need the 1st compatible anyways, what is the point of the
> second one?

The whole point of this driver is that you don't need to modify the
kernel when you add support for a new panel.

> Also, 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).

Yeah, that's true. I'd still need to identify the parts though. I guess
using a generic compatible but a specific model would work?

> And I agree with Neil's comment. At least until we start embedding BPF 
> into DT directly. ;)

And from Neil:

> 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.

I'm quite a bit surprised by that argument though.

We have in the main dt-schema repos bindings like:

https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/post-init-providers.yaml

Or, in Linux:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/google,android-pipe.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/simple-card.yaml

All of them have been reviewed or acked by you, and yet none of them
relate to any hardware description.

panel-mipi-dsi-spi is a generic panel that will load a firmware, and
quite similar to this one. google,android-pipe and qcom,fastrpc don't
attach to anything and will just open a tunnel to userspace, which is
somewhat equivalent but more dramatic than what this driver is doing.
simple-card or its variations will just instantiate a kernel driver from
the DT and is used pretty much everywhere.

I reused the binding from panel-mipi-dsi-spi for this. It was reviewed
by rob, and acked by a panel maintainer, and 4 years ago, so we're way
past the "oh but we didn't know what we were doing back then" argument.

So, let's phrase this differently: what's different about the
description than panel-mipi-dsi-spi, or any other binding already in
tree?

If it's the BPF part, BPF is not Linux-only, and there's hardware with
direct BPF support these days, so it can be considered OS-agnostic and
not an implementation detail.

Maxime