linux-kernel - Re: [PATCH v5] i2c: imx: support DMA defer probing

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <89a3b1c9-2be2-4e7f-a0c6-abbf8b88957b@pengutronix.de>
Date: Fri, 20 Dec 2024 09:40:06 +0100
From: Ahmad Fatoum <a.fatoum@...gutronix.de>
To: Carlos Song <carlos.song@....com>,
 Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andi Shyti <andi.shyti@...nel.org>, Frank Li <frank.li@....com>,
 "kernel@...gutronix.de" <kernel@...gutronix.de>,
 "shawnguo@...nel.org" <shawnguo@...nel.org>,
 "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
 "festevam@...il.com" <festevam@...il.com>,
 "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
 "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Clark Wang <xiaoning.wang@....com>
Subject: Re: [PATCH v5] i2c: imx: support DMA defer probing

Hi,

On 20.12.24 09:06, Carlos Song wrote:
>> -----Original Message-----
>> On Fri, Dec 20, 2024 at 07:38:47AM +0000, Carlos Song wrote:
>>>> -----Original Message-----
>>>> From: Oleksij Rempel <o.rempel@...gutronix.de>
>>>> Sent: Friday, December 20, 2024 3:35 PM
>>>> To: Ahmad Fatoum <a.fatoum@...gutronix.de>
>>>> Cc: Carlos Song <carlos.song@....com>; Andi Shyti
>>>> <andi.shyti@...nel.org>; Frank Li <frank.li@....com>;
>>>> kernel@...gutronix.de; shawnguo@...nel.org; s.hauer@...gutronix.de;
>>>> festevam@...il.com; linux-i2c@...r.kernel.org; imx@...ts.linux.dev;
>>>> linux-arm-kernel@...ts.infradead.org;
>>>> linux-kernel@...r.kernel.org; Clark Wang <xiaoning.wang@....com>
>>>> Subject: [EXT] Re: [PATCH v5] i2c: imx: support DMA defer probing

>>>>>> I think this is what you want to see, right?
>>>>>
>>>>> This loses the information why the error happens (ret). Using
>>>>> dev_err_probe even if no probe deferral is expected in that branch
>>>>> is perfectly fine and the kernel-doc even points it out:
>>>>>
>>>>>   Using this helper in your probe function is totally fine even if @err
>>>>>   is known to never be -EPROBE_DEFER.
>>>>
>>>> Thank you for the feedback. While I recognize the benefits of
>>>> dev_err_probe() for compact and standardized error handling, using
>>>> it without returning its result raises a red flag.

Agreed, which is what spawned this thread in the first place.

If we want to ignore errors intentionally, I think a comment
like the following would make this clearer:

  /*
   * As we can always fall back to PIO, let's ignore the error setting up
   * DMA and see if we run into errors while setting up PIO mode.
   */


>>>> The function's primary purpose is to combine error logging with
>>>> returning the error code. If the return value is not used, it can
>>>> create confusion and suggests potential oversight or unintended
>>>> behavior. This misuse might mislead readers into thinking that the
>>>> function always returns at that point, which is not the case here.
>>>>
>>>> In this scenario, using dev_err() directly is more explicit and
>>>> avoids any ambiguity about the control flow or error handling
>>>> intent. It keeps the code clear and aligned with its actual behavior.

This is a fair point. I don't mind whether we use dev_err_probe or
dev_err with a return code, it's up to you ultimately. I just wanted
the error code to be included and I think a comment would be a good
idea to avoid confusion (provided we keep behavior as-is).

>>> how about this?
>>>
>>> +       ret = i2c_imx_dma_request(i2c_imx, phy_addr);
>>> +       if (ret) {
>>> +               if (ret == -EPROBE_DEFER)
>>> +                       goto clk_notifier_unregister;
>>> +               else if (ret == -ENODEV)
>>> +                       dev_dbg(&pdev->dev, "Only use PIO mode\n");
>>> +               else
>>> +                       dev_err(&pdev->dev, "Failed to setup DMA (%d),
>> only use PIO mode\n", ret);
>>> +       }
>>
>> Please use human readable version of error value. In this case it will
>> be:
>>   dev_err(&pdev->dev, "Failed to setup DMA (%pe), only use PIO mode\n",
>> ERR_PTR(ret));

Sounds good to me.

> Hi, the ret is from i2c_imx_dma_request() and look like that ret has been converted by PTR_ERR,
> So the ret error has been human readable version?

I am not sure I understand the question. ERR_PTR() makes an error pointer and %pe
formats that pointer as error message. So you don't need to change any function
return types unless needed, just at the end print it with %pe instead of %d
(and after error pointer conversion if needed).

Cheers,
Ahmad


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |