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 11:34:18 -0500
From:   Rob Herring <robh@kernel.org>
To:     Lee Jones <lee@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: <20220929163418.GA2270491-robh@kernel.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YzQSnuwPjzJIgsYq@google.com>
Precedence: bulk

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.

Rob