Message-ID: <82612171-46d7-4d82-a8fc-c7d6a99d57e9@sirena.org.uk>
Date:   Fri, 21 Apr 2023 14:33:27 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Lee Jones <lee@...nel.org>
Cc:     Okan Sahin <okan.sahin@...log.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Cosmin Tanislav <demonsingur@...il.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Caleb Connolly <caleb.connolly@...aro.org>,
        Marcus Folkesson <marcus.folkesson@...il.com>,
        Ramona Bolboaca <ramona.bolboaca@...log.com>,
        ChiYuan Huang <cy_huang@...htek.com>,
        Ibrahim Tilki <Ibrahim.Tilki@...log.com>,
        William Breathitt Gray <william.gray@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Hugo Villeneuve <hvilleneuve@...onoff.com>,
        ChiaEn Wu <chiaen_wu@...htek.com>,
        Haibo Chen <haibo.chen@....com>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [PATCH v7 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC
 Support

On Fri, Apr 21, 2023 at 08:39:38AM +0100, Lee Jones wrote:

> I'll try anything once!

> Fair warning, I think this is going to massively complicate things. 

> Either we're going to be left with a situation where child-driver
> maintainers are scrabbling around looking for previous versions for the
> MFD pull-request or contributors being forced to wait a full cycle for
> their dependencies to arrive in the maintainer's base.

If people are resending after the MFD has gone in they really ought to
be including the pull request in the cover letter, with some combination
of either referencing the mail or just saying "this depends on the
signed tag at url+tag", the same way they would for any other dependency.

I can't see how you applying stuff when you can slow things down TBH,
the MFD bits will be applied faster and either people can pull in a
shared tag or you can apply more commits on top of the existing core
driver.

> I'm not sure why simply providing your Ack when you're happy with the
> driver and forgetting about the set until the pull-request arrives, like
> we've been doing for nearly a decade now, isn't working for you anymore
> but I'm mostly sure this method will be a regression.

Like I said I've not been doing that, I've mostly been just applying the
driver when it's ready.  This might not have been so visible to you
since it means that the regulator driver doesn't appear in the series by
the time the MFD settles down.  The whole "Acked-for-MFD" has always
been a bit confusing TBH, it's not a normal ack ("go ahead and apply
this, I'm fine with it") so it was never clear what the intention was.

Before I started just applying the drivers there used to be constant
problems with things like tags going missing (which some of the time is
the submitter just not carrying them but can also be the result of some
churn causing them to be deliberately dropped due to changes) or
forgetting the series as you suggest and then not looking at some other
very similarly named series that was also getting lots of versions after
thinking it was one that had been reviewed already.  It was all very
frustrating.  Not doing the tags until the dependencies have settled
down means that if it's in my inbox it at least consistently needs some
kind of attention and that the submitter didn't drop tags or anything so
I know why there's no tag on it even though the version number is high,
though it's not ideal either.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists