From: Daniel Thompson <daniel.thompson@linaro.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Lee Jones <lee@kernel.org>,
Jingoo Han <jingoohan1@gmail.com>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
Linus Walleij <linus.walleij@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API
Date: Mon, 3 Oct 2022 14:32:49 +0100 [thread overview]
Message-ID: <YzrkgXyVLLer6ckn@maple.lan> (raw)
In-Reply-To: <YzSTkJNAyyF7ufOu@google.com>
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@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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-03 13:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 22:32 [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API Dmitry Torokhov
2022-09-28 11:00 ` Daniel Thompson
2022-09-28 18:33 ` Dmitry Torokhov
2022-10-03 13:32 ` Daniel Thompson [this message]
2022-10-04 9:02 ` Linus Walleij
2022-10-04 12:54 ` Daniel Thompson
2022-10-04 19:50 ` Linus Walleij
2022-10-04 20:35 ` Dmitry Torokhov
2022-10-06 9:03 ` Linus Walleij
2022-10-06 10:04 ` Daniel Thompson
2022-10-10 20:36 ` Linus Walleij
2022-10-12 20:34 ` Dmitry Torokhov
2022-10-13 12:43 ` Daniel Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzrkgXyVLLer6ckn@maple.lan \
--to=daniel.thompson@linaro.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).