On 29/09/2023 13:03, Marek Szyprowski wrote:
> On 29.09.2023 12:46, Daniel Lezcano wrote:
>> On 26/09/2023 13:02, Mateusz Majewski wrote:
>>> Hi,
>>>
>>>> This is not equivalent. If regulator is provided and enable fails, the
>>>> old code is nicely returning error. Now, it will print misleading
>>>> message - failed to get regulator - and continue.
>>>>
>>>> While this simplifies the code, it ignores important running
>>>> condition -
>>>> having regulator enabled.
>>>
>>> Would doing this be correct?
>>>
>>> ret = devm_regulator_get_enable_optional(&pdev->dev, "vtmu");
>>> switch (ret) {
>>> case 0:
>>> case -ENODEV:
>>
>> Not sure to understand why -NODEV is not an error
>
>
> Because this what devm_regulator_get_enable_optional() returns if no
> regulator is defined. I also got confused by this a few times.
The code before this change calls devm_regulator_get_optional() which
returns -ENODEV too, right ? But there is no special case for this error.
So this change uses devm_regulator_get_enable_optional() and handle the
ENODEV as a non-error, so there is a change in the behavior.
>>> break;
>>> case -EPROBE_DEFER:
>>> return -EPROBE_DEFER;
>>> default:
>>> dev_err(&pdev->dev, "Failed to get enabled regulator: %d\n",
>>> ret);
>>> return ret;
>>> }
>>
>> ret = devm_regulator_get_enable_optional(&pdev->dev, "vtmu");
>> if (ret < 0) {
>> if (ret != EPROBE_DEFER)
>> dev_err(&pdev->dev, "Failed to get enabled regulator: %d\n",
>> ret);
>> return ret;
>> }
>>
>> ??
>>
> Best regards
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
On 29.09.2023 13:45, Daniel Lezcano wrote:
> On 29/09/2023 13:03, Marek Szyprowski wrote:
>> On 29.09.2023 12:46, Daniel Lezcano wrote:
>>> On 26/09/2023 13:02, Mateusz Majewski wrote:
>>>> Hi,
>>>>
>>>>> This is not equivalent. If regulator is provided and enable fails,
>>>>> the
>>>>> old code is nicely returning error. Now, it will print misleading
>>>>> message - failed to get regulator - and continue.
>>>>>
>>>>> While this simplifies the code, it ignores important running
>>>>> condition -
>>>>> having regulator enabled.
>>>>
>>>> Would doing this be correct?
>>>>
>>>> ret = devm_regulator_get_enable_optional(&pdev->dev, "vtmu");
>>>> switch (ret) {
>>>> case 0:
>>>> case -ENODEV:
>>>
>>> Not sure to understand why -NODEV is not an error
>>
>>
>> Because this what devm_regulator_get_enable_optional() returns if no
>> regulator is defined. I also got confused by this a few times.
>
> The code before this change calls devm_regulator_get_optional() which
> returns -ENODEV too, right ? But there is no special case for this error.
>
> So this change uses devm_regulator_get_enable_optional() and handle
> the ENODEV as a non-error, so there is a change in the behavior.
It looks that the original code ignores any non-EPROBE_DEFER errors from
devm_regulator_get_optional(). That's a bug, indeed.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 29/09/2023 14:00, Marek Szyprowski wrote:
> On 29.09.2023 13:45, Daniel Lezcano wrote:
>> On 29/09/2023 13:03, Marek Szyprowski wrote:
>>> On 29.09.2023 12:46, Daniel Lezcano wrote:
>>>> On 26/09/2023 13:02, Mateusz Majewski wrote:
>>>>> Hi,
>>>>>
>>>>>> This is not equivalent. If regulator is provided and enable fails,
>>>>>> the
>>>>>> old code is nicely returning error. Now, it will print misleading
>>>>>> message - failed to get regulator - and continue.
>>>>>>
>>>>>> While this simplifies the code, it ignores important running
>>>>>> condition -
>>>>>> having regulator enabled.
>>>>>
>>>>> Would doing this be correct?
>>>>>
>>>>> ret = devm_regulator_get_enable_optional(&pdev->dev, "vtmu");
>>>>> switch (ret) {
>>>>> case 0:
>>>>> case -ENODEV:
>>>>
>>>> Not sure to understand why -NODEV is not an error
>>>
>>>
>>> Because this what devm_regulator_get_enable_optional() returns if no
>>> regulator is defined. I also got confused by this a few times.
>>
>> The code before this change calls devm_regulator_get_optional() which
>> returns -ENODEV too, right ? But there is no special case for this error.
>>
>> So this change uses devm_regulator_get_enable_optional() and handle
>> the ENODEV as a non-error, so there is a change in the behavior.
>
>
> It looks that the original code ignores any non-EPROBE_DEFER errors from
> devm_regulator_get_optional(). That's a bug, indeed.
How about separate change fixing it? I know the same code will be
changed twice, but it will be easier to backport and analyze in case of
issues.
Best regards,
Krzysztof