[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70cc9c74785937695c795b5a655f3ab894b14141.camel@perches.com>
Date: Fri, 13 Nov 2020 09:08:17 -0800
From: Joe Perches <joe@...ches.com>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Cc: linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH 3/2] checkpatch: document the function renaming and
deprecation around devm_ioremap_resource
On Fri, 2020-11-13 at 18:00 +0100, Uwe Kleine-König wrote:
> On Fri, Nov 13, 2020 at 08:36:44AM -0800, Joe Perches wrote:
> > On Fri, 2020-11-13 at 10:11 +0100, Uwe Kleine-König wrote:
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> > > ---
> > > Hello,
> > >
> > > this can also be squashed into the respective patches instead.
> > >
> > > Best regards
> > > Uwe
> > >
> > > scripts/checkpatch.pl | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > []
> > > @@ -615,6 +615,11 @@ our %deprecated_apis = (
> > > "rcu_barrier_sched" => "rcu_barrier",
> > > "get_state_synchronize_sched" => "get_state_synchronize_rcu",
> > > "cond_synchronize_sched" => "cond_synchronize_rcu",
> > > + "devm_platform_get_and_ioremap_resource" => "devm_platform_get_request_and_ioremap_resource",
> >
> > Do we really need 46 character length function names?
>
> I can drop the "_and" and maybe "_get", so we're down to 38 "only".
> Other than that I think all name parts are relevant.
>
> > > + "devm_platform_ioremap_resource" => "devm_platform_request_ioremap_resource",
> > > + "devm_platform_ioremap_resource_wc" => "devm_platform_request_ioremap_resource_wc",
> > > + "devm_ioremap_resource" => "devm_request_ioremap_resource",
> > > + "devm_ioremap_resource_wc" => "devm_request_ioremap_resource_wc",
> > > );
> > >
> > >
> > > #Create a search pattern for all these strings to speed up a loop below
> >
> > And do please send your proposed patches to the appropriate maintainers.
>
> Yes, sure. This patch 3/2 was only a quick shot and it was already clear
> to me that I have to redo it. I want to squash this change in the patch
> that does the actual renaming, I assume that's fine for you?!
Sure.
But please do take Thierry Reding's comment about overall
API complexity into account.
All wrapper macro/functions aren't always obviously good.
They can be useful, but can make knowing which of many
possible wrappers to use and when to use them appropriately
difficult.
Wrappers also add complexity to documentation.
Powered by blists - more mailing lists