Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
 149.199.60.83 as permitted sender) receiver=protection.outlook.com;
 client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01;
Subject: Re: [PATCH v2 0/2] drivers: provide devm_platform_request_irq()
To:     Dejin Zheng <zhengdejin5@gmail.com>, Wolfram Sang <wsa@kernel.org>
Cc:     gregkh@linuxfoundation.org, rafael@kernel.org,
        f.fainelli@gmail.com, rjui@broadcom.com, sbranden@broadcom.com,
        michal.simek@xilinx.com, baruch@tkos.co.il, paul@crapouillou.net,
        khilman@baylibre.com, shawnguo@kernel.org, festevam@gmail.com,
        vz@mleia.com, heiko@sntech.de, linus.walleij@linaro.org,
        baohua@kernel.org, ardb@kernel.org, linux-i2c@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20200523145157.16257-1-zhengdejin5@gmail.com>
 <20200523160828.GE3459@ninjato> <20200523170933.GA16771@nuc8i5>
From:   Michal Simek <michal.simek@xilinx.com>
Message-ID: <ad90d9b5-5906-fef3-85b8-00c7eff70e61@xilinx.com>
Date:   Mon, 25 May 2020 09:05:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200523170933.GA16771@nuc8i5>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2020 07:06:00.7313
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7407a3b9-ecc3-4013-cbc5-08d8007a14c7
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.83];Helo=[xsj-pvapsmtpgw01]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR02MB6643
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Thanks,
Michal