From: Lee Jones <lee@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
William Breathitt Gray <william.gray@linaro.org>,
"Sahin, Okan" <Okan.Sahin@analog.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Cosmin Tanislav <demonsingur@gmail.com>,
Stephen Boyd <sboyd@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Caleb Connolly <caleb.connolly@linaro.org>,
Marcus Folkesson <marcus.folkesson@gmail.com>,
"Bolboaca, Ramona" <Ramona.Bolboaca@analog.com>,
ChiYuan Huang <cy_huang@richtek.com>,
"Tilki, Ibrahim" <Ibrahim.Tilki@analog.com>,
Arnd Bergmann <arnd@arndb.de>,
Hugo Villeneuve <hvilleneuve@dimonoff.com>,
ChiaEn Wu <chiaen_wu@richtek.com>,
Haibo Chen <haibo.chen@nxp.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH v7 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support
Date: Thu, 29 Jun 2023 08:25:00 +0100 [thread overview]
Message-ID: <20230629072500.GA2110266@google.com> (raw)
In-Reply-To: <472a4d86-3bfb-4c2b-a099-f1254dd01e24@sirena.org.uk>
TL;DR: I'm reverting back to the old style of cross-subsystem patch
management where sets get merged as sets with maintainer Acks (or
Reviews!).
On Wed, 28 Jun 2023, Mark Brown wrote:
> On Wed, Jun 28, 2023 at 02:40:13PM +0100, Lee Jones wrote:
> > On Tue, 27 Jun 2023, Rob Herring wrote:
> > > On Tue, Jun 27, 2023 at 10:33 AM Lee Jones <lee@kernel.org> wrote:
>
> > > IMO, a series with interdependencies, which most cases of a new MFD
> > > are, should be applied as a series. That's generally what happens
> > > everywhere else. Creating a branch and PR seems like extra work for
> > > everyone. The downside to that is any API changes outside of MFD would
>
> > This is what we've been doing for the last decade. However, I'm getting
> > mixed messages from folk. Mark recently asked for something completely
> > different (which I did say would be a bad idea at the time):
>
> > https://lore.kernel.org/all/20230421073938.GO996918@google.com/
>
> > Could we please just pick a strategy and go with it?
>
> The basic ask from me is for things that cause these serieses to make
> progress, ideally in ways that minimise the amount of noise that they
> generate (given that they're generally pretty routine). Applying
> patches when they're ready at least mitigates the size of the series,
> makes it easy to tell that they're OK and doesn't preclude applying more
> patches on top of it if that's a thing that people want to do.
>
> > > need some coordination. That coordination would only be needed when a
> > > subsystem has some API change and there's a new MFD using that
> > > subsystem rather than by default for every new MFD.
>
> > > Another option is just that you take all the binding patches since the
> > > MFD binding depends on the others. The drivers can still go via the
> > > subsystem. Not totally ideal to have branches of drivers missing
> > > bindings, but better than mainline missing bindings.
>
> > My original method of taking everything with Acks was fine IMHO.
>
> As I mentioned before the number of resends of what are frequently very
> similar serieses (eg, two PMICs from the same vendor in flight at the
> same time) was causing me real issues with tags going AWOL and things
> getting lost in the noise.
As much as I empathise with each of these points (I feel it too), the
alternative seems to be causing more issues for more people. With that
in mind, I'm going to revert back to how we've been doing things for a
long time now. Please try to Ack and forget. If a contributor fails to
apply a previously issued tag, we'll have to bring that up at the time.
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2023-06-29 7:25 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 11:12 [PATCH v7 0/5] Add MAX77541/MAX77540 PMIC Support Okan Sahin
2023-04-12 11:12 ` [PATCH v7 1/5] dt-bindings: regulator: max77541: Add ADI MAX77541/MAX77540 Regulator Okan Sahin
2023-06-28 14:17 ` Lee Jones
2023-04-12 11:12 ` [PATCH v7 2/5] regulator: max77541: Add ADI MAX77541/MAX77540 Regulator Support Okan Sahin
2023-04-21 12:41 ` Mark Brown
2023-06-28 14:17 ` Lee Jones
2023-04-12 11:12 ` [PATCH v7 3/5] iio: adc: max77541: Add ADI MAX77541 ADC Support Okan Sahin
2023-04-12 13:41 ` Andy Shevchenko
2023-06-28 14:18 ` Lee Jones
2023-04-12 11:12 ` [PATCH v7 4/5] dt-bindings: mfd: max77541: Add ADI MAX77541/MAX77540 Okan Sahin
2023-06-28 14:18 ` Lee Jones
2023-04-12 11:12 ` [PATCH v7 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support Okan Sahin
2023-04-12 13:41 ` Andy Shevchenko
2023-04-20 10:34 ` Lee Jones
2023-04-20 16:52 ` Mark Brown
2023-04-21 7:39 ` Lee Jones
2023-04-21 13:33 ` Mark Brown
2023-06-13 7:34 ` Sahin, Okan
2023-06-21 17:13 ` Lee Jones
2023-06-26 17:54 ` Rob Herring
2023-06-27 13:56 ` Lee Jones
2023-06-27 14:10 ` Rob Herring
2023-06-27 14:32 ` William Breathitt Gray
2023-06-27 16:33 ` Lee Jones
2023-06-27 18:21 ` Rob Herring
2023-06-28 13:40 ` Lee Jones
2023-06-28 19:20 ` Mark Brown
2023-06-29 7:25 ` Lee Jones [this message]
2023-06-29 10:38 ` Mark Brown
2023-06-29 15:51 ` Lee Jones
2023-06-29 16:00 ` Mark Brown
2023-06-29 17:48 ` Rob Herring
2023-06-29 17:58 ` Mark Brown
2023-06-29 18:14 ` Rob Herring
2023-06-29 18:22 ` Mark Brown
2023-06-30 7:17 ` Lee Jones
2023-06-30 11:58 ` Mark Brown
2023-06-27 14:39 ` Mark Brown
2023-06-27 14:25 ` Mark Brown
2023-06-21 17:14 ` 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=20230629072500.GA2110266@google.com \
--to=lee@kernel.org \
--cc=Ibrahim.Tilki@analog.com \
--cc=Okan.Sahin@analog.com \
--cc=Ramona.Bolboaca@analog.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=caleb.connolly@linaro.org \
--cc=chiaen_wu@richtek.com \
--cc=cy_huang@richtek.com \
--cc=demonsingur@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=haibo.chen@nxp.com \
--cc=hvilleneuve@dimonoff.com \
--cc=jic23@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcus.folkesson@gmail.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=william.gray@linaro.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;
as well as URLs for NNTP newsgroup(s).