From: "Dr. David Alan Gilbert" <linux@treblig.org>
To: Mark Brown <broonie@kernel.org>
Cc: lgirdwood@gmail.com, linux-doc@vger.kernel.org, corbet@lwn.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] Regulator deadcode cleanups
Date: Thu, 1 May 2025 00:03:30 +0000 [thread overview]
Message-ID: <aBK6UqZDx3tWnBcm@gallifrey> (raw)
In-Reply-To: <aBKvw3KEikfdQbn7@finisterre.sirena.org.uk>
* Mark Brown (broonie@kernel.org) wrote:
> On Sun, Apr 27, 2025 at 02:58:03PM +0000, Dr. David Alan Gilbert wrote:
> > * Mark Brown (broonie@kernel.org) wrote:
>
> > > Please do some analysis as to why the functions are there, don't just
> > > blindly delete things.
>
> > I'd appreciate some more idea of what you're after; each patch
> > shows where and when the function was added or last used. Some have
>
> Something that indicates that this is a patch written by a human rather
> than some automated noise, that considers things like API usability and
> coherence, or what people might do if the API is not available when they
> need it, rather than just mechanically churning something out. None of
> your commit logs consider what the code you're deleting does at all.
I do manually write each patch, but I don't have that global feel of the
API; but I do use my judgement to avoid some things:
* I tend not to remove one side of an obvious pair of functions
(e.g. a set/clear or an alloc/free)
* I avoid things that look like a function for every firmware interface
where the functions are almost documenting the interface.
* I only bother deleting one line functions if it's part of a set.
and some others. It's not automatic, but I don't claim to understand
the whole interface. I will try and follow a thread if I end up deleting
something which then makes it look like something else isn't needed.
I do have _some_ feel - so have spotted some bugs where a function
should have been called.
> > comments saying things like the devm_ version is being used (so it
> > seemed reasonable to me to delete the plain version if no one uses it).
>
> Deleting the plain version of something where a devm version exists is
> an obvious example of making the API less coherent and hard to use,
> managed resources aren't universally appropriate and so you should
> generally be able to do the same thing with manual resource management.
OK, that's something I hadn't expected - I'd thought if one style was
used for many years, that the other was redundant.
It can be quite tricky to see why functions have ended up not being
used for years (or decades), some is making a nice API, but sometimes
it's people blindly copying another API or who had a set of patches
which used the function but those patches got abandoned.
It also varies a lot between maintainer - some really prefer not
to have unused functions at all.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
prev parent reply other threads:[~2025-05-01 0:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-26 17:51 [PATCH 0/5] Regulator deadcode cleanups linux
2025-04-26 17:51 ` [PATCH 1/5] regulator: devres: Remove unused devm_regulator_bulk_register_supply_alias linux
2025-04-26 17:51 ` [PATCH 2/5] regulator: core: Remove unused regulator_bulk_force_disable linux
2025-04-26 17:51 ` [PATCH 3/5] regulator: core: Remove unused regulator_*drvdata functions linux
2025-04-26 17:51 ` [PATCH 4/5] regulator: core: Remove unused regulator_suspend_(disable|enable) linux
2025-04-26 17:51 ` [PATCH 5/5] regulator: core: Remove unused regulator_set_suspend_voltage linux
2025-04-27 14:34 ` [PATCH 0/5] Regulator deadcode cleanups Mark Brown
2025-04-27 14:58 ` Dr. David Alan Gilbert
2025-04-30 23:18 ` Mark Brown
2025-05-01 0:03 ` Dr. David Alan Gilbert [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=aBK6UqZDx3tWnBcm@gallifrey \
--to=linux@treblig.org \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=lgirdwood@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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