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@xxxxxxxxx/ >>> 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. Thanks, Michal
