From: Jonathan Cameron <jic23@kernel.org>
To: Lee Jones <lee@kernel.org>
Cc: Rob Herring <robh@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
Date: Sat, 1 Oct 2022 18:11:17 +0100 [thread overview]
Message-ID: <20221001181117.7b3f3297@jic23-huawei> (raw)
In-Reply-To: <YzXbJM31s0P0nLD5@google.com>
On Thu, 29 Sep 2022 18:51:32 +0100
Lee Jones <lee@kernel.org> wrote:
> 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.
>
In this case the bindings include is included from the driver - not just the
binding. Obviously there are dances to get around that by using the values
and replacing in following cycle, but that's not the case here!
Jonathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-01 17:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 2:51 [PATCH v12 0/5] Add MediaTek MT6370 PMIC support ChiaEn Wu
2022-09-23 2:51 ` [PATCH v12 1/5] dt-bindings: leds: mt6370: Add MediaTek MT6370 current sink type LED indicator ChiaEn Wu
2022-09-23 2:51 ` [PATCH v12 2/5] dt-bindings: leds: Add MediaTek MT6370 flashlight ChiaEn Wu
2022-10-03 15:38 ` Rob Herring
2022-09-23 2:51 ` [PATCH v12 3/5] iio: adc: mt6370: Add MediaTek MT6370 support ChiaEn Wu
2022-09-24 14:55 ` Jonathan Cameron
2022-09-26 7:46 ` Lee Jones
2022-09-26 15:06 ` Rob Herring
2022-09-28 9:23 ` Lee Jones
2022-09-29 16:34 ` Rob Herring
2022-09-29 17:51 ` Lee Jones
2022-10-01 17:11 ` Jonathan Cameron [this message]
2022-10-03 7:38 ` Lee Jones
2022-09-23 2:51 ` [PATCH v12 4/5] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support ChiaEn Wu
2022-09-23 2:51 ` [PATCH v12 5/5] leds: flash: mt6370: Add MediaTek MT6370 flashlight support ChiaEn Wu
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=20221001181117.7b3f3297@jic23-huawei \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=alice_chen@richtek.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chiaen_wu@richtek.com \
--cc=cy_huang@richtek.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=pavel@ucw.cz \
--cc=peterwu.pub@gmail.com \
--cc=robh@kernel.org \
--cc=szunichen@gmail.com \
/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).