On Wed, Sep 30, 2026 at 12:08:41PM +0300, Svyatoslav Ryhel wrote:
> ср, 30 вер. 2026 р. о 12:02 Thierry Reding <thierry.reding@kernel.org> пише:
> > On Wed, Sep 30, 2026 at 10:05:35AM +0300, Svyatoslav Ryhel wrote:
[...]
> > > +static const struct of_device_id panel_dbi_of_match[] = {
> > > +     { .compatible = "hit,tx10d07vm0baa", .data = (void *)PANEL_DBI_TX10D07VM0BAA },
> > > +     { .compatible = "lg,lh400wv3-sd04", .data = (void *)PANEL_DBI_LH400WV3 },
> >
> > Why the detour through that PANEL_DB_* enum? You could just pass the
> > panel funcs pointers directly via .data here.
> >
> 
> Passing API/OPS via .data is discouraged.

No it's not. We do it all the time.

> > Also, looking at the enable/disable sequences these are in fact two
> > different drivers, with the only commonality being that they happen to
> > be used in the same device. Rolling them both into one driver seems a
> > bit odd.
> 
> I did this to simplify maintainance. Both panels are used in the LG
> Optimus 2X. My assumption is that LG switched one to another at some
> point, hence they share same timings, controls and supplies, but
> differ in en/disable sequence. Additionally, these are the the only
> DBI Type B-only panels in the kernel, from what I can see.

That's just one more reason to put them into more of a generic driver,
which would allow people to find it and extend/improve it as needed.

> > If you really want to avoid duplication, maybe they should go
> > into some kind of "simple" or "generic" DBI driver.
> 
> DBI Type B is not well supported in the kernel.

Well, you always start somewhere.

Thierry