Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752678AbcD1KOm (ORCPT ); Thu, 28 Apr 2016 06:14:42 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:11120 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbcD1KOk (ORCPT ); Thu, 28 Apr 2016 06:14:40 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Thu, 28 Apr 2016 03:14:15 -0700 Message-ID: <5721DFC2.4070301@nvidia.com> Date: Thu, 28 Apr 2016 15:32:42 +0530 From: Laxman Dewangan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lee Jones , Krzysztof Kozlowski CC: , , , , , , Subject: Re: [PATCH 3/7] mfd: max77686: Use devm_mfd_add_devices and devm_regmap_add_irq_chip References: <1461241558-26983-1-git-send-email-ldewangan@nvidia.com> <1461241558-26983-4-git-send-email-ldewangan@nvidia.com> <571DF7FD.8020209@samsung.com> <20160428090102.GM4892@dell> In-Reply-To: <20160428090102.GM4892@dell> X-Originating-IP: [10.19.65.30] X-ClientProxiedBy: DRHKMAIL102.nvidia.com (10.25.59.16) To bgmail102.nvidia.com (10.25.59.11) Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1750 Lines: 37 On Thursday 28 April 2016 02:31 PM, Lee Jones wrote: > On Mon, 25 Apr 2016, Krzysztof Kozlowski wrote: > >> On 04/21/2016 02:25 PM, Laxman Dewangan wrote: >>> Use devm_mfd_add_devices() for adding MFD child devices and >>> devm_regmap_add_irq_chip() for IRQ chip registration. >>> >>> This reduces the error code path and .remove callback for removing >>> MFD child devices and deleting IRQ chip data. >>> >>> Signed-off-by: Laxman Dewangan >>> CC: Chanwoo Choi >>> CC: Krzysztof Kozlowski >>> --- >>> drivers/mfd/max77686.c | 31 ++++++++----------------------- >>> 1 file changed, 8 insertions(+), 23 deletions(-) >> Switching existing code to devm-like interface doesn't bring huge >> benefits but looks okay and I'm fine with it: > This is pretty much my view, but it get's Laxman's patch count up. ;) Yaah. :-) There is some other motivation of doing this: * I got the review comment about the resource leak and sequencing in my max77620. It was silly mistake done by me and it causes recycle of patch. To avoid this in future, devm_ was better option. * Spent lots of time on unbinding test during my RTC patch. Although fix was not related to the devm_ but gave the impression that something we are doing on probe. devm_ looks straight forward. - Some of code quality tools suggest to avoid goto statement. Only possible if we dont have any code in error path i.e. return from any place. - If we have devm_ apis for few resource and some does not support then difficult to use them as this affect the sequence of deallocation. Existing devm_ can be used effectively only if we have all resource allocation using devm_. - Reducing code size always better.