Linux driver-core infrastructure
 help / color / mirror / Atom feed
* [PATCH v4 0/2] platform/x86: x86-android-tablets: use real firmware node references with intel drivers
@ 2026-04-30  7:34 Bartosz Golaszewski
  2026-04-30  7:34 ` [PATCH v4 1/2] ACPI: provide acpi_bus_find_device_by_name() Bartosz Golaszewski
  2026-04-30  7:34 ` [PATCH v4 2/2] platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips Bartosz Golaszewski
  0 siblings, 2 replies; 8+ messages in thread
From: Bartosz Golaszewski @ 2026-04-30  7:34 UTC (permalink / raw)
  To: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
	Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
	Mika Westerberg, Andy Shevchenko, Linus Walleij, Hans de Goede,
	Ilpo Järvinen, Dmitry Torokhov, Len Brown
  Cc: linux-acpi, driver-core, linux-kernel, linux-gpio,
	platform-driver-x86, brgl, Bartosz Golaszewski

First let me repeat the problem statement:

==

GPIO software node lookup should rely exclusively on matching the
addresses of the referenced firmware nodes. I tried to enforce it with
commit e5d527be7e69 ("gpio: swnode: don't use the swnode's name as the
key for GPIO lookup") but it broke existing users who abuse the software
node mechanism by creating "dummy" software nodes named after the device
they want to get GPIOs from but never attaching them to the actual GPIO
devices. They rely on the current behavior of GPIOLIB where it will match
the label of the GPIO controller against the name of the software node
and does not require a true link.

x86-android-tablets driver is one of the abusers in that it creates
dummy software nodes for baytrail and cherryview GPIO controllers but
they don't really reference these devices. Before we can reapply
e5d527be7e69 and support matching by fwnode address exclusively, we need
to convert all the users to using actual fwnode references.

==

Now for the new approach:

Now with the recent patches I sent or plan to send out, it turns out
that almost all existing users of software node lookup can easily have
the software node's representing the GPIO controllers attached to their
target devices as their primary firmware node. The remaining complex
cases are: pcengines-apuv2 and geode-common but in the first case we
have control over the creation of the GPIO device - we can assign it a
firmware node - and in the second case, we deal with an MFD driver so
can export the cell's software node in a header.

The only remaining use-case where we need to reference a GPIO controller
described in ACPI from a software node is the x86-android-tablets
driver. In this case, I think it no longer makes sense to propose a new
generic interface. Instead, I'd like to propose to keep it as a
driver-specific quirk.

This series proposes the following changes:
1. Provide acpi_bus_find_device_by_name() for looking up ACPI devices.
2. Implement support for dynamic assignment of secondary firmware nodes
in the x86-android-tablets driver. More details on how it's approached
are in the relevant commit message.

The dependencies in driver core and GPIOLIB are already upstream.

Merging strategy: Both patches should go through the X86 platform tree
with an Ack from Rafael.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v4:
- As pointed out by Hans: we don't need the notifier logic so replace
  patch 1/2 with another, providing an ACPI helper for locating devices
  by name and simplify patch 2/2
- Link to v3: https://patch.msgid.link/20260427-baytrail-real-swnode-v3-0-0003e4c1708c@oss.qualcomm.com

Changes in v3:
- Drop dependencies that got upstream for v7.1
- Rebase on top of v7.1-rc1
- Link to v2: https://patch.msgid.link/20260402-baytrail-real-swnode-v2-0-6f5054a4cc07@oss.qualcomm.com

Changes in v2:
- Completely new approach
- Keep the cherryview and baytrail secondary fwnode handling as a
  driver-specific quirk for x86 tablets and don't introduce any new API
- Change the return value when resolving a reference to an unregistered
  software node and defer probe in GPIOLIB in that situation
- Export acpi_bus_type for use in x86-android-tablets
- Link to v1: https://patch.msgid.link/20260319-baytrail-real-swnode-v1-0-75f2264ae49f@oss.qualcomm.com

---
Bartosz Golaszewski (2):
      ACPI: provide acpi_bus_find_device_by_name()
      platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips

 drivers/acpi/bus.c                              | 13 +++++
 drivers/platform/x86/x86-android-tablets/core.c | 78 ++++++++++++++++++++++++-
 include/linux/acpi.h                            |  7 +++
 3 files changed, 95 insertions(+), 3 deletions(-)
---
base-commit: 085f14acda1c46ab815605ecf2341afe5a691eb9
change-id: 20260319-baytrail-real-swnode-7de7a3870f78

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-04-30 13:01 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-30  7:34 [PATCH v4 0/2] platform/x86: x86-android-tablets: use real firmware node references with intel drivers Bartosz Golaszewski
2026-04-30  7:34 ` [PATCH v4 1/2] ACPI: provide acpi_bus_find_device_by_name() Bartosz Golaszewski
2026-04-30  9:57   ` Rafael J. Wysocki
2026-04-30 12:45   ` Andy Shevchenko
2026-04-30  7:34 ` [PATCH v4 2/2] platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips Bartosz Golaszewski
2026-04-30 10:03   ` Rafael J. Wysocki
2026-04-30 12:51   ` Andy Shevchenko
2026-04-30 13:01     ` Andy Shevchenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox