Re: [PATCH 0/7] regulator: Set PROBE_PREFER_ASYNCHRONOUS for everything in drivers/regulator

[Matti Vaittinen]

Hi dee Ho peeps,

On 3/16/23 21:54, Douglas Anderson wrote:
> This series directly follows from the discussion when I tried to turn
> on PROBE_PREFER_ASYNCHRONOUS just for the fixed-regulator [1] and
> attempts to switch everything in drivers/regulator over to async
> probe.
>
> Like the similar patch series I did for the MMC subsystem a few years
> ago [2], I've split this patch series into batches corresponding to
> drivers corresponding to actively maintained stable kernel trees with
> the idea to break the patch series up somewhat.
>
> Most of the description of this series is contained in the first patch
> of the series and then the further patches simply refer back to the
> first one. The logic and reasoning behind all the patches is exactly
> the same.
>
> As talked about in the first patch, it wouldn't be at all shocking if
> this broke someone. Hopefully this doesn't cause too much of a
> problem. Most of the problems expected would be real underlying bugs
> that already existed and were just tickled by this change. If you're
> facing a problem, it's fairly easy to force individual drivers back to
> "synchronous" probing while the problem is tracked down and fixed.
>
> I am opting _not_ to CC every single person involved in each of these
> regulators on this patch series because I suspect that the mailing
> lists couldn't handle CCing that many people. This should be on LKML
> so hopefully people can find it there and respond to it that
> way. Anyone who responds will get CCed on future versions, if there
> are any.

The ROHM bd71837/47 (which is included in this series) as well as for 
the ROHM bd71815, bd71828, bd9576 and bd9573 (which are included in the 
other series) - there should be no PMIC internal dependencies to 
regulators. So, from my perspective this looks good.

Right after saying this - I don't have access to most of the boards 
using these PMICs - nor do I know what kind of system level issues there 
may be - hence my ack is not really worth much - but at least I can say: 
"Yes, bring em on - I am mentally prepared for the bug reports" :)

Thanks!

Yours,
	-- Matti


--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~