ср, 30 вер. 2026 р. о 13:23 Thierry Reding <[email protected]> пише: > > On Wed, Sep 30, 2026 at 12:08:41PM +0300, Svyatoslav Ryhel wrote: > > ср, 30 вер. 2026 р. о 12:02 Thierry Reding <[email protected]> пише: > > > 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. >
I have had some controversial experience with MFD, with passing cell composition. If DRM subsystem allows this, I am more then happy to pass panel ops directly. > > > 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. > This driver cannot be "generic". Both panels don't fall into any category of being "generic". They are grouped solely cause they share same timings, controls and supplies (only these 2 panels, other will definitely differ) and are used in the same device. I have no problems in splitting them into 2 distinct drivers. > > > 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. > I don't think that DBI Type B needs some deep and fundamental support. Even for its time it does not seem to be common, not saying today. More a curiosity. > Thierry
