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[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.
