From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: Jonathan Cameron <jic23@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
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>,
Lee Jones <lee@kernel.org>,
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>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, linux-leds@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH 3/6] leds: bd2606mvv: use device_for_each_child_node() to access device child nodes
Date: Sat, 13 Jul 2024 23:37:46 +0200 [thread overview]
Message-ID: <4f996369-2959-4e17-917d-f2de48d22064@gmail.com> (raw)
In-Reply-To: <20240712230656.67e89eb2@akphone>
On 12/07/2024 23:06, Andreas Kemnade wrote:
> On Mon, 8 Jul 2024 17:45:43 +0200
> Javier Carrasco <javier.carrasco.cruz@gmail.com> wrote:
>
>> On 08/07/2024 10:14, Javier Carrasco wrote:
>> What was the reason for this modification? Apparently, similar drivers
>> do everything in one loop to avoid such issues.
>>
> The reason for two loops is that we check in the first loop whether
> broghtness can be individually controlled so we can set max_brightness
> in the second loop. I had the assumption that max_brightness should be
> set before registering leds.
>
> Some LEDs share brightness register, in the case where leds are defined
> with a shared register, we revert to on-off.
>
>> Maybe refactoring to have a single loop again (if possible) would be
>> the cleanest solution. Otherwise a get/put mechanism might be
>> necessary.
>>
> I had no idea how to do it the time I wrote the patch.
>
> Regards,
> Andreas
Then we could leave the two loops, and fix them. I am thinking of something
like this:
static int bd2606mvv_probe(struct i2c_client *client)
{
- struct fwnode_handle *child;
struct device *dev = &client->dev;
struct bd2606mvv_priv *priv;
struct fwnode_handle *led_fwnodes[BD2606_MAX_LEDS] = { 0 };
int active_pairs[BD2606_MAX_LEDS / 2] = { 0 };
int err, reg;
- int i;
+ int i, j;
if (!dev_fwnode(dev))
return -ENODEV;
@@ -93,20 +92,18 @@ static int bd2606mvv_probe(struct i2c_client *client)
i2c_set_clientdata(client, priv);
- device_for_each_child_node(dev, child) {
+ device_for_each_child_node_scoped(dev, child) {
struct bd2606mvv_led *led;
err = fwnode_property_read_u32(child, "reg", ®);
- if (err) {
- fwnode_handle_put(child);
+ if (err)
return err;
- }
- if (reg < 0 || reg >= BD2606_MAX_LEDS || led_fwnodes[reg]) {
- fwnode_handle_put(child);
+
+ if (reg < 0 || reg >= BD2606_MAX_LEDS || led_fwnodes[reg])
return -EINVAL;
- }
+
led = &priv->leds[reg];
- led_fwnodes[reg] = child;
+ led_fwnodes[reg] = fwnode_handle_get(child);
active_pairs[reg / 2]++;
led->priv = priv;
led->led_no = reg;
@@ -129,7 +126,8 @@ static int bd2606mvv_probe(struct i2c_client *client)
&priv->leds[i].ldev,
&init_data);
if (err < 0) {
- fwnode_handle_put(child);
+ for (j = i; j < BD2606_MAX_LEDS; j++)
+ fwnode_handle_put(led_fwnodes[j]);
return dev_err_probe(dev, err,
"couldn't register LED %s\n",
priv->leds[i].ldev.name);
Thanks to the call to fwnode_get_handle(child), the child nodes get their
refcount incremented to be used in the second loop, where all child nodes that
have not been registered are released in case of error.
The first loop becomes a scoped one, keeping the `child` variable from being
accessed anywhere else.
Any feedback before I send a v2 with this is very welcome.
Best regards,
Javier Carrasco
next prev parent reply other threads:[~2024-07-13 21:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-06 15:23 [PATCH 0/6] use device_for_each_child_node() to access device child nodes Javier Carrasco
2024-07-06 15:23 ` [PATCH 1/6] device property: document device_for_each_child_node macro Javier Carrasco
2024-07-07 16:53 ` Jonathan Cameron
2024-07-06 15:23 ` [PATCH 2/6] hwmon: (ltc2992) use device_for_each_child_node_scoped() to access child nodes Javier Carrasco
2024-07-07 16:55 ` Jonathan Cameron
2024-07-06 15:23 ` [PATCH 3/6] leds: bd2606mvv: use device_for_each_child_node() to access device " Javier Carrasco
2024-07-07 16:57 ` Jonathan Cameron
2024-07-08 8:14 ` Javier Carrasco
2024-07-08 8:28 ` Jonathan Cameron
2024-07-08 15:45 ` Javier Carrasco
2024-07-12 21:06 ` Andreas Kemnade
2024-07-13 21:37 ` Javier Carrasco [this message]
2024-07-06 15:23 ` [PATCH 4/6] leds: is31fl319x: use device_for_each_child_node_scoped() to access " Javier Carrasco
2024-07-07 16:58 ` Jonathan Cameron
2024-07-06 15:23 ` [PATCH 5/6] leds: pca995x: use device_for_each_child_node() to access device " Javier Carrasco
2024-07-07 16:59 ` Jonathan Cameron
2024-07-06 15:23 ` [PATCH 6/6] net: mvpp2: " Javier Carrasco
2024-07-07 17:01 ` Jonathan Cameron
2024-07-29 8:23 ` Russell King (Oracle)
2024-07-29 9:23 ` Javier Carrasco
2024-07-29 13:00 ` Russell King (Oracle)
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=4f996369-2959-4e17-917d-f2de48d22064@gmail.com \
--to=javier.carrasco.cruz@gmail.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=jdelvare@suse.com \
--cc=jic23@kernel.org \
--cc=kuba@kernel.org \
--cc=lee@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 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 NNTP newsgroup(s).