From: Rob Herring <robh@kernel.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: devicetree@vger.kernel.org, linux-iio@vger.kernel.org,
Frank Rowand <frowand.list@gmail.com>,
linux-kernel@vger.kernel.org,
Julia Lawall <Julia.Lawall@inria.fr>,
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: Re: [RESEND PATCH v2 0/4] of: automate of_node_put() - new approach to loops.
Date: Fri, 1 Mar 2024 16:39:42 -0600 [thread overview]
Message-ID: <20240301223942.GA3179769-robh@kernel.org> (raw)
In-Reply-To: <20240225142714.286440-1-jic23@kernel.org>
On Sun, Feb 25, 2024 at 02:27:10PM +0000, Jonathan Cameron wrote:
> 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).
I'll let you take it. For the series:
Reviewed-by: Rob Herring <robh@kernel.org>
I've got some drivers/of/ conversions too, but they are probably next
cycle at this point.
Rob
next prev parent reply other threads:[~2024-03-01 22:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-25 14:27 [RESEND PATCH v2 0/4] of: automate of_node_put() - new approach to loops Jonathan Cameron
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 ` Rob Herring [this message]
2024-03-03 11:56 ` [RESEND PATCH v2 0/4] of: automate of_node_put() - new approach to loops 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=20240301223942.GA3179769-robh@kernel.org \
--to=robh@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=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marek.vasut@gmail.com \
--cc=peterz@infradead.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 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.