From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Amireddy Mallikarjuna reddy"
<mallikarjunax.reddy@linux.intel.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Marek Behún" <marek.behun@nic.cz>,
"Abanoub Sameh" <abanoubsameh8@gmail.com>,
"Dan Murphy" <dmurphy@ti.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
"Luca Weiss" <luca@z3ntu.xyz>
Subject: Re: [PATCH v1 28/28] leds: sgm3140: Put fwnode in any case during ->probe()
Date: Fri, 28 May 2021 13:59:53 +0300 [thread overview]
Message-ID: <YLDNKekDfNQPorRG@smile.fi.intel.com> (raw)
In-Reply-To: <20210528101454.GJ2209@amd>
On Fri, May 28, 2021 at 12:14:54PM +0200, Pavel Machek wrote:
> Hi!
>
> > fwnode_get_next_child_node() bumps a reference counting of a returned variable.
> > We have to balance it whenever we return to the caller.
>
> This (and similar) -- in half of the drivers we hold the handle from
> successful probe. Is it a problem and why is it problem only for some
> drivers?
Hmm... I'm not sure I have understood the question correctly. Any examples of
the driver that you think needs some attention?
In general the idea is that these kind of for-loops or getting next fwnode
should be balanced.
In case of for-loops the error or any other breakage means that reference count
is bumped, for the get_next API it's always the case.
I have checked between drivers and only considered above cases. Wherever there
is a for-loop which isn't broken, we are fine. Wherever we have explicit
reference counter drop for get_next cases, we are fine. If (any) framework
requires the resource to be present that framework should bump and drop
reference count on the resource by itself (so I split LED framework out from
the consideration and consider that it does the right things)
> Thanks for series, btw, I pushed out current version of the tree.
Should I rebase the new version on something I can find in your Git tree?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2021-05-28 10:59 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 9:50 [PATCH v1 00/28] leds: cleanups and fwnode refcounting bug fixes Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 01/28] leds: class: The -ENOTSUPP should never be seen by user space Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 02/28] leds: core: " Andy Shevchenko
2021-05-28 10:03 ` Pavel Machek
2021-05-28 10:43 ` Andy Shevchenko
2021-05-29 9:42 ` Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 03/28] leds: el15203000: Give better margin for usleep_range() Andy Shevchenko
2021-05-28 10:04 ` Pavel Machek
2021-05-28 10:45 ` Andy Shevchenko
2021-05-29 9:41 ` Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 04/28] leds: el15203000: Make error handling more robust Andy Shevchenko
2021-05-28 20:59 ` Oleh Kravchenko
2021-05-10 9:50 ` [PATCH v1 05/28] leds: el15203000: Correct headers (of*.h -> mod_devicetable.h) Andy Shevchenko
2021-05-28 21:00 ` Oleh Kravchenko
2021-05-29 9:45 ` Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 06/28] leds: el15203000: Introduce to_el15203000_led() helper Andy Shevchenko
2021-05-28 21:01 ` Oleh Kravchenko
2021-05-10 9:50 ` [PATCH v1 07/28] leds: lgm-sso: Fix clock handling Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 08/28] leds: lgm-sso: Put fwnode in any case during ->probe() Andy Shevchenko
2021-05-28 10:08 ` Pavel Machek
2021-05-28 10:46 ` Andy Shevchenko
2021-05-29 9:28 ` Andy Shevchenko
2021-05-29 10:46 ` Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 09/28] leds: lgm-sso: Don't spam logs when probe is deferred Andy Shevchenko
2021-05-28 10:11 ` Pavel Machek
2021-05-28 10:47 ` Andy Shevchenko
2021-05-29 9:54 ` Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 10/28] leds: lgm-sso: Remove unneeded of_match_ptr() Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 11/28] leds: lgm-sso: Remove explicit managed resource cleanups Andy Shevchenko
2021-05-28 10:09 ` Pavel Machek
2021-05-28 10:49 ` Andy Shevchenko
2021-05-29 9:46 ` Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 12/28] leds: lgm-sso: Drop duplicate NULL check for GPIO operations Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 13/28] leds: lgm-sso: Convert to use list_for_each_entry*() API Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 14/28] leds: lm3532: select regmap I2C API Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 15/28] leds: lm3532: Make error handling more robust Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 16/28] leds: lm36274: Put fwnode in error case during ->probe() Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 17/28] leds: lm36274: Correct headers (of*.h -> mod_devicetable.h) Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 18/28] leds: lm3692x: Put fwnode in any case during ->probe() Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 19/28] leds: lm3692x: Correct headers (of*.h -> mod_devicetable.h) Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 20/28] leds: lm3697: Update header block to reflect reality Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 21/28] leds: lm3697: Make error handling more robust Andy Shevchenko
2021-05-28 10:10 ` Pavel Machek
2021-05-28 10:50 ` Andy Shevchenko
2021-05-29 9:50 ` Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 22/28] leds: lm3697: Don't spam logs when probe is deferred Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 23/28] leds: lp50xx: Put fwnode in error case during ->probe() Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 24/28] leds: lt3593: Put fwnode in any " Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 25/28] leds: lt3593: Make use of device properties Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 26/28] leds: pwm: Make error handling more robust Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 27/28] leds: rt8515: Put fwnode in any case during ->probe() Andy Shevchenko
2021-05-10 9:50 ` [PATCH v1 28/28] leds: sgm3140: " Andy Shevchenko
2021-05-28 10:14 ` Pavel Machek
2021-05-28 10:59 ` Andy Shevchenko [this message]
2021-05-29 9:58 ` Andy Shevchenko
2021-05-17 7:30 ` [PATCH v1 00/28] leds: cleanups and fwnode refcounting bug fixes Andy Shevchenko
2021-05-24 14:56 ` Andy Shevchenko
2021-05-24 17:49 ` Pavel Machek
2021-05-24 18:39 ` Andy Shevchenko
2021-05-28 10:02 ` Pavel Machek
2021-05-28 11:05 ` Andy Shevchenko
2021-05-28 20:34 ` Pavel Machek
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=YLDNKekDfNQPorRG@smile.fi.intel.com \
--to=andy.shevchenko@gmail.com \
--cc=abanoubsameh8@gmail.com \
--cc=dmurphy@ti.com \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=luca@z3ntu.xyz \
--cc=mallikarjunax.reddy@linux.intel.com \
--cc=marek.behun@nic.cz \
--cc=pavel@ucw.cz \
/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.