All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "broonie@kernel.org" <broonie@kernel.org>,
	"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"linux-gpio@ger.kernel.org" <linux-gpio@ger.kernel.org>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>
Subject: Re: [PATCH v13 00/11] Support ROHM BD71828 PMIC
Date: Tue, 21 Jan 2020 08:34:50 +0000	[thread overview]
Message-ID: <20200121083450.GG15507@dell> (raw)
In-Reply-To: <70ac7b71d5d54d4b90ded032214c473569b9fae1.camel@fi.rohmeurope.com>

On Mon, 20 Jan 2020, Vaittinen, Matti wrote:
> On Mon, 2020-01-20 at 13:54 +0000, Mark Brown wrote:
> > On Mon, Jan 20, 2020 at 03:40:20PM +0200, Matti Vaittinen wrote:
> > > Patch series introducing support for ROHM BD71828 PMIC
> > > 
> > > ROHM BD71828 is a power management IC containing 7 bucks and 7
> > > LDOs. All
> > > regulators can be controlled individually via I2C. Bucks 1,2,6 and
> > > 7 can also be assigned to a "regulator group" controlled by run-
> > > levels.
> > 
> > This is the *third* version of this you've sent today alone.  Please
> > stop sending me this series until the MFD has been merged, perhaps
> > just
> > drop the subsystem patches while you resolve whatever the problems
> > are
> > that remain with the MFD?  I'm pretty much just deleting these
> > patches
> > without even looking at them at this point, it's a large series, it's
> > getting huge numbers of resends and I don't think any version I've
> > had a
> > chance to look at before it got resent had a change in the one
> > regulator
> > patch that'd cause me to have to re-review it.

To be fair, yours is one of the reviews we're waiting for!

See [PATCH 03/11].

> Sorry Mark (and all). I guess this is annoying. Why I do resend whole
> series is that during the bd71837 work Lee instructed me to always
> resend whole series - not just the changed patches.

Which in general is the correct thing to do.  Having a large threaded
series on the list containing in the form of subsequent
versions gets real confusing real quick:

| [PATCH v2 01/05]
| > [PATCH v3 01/05]
| [PATCH v2 02/05]
| > [PATCH v3 02/05]
| -> [PATCH v4 02/05]
| [PATCH v2 03/05]
| [PATCH v2 04/05]
| > [PATCH v3 04/05]
| [PATCH v2 05/05]
| > [PATCH v3 05/05]
| -> [PATCH v4 05/05]
| --> [PATCH v5 05/05]
| ---> [PATCH v6 05/05]

However, you should wait for a suitable period per submission, to give
each maintainer a chance to review the patches they are responsible
for.

> I sure can learn and drop some of the recipients in the future - and
> actually I did for this last resend. Reason why you are in the
> recipients is that Lee asked me to get your ack for patch 3/11. Same
> goes with Stephen.
> 
> Linus is involved as Lee asked me to get his ack for patch 11.
> 
> But resending this series 3 times today is really my fault. (Well, of
> course, I did send this and no one else). I messed up the previous
> series.
> 
> I was hoping the revision history in cover letter would be a fast way
> to determine if something relevant has changed. Additionally, I did try
> to include statement that "no changes" in the beginning of each patches
> for most of the versions. (for versions up-to 11 - this was omitted
> from v12 and v13 which only did very specific changes).
> 
> But sure, I should try to be more careful so that I don't need to do so
> many resends - and I really could drop most of the recipients earlier.
> Thanks for pointing it out.

If dropping recipients is your tactic of choice (I wouldn't choose to
do that myself), just ensure you keep everyone on Cc for the
cover-letter ("[PATCH 00/00]") and maybe indicate the fact that they
have been dropped and why ("dropped Lee since the MFD patches have
been reviewed and are unchanged in this series").  Reason being;
if/when a set is applied, the cover-letter is used as the Reply-to
for sending out the pull-request to all those concerned.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-01-21  8:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 13:40 [PATCH v13 00/11] Support ROHM BD71828 PMIC Matti Vaittinen
2020-01-20 13:40 ` [PATCH v13 01/11] dt-bindings: leds: ROHM BD71282 PMIC LED driver Matti Vaittinen
2020-01-20 13:41 ` [PATCH v13 02/11] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
2020-01-20 13:42 ` [PATCH v13 03/11] mfd: rohm PMICs - use platform_device_id to match MFD sub-devices Matti Vaittinen
2020-01-21 16:40   ` Mark Brown
2020-01-22  6:15     ` Vaittinen, Matti
2020-01-20 13:43 ` [PATCH v13 04/11] mfd: bd718x7: Add compatible for BD71850 Matti Vaittinen
2020-01-20 13:43 ` [PATCH v13 05/11] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2020-01-20 13:43 ` [PATCH v13 06/11] mfd: bd71828: Add power-key support Matti Vaittinen
2020-01-20 13:44 ` [PATCH v13 07/11] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2020-01-20 13:44 ` [PATCH v13 08/11] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2020-01-20 13:45 ` [PATCH v13 09/11] mfd: bd70528: Fix hour register mask Matti Vaittinen
2020-01-20 13:45 ` [PATCH v13 10/11] rtc: bd70528: add BD71828 support Matti Vaittinen
2020-01-20 13:47 ` [PATCH v13 11/11] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2020-01-20 13:54 ` [PATCH v13 00/11] Support ROHM BD71828 PMIC Mark Brown
2020-01-20 14:21   ` Vaittinen, Matti
2020-01-21  8:34     ` Lee Jones [this message]
2020-01-21 13:11     ` Mark Brown
2020-01-22  6:44       ` Vaittinen, Matti
2020-01-22 12:19         ` Mark Brown
2020-01-21  8:36   ` Lee Jones
2020-01-21 16:15     ` Mark Brown
2020-01-22  6:28       ` Vaittinen, Matti
2020-01-22 11:58         ` Mark Brown
2020-01-22  7:32       ` Lee Jones
2020-01-22 12:11         ` Mark Brown
2020-01-22 13:33 ` Lee Jones
2020-01-24  7:32 ` [GIT PULL] Immutable branch between MFD, Clk, GPIO, Regulator and RTC due for the v5.6 merge window Lee Jones

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=20200121083450.GG15507@dell \
    --to=lee.jones@linaro.org \
    --cc=Matti.Vaittinen@fi.rohmeurope.com \
    --cc=broonie@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-gpio@ger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=sboyd@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 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.