linux-kernel - Re: [PATCH v2 0/2] drivers: provide devm_platform_request

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: <52fdb5f6-2108-4857-8d0f-3f17ee863781@ti.com>
Date:   Tue, 26 May 2020 20:13:25 +0300
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Michal Simek <michal.simek@...inx.com>,
        Dejin Zheng <zhengdejin5@...il.com>,
        Wolfram Sang <wsa@...nel.org>
CC:     <gregkh@...uxfoundation.org>, <rafael@...nel.org>,
        <f.fainelli@...il.com>, <rjui@...adcom.com>,
        <sbranden@...adcom.com>, <baruch@...s.co.il>,
        <paul@...pouillou.net>, <khilman@...libre.com>,
        <shawnguo@...nel.org>, <festevam@...il.com>, <vz@...ia.com>,
        <heiko@...ech.de>, <linus.walleij@...aro.org>, <baohua@...nel.org>,
        <ardb@...nel.org>, <linux-i2c@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/2] drivers: provide devm_platform_request_irq()



On 25/05/2020 10:05, Michal Simek wrote:
> On 23. 05. 20 19:09, Dejin Zheng wrote:
>> On Sat, May 23, 2020 at 06:08:29PM +0200, Wolfram Sang wrote:
>>> On Sat, May 23, 2020 at 10:51:55PM +0800, Dejin Zheng wrote:
>>>> It will call devm_request_irq() after platform_get_irq() function
>>>> in many drivers, sometimes, it is not right for the error handling
>>>> of these two functions in some drivers. so provide this function
>>>> to simplify the driver.
>>>>
>>>> the first patch will provide devm_platform_request_irq(), and the
>>>> other patch will convert to devm_platform_request_irq() in some
>>>> i2c bus dirver.
>>>>
>>>> v1 -> v2:
>>>> 	- I give up this series of patches in v1 version. I resend this
>>>> 	  patches v2 by that discussion:
>>>> 	  https://patchwork.ozlabs.org/project/linux-i2c/patch/20200520144821.8069-1-zhengdejin5@gmail.com/
>>>> 	  The patch content has not changed.
>>>
>>> I don't understand. v1 has been nacked because of technical reasons. How
>>> did the discussion above change the situation? Am I missing something?
>>>
>> No, you are not missing something. Maybe I did not explain clearly.
>>
>> The v1 has been nacked because Grygorii told me that the
>> function platform_get_irq() should be done as early as possible to avoid
>> unnecessary initialization steps, and the function devm_request_irq()
>> should be done late in probe when driver and HW are actually ready to
>> handle IRQs. It can do the other things between the two funtions. I agree
>> with him that it may be necessary in some complex drives. So abandon the
>> patch v1.
>>
>> Base on the discussion of you and Michal, I think maybe this patch is also
>> needed for the simple driver or the driver of already use it like that:
>> 	
>> 	irq = platform_get_irq(pdev, 0);
>> 	if (irq < 0)
>> 		return irq;
>> 	ret = devm_request_irq()
>>
>> It provides a common error handling and reduce one function call for each
>> drivers, more easier to use and simplify code. So resend it.
>>
>> BR,
>> Dejin
>>
>>>>
>>>> Dejin Zheng (2):
>>>>    drivers: provide devm_platform_request_irq()
>>>>    i2c: busses: convert to devm_platform_request_irq()
>>>>
>>>>   drivers/base/platform.c            | 33 ++++++++++++++++++++++++++++++
>>>>   drivers/i2c/busses/i2c-bcm-kona.c  | 16 +++------------
>>>>   drivers/i2c/busses/i2c-cadence.c   | 10 +++------
>>>>   drivers/i2c/busses/i2c-digicolor.c | 10 +++------
>>>>   drivers/i2c/busses/i2c-emev2.c     |  5 ++---
>>>>   drivers/i2c/busses/i2c-jz4780.c    |  5 ++---
>>>>   drivers/i2c/busses/i2c-meson.c     | 13 ++++--------
>>>>   drivers/i2c/busses/i2c-mxs.c       |  9 +++-----
>>>>   drivers/i2c/busses/i2c-pnx.c       |  9 ++------
>>>>   drivers/i2c/busses/i2c-rcar.c      |  9 +++-----
>>>>   drivers/i2c/busses/i2c-rk3x.c      | 14 +++----------
>>>>   drivers/i2c/busses/i2c-sirf.c      | 10 ++-------
>>>>   drivers/i2c/busses/i2c-stu300.c    |  4 ++--
>>>>   drivers/i2c/busses/i2c-synquacer.c | 12 +++--------
>>>>   include/linux/platform_device.h    |  4 ++++
>>>>   15 files changed, 72 insertions(+), 91 deletions(-)
> 
> If you look at all driver except for cadence one it doesn't do any
> change and I can't see any issue with it because sequences are the same
> as were before.
> 
> Regarding Cadence and Grygorii's comments:
> We are not checking that id->irq is valid that's why even if that fails
> driver continues to work. Which means that this change doesn't increase
> boot time or change code flow.
> On Xilinx devices cadence i2c is connected to ARM GIC which is
> initialized very early and IRC controller should be up and running all
> the time.
> That's why I can't see any issue which this change on Cadence driver too.


My main point was to pay attention on changes, which may be risky
especially when they are part of bulk changes (such optimization tend to spread
fast and all over the kernel without proper review).

Sry, if i introduced some misunderstanding, but it seems worked and this patch has got more attention.
There are no objection from my side to use devm_platform_get_and_ioremap_resource() if driver
owners find it acceptable.

-- 
Best regards,
grygorii