[RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API

[Daniel Thompson]

On Wed, Sep 28, 2022 at 11:33:52AM -0700, Dmitry Torokhov wrote:
> On Wed, Sep 28, 2022 at 12:00:51PM +0100, Daniel Thompson wrote:
> > On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote:
> > > Properties describing GPIOs should be named as "<property>-gpios" or
> > > "<property>-gpio", and that is what gpiod API expects, however the
> > > driver uses non-standard "gpios-reset" name. Let's adjust this, and also
> > > note that the reset line is active low as that is also important to
> > > gpiod API.
> >
> > No objections to the goal but...
> >
> >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov at gmail.com>
> > > ---
> > >
> > > Another option is to add another quirk into gpiolib-of.c, but we
> > > may end up with a ton of them once we convert everything away from
> > > of_get_named_gpio() to gpiod API, so I'd prefer not doing that.
> >
> > ... it is unusual to permit backwards incompatible changes to the DT
> > bindings[1]: creating "flag days" where hardware stops functioning if
> > you boot an new kernel with an old DT is a known annoyance to users.
> >
> > I usually favour quirks tables or similar[2] rather than break legacy
> > DTs. Very occasionally I accept (believable) arguments that no legacy
> > DTs actually exist but that can very difficult to verify.
> >
> > Overall I'd like to solicit views from both GPIO and DT maintainers
> > before rejecting quirks tables as a way to help smooth these sort of
> > changes (or links to ML archives if this has already been discussed).
>
> I believe I was able to convince Rob once or twice that keeping
> compatibility was not worth it (not in general but in a couple of
> concrete cases), at least while device tree bindings are part of the
> kernel. Can't find the emails though...
>
> I think we should consider several options:

I have to note that these are *non-exclusive* options


> 1. DTS/DTB is in firmware. In this case absolutely, we need to keep
> binary compatibility as we can not expect users to reflash firmware
> (there might not even be a new firmware). This situation matches what we
> have with ACPI systems where we are trying to work around issues
>
> 2. DTS is shipped with the kernel:
> 	2a. DTS is present in upstream kernel - awesome, we can patch it
> 	    as needed and have one less thing to worry about.

I don't think the presence of a DT within the kernel can be the basis
for any useful reasoning.

a. "Better" firmware projects aimed are likely to consume a DT that is
   shipped with the kernel and pin it (meaning the kernel cannot solve
   version skew problems by updating it's copies of the DT). I think
   tow-boot to be a specific example of this.

b. The fact there are are consumers of the binding shipped with the
   kernel isn't sufficient to show that *all* consumers of the binding
   are shipped with the kernel.

On other words I don't think the presence of a DT in the kernel is
especially useful to showing that neither #1 nor #3 apply.


> 	2b. DTS is not upstream. Vendor did not bother sending it. In
> 	    this case it is extremely unlikely that an upstream kernel
> 	    will work on such system out of the box, and updating the
> 	    kernel is a large engineering task where you pull down new
> 	    kernel, rework and apply non-upstream patches, rework kernel
> 	    config (new Kconfig options can be introduced, old options
> 	    can be renamed, etc). And then spend several weeks
> 	    stabilizing the system and tracking down regressions (in
> 	    general, not DTS-related ones)
>
> 3. DTS is not in firmware and not in kernel. Are there such systems?

DT overlays strike me are an example of this case. I'm particularly
thinking of daughterboard/expansion card examples here where the DT
overlay could be any several different places: firmware, an add on
boards I2C FLASH, daughterboard documentation, blog posts, etc.

That is especially relevant to this specific patch since HX8357 is found
on several widely available add-on boards.


> So my opinion is that while device trees are part of kernel code and
> have not been split into a separate project they are a fair game. If the
> change can be handled in the driver without much effort (something like
> "wakeup-source" vs "linux,wakeup" vs "linux,keypad-wakeup") - fine, we
> can just put a tiny quirk in the driver, but if we need something more
> substantial we need to think long and hard if we should implement a
> fallback and how much effort there is to maintain/test it so it does not
> bitrot.

To be honest my original thoughts were that for simple renames, a rename
quirk table shared by all renames needed to introduce libgpiod would
probably have a lower impact than all the "tiny" per-driver quirks (because
it could share code across multiple names).


> Anyway, I hope Rob, Linux and Krzysztof to chime in on this exciting
> topic once again ;)

I'm especially interested in a gpiod point of view! I have invested
quite a few characters in this thread. That is because, if accepted,
adding strings to a quirks table is much less effort for patch
submitters than having to demonstrate on a per-patch basis the due
diligence that has been undertaken to show that cases #1 and #3 do not
apply to the particular rename being sought.


Daniel.