mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Chen-Yu Tsai <wenst@chromium.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] regulator: core: resolve supply voltage deferral silently
Date: Fri, 3 Sep 2021 12:10:23 +0100	[thread overview]
Message-ID: <20210903111023.GE4932@sirena.org.uk> (raw)
In-Reply-To: <CA+ASDXPJO=F+fa2zE4LDdRzMjgiugJfuzZKnZ-pndagVtw++Ug@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

On Thu, Sep 02, 2021 at 03:41:02PM -0700, Brian Norris wrote:
> On Thu, Sep 2, 2021 at 10:06 AM Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Sep 01, 2021 at 01:06:28PM -0700, Brian Norris wrote:

> > > Take a look at the commit this "Fixes":
> >
> > > 21e39809fd7c ("regulator: vctrl: Avoid lockdep warning in enable/disable ops")

> > That driver change is at most tangentially related to the code that's
> > being updated,

> It introduced another case where we hit a spurious error log. And
> below, you admit that you didn't understand what this is fixing
> without that pointer. I guess we disagree.

The point is the "another" bit - by just picking a random commit you
will cause people to think that an issue was introduced by that commit
which in turn means that people will for example use the presence of
that commit as a guide to backporting.  They may not backport things far
enough since the random commit isn't there, or backport things too far
if the actual issue was introduced later which can be even worse as it
can introduce breakage where it wasn't before.

In terms of not understanding the issue here is that the patch didn't
pass the smell test, it was your explanation that helped here not the
pointing at a driver change that lacks obvious relevance.  I really
don't know what the reader is supposed to infer about the change from
the commit, 

> > That's definitely an abuse of the API, the hardware design is pretty
> > much a gross hack anywhere as far as I remember.  As Chen-Yu says I'd
> > only expect this to be possible in the case where the supply is in
> > bypass mode and hasn't got its own parent.  In any case I can see why
> > it's happening now...

> Well the hardware exists, the driver exists, and it all worked OK
> until somewhat recently (and now it works again, thanks to Chen-Yu).
> What should we do here, then? Just leave the "abuse" in place?

I don't think anyone came up with anything more tasteful to do with that
hardware, like I say the hardware is itself very hacky.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-09-03 11:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26 19:40 Brian Norris
2021-09-01 15:08 ` Mark Brown
2021-09-01 20:06   ` Brian Norris
2021-09-02  4:09     ` Chen-Yu Tsai
2021-09-02 17:06     ` Mark Brown
2021-09-02 22:41       ` Brian Norris
2021-09-03 11:10         ` Mark Brown [this message]
2021-09-03 17:09           ` Brian Norris
2021-09-03 17:54             ` Mark Brown
2021-09-03 20:10               ` Brian Norris
2021-09-13 10:53 ` 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=20210903111023.GE4932@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=briannorris@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wenst@chromium.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®