All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Bartosz Golaszewski <brgl@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] software node: allow referencing software nodes by name
Date: Tue, 24 Mar 2026 08:59:24 +0100	[thread overview]
Message-ID: <2026032406-recycler-device-7660@gregkh> (raw)
In-Reply-To: <acIV6xF8mY-8wd5e@google.com>

On Mon, Mar 23, 2026 at 09:46:50PM -0700, Dmitry Torokhov wrote:
> Currently static device properties references require either an
> instance of software node or an instance of fwnode_handle to be
> available when defining a reference property. This may not be very
> convenient when device node is instantiated from a different module
> (which is usually the case).
> 
> The original implementation for describing GPIOs using software nodes
> worked around this by creating a detached from gpiochip instances
> software nodes, and performing matching using gpiochip label and node
> name. The gpiolib maintainers rightfully questioned this approach, and
> currently recommend to attach secondary software node to gpiochip
> instance, export the symbol, and use it in board file when instantiating
> static properties. This unfortunately results in tight coupling between
> gpiochip drivers and board code, necessitates creation of header files,
> requires adding Kconfig dependencies, limits options for choosing module
> vs built-in compilation, and alters device initialization/probing order.
> 
> Solve the issue by providing an option to use software node name in
> place of the node instance when describing reference properties. When
> evaluating reference driver core will attempt to resolve the name to
> concrete node instance and, in case of GPIO references, will use
> identity match on firmware node to locate corresponding gpiochip device.
> 
> This approach has a drawback of needing to know name of the node that
> gpiochip device will be using, however benefits (minimal coupling, no
> need for adding dependencies) outweigh this drawback.
> 
> To deal cases with software nodes not being created or registered at
> time of look up, assume that the node with matching name will get
> registered eventually and return -EPROBE_DEFER in the meantime.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  drivers/base/swnode.c    | 25 +++++++++++++++++++------
>  include/linux/property.h |  4 ++++
>  2 files changed, 23 insertions(+), 6 deletions(-)

Do you have a follow-on patch that uses this new api anywhere?

thanks,

greg k-h

  reply	other threads:[~2026-03-24  7:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24  4:46 [PATCH] software node: allow referencing software nodes by name Dmitry Torokhov
2026-03-24  7:59 ` Greg Kroah-Hartman [this message]
2026-03-24 16:25   ` Dmitry Torokhov
2026-03-24  9:46 ` Bartosz Golaszewski
2026-03-24 19:30   ` Dmitry Torokhov
2026-03-25 16:32     ` Bartosz Golaszewski
2026-03-25 18:11       ` Dmitry Torokhov
2026-03-26  8:26       ` Andy Shevchenko
2026-03-26  8:28         ` Andy Shevchenko
2026-03-26  8:34         ` Bartosz Golaszewski
2026-03-26  8:39           ` Andy Shevchenko
2026-03-26  8:47             ` Bartosz Golaszewski
2026-03-26  9:03               ` Andy Shevchenko
2026-03-26  8:48             ` Andy Shevchenko
2026-03-26 15:47               ` Bartosz Golaszewski
2026-03-26 19:01                 ` Andy Shevchenko
2026-03-31 12:18                   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026032406-recycler-device-7660@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brgl@kernel.org \
    --cc=dakr@kernel.org \
    --cc=djrscally@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=driver-core@lists.linux.dev \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.