Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API
From: Daniel Thompson
Date: Mon Oct 03 2022 - 09:33:07 EST
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@xxxxxxxxx>
> > > ---
> > >
> > > 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: 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 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
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.