From: Robin Murphy <robin.murphy@arm.com>
To: "Thierry Reding" <thierry.reding@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: alexandre.belloni@bootlin.com, heiko@sntech.de,
Yangtao Li <tiny.windzz@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
nicolas.ferre@microchip.com, matthias.bgg@gmail.com,
linux-riscv@lists.infradead.org, festevam@gmail.com,
f.fainelli@gmail.com, shc_work@mail.ru,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
khilman@baylibre.com, ludovic.desroches@microchip.com,
jonathanh@nvidia.com, linux-rockchip@lists.infradead.org,
wens@csie.org, bcm-kernel-feedback-list@broadcom.com,
linux-imx@nxp.com, slemieux.tyco@gmail.com,
linux-pwm@vger.kernel.org, rjui@broadcom.com,
s.hauer@pengutronix.de, mripard@kernel.org, vz@mleia.com,
linux-mediatek@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org, paul.walmsley@sifive.com,
linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org,
Lee Jones <lee.jones@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-arm-kernel@lists.infradead.org, sbranden@broadcom.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, palmer@dabbelt.com,
kernel@pengutronix.de, shawnguo@kernel.org,
claudiu.beznea@microchip.com, nsaenzjulienne@suse.de
Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource]
Date: Fri, 13 Nov 2020 17:40:41 +0000 [thread overview]
Message-ID: <6cddd32c-50eb-4399-02bc-d4377237134c@arm.com> (raw)
In-Reply-To: <20201113161153.GB1408970@ulmo>
On 2020-11-13 16:11, Thierry Reding wrote:
> On Fri, Nov 13, 2020 at 08:03:43AM +0100, Uwe Kleine-König 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önig 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 this was
>>>> unknowingly used for cases where it shouldn't have been used and then
>>>> broke things (because some drivers must not do the request_mem_region()
>>>> for example).
>>>
>>> You have a link to such an accident?
>>
>> I got a hint in private here: https://lore.kernel.org/r/1555670144-24220-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.
>
> The semantics aren't unclear. It's just that the symbol name doesn't
> spell out every detail that the function implements, which, frankly, no
> function name ever does, at least not for anything beyond simple
> instructional examples. That's what we have documentation for and why
> people should read the documentation before they use a function and make
> (potentially wrong) assumption about what it does.
>
>> 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?
>
> I think function names are always a compromise between giving you the
> gist of what the implementation does and being short enough so it
> doesn't become difficult to read or use.
>
> One of the reasons why I dislike the addition of helpers for every
> common special case (like devm_platform_ioremap_resource()) is because
> it doesn't (always) actually make things easier for developers and/or
> maintainers. Replacing three lines of code with one is a minor
> improvement, even though there may be many callsites and therefore in
> the sum this being a fairly sizeable reduction. The flip side is that
> now we've got an extra symbol with an unwieldy name that people need
> to become familiar with, and then, like the link above shows, it doesn't
> work in all cases, so you either need to fall back to the open-coded
> version or you keep adding helpers until you've covered all cases. And
> then we end up with a bunch of helpers that you actually have to go and
> read the documentation for in order to find out which one exactly fits
> your use-case.
>
> Without the helpers it's pretty simple to write, even if a little
> repetitive:
>
> 1) get the resource you want to map
> 2) request the resource
> 3) map the resource
>
> 2) & 3) are very commonly done together, so it makes sense to have a
> generic helper for them. If you look at the implementation, the
> devm_ioremap_request() implementation does quite a bit of things in
> addition to just requesting and remapping, and that's the reason why
> that helper makes sense.
>
> For me personally, devm_platform_ioremap_resource() is just not adding
> enough value to justify its existence. And then we get all these other
> variants that operate on the resource name (_byname) and those which
> remap write-combined (_wc). But don't we also need a _byname_wc()
> variant for the combination? Where does it stop?
Arguably the worst thing about devm_platform_ioremap_resource() is that
it was apparently the gateway drug to a belief that
devm_platform_get_and_ioremap_resource() is anything other than a
hideous way to obfuscate an assignment...
Robin.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2020-11-13 17:41 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191229080610.7597-1-tiny.windzz@gmail.com>
2019-12-29 8:05 ` [PATCH 02/32] pwm: fsl-ftm: convert to devm_platform_ioremap_resource Yangtao Li
2019-12-29 8:05 ` [PATCH 03/32] pwm: rcar: " Yangtao Li
2019-12-29 8:05 ` [PATCH 04/32] pwm: renesas-tpu: " Yangtao Li
2019-12-29 8:05 ` [PATCH 05/32] pwm: ep93xx: " Yangtao Li
[not found] ` <20191229080610.7597-1-tiny.windzz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-12-29 8:05 ` [PATCH 02/32] pwm: fsl-ftm: " Yangtao Li
2019-12-29 8:05 ` [PATCH 03/32] pwm: rcar: " Yangtao Li
2019-12-29 8:05 ` [PATCH 04/32] pwm: renesas-tpu: " Yangtao Li
2019-12-29 8:05 ` [PATCH 05/32] pwm: ep93xx: " Yangtao Li
2019-12-29 8:05 ` [PATCH 06/32] pwm: tegra: " Yangtao Li
2019-12-29 8:05 ` [PATCH 07/32] pwm: mediatek: " Yangtao Li
2019-12-29 8:05 ` [PATCH 08/32] pwm: sti: " Yangtao Li
2019-12-29 8:05 ` [PATCH 09/32] pwm: pxa: " Yangtao Li
2019-12-29 8:05 ` [PATCH 10/32] pwm: zx: " Yangtao Li
2019-12-29 8:05 ` [PATCH 11/32] pwm: spear: " Yangtao Li
2019-12-29 8:05 ` [PATCH 12/32] pwm: bcm-kona: " Yangtao Li
2019-12-29 8:05 ` [PATCH 13/32] pwm: lpc32xx: " Yangtao Li
2019-12-29 8:05 ` [PATCH 14/32] pwm: meson: " Yangtao Li
2019-12-29 8:05 ` [PATCH 15/32] pwm: rockchip: " Yangtao Li
2019-12-29 8:05 ` [PATCH 16/32] pwm: bcm-iproc: " Yangtao Li
2019-12-29 8:05 ` [PATCH 17/32] pwm: samsung: " Yangtao Li
2019-12-29 8:05 ` [PATCH 18/32] pwm: tiehrpwm: " Yangtao Li
2019-12-29 8:05 ` [PATCH 19/32] pwm: puv3: " Yangtao Li
2019-12-29 8:05 ` [PATCH 20/32] pwm: imx: " Yangtao Li
2019-12-29 8:05 ` [PATCH 21/32] pwm: tiecap: " Yangtao Li
2019-12-29 8:06 ` [PATCH 22/32] pwm: bcm2835: " Yangtao Li
2019-12-29 8:06 ` [PATCH 23/32] pwm: berlin: " Yangtao Li
2019-12-29 8:06 ` [PATCH 24/32] pwm: vt8500: " Yangtao Li
2019-12-29 8:06 ` [PATCH 25/32] pwm: brcmstb: " Yangtao Li
2019-12-29 8:06 ` [PATCH 26/32] pwm: mtk-disp: " Yangtao Li
2019-12-29 8:06 ` [PATCH 27/32] pwm: clps711x: " Yangtao Li
2019-12-29 8:06 ` [PATCH 28/32] pwm: img: " Yangtao Li
2019-12-29 8:06 ` [PATCH 29/32] pwm: lpc18xx-sct: " Yangtao Li
2019-12-29 8:06 ` [PATCH 30/32] pwm: hibvt: do some cleanup Yangtao Li
2019-12-29 8:06 ` [PATCH 31/32] pwm: sifive: convert to devm_platform_ioremap_resource Yangtao Li
2019-12-29 8:06 ` [PATCH 32/32] pwm: atmel: " Yangtao Li
2019-12-29 8:05 ` [PATCH 06/32] pwm: tegra: " Yangtao Li
2019-12-29 8:05 ` [PATCH 07/32] pwm: mediatek: " Yangtao Li
2019-12-29 8:05 ` [PATCH 08/32] pwm: sti: " Yangtao Li
2019-12-29 8:05 ` [PATCH 09/32] pwm: pxa: " Yangtao Li
2019-12-29 8:05 ` [PATCH 10/32] pwm: zx: " Yangtao Li
2019-12-29 8:05 ` [PATCH 11/32] pwm: spear: " Yangtao Li
2019-12-29 8:05 ` [PATCH 12/32] pwm: bcm-kona: " Yangtao Li
2019-12-29 8:05 ` [PATCH 13/32] pwm: lpc32xx: " Yangtao Li
2019-12-29 8:05 ` [PATCH 14/32] pwm: meson: " Yangtao Li
2019-12-29 8:05 ` [PATCH 15/32] pwm: rockchip: " Yangtao Li
2019-12-29 8:05 ` [PATCH 16/32] pwm: bcm-iproc: " Yangtao Li
2019-12-29 8:05 ` [PATCH 17/32] pwm: samsung: " Yangtao Li
2019-12-29 8:05 ` [PATCH 18/32] pwm: tiehrpwm: " Yangtao Li
2019-12-29 8:05 ` [PATCH 19/32] pwm: puv3: " Yangtao Li
2019-12-29 8:05 ` [PATCH 20/32] pwm: imx: " Yangtao Li
2019-12-29 8:05 ` [PATCH 21/32] pwm: tiecap: " Yangtao Li
2019-12-29 8:06 ` [PATCH 22/32] pwm: bcm2835: " Yangtao Li
2019-12-29 8:06 ` [PATCH 23/32] pwm: berlin: " Yangtao Li
2019-12-29 8:06 ` [PATCH 24/32] pwm: vt8500: " Yangtao Li
2019-12-29 8:06 ` [PATCH 25/32] pwm: brcmstb: " Yangtao Li
2019-12-29 8:06 ` [PATCH 26/32] pwm: mtk-disp: " Yangtao Li
2019-12-29 8:06 ` [PATCH 27/32] pwm: clps711x: " Yangtao Li
2019-12-29 8:06 ` [PATCH 28/32] pwm: img: " Yangtao Li
2019-12-29 8:06 ` [PATCH 29/32] pwm: lpc18xx-sct: " Yangtao Li
2019-12-29 8:06 ` [PATCH 30/32] pwm: hibvt: do some cleanup Yangtao Li
2019-12-29 8:06 ` [PATCH 31/32] pwm: sifive: convert to devm_platform_ioremap_resource Yangtao Li
2019-12-29 8:06 ` [PATCH 32/32] pwm: atmel: " Yangtao Li
[not found] ` <20191229080610.7597-15-tiny.windzz@gmail.com>
2019-12-30 8:39 ` [PATCH 15/32] pwm: rockchip: " Heiko Stuebner
2020-05-23 17:25 ` Uwe Kleine-König
[not found] ` <20191229080610.7597-14-tiny.windzz@gmail.com>
2019-12-31 14:53 ` [PATCH 14/32] pwm: meson: " Martin Blumenstingl
2020-05-23 17:25 ` Uwe Kleine-König
[not found] ` <20191229080610.7597-32-tiny.windzz@gmail.com>
2020-01-06 10:32 ` [PATCH 32/32] pwm: atmel: " Claudiu.Beznea
[not found] ` <20191229080610.7597-32-tiny.windzz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-01-06 10:32 ` Claudiu.Beznea-UWL1GkI3JZL3oGB3hsPCZA
2020-01-06 10:32 ` Claudiu.Beznea-UWL1GkI3JZL3oGB3hsPCZA
2020-05-23 17:25 ` Uwe Kleine-König
[not found] ` <20191229080610.7597-25-tiny.windzz@gmail.com>
[not found] ` <20191229080610.7597-25-tiny.windzz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-01-07 10:54 ` [PATCH 25/32] pwm: brcmstb: " Nicolas Saenz Julienne
2020-05-23 17:25 ` Uwe Kleine-König
2020-01-07 10:54 ` Nicolas Saenz Julienne
[not found] ` <20191229080610.7597-30-tiny.windzz@gmail.com>
2020-02-20 20:41 ` [PATCH 30/32] pwm: hibvt: do some cleanup Uwe Kleine-König
2020-05-23 17:44 ` Uwe Kleine-König
[not found] ` <20191229080610.7597-26-tiny.windzz@gmail.com>
[not found] ` <20191229080610.7597-26-tiny.windzz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-02-20 20:49 ` [PATCH 26/32] pwm: mtk-disp: convert to devm_platform_ioremap_resource Matthias Brugger
2020-02-20 20:49 ` Matthias Brugger
2020-05-23 17:11 ` [PATCH 01/32] pwm: sun4i: " Uwe Kleine-König
[not found] ` <20191229080610.7597-4-tiny.windzz@gmail.com>
2020-05-23 17:12 ` [PATCH 04/32] pwm: renesas-tpu: " Uwe Kleine-König
[not found] ` <20191229080610.7597-24-tiny.windzz@gmail.com>
2020-05-23 17:14 ` [PATCH 24/32] pwm: vt8500: " Uwe Kleine-König
[not found] ` <20191229080610.7597-31-tiny.windzz@gmail.com>
2020-05-23 17:15 ` [PATCH 31/32] pwm: sifive: " Uwe Kleine-König
[not found] ` <20191229080610.7597-28-tiny.windzz@gmail.com>
2020-05-23 17:16 ` [PATCH 28/32] pwm: img: " Uwe Kleine-König
[not found] ` <20191229080610.7597-27-tiny.windzz@gmail.com>
2020-05-23 17:17 ` [PATCH 27/32] pwm: clps711x: " Uwe Kleine-König
[not found] ` <20191229080610.7597-23-tiny.windzz@gmail.com>
2020-05-23 17:18 ` [PATCH 23/32] pwm: berlin: " Uwe Kleine-König
[not found] ` <20191229080610.7597-22-tiny.windzz@gmail.com>
2020-05-23 17:18 ` [PATCH 22/32] pwm: bcm2835: " Uwe Kleine-König
[not found] ` <20191229080610.7597-21-tiny.windzz@gmail.com>
2020-05-23 17:19 ` [PATCH 21/32] pwm: tiecap: " Uwe Kleine-König
[not found] ` <20191229080610.7597-19-tiny.windzz@gmail.com>
2020-05-23 17:19 ` [PATCH 19/32] pwm: puv3: " Uwe Kleine-König
[not found] ` <20191229080610.7597-9-tiny.windzz@gmail.com>
2020-05-23 17:20 ` [PATCH 09/32] pwm: pxa: " Uwe Kleine-König
[not found] ` <20191229080610.7597-12-tiny.windzz@gmail.com>
2020-05-23 17:20 ` [PATCH 12/32] pwm: bcm-kona: " Uwe Kleine-König
[not found] ` <20191229080610.7597-17-tiny.windzz@gmail.com>
2020-05-23 17:21 ` [PATCH 17/32] pwm: samsung: " Uwe Kleine-König
[not found] ` <20191229080610.7597-20-tiny.windzz@gmail.com>
2020-05-23 17:22 ` [PATCH 20/32] pwm: imx: " Uwe Kleine-König
[not found] ` <20191229080610.7597-18-tiny.windzz@gmail.com>
2020-05-23 17:22 ` [PATCH 18/32] pwm: tiehrpwm: " Uwe Kleine-König
[not found] ` <20191229080610.7597-16-tiny.windzz@gmail.com>
2020-05-23 17:22 ` [PATCH 16/32] pwm: bcm-iproc: " Uwe Kleine-König
[not found] ` <20191229080610.7597-11-tiny.windzz@gmail.com>
2020-05-23 17:23 ` [PATCH 11/32] pwm: spear: " Uwe Kleine-König
[not found] ` <20191229080610.7597-10-tiny.windzz@gmail.com>
2020-05-23 17:23 ` [PATCH 10/32] pwm: zx: " Uwe Kleine-König
[not found] ` <20191229080610.7597-8-tiny.windzz@gmail.com>
2020-05-23 17:23 ` [PATCH 08/32] pwm: sti: " Uwe Kleine-König
[not found] ` <20191229080610.7597-7-tiny.windzz@gmail.com>
2020-05-23 17:23 ` [PATCH 07/32] pwm: mediatek: " Uwe Kleine-König
[not found] ` <20191229080610.7597-6-tiny.windzz@gmail.com>
2020-05-23 17:23 ` [PATCH 06/32] pwm: tegra: " Uwe Kleine-König
[not found] ` <20191229080610.7597-5-tiny.windzz@gmail.com>
2020-05-23 17:24 ` [PATCH 05/32] pwm: ep93xx: " Uwe Kleine-König
[not found] ` <20191229080610.7597-3-tiny.windzz@gmail.com>
2020-05-23 17:24 ` [PATCH 03/32] pwm: rcar: " Uwe Kleine-König
[not found] ` <20191229080610.7597-2-tiny.windzz@gmail.com>
2020-05-23 17:24 ` [PATCH 02/32] pwm: fsl-ftm: " Uwe Kleine-König
2020-11-12 16:13 ` [PATCH 01/32] pwm: sun4i: " Uwe Kleine-König
2020-11-12 19:06 ` Thierry Reding
2020-11-12 21:14 ` Uwe Kleine-König
2020-11-13 7:03 ` About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource] Uwe Kleine-König
2020-11-13 9:12 ` Bartosz Golaszewski
2020-11-13 9:35 ` Uwe Kleine-König
2020-11-13 16:11 ` Thierry Reding
2020-11-13 17:40 ` Robin Murphy [this message]
2020-11-19 17:08 ` Uwe Kleine-König
[not found] ` <20191229080610.7597-29-tiny.windzz@gmail.com>
2020-05-23 17:14 ` [PATCH 29/32] pwm: lpc18xx-sct: convert to devm_platform_ioremap_resource Uwe Kleine-König
2020-11-12 21:29 ` Vladimir Zapolskiy
[not found] ` <20191229080610.7597-13-tiny.windzz@gmail.com>
[not found] ` <20191229080610.7597-13-tiny.windzz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-05-23 17:20 ` [PATCH 13/32] pwm: lpc32xx: " Uwe Kleine-König
2020-11-12 21:29 ` Vladimir Zapolskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6cddd32c-50eb-4399-02bc-d4377237134c@arm.com \
--to=robin.murphy@arm.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bgolaszewski@baylibre.com \
--cc=claudiu.beznea@microchip.com \
--cc=f.fainelli@gmail.com \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=jonathanh@nvidia.com \
--cc=kernel@pengutronix.de \
--cc=khilman@baylibre.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=ludovic.desroches@microchip.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=nsaenzjulienne@suse.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rjui@broadcom.com \
--cc=s.hauer@pengutronix.de \
--cc=sbranden@broadcom.com \
--cc=shawnguo@kernel.org \
--cc=shc_work@mail.ru \
--cc=slemieux.tyco@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=tiny.windzz@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vz@mleia.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).