Re: [PATCH 0/6] drm/bridge: Add a BPF-based MIPI-DSI panel driver

[Neil Armstrong]

On 10/2/26 09:37, Javier Martinez Canillas wrote:
> Neil Armstrong <neil.armstrong@xxxxxxxxxx> writes:
>
> Hello Neil,
>
> > On 10/1/26 08:50, Maxime Ripard wrote:
>
> [...]
>
> > > > I don't want to add a supplementary maintenance burden for the sake of using a cool
> > > > technology which has serious drawbacks and dependencies on user-space even if looks
> > > > really cool.
> > >
> > > Spoiler alert: v2 won't. I've got the in-kernel loader to work and thus
> > > you can have a built-in panel driver that works without user-space
> > > intervention. So this is not a topic of discussion anymore.
> >
> > It will still have users-space dependency, meaning the BPF files will need to
> > exist in the fs when drivers probes.
>
> It doesn't have to AFAIU. The BPF programs could be built into the kernel
> image, just like firmware binaries could be built-in as well.

Right so my main question still is: what does it solve exactly ?

All the descriptions I saw so far is that it simply moves
the panel C code to a BPF code with no other additions.

I still don't have a clear view of what is precisely solves.

It adds some complexity to load those BPF driver, adds some
maintenance complexities since with every API change we will
need validate BPF still works in addition to C (and maybe one day Rust).

As the maintainer of the panels, merging a bunch of new panels at each
releases and helping migrating to newer and modern way to interact
with panels, I think I have the right to express my interrogations.

I'm clearly not the oldest kernel contributor & maintainer around here,
but the main interrogation I have when submitting, reviewing and
merging is : does it really solve something efficiently.

I don't want people to be frustrated by my review and question,
but I feel I'm allowed to say I'm not convinced about this solution.

Neil

> > Neil