Devicetree
 help / color / mirror / Atom feed
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

  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