From: Lee Jones <lee@kernel.org>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: sashiko-bot@kernel.org, Mark Brown <broonie@kernel.org>,
sashiko-reviews@lists.linux.dev, robh@kernel.org,
mfd@lists.linux.dev, conor+dt@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH RESEND v6 4/5] mfd: axp20x: Add support for AXP318W PMIC
Date: Thu, 3 Sep 2026 10:03:28 +0100 [thread overview]
Message-ID: <20260903090328.GH2133376@google.com> (raw)
In-Reply-To: <1jld9j8pfg.fsf@starbuckisacylon.baylibre.com>
On Wed, 02 Sep 2026, Jerome Brunet wrote:
> On jeu. 27 août 2026 at 14:42, Lee Jones <lee@kernel.org> wrote:
>
> > On Fri, 14 Aug 2026, Jerome Brunet wrote:
> >
> >> On dim. 13 janv. 2008 at 11:56, Lee Jones <lee@kernel.org> wrote:
> >>
> >> > On Thu, 13 Aug 2026, Jerome Brunet wrote:
> >> >
> >> >> On sam. 12 janv. 2008 at 23:40, sashiko-bot@kernel.org wrote:
> >> >>
> >> >> > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> >> >> > - [High] The corresponding regulator driver lacks support for
> >> >> > `AXP318_ID`, causing the `axp20x-regulator` child device probe to fail.
> >> >>
> >> >> Funny sashiko did not pick up on this when v6 was first sent. This is an
> >> >> ordering problem. The regulator part should be applied before the mfd
> >> >> one.
> >> >>
> >> >> I could reorder here but there is not much point since the 2 changes will
> >> >> land in different subsystems but it does bring a valid question:
> >> >>
> >> >> Lee, Mark, are you OK with picking the patches indended for your
> >> >> subsystem or would you prefer that I split the series, regulator on one
> >> >> side, mfd on the other (with a dep on the regulator one, of course) ?
> >> >
> >> > Does this break existing devices or simply delay support for this new one?
> >>
> >> Existing device are fine and untouched.
> >>
> >> I've just checked and if someone tried to run without PATCH 5 (regulators),
> >> the main axp driver loads fine but the regulator part gives this
> >>
> >> axp20x-regulator axp20x-regulator.0: Unsupported AXP variant: 8
> >
> > Can you not enforce the deps with Kconfig?
>
> This is not a build problem so I do not think Kconfig will change
> anything here. There is no specific config per chip.
>
> It is just a runtime ordering matter and not a problem. regulator and
> mfd are split so at some point the support is incomplete.
>
> * MFD first, it is fine it just cant instantiate the regulator until it
> lands. it is (mostly) useless without it, which is fine.
> * Regulator first. regulator will never be instanciate until MFD support
> lands, just as useless.
Okay, this is normal. So there are no deps between them?
--
Lee Jones
next prev parent reply other threads:[~2026-09-03 9:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 21:30 [PATCH RESEND v6 0/5] regulator: Add X-Powers AXP318W PMIC support Jerome Brunet
2026-08-12 21:30 ` [PATCH RESEND v6 1/5] mfd: axp20x: Constify axp313 and axp717 cells Jerome Brunet
2026-08-12 21:37 ` sashiko-bot
2026-08-13 8:19 ` Jerome Brunet
2026-08-12 21:30 ` [PATCH RESEND v6 2/5] mfd: axp20x-i2c: Fix i2c instantiation Jerome Brunet
2026-08-12 21:41 ` sashiko-bot
2026-08-12 21:30 ` [PATCH RESEND v6 3/5] dt-bindings: mfd: x-powers,axp152: Document AXP318W Jerome Brunet
2026-08-12 21:37 ` sashiko-bot
2026-08-12 21:30 ` [PATCH RESEND v6 4/5] mfd: axp20x: Add support for AXP318W PMIC Jerome Brunet
2026-08-12 21:40 ` sashiko-bot
2026-08-13 8:29 ` Jerome Brunet
2026-08-13 9:56 ` Lee Jones
2026-08-14 13:41 ` Jerome Brunet
2026-08-27 13:42 ` Lee Jones
2026-09-02 18:43 ` Jerome Brunet
2026-09-03 9:03 ` Lee Jones [this message]
2026-09-03 12:41 ` Jerome Brunet
2026-08-23 13:17 ` Chen-Yu Tsai
2026-09-02 18:46 ` Jerome Brunet
2026-09-03 17:11 ` Chen-Yu Tsai
2026-08-12 21:30 ` [PATCH RESEND v6 5/5] regulator: axp20x: add support for the AXP318W Jerome Brunet
2026-08-12 21:37 ` sashiko-bot
2026-08-23 15:04 ` Chen-Yu Tsai
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=20260903090328.GH2133376@google.com \
--to=lee@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jbrunet@baylibre.com \
--cc=mfd@lists.linux.dev \
--cc=robh@kernel.org \
--cc=sashiko-bot@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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