From: Mark Brown <broonie@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [GIT PULL] regulator updates for v4.7
Date: Tue, 17 May 2016 11:18:08 +0100 [thread overview]
Message-ID: <20160517101808.GB8104@sirena.org.uk> (raw)
In-Reply-To: <CA+55aFwAxigrSb56OzoyWdAG_Rd9Herw9myS7Yk7aX30BB1qoA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On Mon, May 16, 2016 at 07:38:23PM -0700, Linus Torvalds wrote:
> On Mon, May 16, 2016 at 5:27 AM, Mark Brown <broonie@kernel.org> wrote:
> > Mark Brown (26):
> > regulator: Deprecate regulator_can_change_voltage()
> This needs to be fixed.
> It causes a build warning, and it's just not acceptable. We've had
> driver subsystems do this before, and then the warning stays around
> for years and nothing gets done.
> The warning is not just ugly, it ends up often hiding real problems
> when people get used to seeing warnings during the build.
I agree, it's not great, I wouldn't normally do it and it's certainly
not good to just shove the annotation on there with no other action. In
this case a combination of this and pushing patches at people seems to
be working - I am expecting all the broken users to be fixed during the
merge window (-next looks OK) at which point I can send a patch to you
dropping the API.
> The whole "__deprecated" crap has been a bigger problem in itself than
> it has ever actually solved.
> So don't do it. Either remove bad interfaces or leave them alone. None
> of this "let's annoy everybody else with our deprecation messages
> whether they care about it or not".
I was also trying to remove the users via other means so I could delete
the function. The reason I added the warning was that all the users
were in the embedded graphics drivers and for whatever reason it's
historically been suprisingly difficult to get any attention on issues
there that don't show up during the build so I hoped this would help
push things along faster and avoid new attempts to use it. Like I say
something seems to have worked better this time around, though I don't
know how much of it is down to the warning of course.
I'll send a patch either deleting the interface or reverting this after
-rc1 (or earlier if the users are gone from your tree before then) if
that's OK?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-05-17 10:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 12:27 Mark Brown
2016-05-17 2:38 ` Linus Torvalds
2016-05-17 10:18 ` Mark Brown [this message]
2016-05-17 15:57 ` Mark Brown
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=20160517101808.GB8104@sirena.org.uk \
--to=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®