Re: [PATCH RESEND v6 4/5] mfd: axp20x: Add support for AXP318W PMIC

[Lee Jones <lee@kernel.org>]

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?

> 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