All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	patches@opensource.cirrus.com
Subject: Re: [PATCH] mfd: arizona: Correct link for sound binding document
Date: Wed, 31 Oct 2018 10:38:14 -0500	[thread overview]
Message-ID: <CAL_JsqLCCMg1GeCU0_2-EvGS2FaRq4j1tFqEMswv5QBZ_jr9ZQ@mail.gmail.com> (raw)
In-Reply-To: <20181009065522.GD32033@dell>

On Tue, Oct 9, 2018 at 1:55 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Fri, 28 Sep 2018, Rob Herring wrote:
>
> > On Fri, Sep 28, 2018 at 12:46 AM Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > > On Wed, 26 Sep 2018, Rob Herring wrote:
> > >
> > > > On Mon, Sep 17, 2018 at 04:33:22PM +0100, Charles Keepax wrote:
> > > > > Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> > > > > ---
> > > > >  Documentation/devicetree/bindings/mfd/arizona.txt | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Applied.
> > >
> > > Probably won't do any harm in this instance, but it's usually better
> > > for MFD binding changes to go through the MFD tree to avoid
> > > merge-conflicts.
> >
> > It had been sitting there for a while, so I picked it up. Plus if we
>
> A little over a week is not 'a while'. :)

You're right. Probably should have waited 2 weeks. Developers
shouldn't have to wait longer than that for a response (according to
the chief penguin).

> > have conflicts within a binding (other than tree wide clean ups I do),
> > that's not a good sign that the binding is changing.
>
> Not sure I understand this.

If there are multiple sets of changes to a single binding within 1
release cycle (more than 1 really IMO), then that is a problem in and
of itself. We may want drivers enhanced feature by feature, but I
don't want bindings to. Bindings shouldn't be evolving. Maybe
sometimes different people add different things, but then they need to
work out the dependencies and conflicts, not you or me.

Rob

      reply	other threads:[~2018-10-31 15:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 15:33 [PATCH] mfd: arizona: Correct link for sound binding document Charles Keepax
2018-09-17 15:33 ` Charles Keepax
2018-09-26 22:39 ` Rob Herring
2018-09-28  5:46   ` Lee Jones
2018-09-28 16:00     ` Rob Herring
2018-10-09  6:55       ` Lee Jones
2018-10-31 15:38         ` Rob Herring [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=CAL_JsqLCCMg1GeCU0_2-EvGS2FaRq4j1tFqEMswv5QBZ_jr9ZQ@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=patches@opensource.cirrus.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.