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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 D912AC388F7 for ; Fri, 13 Nov 2020 09:35:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 716DF22240 for ; Fri, 13 Nov 2020 09:35:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726299AbgKMJfn (ORCPT ); Fri, 13 Nov 2020 04:35:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726184AbgKMJfn (ORCPT ); Fri, 13 Nov 2020 04:35:43 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0B1DC0613D1 for ; Fri, 13 Nov 2020 01:35:42 -0800 (PST) Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdVUU-0003xq-0z; Fri, 13 Nov 2020 10:35:34 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1kdVUR-00027t-Jr; Fri, 13 Nov 2020 10:35:31 +0100 Date: Fri, 13 Nov 2020 10:35:29 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Bartosz Golaszewski Cc: Alexandre Belloni , Heiko =?utf-8?Q?St=C3=BCbner?= , Yangtao Li , Linus Walleij , LKML , linux-tegra@vger.kernel.org, Thierry Reding , linux-riscv@lists.infradead.org, Fabio Estevam , Florian Fainelli , shc_work@mail.ru, Kevin Hilman , Chen-Yu Tsai , Jonathan Hunter , linux-rockchip@lists.infradead.org, Ludovic Desroches , bcm-kernel-feedback-list@broadcom.com, dl-linux-imx , Sylvain Lemieux , linux-pwm@vger.kernel.org, Ray Jui , Sascha Hauer , Maxime Ripard , Vladimir Zapolskiy , "moderated list:ARM/Mediatek SoC..." , linux-rpi-kernel@lists.infradead.org, Paul Walmsley , Matthias Brugger , linux-amlogic@lists.infradead.org, Lee Jones , Andy Shevchenko , arm-soc , Scott Branden , Greg Kroah-Hartman , Nicolas Ferre , Palmer Dabbelt , Sascha Hauer , Shawn Guo , claudiu.beznea@microchip.com, Nicolas Saenz Julienne Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource] Message-ID: <20201113093529.xy63ncisl4wuesig@pengutronix.de> References: <20191229080610.7597-1-tiny.windzz@gmail.com> <20201112161346.gp5nenuagx5wmwl2@pengutronix.de> <20201112190649.GA908613@ulmo> <20201112211429.kfyqzkmmchjo6pll@pengutronix.de> <20201113070343.lhcsbyvi5baxn3lq@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mk2yqeuqnozfxyjy" Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-tegra@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org --mk2yqeuqnozfxyjy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote: > On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-K=F6nig > wrote: > > > > Hello, > > > > [Added lkml and the people involved in commit 7945f929f1a7 > > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the > > new readers: This is about patches making use of > > devm_platform_ioremap_resource() instead of open coding it. Full context > > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo] > > > > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-K=F6nig wrote: > > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote: > > > > I also think that it's overly narrow is scope, so you can't actually > > > > "blindly" use this helper and I've seen quite a few cases where thi= s was > > > > unknowingly used for cases where it shouldn't have been used and th= en > > > > broke things (because some drivers must not do the request_mem_regi= on() > > > > for example). > > > > > > You have a link to such an accident? > > > > I got a hint in private here: https://lore.kernel.org/r/1555670144-2422= 0-1-git-send-email-aisheng.dong@nxp.com > > > > devm_platform_ioremap_resource() is platform_get_resource() + > > devm_ioremap_resource() and here it was used to replace > > platform_get_resource() + devm_ioremap(). > > > > IMHO the unlucky thing in this situation is that devm_ioremap_resource() > > and devm_ioremap() are different by more than just how they get the area > > to remap. (i.e. devm_ioremap_resource() also does > > devm_request_mem_region().) > > > > So the problem is not the added wrapper, but unclear semantics in the > > functions it uses. In my eyes devm_ioremap() and > > devm_platform_ioremap_resource() should better be named > > devm_request_ioremap() and devm_platform_request_ioremap_resource() > > respectively. Is it worth to rename these for clearity? >=20 > But devm_ioremap() doesn't request the region. Did you mean > devm_ioremap_resource() should become devm_request_ioremap_resource()? Yes indeed. The last paragraph should be: So the problem is not the added wrapper, but unclear semantics in the functions it uses. In my eyes devm_ioremap_resource() and devm_platform_ioremap_resource() should better be named devm_request_ioremap_resource() and devm_platform_request_ioremap_resource(). (Note that I created a patch series that implements this suggestion, but you were not on Cc: as I extensively trimmed the recipents assuming most people are not interested. See https://lore.kernel.org/r/20201113085327.125= 041-1-u.kleine-koenig@pengutronix.de) Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --mk2yqeuqnozfxyjy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl+uU14ACgkQwfwUeK3K 7AlU7QgAoZhawnyVQOW4iLHTE9/NQxowSwJSANvLVm53S0/6e+o77Hwa0KM5cta2 t3wyndXM7qElPrW4Bx2J23P/m4jGyoSN4Nb/f1dH8T/pmXy7tPOqqnO+slxOTs4Y nNoFSVWSUiDCp5dgRH11sKOCp5P7hxZZ/05DhqyLYsdwUmaTzXoc28xnvmFjydxP acgIc0UGMEYWNMUOSuF+rQros8xH2r2IQZDhG58L7fD2RAMCzj+UV72056PIqrmB AVlebjEzBpYtxjhOaosAA7DY53/wHpwVTBzmFxZUXf8JlM8j8A9fVM7uwPE0xWZ+ kmF704/YfebQRL8T1P/z6v9SjuT/Vw== =fO+P -----END PGP SIGNATURE----- --mk2yqeuqnozfxyjy-- 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 6727CC56202 for ; Fri, 13 Nov 2020 09:36:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C393022244 for ; Fri, 13 Nov 2020 09:36:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zFB+fa8H" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C393022244 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=c/YkS2pDsEdJrTSObrzsF+2UqThPONXRdy+Jzx842dQ=; b=zFB+fa8HBbKZv05hPg4WmbSRk czV/zXVoQEy54OuM9nppRfj2fxtVnVOt21pdxEouefNC+a5ypOcv3W/b0pWHglA5htpAuqLAJ/Z/1 4DmB1IGDbe4zcoyMGQIK5/iHliKzMVTZY3dW7mCzCoh1DzCJeYZJTkPSas309IGsRtStwqlCUVoUS XvB1uF/vOVOuy15t9by04N/+HSfqh1mQ3OMviZhfNKcEtMkJkVV/8QQl84zF9bs1WeEfH4XPOMQQn sOeWHLqjN36ntKiSC2gmbnHNTZSp+TwdbbcpjrYq9t6f9bTA7HoI22kkx4oEcyiA82QL5qrzakpfa ECqbc/Syw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUq-0001r2-OI; Fri, 13 Nov 2020 09:35:56 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUk-0001po-SF for linux-riscv@lists.infradead.org; Fri, 13 Nov 2020 09:35:54 +0000 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdVUU-0003xq-0z; Fri, 13 Nov 2020 10:35:34 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1kdVUR-00027t-Jr; Fri, 13 Nov 2020 10:35:31 +0100 Date: Fri, 13 Nov 2020 10:35:29 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Bartosz Golaszewski Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource] Message-ID: <20201113093529.xy63ncisl4wuesig@pengutronix.de> References: <20191229080610.7597-1-tiny.windzz@gmail.com> <20201112161346.gp5nenuagx5wmwl2@pengutronix.de> <20201112190649.GA908613@ulmo> <20201112211429.kfyqzkmmchjo6pll@pengutronix.de> <20201113070343.lhcsbyvi5baxn3lq@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-riscv@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201113_043550_956297_6CE9DB7C X-CRM114-Status: GOOD ( 28.99 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre Belloni , Heiko =?utf-8?Q?St=C3=BCbner?= , Yangtao Li , Linus Walleij , Nicolas Ferre , Matthias Brugger , Thierry Reding , linux-riscv@lists.infradead.org, Fabio Estevam , Florian Fainelli , shc_work@mail.ru, Kevin Hilman , Ludovic Desroches , Jonathan Hunter , linux-rockchip@lists.infradead.org, Chen-Yu Tsai , bcm-kernel-feedback-list@broadcom.com, dl-linux-imx , Sylvain Lemieux , linux-pwm@vger.kernel.org, Ray Jui , Sascha Hauer , Maxime Ripard , Vladimir Zapolskiy , "moderated list:ARM/Mediatek SoC..." , linux-rpi-kernel@lists.infradead.org, Paul Walmsley , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, Lee Jones , Andy Shevchenko , arm-soc , Scott Branden , Greg Kroah-Hartman , LKML , Palmer Dabbelt , Sascha Hauer , Shawn Guo , claudiu.beznea@microchip.com, Nicolas Saenz Julienne Content-Type: multipart/mixed; boundary="===============0070450060988889744==" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org --===============0070450060988889744== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mk2yqeuqnozfxyjy" Content-Disposition: inline --mk2yqeuqnozfxyjy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote: > On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-K=F6nig > wrote: > > > > Hello, > > > > [Added lkml and the people involved in commit 7945f929f1a7 > > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the > > new readers: This is about patches making use of > > devm_platform_ioremap_resource() instead of open coding it. Full context > > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo] > > > > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-K=F6nig wrote: > > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote: > > > > I also think that it's overly narrow is scope, so you can't actually > > > > "blindly" use this helper and I've seen quite a few cases where thi= s was > > > > unknowingly used for cases where it shouldn't have been used and th= en > > > > broke things (because some drivers must not do the request_mem_regi= on() > > > > for example). > > > > > > You have a link to such an accident? > > > > I got a hint in private here: https://lore.kernel.org/r/1555670144-2422= 0-1-git-send-email-aisheng.dong@nxp.com > > > > devm_platform_ioremap_resource() is platform_get_resource() + > > devm_ioremap_resource() and here it was used to replace > > platform_get_resource() + devm_ioremap(). > > > > IMHO the unlucky thing in this situation is that devm_ioremap_resource() > > and devm_ioremap() are different by more than just how they get the area > > to remap. (i.e. devm_ioremap_resource() also does > > devm_request_mem_region().) > > > > So the problem is not the added wrapper, but unclear semantics in the > > functions it uses. In my eyes devm_ioremap() and > > devm_platform_ioremap_resource() should better be named > > devm_request_ioremap() and devm_platform_request_ioremap_resource() > > respectively. Is it worth to rename these for clearity? >=20 > But devm_ioremap() doesn't request the region. Did you mean > devm_ioremap_resource() should become devm_request_ioremap_resource()? Yes indeed. The last paragraph should be: So the problem is not the added wrapper, but unclear semantics in the functions it uses. In my eyes devm_ioremap_resource() and devm_platform_ioremap_resource() should better be named devm_request_ioremap_resource() and devm_platform_request_ioremap_resource(). (Note that I created a patch series that implements this suggestion, but you were not on Cc: as I extensively trimmed the recipents assuming most people are not interested. See https://lore.kernel.org/r/20201113085327.125= 041-1-u.kleine-koenig@pengutronix.de) Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --mk2yqeuqnozfxyjy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl+uU14ACgkQwfwUeK3K 7AlU7QgAoZhawnyVQOW4iLHTE9/NQxowSwJSANvLVm53S0/6e+o77Hwa0KM5cta2 t3wyndXM7qElPrW4Bx2J23P/m4jGyoSN4Nb/f1dH8T/pmXy7tPOqqnO+slxOTs4Y nNoFSVWSUiDCp5dgRH11sKOCp5P7hxZZ/05DhqyLYsdwUmaTzXoc28xnvmFjydxP acgIc0UGMEYWNMUOSuF+rQros8xH2r2IQZDhG58L7fD2RAMCzj+UV72056PIqrmB AVlebjEzBpYtxjhOaosAA7DY53/wHpwVTBzmFxZUXf8JlM8j8A9fVM7uwPE0xWZ+ kmF704/YfebQRL8T1P/z6v9SjuT/Vw== =fO+P -----END PGP SIGNATURE----- --mk2yqeuqnozfxyjy-- --===============0070450060988889744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv --===============0070450060988889744==-- 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 F213DC63697 for ; Fri, 13 Nov 2020 09:36:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 73FE92145D for ; Fri, 13 Nov 2020 09:36:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Zmf4ml/P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 73FE92145D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=mQjuXiTqIfoG0XNE8vcm67tMHL0z/28SlBHy5NBfR0w=; b=Zmf4ml/P+fVlYoIzpoMcvXEO3 zsW62UChe25GMPeoYovIMX0Na9pFi0nUCFv374wicR1W8o6MZLOX/krTaWOZbmXuJSe9xWVlKFbnE UQSy6ZlquW4WPnWU7Bb7f3o3plilEbi66wybjPQPAdTi6yBzwyQ1VB6oBOursIdk0T+cFEKTp0bXm KYAi/UXeSNOlevxCdeG91ElmO9X8hqyKJDWmV6LJcfSn+9jXPx7ggl7TXTjUcjCQOC64aVkDRAhQD qVMReXtCzBVxdJlbv3UCMdW3l7UbZ8Vm+jNu5q0Y455ZdCTNFL45dZD8yomRJWnzuFJFHOCpwLpAd LzvKKGeEg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUr-0001rG-8B; Fri, 13 Nov 2020 09:35:57 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUn-0001q9-Me for linux-rockchip@lists.infradead.org; Fri, 13 Nov 2020 09:35:54 +0000 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdVUU-0003xq-0z; Fri, 13 Nov 2020 10:35:34 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1kdVUR-00027t-Jr; Fri, 13 Nov 2020 10:35:31 +0100 Date: Fri, 13 Nov 2020 10:35:29 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Bartosz Golaszewski Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource] Message-ID: <20201113093529.xy63ncisl4wuesig@pengutronix.de> References: <20191229080610.7597-1-tiny.windzz@gmail.com> <20201112161346.gp5nenuagx5wmwl2@pengutronix.de> <20201112190649.GA908613@ulmo> <20201112211429.kfyqzkmmchjo6pll@pengutronix.de> <20201113070343.lhcsbyvi5baxn3lq@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-rockchip@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201113_043553_773667_CC11DAA8 X-CRM114-Status: GOOD ( 29.20 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre Belloni , Heiko =?utf-8?Q?St=C3=BCbner?= , Yangtao Li , Linus Walleij , Nicolas Ferre , Matthias Brugger , Thierry Reding , linux-riscv@lists.infradead.org, Fabio Estevam , Florian Fainelli , shc_work@mail.ru, Kevin Hilman , Ludovic Desroches , Jonathan Hunter , linux-rockchip@lists.infradead.org, Chen-Yu Tsai , bcm-kernel-feedback-list@broadcom.com, dl-linux-imx , Sylvain Lemieux , linux-pwm@vger.kernel.org, Ray Jui , Sascha Hauer , Maxime Ripard , Vladimir Zapolskiy , "moderated list:ARM/Mediatek SoC..." , linux-rpi-kernel@lists.infradead.org, Paul Walmsley , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, Lee Jones , Andy Shevchenko , arm-soc , Scott Branden , Greg Kroah-Hartman , LKML , Palmer Dabbelt , Sascha Hauer , Shawn Guo , claudiu.beznea@microchip.com, Nicolas Saenz Julienne Content-Type: multipart/mixed; boundary="===============2080561289941076731==" Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org --===============2080561289941076731== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mk2yqeuqnozfxyjy" Content-Disposition: inline --mk2yqeuqnozfxyjy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote: > On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-K=F6nig > wrote: > > > > Hello, > > > > [Added lkml and the people involved in commit 7945f929f1a7 > > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the > > new readers: This is about patches making use of > > devm_platform_ioremap_resource() instead of open coding it. Full context > > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo] > > > > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-K=F6nig wrote: > > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote: > > > > I also think that it's overly narrow is scope, so you can't actually > > > > "blindly" use this helper and I've seen quite a few cases where thi= s was > > > > unknowingly used for cases where it shouldn't have been used and th= en > > > > broke things (because some drivers must not do the request_mem_regi= on() > > > > for example). > > > > > > You have a link to such an accident? > > > > I got a hint in private here: https://lore.kernel.org/r/1555670144-2422= 0-1-git-send-email-aisheng.dong@nxp.com > > > > devm_platform_ioremap_resource() is platform_get_resource() + > > devm_ioremap_resource() and here it was used to replace > > platform_get_resource() + devm_ioremap(). > > > > IMHO the unlucky thing in this situation is that devm_ioremap_resource() > > and devm_ioremap() are different by more than just how they get the area > > to remap. (i.e. devm_ioremap_resource() also does > > devm_request_mem_region().) > > > > So the problem is not the added wrapper, but unclear semantics in the > > functions it uses. In my eyes devm_ioremap() and > > devm_platform_ioremap_resource() should better be named > > devm_request_ioremap() and devm_platform_request_ioremap_resource() > > respectively. Is it worth to rename these for clearity? >=20 > But devm_ioremap() doesn't request the region. Did you mean > devm_ioremap_resource() should become devm_request_ioremap_resource()? Yes indeed. The last paragraph should be: So the problem is not the added wrapper, but unclear semantics in the functions it uses. In my eyes devm_ioremap_resource() and devm_platform_ioremap_resource() should better be named devm_request_ioremap_resource() and devm_platform_request_ioremap_resource(). (Note that I created a patch series that implements this suggestion, but you were not on Cc: as I extensively trimmed the recipents assuming most people are not interested. See https://lore.kernel.org/r/20201113085327.125= 041-1-u.kleine-koenig@pengutronix.de) Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --mk2yqeuqnozfxyjy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl+uU14ACgkQwfwUeK3K 7AlU7QgAoZhawnyVQOW4iLHTE9/NQxowSwJSANvLVm53S0/6e+o77Hwa0KM5cta2 t3wyndXM7qElPrW4Bx2J23P/m4jGyoSN4Nb/f1dH8T/pmXy7tPOqqnO+slxOTs4Y nNoFSVWSUiDCp5dgRH11sKOCp5P7hxZZ/05DhqyLYsdwUmaTzXoc28xnvmFjydxP acgIc0UGMEYWNMUOSuF+rQros8xH2r2IQZDhG58L7fD2RAMCzj+UV72056PIqrmB AVlebjEzBpYtxjhOaosAA7DY53/wHpwVTBzmFxZUXf8JlM8j8A9fVM7uwPE0xWZ+ kmF704/YfebQRL8T1P/z6v9SjuT/Vw== =fO+P -----END PGP SIGNATURE----- --mk2yqeuqnozfxyjy-- --===============2080561289941076731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip --===============2080561289941076731==-- 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 EEE70C388F7 for ; Fri, 13 Nov 2020 09:36:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 458ED22244 for ; Fri, 13 Nov 2020 09:36:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DeA7ugsL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 458ED22244 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vGJw3/dLJEDEh6noGPrg6BLLHXiEOOkn0GqVa3HxdqY=; b=DeA7ugsLi84GT/SdhDLzXVPmE pWXptiCExihzz0OKPfAItLRjzGC5GejNBgzf6naS3bmJ67Qw/IIGaJs8N1bx06OYRG4zT8CsrWiLI P+GjlxT9tz4cfjoCfD1H3SiuqRV+GcNrn/wh12qScsIdiMu76vF5r9BGDaRYqYoTCOYK4CkumyLWv MDBgBm/KGp+nIIHLtCRydx4HypUjbzo7rUvbYffWH/6d/qEnoXY9ci7doc0UOPkj5r2O6En5NYx2A d748KbOrbqUrtAi3cohZXAOgt7IxeHAC8i0AMJu4OS0j+zXso8vC2TT7hp/ixsFg2RMfuecqfwMXe J9aOt0tpg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUs-0001sD-VV; Fri, 13 Nov 2020 09:35:59 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUp-0001qU-8o for linux-mediatek@lists.infradead.org; Fri, 13 Nov 2020 09:35:56 +0000 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdVUU-0003xq-0z; Fri, 13 Nov 2020 10:35:34 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1kdVUR-00027t-Jr; Fri, 13 Nov 2020 10:35:31 +0100 Date: Fri, 13 Nov 2020 10:35:29 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Bartosz Golaszewski Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource] Message-ID: <20201113093529.xy63ncisl4wuesig@pengutronix.de> References: <20191229080610.7597-1-tiny.windzz@gmail.com> <20201112161346.gp5nenuagx5wmwl2@pengutronix.de> <20201112190649.GA908613@ulmo> <20201112211429.kfyqzkmmchjo6pll@pengutronix.de> <20201113070343.lhcsbyvi5baxn3lq@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-mediatek@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201113_043555_705568_75654478 X-CRM114-Status: GOOD ( 28.99 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre Belloni , Heiko =?utf-8?Q?St=C3=BCbner?= , Yangtao Li , Linus Walleij , Nicolas Ferre , Matthias Brugger , Thierry Reding , linux-riscv@lists.infradead.org, Fabio Estevam , Florian Fainelli , shc_work@mail.ru, Kevin Hilman , Ludovic Desroches , Jonathan Hunter , linux-rockchip@lists.infradead.org, Chen-Yu Tsai , bcm-kernel-feedback-list@broadcom.com, dl-linux-imx , Sylvain Lemieux , linux-pwm@vger.kernel.org, Ray Jui , Sascha Hauer , Maxime Ripard , Vladimir Zapolskiy , "moderated list:ARM/Mediatek SoC..." , linux-rpi-kernel@lists.infradead.org, Paul Walmsley , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, Lee Jones , Andy Shevchenko , arm-soc , Scott Branden , Greg Kroah-Hartman , LKML , Palmer Dabbelt , Sascha Hauer , Shawn Guo , claudiu.beznea@microchip.com, Nicolas Saenz Julienne Content-Type: multipart/mixed; boundary="===============7865715272218914591==" Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org --===============7865715272218914591== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mk2yqeuqnozfxyjy" Content-Disposition: inline --mk2yqeuqnozfxyjy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote: > On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-K=F6nig > wrote: > > > > Hello, > > > > [Added lkml and the people involved in commit 7945f929f1a7 > > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the > > new readers: This is about patches making use of > > devm_platform_ioremap_resource() instead of open coding it. Full context > > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo] > > > > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-K=F6nig wrote: > > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote: > > > > I also think that it's overly narrow is scope, so you can't actually > > > > "blindly" use this helper and I've seen quite a few cases where thi= s was > > > > unknowingly used for cases where it shouldn't have been used and th= en > > > > broke things (because some drivers must not do the request_mem_regi= on() > > > > for example). > > > > > > You have a link to such an accident? > > > > I got a hint in private here: https://lore.kernel.org/r/1555670144-2422= 0-1-git-send-email-aisheng.dong@nxp.com > > > > devm_platform_ioremap_resource() is platform_get_resource() + > > devm_ioremap_resource() and here it was used to replace > > platform_get_resource() + devm_ioremap(). > > > > IMHO the unlucky thing in this situation is that devm_ioremap_resource() > > and devm_ioremap() are different by more than just how they get the area > > to remap. (i.e. devm_ioremap_resource() also does > > devm_request_mem_region().) > > > > So the problem is not the added wrapper, but unclear semantics in the > > functions it uses. In my eyes devm_ioremap() and > > devm_platform_ioremap_resource() should better be named > > devm_request_ioremap() and devm_platform_request_ioremap_resource() > > respectively. Is it worth to rename these for clearity? >=20 > But devm_ioremap() doesn't request the region. Did you mean > devm_ioremap_resource() should become devm_request_ioremap_resource()? Yes indeed. The last paragraph should be: So the problem is not the added wrapper, but unclear semantics in the functions it uses. In my eyes devm_ioremap_resource() and devm_platform_ioremap_resource() should better be named devm_request_ioremap_resource() and devm_platform_request_ioremap_resource(). (Note that I created a patch series that implements this suggestion, but you were not on Cc: as I extensively trimmed the recipents assuming most people are not interested. See https://lore.kernel.org/r/20201113085327.125= 041-1-u.kleine-koenig@pengutronix.de) Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --mk2yqeuqnozfxyjy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl+uU14ACgkQwfwUeK3K 7AlU7QgAoZhawnyVQOW4iLHTE9/NQxowSwJSANvLVm53S0/6e+o77Hwa0KM5cta2 t3wyndXM7qElPrW4Bx2J23P/m4jGyoSN4Nb/f1dH8T/pmXy7tPOqqnO+slxOTs4Y nNoFSVWSUiDCp5dgRH11sKOCp5P7hxZZ/05DhqyLYsdwUmaTzXoc28xnvmFjydxP acgIc0UGMEYWNMUOSuF+rQros8xH2r2IQZDhG58L7fD2RAMCzj+UV72056PIqrmB AVlebjEzBpYtxjhOaosAA7DY53/wHpwVTBzmFxZUXf8JlM8j8A9fVM7uwPE0xWZ+ kmF704/YfebQRL8T1P/z6v9SjuT/Vw== =fO+P -----END PGP SIGNATURE----- --mk2yqeuqnozfxyjy-- --===============7865715272218914591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek --===============7865715272218914591==-- 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B25C6C4742C for ; Fri, 13 Nov 2020 09:36:37 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2D30422244 for ; Fri, 13 Nov 2020 09:36:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="x0cU8VGZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D30422244 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JT+9BDnb5kfD5bjJMlwmlNTrCvja/O9l3SfIy65Q7oA=; b=x0cU8VGZCsnNDDGJ7oOPEtKfO 23f85M4d3QNOg5qQDZGOXQNUQqGItF7xUrZm28dqlgfqul/W0rxJQ+Gt8CHzwJja/sDYYmf7euHv3 8lyEw0f5yLQp39O1u5RqkVshj21S9jo5jIrmPjtiABDMN5j2yJwivyFdBwh4chhWT3UtNo91R1uUJ 1Q+E30/sZWRjqeSP0q32fqkPW1I3b1DimuiSXjHrpMcOkvTVB9e3js0jSTAljURTfBDwHUtnkPS5a 289CyaxU3D/I0Ld8JWAMDTN6rQb/miv39z/8ewuthkRS5uhZrQ0qTa2beUTKXR2C6S3JyatD2ke0j wdMMcO9Yw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUw-0001tI-Hq; Fri, 13 Nov 2020 09:36:02 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUs-0001rR-49 for linux-arm-kernel@lists.infradead.org; Fri, 13 Nov 2020 09:35:59 +0000 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdVUU-0003xq-0z; Fri, 13 Nov 2020 10:35:34 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1kdVUR-00027t-Jr; Fri, 13 Nov 2020 10:35:31 +0100 Date: Fri, 13 Nov 2020 10:35:29 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Bartosz Golaszewski Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource] Message-ID: <20201113093529.xy63ncisl4wuesig@pengutronix.de> References: <20191229080610.7597-1-tiny.windzz@gmail.com> <20201112161346.gp5nenuagx5wmwl2@pengutronix.de> <20201112190649.GA908613@ulmo> <20201112211429.kfyqzkmmchjo6pll@pengutronix.de> <20201113070343.lhcsbyvi5baxn3lq@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201113_043558_220714_1E47494E X-CRM114-Status: GOOD ( 30.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre Belloni , Heiko =?utf-8?Q?St=C3=BCbner?= , Yangtao Li , Linus Walleij , Matthias Brugger , Thierry Reding , linux-riscv@lists.infradead.org, Fabio Estevam , Florian Fainelli , shc_work@mail.ru, Kevin Hilman , Ludovic Desroches , Jonathan Hunter , linux-rockchip@lists.infradead.org, Chen-Yu Tsai , bcm-kernel-feedback-list@broadcom.com, dl-linux-imx , Sylvain Lemieux , linux-pwm@vger.kernel.org, Ray Jui , Sascha Hauer , Maxime Ripard , Vladimir Zapolskiy , "moderated list:ARM/Mediatek SoC..." , linux-rpi-kernel@lists.infradead.org, Paul Walmsley , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, Lee Jones , Andy Shevchenko , arm-soc , Scott Branden , Greg Kroah-Hartman , LKML , Palmer Dabbelt , Sascha Hauer , Shawn Guo , claudiu.beznea@microchip.com, Nicolas Saenz Julienne Content-Type: multipart/mixed; boundary="===============5904846919053858543==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============5904846919053858543== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mk2yqeuqnozfxyjy" Content-Disposition: inline --mk2yqeuqnozfxyjy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote: > On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-K=F6nig > wrote: > > > > Hello, > > > > [Added lkml and the people involved in commit 7945f929f1a7 > > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the > > new readers: This is about patches making use of > > devm_platform_ioremap_resource() instead of open coding it. Full context > > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo] > > > > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-K=F6nig wrote: > > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote: > > > > I also think that it's overly narrow is scope, so you can't actually > > > > "blindly" use this helper and I've seen quite a few cases where thi= s was > > > > unknowingly used for cases where it shouldn't have been used and th= en > > > > broke things (because some drivers must not do the request_mem_regi= on() > > > > for example). > > > > > > You have a link to such an accident? > > > > I got a hint in private here: https://lore.kernel.org/r/1555670144-2422= 0-1-git-send-email-aisheng.dong@nxp.com > > > > devm_platform_ioremap_resource() is platform_get_resource() + > > devm_ioremap_resource() and here it was used to replace > > platform_get_resource() + devm_ioremap(). > > > > IMHO the unlucky thing in this situation is that devm_ioremap_resource() > > and devm_ioremap() are different by more than just how they get the area > > to remap. (i.e. devm_ioremap_resource() also does > > devm_request_mem_region().) > > > > So the problem is not the added wrapper, but unclear semantics in the > > functions it uses. In my eyes devm_ioremap() and > > devm_platform_ioremap_resource() should better be named > > devm_request_ioremap() and devm_platform_request_ioremap_resource() > > respectively. Is it worth to rename these for clearity? >=20 > But devm_ioremap() doesn't request the region. Did you mean > devm_ioremap_resource() should become devm_request_ioremap_resource()? Yes indeed. The last paragraph should be: So the problem is not the added wrapper, but unclear semantics in the functions it uses. In my eyes devm_ioremap_resource() and devm_platform_ioremap_resource() should better be named devm_request_ioremap_resource() and devm_platform_request_ioremap_resource(). (Note that I created a patch series that implements this suggestion, but you were not on Cc: as I extensively trimmed the recipents assuming most people are not interested. See https://lore.kernel.org/r/20201113085327.125= 041-1-u.kleine-koenig@pengutronix.de) Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --mk2yqeuqnozfxyjy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl+uU14ACgkQwfwUeK3K 7AlU7QgAoZhawnyVQOW4iLHTE9/NQxowSwJSANvLVm53S0/6e+o77Hwa0KM5cta2 t3wyndXM7qElPrW4Bx2J23P/m4jGyoSN4Nb/f1dH8T/pmXy7tPOqqnO+slxOTs4Y nNoFSVWSUiDCp5dgRH11sKOCp5P7hxZZ/05DhqyLYsdwUmaTzXoc28xnvmFjydxP acgIc0UGMEYWNMUOSuF+rQros8xH2r2IQZDhG58L7fD2RAMCzj+UV72056PIqrmB AVlebjEzBpYtxjhOaosAA7DY53/wHpwVTBzmFxZUXf8JlM8j8A9fVM7uwPE0xWZ+ kmF704/YfebQRL8T1P/z6v9SjuT/Vw== =fO+P -----END PGP SIGNATURE----- --mk2yqeuqnozfxyjy-- --===============5904846919053858543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============5904846919053858543==-- 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 3D2EDC388F7 for ; Fri, 13 Nov 2020 09:36:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B6B5E22240 for ; Fri, 13 Nov 2020 09:36:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mOqPTHKP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6B5E22240 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bLirJQ5mnPFsATiiefm0ibV+bd+otr6ucfr4JlK+RAI=; b=mOqPTHKPmQ370tfAXWnUXM7Yt y8wfz579sYTDF1qQi9ZkYp/paQDC7SCczXOPaduLedsBWBGtJLi8M4thUdubrrDTfARNSYUID/O1R x7S9w/6LVSimISdPFIBJ/l8Vu0zDsQ96UaQuuBqDJ2L+dU94qYvJPRSTvEMyLfEOfK1TTHc9lMrFn 1UPOqom9iGebc7hNwFLIGrOa10WoQaxErJutzjW1/5tBT+8vsikilOnOBi3oyCI+Y/xWZdR1YeSv9 YakiMdUuQPtxQlURjuekf1duqapUs+NK9JXv5cguyVEqxwDkhKtqgIEcHw6kC43/cgHkuTI5gdQgI O4gBYwWjQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUv-0001st-7Q; Fri, 13 Nov 2020 09:36:01 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdVUr-0001rO-Ta for linux-amlogic@lists.infradead.org; Fri, 13 Nov 2020 09:35:59 +0000 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdVUU-0003xq-0z; Fri, 13 Nov 2020 10:35:34 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1kdVUR-00027t-Jr; Fri, 13 Nov 2020 10:35:31 +0100 Date: Fri, 13 Nov 2020 10:35:29 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Bartosz Golaszewski Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource] Message-ID: <20201113093529.xy63ncisl4wuesig@pengutronix.de> References: <20191229080610.7597-1-tiny.windzz@gmail.com> <20201112161346.gp5nenuagx5wmwl2@pengutronix.de> <20201112190649.GA908613@ulmo> <20201112211429.kfyqzkmmchjo6pll@pengutronix.de> <20201113070343.lhcsbyvi5baxn3lq@pengutronix.de> MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-amlogic@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201113_043557_988512_7CE697C5 X-CRM114-Status: GOOD ( 28.88 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre Belloni , Heiko =?utf-8?Q?St=C3=BCbner?= , Yangtao Li , Linus Walleij , Nicolas Ferre , Matthias Brugger , Thierry Reding , linux-riscv@lists.infradead.org, Fabio Estevam , Florian Fainelli , shc_work@mail.ru, Kevin Hilman , Ludovic Desroches , Jonathan Hunter , linux-rockchip@lists.infradead.org, Chen-Yu Tsai , bcm-kernel-feedback-list@broadcom.com, dl-linux-imx , Sylvain Lemieux , linux-pwm@vger.kernel.org, Ray Jui , Sascha Hauer , Maxime Ripard , Vladimir Zapolskiy , "moderated list:ARM/Mediatek SoC..." , linux-rpi-kernel@lists.infradead.org, Paul Walmsley , linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, Lee Jones , Andy Shevchenko , arm-soc , Scott Branden , Greg Kroah-Hartman , LKML , Palmer Dabbelt , Sascha Hauer , Shawn Guo , claudiu.beznea@microchip.com, Nicolas Saenz Julienne Content-Type: multipart/mixed; boundary="===============4245241255139373424==" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org --===============4245241255139373424== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mk2yqeuqnozfxyjy" Content-Disposition: inline --mk2yqeuqnozfxyjy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote: > On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-K=F6nig > wrote: > > > > Hello, > > > > [Added lkml and the people involved in commit 7945f929f1a7 > > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the > > new readers: This is about patches making use of > > devm_platform_ioremap_resource() instead of open coding it. Full context > > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo] > > > > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-K=F6nig wrote: > > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote: > > > > I also think that it's overly narrow is scope, so you can't actually > > > > "blindly" use this helper and I've seen quite a few cases where thi= s was > > > > unknowingly used for cases where it shouldn't have been used and th= en > > > > broke things (because some drivers must not do the request_mem_regi= on() > > > > for example). > > > > > > You have a link to such an accident? > > > > I got a hint in private here: https://lore.kernel.org/r/1555670144-2422= 0-1-git-send-email-aisheng.dong@nxp.com > > > > devm_platform_ioremap_resource() is platform_get_resource() + > > devm_ioremap_resource() and here it was used to replace > > platform_get_resource() + devm_ioremap(). > > > > IMHO the unlucky thing in this situation is that devm_ioremap_resource() > > and devm_ioremap() are different by more than just how they get the area > > to remap. (i.e. devm_ioremap_resource() also does > > devm_request_mem_region().) > > > > So the problem is not the added wrapper, but unclear semantics in the > > functions it uses. In my eyes devm_ioremap() and > > devm_platform_ioremap_resource() should better be named > > devm_request_ioremap() and devm_platform_request_ioremap_resource() > > respectively. Is it worth to rename these for clearity? >=20 > But devm_ioremap() doesn't request the region. Did you mean > devm_ioremap_resource() should become devm_request_ioremap_resource()? Yes indeed. The last paragraph should be: So the problem is not the added wrapper, but unclear semantics in the functions it uses. In my eyes devm_ioremap_resource() and devm_platform_ioremap_resource() should better be named devm_request_ioremap_resource() and devm_platform_request_ioremap_resource(). (Note that I created a patch series that implements this suggestion, but you were not on Cc: as I extensively trimmed the recipents assuming most people are not interested. See https://lore.kernel.org/r/20201113085327.125= 041-1-u.kleine-koenig@pengutronix.de) Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --mk2yqeuqnozfxyjy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl+uU14ACgkQwfwUeK3K 7AlU7QgAoZhawnyVQOW4iLHTE9/NQxowSwJSANvLVm53S0/6e+o77Hwa0KM5cta2 t3wyndXM7qElPrW4Bx2J23P/m4jGyoSN4Nb/f1dH8T/pmXy7tPOqqnO+slxOTs4Y nNoFSVWSUiDCp5dgRH11sKOCp5P7hxZZ/05DhqyLYsdwUmaTzXoc28xnvmFjydxP acgIc0UGMEYWNMUOSuF+rQros8xH2r2IQZDhG58L7fD2RAMCzj+UV72056PIqrmB AVlebjEzBpYtxjhOaosAA7DY53/wHpwVTBzmFxZUXf8JlM8j8A9fVM7uwPE0xWZ+ kmF704/YfebQRL8T1P/z6v9SjuT/Vw== =fO+P -----END PGP SIGNATURE----- --mk2yqeuqnozfxyjy-- --===============4245241255139373424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic --===============4245241255139373424==--