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:
 <AM0PR0402MB39374CFFA66D8121DB218334E8072@AM0PR0402MB3937.eurprd04.prod.outlook.com>
Date: Fri, 20 Dec 2024 09:23:23 +0000
From: Carlos Song <carlos.song@....com>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>, 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



> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@...gutronix.de>
> Sent: Friday, December 20, 2024 4:40 PM
> 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; 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
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> 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
>

Sorry, I don't know if I understand it incorrectly.
I review other driver code, most choose to return error value but not an error pointer.
Shouldn't error value be more readable than error pointers?
When we see -110 we know TIMEOUT and we see -12 we know NO MEM.

i2c_imx_dma_request is using PTR_ERR to convert pointer to error value[1].
I don't know why need to use ERR_PTR to reconvert the value to pointer:

dev_err(&pdev->dev, "Failed to setup DMA (%pe), only use PIO mode\n", ERR_PTR(ret));

Is there some strong reason?

[1] https://lore.kernel.org/imx/AM0PR0402MB3937419BBB58B75FB8F8DE2DE8072@AM0PR0402MB3937.eurprd04.prod.outlook.com/
>
> --
> Pengutronix e.K.                           |
> |
> Steuerwalder Str. 21                       |
> http://www.pen/
> gutronix.de%2F&data=05%7C02%7Ccarlos.song%40nxp.com%7C594497db1b5
> 44e479a8f08dd20d1e88e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C638702808104903131%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D%3D%7C0%7C%7C%7C&sdata=EnhsIFlBooqjB%2FSRWF7uAqRHE3yN6rbdD
> 1yQueTrRus%3D&reserved=0  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |