Re: [PATCH v2 0/2] drivers: provide devm_platform_request_irq()

From: Grygorii Strashko
Date: Tue May 26 2020 - 13:13:58 EST

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:
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.


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,