linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>
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: Thu, 19 Nov 2020 18:08:02 +0100	[thread overview]
Message-ID: <20201119170802.bup5foltlhrg5576@pengutronix.de> (raw)
In-Reply-To: <20201113161153.GB1408970@ulmo>


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

Hello,

On Fri, Nov 13, 2020 at 05:11:53PM +0100, Thierry Reding wrote:
> 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.

Right. In my eyes if you have 

 - devm_platform_ioremap_resource
 - devm_platform_get_and_ioremap_resource
 - devm_ioremap_resource
 - devm_ioremap

(to list just a few) with the current semantics, the compromise is badly
shifted into the "short name" direction however; and that was the
motivation for this patch set. In my eyes it must be more obvious which
of these functions include devm_request_mem_region() and which don't.

And note, my patch series doesn't introduce new helpers, just renames
them to have a better name (and adds compat glue for the old names).

> 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.

This is indeed a relevant point. An alternative is to make the helper
more flexible. This complicates the API, too, however, so this isn't
always gold, either.
 
> 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?

I'm on your side for the _wc stuff, looking at next-20201119:

 - devm_ioremap_resource_wc has a single user:
   devm_platform_ioremap_resource_wc
 - devm_platform_ioremap_resource_wc has a single user:
   drivers/misc/sram.c

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

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

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

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

      parent reply	other threads:[~2020-11-19 17:08 UTC|newest]

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
2020-11-13 17:40           ` Robin Murphy
2020-11-19 17:08           ` Uwe Kleine-König [this message]

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=20201119170802.bup5foltlhrg5576@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --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=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).