From: Jerome Brunet <jbrunet@baylibre.com>
To: Lee Jones <lee@kernel.org>
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: Wed, 02 Sep 2026 20:43:15 +0200 [thread overview]
Message-ID: <1jld9j8pfg.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <20260827134235.GN770273@google.com>
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.
IMO there is nothing to do here.
>
>> Seems sane enough if the regulator part is not present (and no board
>> using it has landed yet)
>>
>> To completly avoid this, the ID would need to be in its own patch,
>> then the regulators, finally the MFD. It seems like an unecessary churn
>> but I can do that if you prefer.
>
> --
> Lee Jones
--
Jerome
next prev parent reply other threads:[~2026-09-02 18:43 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 [this message]
2026-09-03 9:03 ` Lee Jones
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=1jld9j8pfg.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.