Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 29 Sep 2022 18:51:32 +0100
From:   Lee Jones <lee@kernel.org>
To:     Rob Herring <robh@kernel.org>
Cc:     Jonathan Cameron <jic23@kernel.org>,
        ChiaEn Wu <peterwu.pub@gmail.com>, pavel@ucw.cz,
        krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
        lars@metafoo.de, andriy.shevchenko@linux.intel.com,
        chiaen_wu@richtek.com, alice_chen@richtek.com,
        cy_huang@richtek.com, linux-leds@vger.kernel.org,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-iio@vger.kernel.org, szunichen@gmail.com,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v12 3/5] iio: adc: mt6370: Add MediaTek MT6370 support
Message-ID: <YzXbJM31s0P0nLD5@google.com>
References: <cover.1663926551.git.chiaen_wu@richtek.com>
 <9bf36f09bc5f002f2b09b7cc26edccf109516465.1663926551.git.chiaen_wu@richtek.com>
 <20220924155525.5663bed8@jic23-huawei>
 <YzFY5FI0PrZqdAiZ@google.com>
 <CAL_JsqKKJGtacbzGqCupFniSGha610L1cay2V+AK8vehTA=F=g@mail.gmail.com>
 <YzQSnuwPjzJIgsYq@google.com>
 <20220929163418.GA2270491-robh@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220929163418.GA2270491-robh@kernel.org>
Precedence: bulk

On Thu, 29 Sep 2022, Rob Herring wrote:

> On Wed, Sep 28, 2022 at 10:23:42AM +0100, Lee Jones wrote:
> > On Mon, 26 Sep 2022, Rob Herring wrote:
> > 
> > > On Mon, Sep 26, 2022 at 2:46 AM Lee Jones <lee@kernel.org> wrote:
> > > >
> > > > On Sat, 24 Sep 2022, Jonathan Cameron wrote:
> > > >
> > > > > On Fri, 23 Sep 2022 10:51:24 +0800
> > > > > ChiaEn Wu <peterwu.pub@gmail.com> wrote:
> > > > >
> > > > > > From: ChiaEn Wu <chiaen_wu@richtek.com>
> > > > > >
> > > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> > > > > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> > > > > > driver, display bias voltage supply, one general purpose LDO, and the
> > > > > > USB Type-C & PD controller complies with the latest USB Type-C and PD
> > > > > > standards.
> > > > > >
> > > > > > Add support for the MT6370 ADC driver for system monitoring, including
> > > > > > charger current, voltage, and temperature.
> > > > > >
> > > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com>
> > > > >
> > > > > This will have to either wait for next cycle, or go through mfd because
> > > > > of the dt-bindings include which is in the mfd tree.
> > > > >
> > > > > Please make those dependencies clear in new versions.
> > > >
> > > > If the bindings come together in -next, then subsequently in Mainline,
> > > > it shouldn't really matter.
> > > 
> > > Except that the bindings haven't come together and at this point may
> > > not for 6.1. linux-next has been warning for weeks because the child
> > > device schemas haven't been applied. I've said it before, all the
> > > schemas for MFD devices need to be applied together. Or at least the
> > > MFD schema needs to get applied last.
> > > 
> > > Furthermore, subsequent versions of this don't get tested and we end
> > > up with more warnings[1].
> > > 
> > > It's only your IIO tree that the DT
> > > > tooling with complain about, right?
> > > 
> > > And the MFD tree...
> > > 
> > > Please apply the LED bindings (patches 1 and 2) so we can get the
> > > existing warnings fixed and address any new warnings.
> > 
> > Who usually applies LED bindings?  Looks as though they're good to go.
> 
> Pavel. The issue would be I don't know if the driver side is ready and 
> those usually go together. Other than my complaining here, how's he 
> supposed to know that the bindings at least need to be applied?
> 
> Again, the process here is not working. I've said before, all the 
> bindings for an MFD need to go via 1 tree. You obviously don't agree, so 
> propose something. The current process of no coordination doesn't work.

The solution would be for someone to create succinct immutable branches, like
I do for real code.  If someone would be happy to do that, I'd be more than
happy to pull from them.

I go to the effort of creating them to prevent actual build breakages,
however doing so to keep a documentation helper script happy is a step
too far for me personally, sorry.

-- 
Lee Jones [李琼斯]