From: Lee Jones <lee@kernel.org>
To: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Jonathan Cameron <jic23@kernel.org>,
Rob Herring <robh@kernel.org>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Jean Delvare <jdelvare@suse.com>,
Guenter Roeck <linux@roeck-us.net>, Pavel Machek <pavel@ucw.cz>,
Marcin Wojtas <marcin.s.wojtas@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Andreas Kemnade <andreas@kemnade.info>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, linux-leds@vger.kernel.org,
netdev@vger.kernel.org,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v2 0/6] use device_for_each_child_node() to access device child nodes
Date: Thu, 25 Jul 2024 16:48:13 +0100 [thread overview]
Message-ID: <20240725154813.GI501857@google.com> (raw)
In-Reply-To: <20240721-device_for_each_child_node-available-v2-0-f33748fd8b2d@gmail.com>
On Sun, 21 Jul 2024, Javier Carrasco wrote:
> This series aims to clarify the use cases of:
>
> - device_for_each_child_node[_scoped]()
> - fwnode_for_each_available_child_node[_scoped]()
>
> to access firmware nodes.
>
> There have been multiple discussions [1][2] about what the first macro
> implies in the sense of availability, and a number of users have opted
> for the second macro in cases where the first one should have been
> preferred.
>
> The second macro is intended to be used over child nodes of a firmware
> node, not direct child nodes of the device node. Instead, those users
> retrieve the fwnode member from the device struct just to have access to
> a macro that explicitly indicates node availability.
>
> That workaround is not necessary because `device_for_each_child_node()`
> implies availability for the existing backends (ACPI, DT, swnode).
>
> This series does not cover other points discussed in [2] like addressing
> uses of `fwnode_for_each_child_node()` where `device_*` should have been
> used, using the `_avaialble_` variant of the fwnode loop whenever
> possible, or adding new `_scoped` macros. Such points will be covered by
> subsequent series to keep focus on the "availability" issue.
>
> The conversion has been validated with an LTC2992 hwmon sensor, which is
> one of the affected drivers. The rest of the drivers could only be
> compiled and checked with static-analysis tools.
>
> Link: https://lore.kernel.org/all/20211205190101.26de4a57@jic23-huawei/ [1]
> Link: https://lore.kernel.org/all/20240523-fwnode_for_each_available_child_node_scoped-v2-0-701f3a03f2fb@gmail.com/ [2]
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> Changes in v2:
> - [1/6] property.h: drop "if found" from the description of
> device_for_each_child_node()
> - [3/6] bd2607mvv.c: fix child node usage.
> - Link to v1: https://lore.kernel.org/r/20240706-device_for_each_child_node-available-v1-0-8a3f7615e41c@gmail.com
>
> ---
> Javier Carrasco (6):
> device property: document device_for_each_child_node macro
> hwmon: (ltc2992) use device_for_each_child_node_scoped() to access child nodes
> leds: bd2606mvv: fix device child node usage in bd2606mvv_probe()
> leds: is31fl319x: use device_for_each_child_node_scoped() to access child nodes
> leds: pca995x: use device_for_each_child_node() to access device child nodes
> net: mvpp2: use device_for_each_child_node() to access device child nodes
>
> drivers/hwmon/ltc2992.c | 19 ++++----------
> drivers/leds/leds-bd2606mvv.c | 23 ++++++++---------
> drivers/leds/leds-is31fl319x.c | 34 ++++++++-----------------
> drivers/leds/leds-pca995x.c | 15 ++++-------
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 13 +++-------
> include/linux/property.h | 10 ++++++++
> 6 files changed, 45 insertions(+), 69 deletions(-)
> ---
> base-commit: 41c196e567fb1ea97f68a2ffb7faab451cd90854
> change-id: 20240701-device_for_each_child_node-available-1c1eca4b6495
fatal: bad object 41c196e567fb1ea97f68a2ffb7faab451cd90854
And the LED patches do not apply to LED.
Please rebase onto -next.
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2024-07-25 15:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-21 15:19 [PATCH v2 0/6] use device_for_each_child_node() to access device child nodes Javier Carrasco
2024-07-21 15:19 ` [PATCH v2 1/6] device property: document device_for_each_child_node macro Javier Carrasco
2024-07-22 7:15 ` Markus Elfring
2024-07-22 7:40 ` Greg Kroah-Hartman
2024-07-21 15:19 ` [PATCH v2 2/6] hwmon: (ltc2992) use device_for_each_child_node_scoped() to access child nodes Javier Carrasco
2024-07-21 18:22 ` Guenter Roeck
2024-07-21 15:19 ` [PATCH v2 3/6] leds: bd2606mvv: fix device child node usage in bd2606mvv_probe() Javier Carrasco
2024-07-21 15:19 ` [PATCH v2 4/6] leds: is31fl319x: use device_for_each_child_node_scoped() to access child nodes Javier Carrasco
2024-07-21 15:19 ` [PATCH v2 5/6] leds: pca995x: use device_for_each_child_node() to access device " Javier Carrasco
2024-07-21 15:19 ` [PATCH v2 6/6] net: mvpp2: " Javier Carrasco
2024-07-25 15:48 ` Lee Jones [this message]
2024-07-25 16:28 ` (subset) [PATCH v2 0/6] " Lee Jones
2024-07-29 18:12 ` Javier Carrasco
2024-08-01 12:39 ` Lee Jones
2024-08-02 7:37 ` Javier Carrasco
2024-08-05 14:32 ` Lee Jones
2024-08-05 14:33 ` Lee Jones
2024-08-05 14:41 ` Javier Carrasco
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=20240725154813.GI501857@google.com \
--to=lee@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=andreas@kemnade.info \
--cc=andriy.shevchenko@linux.intel.com \
--cc=davem@davemloft.net \
--cc=djrscally@gmail.com \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=jdelvare@suse.com \
--cc=jic23@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@roeck-us.net \
--cc=marcin.s.wojtas@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=robh@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.