On Tue, Sep 29, 2026 at 05:28:22PM -0500, Rob Herring wrote:
> On Tue, Sep 29, 2026 at 10:39:24AM +0200, Maxime Ripard wrote:
> > 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.
> 
> What reads the most specific compatible?

The BPF loader, so either in kernel loader or userspace loader through
uevents, depending on how the driver discussions are going.

> > > 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?
> 
> What? You can't add a generic compatible in these cases.

generic-*hci all have a generic component *and* a platform specific part
for quirks, and yet none of them require a platform specific compatible
to be added to work. PCI has that too.

This driver has a generic part and a platform specific part for quirks.

> > > 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
> 
> Self contained in a node that's specifically not h/w.
> 
> > 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
> 
> Extra hints that are safe to ignore.
> 
> > 
> > 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
> 
> Virtual h/w which tends to have special needs.

How is that not a description of the binding we're discussing?

> > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
> 
> Shrug. Weird Qcom shit...

Cool. What can I do to add this binding to the list of "weird Maxime
shit" or is this kind of exception only for Qualcomm?

Or should we do it the other way and ship the binding anyway, and in two
years, when it will have been in device tree in the wild and
we-cannot-change-it-we-swear, we will be able to upstream it?

And in the process reward the ones *not* playing the upstream game.

> > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/simple-card.yaml
> 
> Just a container... Though I can't say I really like any of the audio 
> bindings.
> 
> All really irrelevant to this discussion other than the panel binding...

Not really. The discussion was "but you're describing something that
isn't hardware". And none of the above are. And were acked. Some
recently.

> > All of them have been reviewed or acked by you, and yet none of them
> > relate to any hardware description.
> 
> There are things which aren't h/w, but this is h/w and we've already 
> made decisions about how panels in particular are represented. We of 
> course have some remanents of how we don't want to do things.
> 
> > 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?
> 
> There's all of 3 panels supported. Compared to all the other panels we 
> have, hardly the rule over the exception. You can always fine "bad" 
> examples or exceptions.
> 
> That one 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?

Sigh... Look, I really don't care about an argument DT maintainers use
at their discretion for this. We both know full well that it's been and
still is inconsistenly applied, and you also know that it's not like
I've been playing the DT game since pretty much the beginning (on ARM
anyway). So it's not like I don't want to make it work, I do. But what I
care about is enabling that driver to work.

I reused exactly the same binding than the last major binding that was
merged for panels, and support about the same number of panels. I guess
that was a mistake, so sorry for that.

I'm fine with reworking the binding any way you want as long as it still
allows for the same use-case, but I would have hoped for a better
feedback on how to do so than "oh what a huge pile of shit this is".

Maxime