From: Jonathan Cameron <jic23@kernel.org>
To: devicetree@vger.kernel.org, linux-iio@vger.kernel.org,
Rob Herring <robh@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
linux-kernel@vger.kernel.org,
Julia Lawall <Julia.Lawall@inria.fr>
Cc: Peter Zijlstra <peterz@infradead.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
marek.vasut@gmail.com,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: [RESEND PATCH v2 0/4] of: automate of_node_put() - new approach to loops.
Date: Sun, 25 Feb 2024 14:27:10 +0000 [thread overview]
Message-ID: <20240225142714.286440-1-jic23@kernel.org> (raw)
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some discussion occured on previous posting.
https://lore.kernel.org/linux-iio/20240223124432.26443-1-Jonathan.Cameron@huawei.com/
Summary:
* fwnode conversions should be considered when applying this
infrastructure to a driver. Perhaps better to move directly to
the generic FW property handling rather than improve existing
of specific code.
* There are lots of potential places to use this based on detections
from Julia's coccinelle scripts linked below.
The equivalent device_for_each_child_node_scoped() series for
fwnode will be queued up in IIO for the merge window shortly as
it has gathered sufficient tags. Hopefully the precdent set there
for the approach will reassure people that instantiating the
child variable inside the macro definition is the best approach.
https://lore.kernel.org/linux-iio/20240217164249.921878-1-jic23@kernel.org/
v2: Andy suggested most of the original converted set should move to
generic fwnode / property.h handling. Within IIO that was
a reasonable observation given we've been trying to move away from
firmware specific handling for some time. Patches making that change
to appropriate drivers posted.
As we discussed there are cases which are not suitable for such
conversion and this infrastructure still provides clear benefits
for them.
Ideally it would be good if this introductory series adding the
infrastructure makes the 6.9 merge window. There are no dependencies
on work queued in the IIO tree, so this can go via devicetree
if the maintainers would prefer. I've had some off list messages
asking when this would be merged, as there is interest in building
on it next cycle for other parts of the kernel (where conversion to
fwnode handling may be less appropriate).
The outputs of Julia's scripts linked below show how widely this can be
easily applied and give a conservative estimate of the complexity reduction
and code savings. In some cases those drivers should move to fwnode
and use the equivalent infrastructure there, but many will be unsuitable
for conversion so this is still good win.
Edited cover letter from v1:
Thanks to Julia Lawal who also posted coccinelle for both types (loop and
non loop cases)
https://lore.kernel.org/all/alpine.DEB.2.22.394.2401312234250.3245@hadrien/
https://lore.kernel.org/all/alpine.DEB.2.22.394.2401291455430.8649@hadrien/
The cover letter of the RFC includes information on the various approaches
considered.
https://lore.kernel.org/all/20240128160542.178315-1-jic23@kernel.org/
Whilst these macros produce nice reductions in complexity the loops
still have the unfortunate side effect of hiding the local declaration
of a struct device_node * which is then used inside the loop.
Julia suggested making that a little more visible via
#define for_each_child_of_node_scoped(parent, struct device_node *, child)
but in discussion we both expressed that this doesn't really make things
all that clear either so I haven't adopted this suggestion.
Jonathan Cameron (4):
of: Add cleanup.h based auto release via __free(device_node) markings.
of: Introduce for_each_*_child_of_node_scoped() to automate
of_node_put() handling
of: unittest: Use for_each_child_of_node_scoped()
iio: adc: rcar-gyroadc: use for_each_available_child_node_scoped()
drivers/iio/adc/rcar-gyroadc.c | 21 ++++++---------------
drivers/of/unittest.c | 11 +++--------
include/linux/of.h | 15 +++++++++++++++
3 files changed, 24 insertions(+), 23 deletions(-)
--
2.44.0
next reply other threads:[~2024-02-25 14:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-25 14:27 Jonathan Cameron [this message]
2024-02-25 14:27 ` [RESEND PATCH v2 1/4] of: Add cleanup.h based auto release via __free(device_node) markings Jonathan Cameron
2024-02-25 14:27 ` [RESEND PATCH v2 2/4] of: Introduce for_each_*_child_of_node_scoped() to automate of_node_put() handling Jonathan Cameron
2024-02-25 14:27 ` [RESEND PATCH v2 3/4] of: unittest: Use for_each_child_of_node_scoped() Jonathan Cameron
2024-02-25 14:27 ` [RESEND PATCH v2 4/4] iio: adc: rcar-gyroadc: use for_each_available_child_node_scoped() Jonathan Cameron
2024-03-25 19:53 ` Jonathan Cameron
2024-03-01 22:39 ` [RESEND PATCH v2 0/4] of: automate of_node_put() - new approach to loops Rob Herring
2024-03-03 11:56 ` Jonathan Cameron
2024-03-09 17:33 ` Jonathan Cameron
2024-03-12 18:10 ` Rob Herring
2024-03-13 9:18 ` Jonathan Cameron
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=20240225142714.286440-1-jic23@kernel.org \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=Julia.Lawall@inria.fr \
--cc=andriy.shevchenko@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marek.vasut@gmail.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).