[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKWEGV5_u-kysd0S+CN_TtwHg_Ekp+jue87d4R+QuYzJKssTxw@mail.gmail.com>
Date: Mon, 9 Feb 2026 15:25:02 +0200
From: Yauhen Kharuzhy <jekhor@...il.com>
To: Bartosz Golaszewski <brgl@...nel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Charles Keepax <ckeepax@...nsource.cirrus.com>, Linus Walleij <linus.walleij@...aro.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Daniel Scally <djrscally@...il.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
Krzysztof Kozlowski <krzk@...nel.org>, linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, patches@...nsource.cirrus.com
Subject: Re: [PATCH v4 04/10] gpio: swnode: don't use the swnode's name as the
key for GPIO lookup
пн, 9 февр. 2026 г. в 14:38, Bartosz Golaszewski <brgl@...nel.org>:
>
> On Mon, Feb 9, 2026 at 7:44 AM Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> >
> > On Wed, Nov 19, 2025 at 10:13:30AM +0100, Bartosz Golaszewski wrote:
> > > On Wed, Nov 19, 2025 at 9:41 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > > >
> > > > On Wed, Nov 19, 2025 at 9:35 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > > > >
> > > > > I have an idea for fixing it, let me cook up a patch. It'll still be a
> > > > > bit hacky but will at least create a true link.
> > > > >
> > > >
> > > > Scratch that, I didn't notice before but we register both devices from
> > > > MFD core. We can just set up software nodes there.
> > > >
> > >
> > > Here you go: https://lore.kernel.org/all/20251119-cs42l43-gpio-swnodes-v1-1-25996afebd97@linaro.org/
> > >
> > > Please give it a try. This is independent from this series and should
> > > probably be backported to stable.
> >
> > So think breaks more drivers:
> >
> > https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
> >
> > I think it may also break:
> >
> > arch/arm/mach-omap1/board-nokia770.c
> > arch/arm/mach-pxa/devices.c
> > arch/arm/mach-pxa/devices.h
> > arch/arm/mach-pxa/gumstix.c
> > arch/arm/mach-pxa/pxa25x.c
> > arch/arm/mach-pxa/pxa27x.c
> > arch/arm/mach-pxa/spitz.c
> > arch/arm/mach-tegra/board-paz00.c
>
> Most of them seem to use software nodes correctly. Nokia 770 could
> potentially break depending on the timing but the lookup uses the
> right string.
>
> > arch/x86/platform/geode/geode-common.c
>
> Looks like a correct case of referencing the software node to me.
>
> > drivers/platform/x86/barco-p50-gpio.c
> > drivers/platform/x86/pcengines-apuv2.c
> >
>
> Same here. Nothing here seems to depend on a label and there are real
> links between the GPIO chip's and consumer's software nodes.
>
> The problem we triggered here was caused by a GPIO consumer who would
> create a bogus software node locally without any real link to the
> provider. It would then depend on the provider being named a certain
> way to look up its GPIO. That doesn't seem to be the case in the above
> files.
The driver drivers/platform/x86/x86-android-tablets/core.c also
creates fake gpiochip software nodes
to use them in PROPERTY_ENTRY_GPIO definitions (see
drivers/platform/x86/x86-android-tablets/lenovo.c for examples).
I use the same approach for rt5677 gpiochip in my changes for Lenovo
YB1-X90 tablet (not mainlined yet) and this is broken also now.
--
Yauhen Kharuzhy
Powered by blists - more mailing lists