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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 19 Mar 2023 15:28:18 +0200
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Douglas Anderson <dianders@...omium.org>,
        Mark Brown <broonie@...nel.org>
Cc:     mka@...omium.org, Liam Girdwood <lgirdwood@...il.com>,
        Saravana Kannan <saravanak@...gle.com>,
        dmitry.torokhov@...il.com, linux-kernel@...r.kernel.org,
        swboyd@...omium.org, briannorris@...omium.org
Subject: Re: [PATCH 0/7] regulator: Set PROBE_PREFER_ASYNCHRONOUS for
 everything in drivers/regulator

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