Linux-Amlogic Archive on lore.kernel.org
 help / color / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: "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>,
	linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-riscv@lists.infradead.org, festevam@gmail.com,
	f.fainelli@gmail.com, shc_work@mail.ru,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	khilman@baylibre.com, wens@csie.org, jonathanh@nvidia.com,
	linux-rockchip@lists.infradead.org,
	ludovic.desroches@microchip.com,
	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,
	matthias.bgg@gmail.com, 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>,
	nicolas.ferre@microchip.com, 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:11:53 +0100
Message-ID: <20201113161153.GB1408970@ulmo> (raw)
In-Reply-To: <20201113070343.lhcsbyvi5baxn3lq@pengutronix.de>

[-- Attachment #1.1: Type: text/plain, Size: 4079 bytes --]

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?

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 167 bytes --]

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  parent reply index

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-29  8:05 [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource Yangtao Li
2019-12-29  8:05 ` [PATCH 02/32] pwm: fsl-ftm: " Yangtao Li
2020-05-23 17:24   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 03/32] pwm: rcar: " Yangtao Li
2020-05-23 17:24   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 04/32] pwm: renesas-tpu: " Yangtao Li
2020-05-23 17:12   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 05/32] pwm: ep93xx: " Yangtao Li
2020-05-23 17:24   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 06/32] pwm: tegra: " Yangtao Li
2020-05-23 17:23   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 07/32] pwm: mediatek: " Yangtao Li
2020-05-23 17:23   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 08/32] pwm: sti: " Yangtao Li
2020-05-23 17:23   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 09/32] pwm: pxa: " Yangtao Li
2020-05-23 17:20   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 10/32] pwm: zx: " Yangtao Li
2020-05-23 17:23   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 11/32] pwm: spear: " Yangtao Li
2020-05-23 17:23   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 12/32] pwm: bcm-kona: " Yangtao Li
2020-05-23 17:20   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 13/32] pwm: lpc32xx: " Yangtao Li
2020-05-23 17:20   ` Uwe Kleine-König
2020-11-12 21:29   ` Vladimir Zapolskiy
2019-12-29  8:05 ` [PATCH 14/32] pwm: meson: " Yangtao Li
2019-12-31 14:53   ` Martin Blumenstingl
2020-05-23 17:25   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 15/32] pwm: rockchip: " Yangtao Li
2019-12-30  8:39   ` Heiko Stuebner
2020-05-23 17:25   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 16/32] pwm: bcm-iproc: " Yangtao Li
2020-05-23 17:22   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 17/32] pwm: samsung: " Yangtao Li
2020-05-23 17:21   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 18/32] pwm: tiehrpwm: " Yangtao Li
2020-05-23 17:22   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 19/32] pwm: puv3: " Yangtao Li
2020-05-23 17:19   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 20/32] pwm: imx: " Yangtao Li
2020-05-23 17:22   ` Uwe Kleine-König
2019-12-29  8:05 ` [PATCH 21/32] pwm: tiecap: " Yangtao Li
2020-05-23 17:19   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 22/32] pwm: bcm2835: " Yangtao Li
2020-05-23 17:18   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 23/32] pwm: berlin: " Yangtao Li
2020-05-23 17:18   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 24/32] pwm: vt8500: " Yangtao Li
2020-05-23 17:14   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 25/32] pwm: brcmstb: " Yangtao Li
2020-01-07 10:54   ` Nicolas Saenz Julienne
2020-05-23 17:25   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 26/32] pwm: mtk-disp: " Yangtao Li
2020-02-20 20:49   ` Matthias Brugger
2019-12-29  8:06 ` [PATCH 27/32] pwm: clps711x: " Yangtao Li
2020-05-23 17:17   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 28/32] pwm: img: " Yangtao Li
2020-05-23 17:16   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 29/32] pwm: lpc18xx-sct: " Yangtao Li
2020-05-23 17:14   ` Uwe Kleine-König
2020-11-12 21:29   ` Vladimir Zapolskiy
2019-12-29  8:06 ` [PATCH 30/32] pwm: hibvt: do some cleanup Yangtao Li
2020-02-20 20:41   ` Uwe Kleine-König
2020-05-23 17:44     ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 31/32] pwm: sifive: convert to devm_platform_ioremap_resource Yangtao Li
2020-05-23 17:15   ` Uwe Kleine-König
2019-12-29  8:06 ` [PATCH 32/32] pwm: atmel: " Yangtao Li
2020-01-06 10:32   ` Claudiu.Beznea
2020-05-23 17:25   ` Uwe Kleine-König
2020-05-23 17:11 ` [PATCH 01/32] pwm: sun4i: " Uwe Kleine-König
2020-11-12 16:13 ` 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 [this message]
2020-11-13 17:40           ` Robin Murphy
2020-11-19 17:08           ` Uwe Kleine-König

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=20201113161153.GB1408970@ulmo \
    --to=thierry.reding@gmail.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=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

Linux-Amlogic Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-amlogic/0 linux-amlogic/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-amlogic linux-amlogic/ https://lore.kernel.org/linux-amlogic \
		linux-amlogic@lists.infradead.org
	public-inbox-index linux-amlogic

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-amlogic


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git