linux-kernel - Re: [PATCH v3 3/5] soc: mediatek: pwrap: Move and check return value of platform_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7f4f12ef-4fda-2092-1129-d0be498c7b20@collabora.com>
Date:   Tue, 17 May 2022 12:35:47 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Matthias Brugger <matthias.bgg@...il.com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        nfraprado@...labora.com, rex-bc.chen@...iatek.com,
        zhiyong.tao@...iatek.com
Subject: Re: [PATCH v3 3/5] soc: mediatek: pwrap: Move and check return value
 of platform_get_irq()

Il 17/05/22 11:49, Matthias Brugger ha scritto:
> 
> 
> On 17/05/2022 11:34, AngeloGioacchino Del Regno wrote:
>> Il 17/05/22 11:18, Matthias Brugger ha scritto:
>>>
>>>
>>> On 16/05/2022 14:46, AngeloGioacchino Del Regno wrote:
>>>> Move the call to platform_get_irq() earlier in the probe function
>>>> and check for its return value: if no interrupt is specified, it
>>>> wouldn't make sense to try to call devm_request_irq() so, in that
>>>> case, we can simply return early.
>>>>
>>>> Moving the platform_get_irq() call also makes it possible to use
>>>> one less goto, as clocks aren't required at that stage.
>>>>
>>>> Signed-off-by: AngeloGioacchino Del Regno 
>>>> <angelogioacchino.delregno@...labora.com>
>>>> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
>>>> Tested-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
>>>> ---
>>>>   drivers/soc/mediatek/mtk-pmic-wrap.c | 5 ++++-
>>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
>>>> b/drivers/soc/mediatek/mtk-pmic-wrap.c
>>>> index 852514366f1f..332cbcabc299 100644
>>>> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
>>>> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
>>>> @@ -2204,6 +2204,10 @@ static int pwrap_probe(struct platform_device *pdev)
>>>>       if (!wrp)
>>>>           return -ENOMEM;
>>>> +    irq = platform_get_irq(pdev, 0);
>>>> +    if (irq < 0)
>>>> +        return irq;
>>>> +
>>>>       platform_set_drvdata(pdev, wrp);
>>>>       wrp->master = of_device_get_match_data(&pdev->dev);
>>>> @@ -2316,7 +2320,6 @@ static int pwrap_probe(struct platform_device *pdev)
>>>>       if (HAS_CAP(wrp->master->caps, PWRAP_CAP_INT1_EN))
>>>>           pwrap_writel(wrp, wrp->master->int1_en_all, PWRAP_INT1_EN);
>>>> -    irq = platform_get_irq(pdev, 0);
>>>
>>> For better readability of the code I'd prefer to keep platform_get_irq next to 
>>> devm_request_irq. I understand that you did this change so that you don't have 
>>> to code
>>> if (irq < 0) {
>>>      ret = irq;
>>>      goto err_out2;
>>> }
>>>
>>> Or do I miss something?
>>>
>>
>> That's for the sake of reducing gotos in the code... but there's a bigger
>> picture that I haven't explained in this commit and that will come later
>> because I currently don't have the necessary time to perform a "decent"
>> testing.
>>
>> As I was explaining - the bigger pictures implies adding a new function for
>> clock teardown, that we will add as a devm action:
>>
>> devm_add_action_or_reset(&pdev->dev, pwrap_clk_disable_unprepare, wrp)
>>
>> ...so that we will be able to remove *all* gotos from the probe function.
>>
>> Sounds good?
>>
> 
> Sounds good, but that means we could get rid of the goto as well. Anyway I prefer 
> to have platform_get_irq next to devm_request_irq. If we can get rid of the goto in 
> the future, great.

Oki, then I'll send a v4 and avoid to move that one elsewhere - will keep the goto
as well.

Looking back at it, effectively, it doesn't really make sense to move that call!

Cheers,
Angelo