From: Greg KH <gregkh@linuxfoundation.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PULL] IIO: 3rd set for 6.9 - cleanup.h handling of fwnode_handle_put() related (not ordered wrt to PULL 2)
Date: Sat, 2 Mar 2024 20:06:03 +0100 [thread overview]
Message-ID: <2024030239-gift-cabdriver-266b@gregkh> (raw)
In-Reply-To: <20240229202300.3321cc11@jic23-huawei>
On Thu, Feb 29, 2024 at 08:23:00PM +0000, Jonathan Cameron wrote:
> The following changes since commit d4551c189d6e6a3fcf7f625bd4b273e770fad35a:
>
> Merge tag 'iio-for-6.9a' of http://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next (2024-02-25 14:11:41 +0100)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git tags/iio-for-6.9c
>
> for you to fetch changes up to 64e19caa5564ecc43edaa7fb818d53de650d9b34:
>
> iio: adc: rzg2l_adc: Use device_for_each_child_node_scoped() (2024-02-28 19:15:43 +0000)
>
> ----------------------------------------------------------------
> IIO: 3rd set for 6.9 - cleanup.h related.
>
> I have separated this set out from the more normal patches as they can
> go separately and that may simplify the merge window. Greg, up to you
> how you wish to handle this in the char-misc tree.
>
> Introduces __free() based handling for fwnode_handle_put() to
> allow scope based release of these handles on early exit from functions.
This should be fine, right? No one complains about these.
> Also introduced device_for_each_child_node_scoped() to provide a
> a convenient way to process child nodes without the need to explicitly
> handle the fwnode_handle_put() needed on early exits from the loop.
> Typically these early exits are a result of error handling or completion
> of a search and have proven very prone to being missed.
This is trickier, there was a load of different versions floating
around, do you have a link to the "last" version of this patch series
that got applied here?
> One instance of such a leaked resource was found during these conversions
> though review of that patch was too late for this pull request.
I don't understand, does this series fix that found problem? Or is it
coming?
> A number of drivers are also converted over to generic fwnode handling from
> the device tree specific version.
Deleting code is always good, but:
>
> ----------------------------------------------------------------
> Jonathan Cameron (16):
> device property: Move fwnode_handle_put() into property.h
> device property: Add cleanup.h based fwnode_handle_put() scope based cleanup.
> device property: Introduce device_for_each_child_node_scoped()
> iio: adc: max11410: Use device_for_each_child_node_scoped()
> iio: addac: ad74413r: Use device_for_each_child_node_scoped()
> iio: dac: ltc2688: Use device_for_each_child_node_scoped()
> iio: adc: fsl-imx25-gcq: Switch from of specific handing to fwnode based.
> iio: adc: fsl-imx25-gcq: Use devm_* and dev_err_probe() to simplify probe
> iio: adc: ad7124: Switch from of specific to fwnode based property handling
> iio: adc: ad7292: Switch from of specific to fwnode property handling
> iio: adc: ad7192: Convert from of specific to fwnode property handling
> iio: accel: mma8452: Switch from of specific to fwnode property handling.
> iio: accel: fxls8962af: Switch from of specific to fwnode based properties.
> iio: adc: hx711: Switch from of specific to fwnode property handling.
> iio: temp: ltc2983: Use __free(fwnode_handle) and device_for_each_node_scoped()
> iio: adc: rzg2l_adc: Use device_for_each_child_node_scoped()
You are mixing the two different handlers in this series, right? How
about 2 different ones, one for each? Or do they start to conflict?
thanks,
greg k-h
next prev parent reply other threads:[~2024-03-02 19:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 20:23 [PULL] IIO: 3rd set for 6.9 - cleanup.h handling of fwnode_handle_put() related (not ordered wrt to PULL 2) Jonathan Cameron
2024-03-02 19:06 ` Greg KH [this message]
2024-03-03 11:41 ` Jonathan Cameron
2024-03-25 20:21 ` 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=2024030239-gift-cabdriver-266b@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.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