Machine GPIO lookup is a nice, if a bit clunky, mechanism when we have
absolutely no idea what the GPIO provider is or when it will be created.
However in the case of reset-gpios, we not only know if the chip is
there - we also already hold a reference to its firmware node.

In this case using fwnode lookup makes more sense. However, since the
reset provider is created dynamically, it doesn't have a corresponding
firmware node (in this case: an OF-node). That leaves us with software
nodes which currently cannot reference other implementations of the
fwnode API, only other struct software_node objects. This is a needless
limitation as it's imaginable that a dynamic auxiliary device (with a
software node attached) would want to reference a real device with an OF
node.

This series does three things: extends the software node implementation,
allowing its properties to reference not only static software nodes but
also existing firmware nodes, updates the GPIO property interface to use
the reworked swnode macros and finally makes the reset-gpio code the
first user by converting the GPIO lookup from machine to swnode.

Another user of the software node changes in the future could become the
shared GPIO modules that's in the works in parallel[1].

Merging strategy: the series is logically split into four parts: driver
core, SPI, GPIO and reset respectively. However there are build-time
dependencies between all three parts so I suggest the reset tree as the
right one to take it upstream with an immutable branch provided to
driver core, SPI and GPIO.

[1] https://lore.kernel.org/all/20250924-gpio-shared-v1-0-775e7efeb1a3@linaro.org/

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Changes in v7:
- Add a SPI patch from Charles Keepax that uses the swnode changes to
  improve the GPIO lookup in cs42l43, this is required before we switch
  to the fwnode-based lookup in gpiolib-swnode
- Revert to the previous way of checking the return value of
  fwnode_create_software_node()
- Link to v6: https://lore.kernel.org/r/20251106-reset-gpios-swnodes-v6-0-69aa852de9e4@linaro.org

Changes in v6:
- Do ref[0].swnode -> ref->swnode in software_node_graph_get_remote_endpoint()
- Fix some nit picks from Andy
- Link to v5: https://lore.kernel.org/r/20251105-reset-gpios-swnodes-v5-0-1f67499a8287@linaro.org

Changes in v5:
- Use _Generic() even more and simplify the patch allowing to reference
  firmware nodes significantly
- Use _Generic() to avoid adding more macros to linux/property.h
- Don't rename macro arguments in linux/property.h
- Drop patch renaming the GPIO reference property
- Pick up the patch modifying the swnode GPIO lookup to using fwnodes
  into my fixes branch
- Simplify the patch allowing GPIO swnode references to reference
  firmware nodes
- Link to v4: https://lore.kernel.org/r/20251103-reset-gpios-swnodes-v4-0-6461800b6775@linaro.org

Changes in v4:
- Fix an issue with uninitialized ret variable in reset core
- Use _Generic() to simplify the __SOFTWARE_NODE_REF() macro and remove
  one of the arguments
- Add a comment explaining the relationship between swnodes and fwnodes
  and why we're using the fwnode API in swnode code
- Allow longer lines
- Link to v3: https://lore.kernel.org/r/20251029-reset-gpios-swnodes-v3-0-638a4cb33201@linaro.org

Changes in v3:
- Really fix the typo in commit message in patch 7/9
- Update the commit message in patch 3/9 after implementation changes
- Don't remove checking the refnode for NULL and returning -ENOENT
- Move lockdep assertion higher up in the reset code
- Simplify patch 4/9: don't change the logic of inspecting the gpio
  device's software node
- Add new patch that still allows GPIO lookup from software nodes to
  find chips associated with any firmware nodes
- Drop the comma in reset-gpio auxiliary ID
- Drop the no longer used type argument from software node reference
  macros
- Link to v2: https://lore.kernel.org/r/20251022-reset-gpios-swnodes-v2-0-69088530291b@linaro.org

Changes in v2:
- Don't use a union for different pointer types in the software node
  reference struct
- Use fwnode_property_read_u32() instead of
  fwnode_property_read_u32_array() as we're only reading a single
  integer
- Rename reset_aux_device_release() to reset_gpio_aux_device_release()
- Initialize the device properties instead of memsetting them
- Fix typo in commit message
- As discussed on the list: I didn't change patch 7/9 because most of
  it goes away anyway in patch 9/9 and the cleanup issues will be fixed
  in the upcoming fwnode conversion
- Link to v1: https://lore.kernel.org/r/20251006-reset-gpios-swnodes-v1-0-6d3325b9af42@linaro.org

---
Bartosz Golaszewski (8):
      software node: read the reference args via the fwnode API
      software node: increase the reference of the swnode by its fwnode
      software node: allow referencing firmware nodes
      gpio: swnode: allow referencing GPIO chips by firmware nodes
      reset: order includes alphabetically in reset/core.c
      reset: make the provider of reset-gpios the parent of the reset device
      reset: gpio: convert the driver to using the auxiliary bus
      reset: gpio: use software nodes to setup the GPIO lookup

Charles Keepax (1):
      spi: cs42l43: Use actual ACPI firmware node for chip selects

 drivers/base/swnode.c         |  30 +++++++--
 drivers/gpio/gpiolib-swnode.c |   3 +-
 drivers/reset/Kconfig         |   1 +
 drivers/reset/core.c          | 146 ++++++++++++++++++++++++------------------
 drivers/reset/reset-gpio.c    |  19 +++---
 drivers/spi/spi-cs42l43.c     |  40 +++---------
 include/linux/property.h      |  13 +++-
 7 files changed, 141 insertions(+), 111 deletions(-)
---
base-commit: 8892aac2160438329ea14463cb272c3f9be98214
change-id: 20250925-reset-gpios-swnodes-db553e67095b

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

On Do, 2025-11-20 at 14:23 +0100, Bartosz Golaszewski wrote:
> Machine GPIO lookup is a nice, if a bit clunky, mechanism when we have
> absolutely no idea what the GPIO provider is or when it will be created.
> However in the case of reset-gpios, we not only know if the chip is
> there - we also already hold a reference to its firmware node.
> 
> In this case using fwnode lookup makes more sense. However, since the
> reset provider is created dynamically, it doesn't have a corresponding
> firmware node (in this case: an OF-node). That leaves us with software
> nodes which currently cannot reference other implementations of the
> fwnode API, only other struct software_node objects. This is a needless
> limitation as it's imaginable that a dynamic auxiliary device (with a
> software node attached) would want to reference a real device with an OF
> node.
> 
> This series does three things: extends the software node implementation,
> allowing its properties to reference not only static software nodes but
> also existing firmware nodes, updates the GPIO property interface to use
> the reworked swnode macros and finally makes the reset-gpio code the
> first user by converting the GPIO lookup from machine to swnode.
> 
> Another user of the software node changes in the future could become the
> shared GPIO modules that's in the works in parallel[1].
> 
> Merging strategy: the series is logically split into four parts: driver
> core, SPI, GPIO and reset respectively. However there are build-time
> dependencies between all three parts so I suggest the reset tree as the
> right one to take it upstream with an immutable branch provided to
> driver core, SPI and GPIO.

Applied to reset/next, thanks!

[1/9] software node: read the reference args via the fwnode API
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=f11a8e996d5e
[2/9] software node: increase the reference of the swnode by its fwnode
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=0651933c117e
[3/9] software node: allow referencing firmware nodes
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=d7cdbbc93c56
[4/9] spi: cs42l43: Use actual ACPI firmware node for chip selects
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=d2a6cea44acc
[5/9] gpio: swnode: allow referencing GPIO chips by firmware nodes
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=216c12047571
[6/9] reset: order includes alphabetically in reset/core.c
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=97d85328e3dc
[7/9] reset: make the provider of reset-gpios the parent of the reset device
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=46dae84a90f9
[8/9] reset: gpio: convert the driver to using the auxiliary bus
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=109ce747ac22
[9/9] reset: gpio: use software nodes to setup the GPIO lookup
      https://git.pengutronix.de/cgit/pza/linux/commit/?id=5fc4e4cf7a22

5fc4e4cf7a22 is tagged as reset-gpio-for-v6.19. I'll send a separate
pull request for it.

regards
Philipp

On Thu, Nov 20, 2025 at 02:23:55PM +0100, Bartosz Golaszewski wrote:
> Machine GPIO lookup is a nice, if a bit clunky, mechanism when we have
> absolutely no idea what the GPIO provider is or when it will be created.
> However in the case of reset-gpios, we not only know if the chip is
> there - we also already hold a reference to its firmware node.
> 
> In this case using fwnode lookup makes more sense. However, since the
> reset provider is created dynamically, it doesn't have a corresponding
> firmware node (in this case: an OF-node). That leaves us with software
> nodes which currently cannot reference other implementations of the
> fwnode API, only other struct software_node objects. This is a needless
> limitation as it's imaginable that a dynamic auxiliary device (with a
> software node attached) would want to reference a real device with an OF
> node.
> 
> This series does three things: extends the software node implementation,
> allowing its properties to reference not only static software nodes but
> also existing firmware nodes, updates the GPIO property interface to use
> the reworked swnode macros and finally makes the reset-gpio code the
> first user by converting the GPIO lookup from machine to swnode.
> 
> Another user of the software node changes in the future could become the
> shared GPIO modules that's in the works in parallel[1].
> 
> Merging strategy: the series is logically split into four parts: driver
> core, SPI, GPIO and reset respectively. However there are build-time
> dependencies between all three parts so I suggest the reset tree as the
> right one to take it upstream with an immutable branch provided to
> driver core, SPI and GPIO.

Solution seems still OF-centric (some of_* is in reset-gpio are left),
but the series in the right direction, thanks for doing this!

-- 
With Best Regards,
Andy Shevchenko

On Thu, Nov 20, 2025 at 4:06 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> Solution seems still OF-centric (some of_* is in reset-gpio are left),
> but the series in the right direction, thanks for doing this!
>

That's coming up, don't worry. Though I don't think it'll make v6.19.

Bart