Re: [PATCH v2 0/4] platform/x86: x86-android-tablets: use real firmware node references with intel drivers

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Thu, Apr 02, 2026 at 02:54:25PM +0200, Bartosz Golaszewski wrote:
> 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. Switch to returning -ENXIO if we try to resolve a reference to
> a software node that's not registered as a firmware node yet to
> differentiate it from other situations in which we return -ENOENT.
> 2. In GPIO core: return -EPROBE_DEFER from swnode lookup if
> fwnode_get_reference_args() returns -ENXIO as an unregistered software
> node is not much different from the situation where there's a firmware
> node not backed by a device yet.
> 3. Export the acpi_bus_type symbol. It's already available in the
> acpi_bus.h header but it's not available to loadable modules.

Nowadays we don't do that but export the dev_is_acpi() or something similar if
it's not yet available and to_acpi_dev(). (Names are derived from the existing
pattern, they might be need to be adjusted, dunno.) See how PNP does that.
Note, I haven't read the patches yet, just a quick comment.

> 4. Finally: 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.
> 
> Merging strategy: I'd like to propose queing patches 1-3 independently
> through their respective trees: driver core, GPIO and ACPI. The final
> patch would make its way upstream after v7.1-rc1. I would probably
> extend it to convert the driver to using more devres interfaces too at
> this point.

-- 
With Best Regards,
Andy Shevchenko