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

From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Douglas Anderson <dianders@chromium.org>,
	Mark Brown <broonie@kernel.org>
Cc: mka@chromium.org, Liam Girdwood <lgirdwood@gmail.com>,
	Saravana Kannan <saravanak@google.com>,
	dmitry.torokhov@gmail.com, linux-kernel@vger.kernel.org,
	swboyd@chromium.org, briannorris@chromium.org
Subject: Re: [PATCH 0/7] regulator: Set PROBE_PREFER_ASYNCHRONOUS for everything in drivers/regulator
Date: Sun, 19 Mar 2023 15:28:18 +0200	[thread overview]
Message-ID: <e32ae8d1-f0e4-5434-49e0-c19701967b24@gmail.com> (raw)
In-Reply-To: <20230316195444.3946980-1-dianders@chromium.org>

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! ~~