Re: [PATCH RESEND v6 4/5] mfd: axp20x: Add support for AXP318W PMIC
Jerome Brunet <[email protected]>
| Newsgroups | org.kernel.vger.linux-devicetree,dev.linux.lists.mfd,dev.linux.lists.sashiko-reviews |
|---|---|
| Message-ID | <[email protected]> |
On dim. 13 janv. 2008 at 11:56, Lee Jones <[email protected]> wrote: > On Thu, 13 Aug 2026, Jerome Brunet wrote: > >> On sam. 12 janv. 2008 at 23:40, [email protected] 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 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. -- Jerome