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

[Dmitry Torokhov]

On Mon, Oct 10, 2022 at 10:36:00PM +0200, Linus Walleij wrote:
> On Thu, Oct 6, 2022 at 12:05 PM Daniel Thompson
> <daniel.thompson@xxxxxxxxxx> wrote:
> > On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote:
> > > On Tue, Oct 4, 2022 at 10:35 PM Dmitry Torokhov
> > > <dmitry.torokhov@xxxxxxxxx> wrote:
> > >
> > > > > Dmitry, could you fix this? Just patch away in gpiolib-of.c.
> > > >
> > > > Sure, I'll add a few quirks. I wonder what is the best way to merge
> > > > this? I can create a bunch of IBs to be pulled, or I can send quirks to
> > > > you/Bartosz and once they land send the patches to drivers...
> > >
> > > When I did it I was sufficiently convinced that I was the only one patching
> > > the quirks in gpiolib-of.c that merge window so I just included it as
> > > a hunk in the driver patch. If there will be some more patches to that
> > > file I guess some separate patch(es) for gpiolib-of.c is needed, maybe
> > > an immutable branch for those if it becomes a lot.
> >
> > Are renames likely to be a common quirk on the road to libgpiod
> > conversion?
> >
> > I admit I sort of expected it to be common enough that there would be
> > one rename quirk in the code supported by an alphabetized string table.
> > Such a table would certainly still provoke troublesome merges but ones
> > that are trivially resolved.
> 
> Dmitry added a table of sorts, the problems are usually a bit unique
> for each instance of nonstandard DT GPIO bindings, that's why I
> mostly solved it with open coding in gpiolib-of.c.

OK, so I sent out the patch adding "reset-gpios" -> "gpios-reset"
translation quirk to keep compatibility with the legacy names, but
we still need to figure out what to do with incorrect line polarity
in current DTses in tree. Unlike with names we have no indication
if out of tree DTSes specify correct polarity or not, so we can't
reasonably come up with workarounds that are guaranteed to work for
everyone. I see several options:

- the driver could continue ignoring line polarity specified in DTS
  (and use gpiod_set_value_raw()) and hope that they all/will be
  wired in the same way?

- we could fix up in-kernel DTSes, allow flexibility of connection
  in new designs and respect polarity specified in out of tree DTSes,
  but accept that there can be breakages with old DTSes not contributed
  to the mainline or DTSes that were "cached" from an older kernel
  release

- add another quirk forcing "active low" polarity for the legacy
  "gpios-reset" name, which will allow us respecting polarity in
  new "reset-gpios" name.

Thanks.

-- 
Dmitry