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 <>
To:     Douglas Anderson <>,
        Mark Brown <>
Cc:, Liam Girdwood <>,
        Saravana Kannan <>,,,,
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" :)


	-- Matti

Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

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

Powered by blists - more mailing lists