[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYsDHUTsX4o76OQa@smile.fi.intel.com>
Date: Tue, 10 Feb 2026 12:06:21 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
Cc: Linus Walleij <linusw@...nel.org>,
Bartosz Golaszewski <brgl@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Arnd Bergmann <arnd@...nel.org>, Hans de Goede <hansg@...nel.org>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
platform-driver-x86@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] gpio: swnode: restore the swnode-name-against-chip-label
matching
On Tue, Feb 10, 2026 at 10:48:06AM +0100, Bartosz Golaszewski wrote:
> Using the remote firmware node for software node lookup is the right
> thing to do. The GPIO controller we want to resolve should have the
> software node we scooped out of the reference attached to it. However,
> there are existing users who abuse the software node API by creating
> dummy swnodes whose name is set to the expected label string of the GPIO
> controller whose pins they want to control and use them in their local
> swnode references as GPIO properties.
>
> This used to work when we compared the software node's name to the
> chip's label. When we switched to using a real fwnode lookup, these
> users broke down because the firmware nodes in question were never
> attached to the controllers they were looking for.
>
> Restore the label matching as a fallback to fix the broken users but add
> a big FIXME urging for a better solution.
>
> Link: https://lore.kernel.org/all/aYmV5Axyfo76D19T@smile.fi.intel.com/
Should be
Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/
Acked-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists