linux-kernel - Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 19 Nov 2020 18:08:02 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     alexandre.belloni@...tlin.com, heiko@...ech.de,
        Yangtao Li <tiny.windzz@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-riscv@...ts.infradead.org, festevam@...il.com,
        f.fainelli@...il.com, shc_work@...l.ru,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        khilman@...libre.com, wens@...e.org, jonathanh@...dia.com,
        linux-rockchip@...ts.infradead.org,
        ludovic.desroches@...rochip.com,
        bcm-kernel-feedback-list@...adcom.com, linux-imx@....com,
        slemieux.tyco@...il.com, linux-pwm@...r.kernel.org,
        rjui@...adcom.com, s.hauer@...gutronix.de, mripard@...nel.org,
        vz@...ia.com, linux-mediatek@...ts.infradead.org,
        linux-rpi-kernel@...ts.infradead.org, paul.walmsley@...ive.com,
        matthias.bgg@...il.com, linux-amlogic@...ts.infradead.org,
        Lee Jones <lee.jones@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-arm-kernel@...ts.infradead.org, sbranden@...adcom.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        nicolas.ferre@...rochip.com, palmer@...belt.com,
        kernel@...gutronix.de, shawnguo@...nel.org,
        claudiu.beznea@...rochip.com, nsaenzjulienne@...e.de
Subject: Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32]
 pwm: sun4i: convert to devm_platform_ioremap_resource]

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

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)