[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201113154710.GA1408970@ulmo>
Date: Fri, 13 Nov 2020 16:47:10 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 0/2] Rename ioremap functions that include request_mem
On Fri, Nov 13, 2020 at 09:53:25AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> here comes a patch set that implements the suggestion in the previous
> mail so we have something to discuss about.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (2):
> base: Rename devm_ioremap_resource to make the implicit request_mem
> explicit
> platform: Rename devm_platform_ioremap_resource to make the implicit
> request_mem explicit
>
> .../driver-api/driver-model/devres.rst | 6 +--
> drivers/base/platform.c | 26 +++++------
> include/linux/device.h | 32 ++++++++++++--
> include/linux/platform_device.h | 43 +++++++++++++++++--
> lib/devres.c | 18 ++++----
> 5 files changed, 93 insertions(+), 32 deletions(-)
To be honest, this is getting a bit eccentric for my taste. Yes,
devm_ioremap_resource() does more than just devm_ioremap(), but that's
why it's called devm_ioremap_resource(). It's a compromise between the
new functionality and practical symbol length.
The kerneldoc for devm_ioremap_resource() is very explicit about what it
does, so I think it's fine to omit some of the details from the symbol
name for the sake of brevity.
Things get out of hand pretty quickly if we start incorporating every
single aspect of what a function does into its name.
Thierry
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists