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

[Maxime Ripard <mripard@kernel.org>]

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

On Wed, Sep 30, 2026 at 03:32:19PM +0200, Neil Armstrong wrote:
> On 9/29/26 10:39, Maxime Ripard wrote:
> > Hi,
> > 
> > 
> <snip>
> 
> > 
> > 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?
> 
> The panel-mipi-dsi-spi still describes a class of H/W control interface,
> not a pure software driver implementation type.
> 
> "panel-mipi-dsi-bpf" or "panel-mipi-dsi-rust" or "panel-mipi-dsi-cplusplus"
> would be the same problem.

Rob explicitly said the bpf part wasn't the problem. Also, I don't care
for the compatible itself, so what would be an acceptable compatible for
you?

> > 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.
> 
> If somehow panels used a standardized MIPI firmware we could define this
> in DT, but here we're basically inventing our own type of firmware from
> thin air.

That's not what panel-mipi-dsi-spi is.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]