linux-kernel - Re: [PATCH v7 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230621171315.GL10378@google.com>
Date:   Wed, 21 Jun 2023 18:13:15 +0100
From:   Lee Jones <lee@...nel.org>
To:     "Sahin, Okan" <Okan.Sahin@...log.com>
Cc:     Mark Brown <broonie@...nel.org>, 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>,
        "Bolboaca, Ramona" <Ramona.Bolboaca@...log.com>,
        ChiYuan Huang <cy_huang@...htek.com>,
        "Tilki, Ibrahim" <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" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v7 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC
 Support

On Tue, 13 Jun 2023, Sahin, Okan wrote:

> >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.
> 
> Hi Mark and Lee,
> 
> Is there anything that I need to do for this patch set. I have received reviewed
> by tag for all of them so far. 

Since we are so late in the day, I'm going to just apply this for v6.5.

The remainder can then be applied, friction free, for v6.6.

-- 
Lee Jones [李琼斯]