The iterated nodes are direct children of the device node, and the
`device_for_each_child_node()` macro accounts for child node
availability.

`fwnode_for_each_available_child_node()` is meant to access the child
nodes of an fwnode, and therefore not direct child nodes of the device
node.

Use `device_for_each_child_node()` to indicate device's direct child
nodes.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
 drivers/leds/leds-pca995x.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/leds/leds-pca995x.c b/drivers/leds/leds-pca995x.c
index 686b77772cce..83bc9669544c 100644
--- a/drivers/leds/leds-pca995x.c
+++ b/drivers/leds/leds-pca995x.c
@@ -120,7 +120,7 @@ static const struct regmap_config pca995x_regmap = {
 static int pca995x_probe(struct i2c_client *client)
 {
 	struct fwnode_handle *led_fwnodes[PCA995X_MAX_OUTPUTS] = { 0 };
-	struct fwnode_handle *np, *child;
+	struct fwnode_handle *child;
 	struct device *dev = &client->dev;
 	const struct pca995x_chipdef *chipdef;
 	struct pca995x_chip *chip;
@@ -129,8 +129,7 @@ static int pca995x_probe(struct i2c_client *client)
 
 	chipdef = device_get_match_data(&client->dev);
 
-	np = dev_fwnode(dev);
-	if (!np)
+	if (!dev_fwnode(dev))
 		return -ENODEV;
 
 	chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
@@ -144,17 +143,13 @@ static int pca995x_probe(struct i2c_client *client)
 
 	i2c_set_clientdata(client, chip);
 
-	fwnode_for_each_available_child_node(np, child) {
+	device_for_each_child_node(dev, child) {
 		ret = fwnode_property_read_u32(child, "reg", &reg);
-		if (ret) {
-			fwnode_handle_put(child);
+		if (ret)
 			return ret;
-		}
 
-		if (reg < 0 || reg >= PCA995X_MAX_OUTPUTS || led_fwnodes[reg]) {
-			fwnode_handle_put(child);
+		if (reg < 0 || reg >= PCA995X_MAX_OUTPUTS || led_fwnodes[reg])
 			return -EINVAL;
-		}
 
 		led = &chip->leds[reg];
 		led_fwnodes[reg] = child;

-- 
2.43.0

On Mon, 05 Aug 2024 16:49:45 +0200, Javier Carrasco wrote:
> The iterated nodes are direct children of the device node, and the
> `device_for_each_child_node()` macro accounts for child node
> availability.
> 
> `fwnode_for_each_available_child_node()` is meant to access the child
> nodes of an fwnode, and therefore not direct child nodes of the device
> node.
> 
> [...]

Applied, thanks!

[2/4] leds: pca995x: use device_for_each_child_node() to access device child nodes
      commit: 6eefd65ba6ae29ab801f6461e59c10f93dd496f8

--
Lee Jones [李琼斯]

On Mon, 05 Aug 2024, Lee Jones wrote:

> On Mon, 05 Aug 2024 16:49:45 +0200, Javier Carrasco wrote:
> > The iterated nodes are direct children of the device node, and the
> > `device_for_each_child_node()` macro accounts for child node
> > availability.
> > 
> > `fwnode_for_each_available_child_node()` is meant to access the child
> > nodes of an fwnode, and therefore not direct child nodes of the device
> > node.
> > 
> > [...]
> 
> Applied, thanks!
> 
> [2/4] leds: pca995x: use device_for_each_child_node() to access device child nodes
>       commit: 6eefd65ba6ae29ab801f6461e59c10f93dd496f8

I'm not sure what you rebased onto, but it wasn't LEDs or -next.

Anyway, I fixed-up the conflicts and pushed.

The patch should be in -next by tomorrow.

Please check it to ensure I didn't make any mistakes.

-- 
Lee Jones [李琼斯]

On 05/08/2024 18:01, Lee Jones wrote:
> On Mon, 05 Aug 2024, Lee Jones wrote:
> 
>> On Mon, 05 Aug 2024 16:49:45 +0200, Javier Carrasco wrote:
>>> The iterated nodes are direct children of the device node, and the
>>> `device_for_each_child_node()` macro accounts for child node
>>> availability.
>>>
>>> `fwnode_for_each_available_child_node()` is meant to access the child
>>> nodes of an fwnode, and therefore not direct child nodes of the device
>>> node.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [2/4] leds: pca995x: use device_for_each_child_node() to access device child nodes
>>       commit: 6eefd65ba6ae29ab801f6461e59c10f93dd496f8
> 
> I'm not sure what you rebased onto, but it wasn't LEDs or -next.
> 
> Anyway, I fixed-up the conflicts and pushed.
> 
> The patch should be in -next by tomorrow.
> 
> Please check it to ensure I didn't make any mistakes.
> 

Hi, I rebased onto next-20240805, and its commit ID matches the
base-commit provided in the cover letter (generated by b4). I wonder why
it did not work on your side, but thanks for fixing the conflicts and
applying (I checked it and it looks fine).

Best regards,
Javier Carrasco