From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76EDDECE58E for ; Thu, 17 Oct 2019 13:09:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55ED921835 for ; Thu, 17 Oct 2019 13:09:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394262AbfJQNJI (ORCPT ); Thu, 17 Oct 2019 09:09:08 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:60963 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726898AbfJQNJI (ORCPT ); Thu, 17 Oct 2019 09:09:08 -0400 Received: from localhost (aclermont-ferrand-651-1-259-53.w86-207.abo.wanadoo.fr [86.207.98.53]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 8A42E100018; Thu, 17 Oct 2019 13:09:02 +0000 (UTC) Date: Thu, 17 Oct 2019 15:09:02 +0200 From: Alexandre Belloni To: YueHaibing Cc: linus.walleij@linaro.org, manivannan.sadhasivam@linaro.org, afaerber@suse.de, f.fainelli@gmail.com, rjui@broadcom.com, sbranden@broadcom.com, bcm-kernel-feedback-list@broadcom.com, jesper.nilsson@axis.com, lars.persson@axis.com, ludovic.desroches@microchip.com, nicolas.ferre@microchip.com, baruch@tkos.co.il, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@axis.com, linux-oxnas@groups.io, linux-renesas-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org, vz@mleia.com, narmstrong@baylibre.com, geert+renesas@glider.be, daniel@zonque.org, haojian.zhuang@gmail.com, wens@csie.org, thierry.reding@gmail.com, jonathanh@nvidia.com, agross@kernel.org Subject: Re: [PATCH -next 00/30] pinctrl: use devm_platform_ioremap_resource() to simplify code Message-ID: <20191017130902.GE3125@piout.net> References: <20191017122640.22976-1-yuehaibing@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191017122640.22976-1-yuehaibing@huawei.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Hi, On 17/10/2019 20:26:10+0800, YueHaibing wrote: > devm_platform_ioremap_resource() internally have platform_get_resource() > and devm_ioremap_resource() in it. So instead of calling them separately > use devm_platform_ioremap_resource() directly. > Shouldn't we stop with this insanity? The net gain is exactly 2 lines per driver and this puts the full review load on the maintainers. We end up with crap like: https://lore.kernel.org/lkml/9bbcce19c777583815c92ce3c2ff2586@www.loen.fr/ What is the end goal here ? platform_get_resource and devm_ioremap_resource will have to stay even after you have done the conversion. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com