Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2077c7e1-cf69-8648-20ac-23793f92ad14@9elements.com>
Date:   Mon, 27 Mar 2023 21:17:16 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH v2 2/2] leds: max597x: Add support for max597x
To:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        Lee Jones <lee@kernel.org>, Pavel Machek <pavel@ucw.cz>
Cc:     Patrick Rudolph <patrick.rudolph@9elements.com>,
        linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org
References: <20230323194550.1914725-1-Naresh.Solanki@9elements.com>
 <20230323194550.1914725-2-Naresh.Solanki@9elements.com>
 <d6463018-ebdf-30b2-ce0e-f2b5198847f1@wanadoo.fr>
 <688423c6-ba98-002c-efe5-7b0997d6af73@9elements.com>
 <cf18bc52-af25-8ce0-3536-202ea3c6e86d@wanadoo.fr>
Content-Language: en-US
From:   Naresh Solanki <naresh.solanki@9elements.com>
In-Reply-To: <cf18bc52-af25-8ce0-3536-202ea3c6e86d@wanadoo.fr>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi,

On 24-03-2023 09:06 pm, Christophe JAILLET wrote:
> Le 24/03/2023 à 11:54, Naresh Solanki a écrit :
>> Hi,
>>
>> On 24-03-2023 01:48 am, Christophe JAILLET wrote:
>>> Le 23/03/2023 à 20:45, Naresh Solanki a écrit :
>>>> From: Patrick Rudolph <patrick.rudolph@9elements.com>
>>>>
>>>> max597x is hot swap controller with indicator LED support.
>>>> This driver uses DT property to configure led during boot time &
>>>> also provide the LED control in sysfs.
>>>>
> 
> [...]
> 
> 
>>>> +static int max597x_led_probe(struct platform_device *pdev)
>>>> +{
>>>> +    struct device_node *np = dev_of_node(pdev->dev.parent);
>>>> +    struct regmap *regmap = dev_get_regmap(pdev->dev.parent, NULL);
>>>> +    struct device_node *led_node;
>>>> +    struct device_node *child;
>>>> +    int ret = 0;
>>>> +
>>>> +    if (!regmap)
>>>> +        return -EPROBE_DEFER;
>>>> +
>>>> +    led_node = of_get_child_by_name(np, "leds");
>>>> +    if (!led_node)
>>>> +        return -ENODEV;
>>>> +
>>>> +    for_each_available_child_of_node(led_node, child) {
>>>> +        u32 reg;
>>>> +
>>>> +        if (of_property_read_u32(child, "reg", &reg))
>>>> +            continue;
>>>> +
>>>> +        if (reg >= MAX597X_NUM_LEDS) {
>>>> +            dev_err(&pdev->dev, "invalid LED (%u >= %d)\n", reg,
>>>> +                MAX597X_NUM_LEDS);
>>>> +            continue;
>>>> +        }
>>>> +
>>>> +        ret = max597x_setup_led(&pdev->dev, regmap, child, reg);
>>>> +        if (ret < 0)
>>>> +            of_node_put(child);
>>>
>>> This of_node_put() looks odd to me.
>> Not sure if I get this right but if led setup fails of_node_put should 
>> be called.
> 
> My understanding is that this of_node_put() is there in case of error, 
> to release what would otherwise never be released by 
> for_each_available_child_of_node() if we exit early from the loop.
> 
> If the purpose is to release a reference taken in max597x_setup_led() in 
> case of error:
>     - this should be done IMHO within max597x_setup_led() directly
>     - there should be a of_node_get() somewhere in max597x_setup_led()
>       (after:
>      if (of_property_read_string(nc, "label", &led->led.name))
>          led->led.name = nc->name;
>        + error handling path,  *or*
>       just before the final return ret; when we know that everything is 
> fine,
>       if I understand correctly the code)
> 
> Is the reference taken elsewhere?
> Did I miss something obvious?
> 
> 
One of the reference is "drivers/leds/leds-sc27xx-bltc.c" line 311
Please do let me know if I have to do anything about it.

>>> "return ret;" or "break;" missing ?
>>>
>> Didn't add a break so that it can continue initializing remaining led 
>> if any.
> 
> Ok. Don't know the code enough to see if correct or not, but based on my 
> comment above, I think that something is missing in max597x_setup_led() 
> and that errors should be silently ignored here.
In my implementation, I have chosen to continue with the next LED if an 
error occurs, rather than aborting the 'for loop' with an error. I have 
seen other implementations also done in a similar way.
Do you have any further inputs or suggestions on this approach.

> 
> CJ
> 
>>>> +    }
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
> 
> [...]
> 
Regards,
Naresh