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] [day] [month] [year] [list]
Date:   Wed, 29 Apr 2020 19:35:20 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>, linux-pm@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Thierry Reding <treding@...dia.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Todd Kjos <tkjos@...gle.com>, Len Brown <len.brown@...el.com>,
        Pavel Machek <pavel@....cz>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Kevin Hilman <khilman@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Rob Herring <robh@...nel.org>
Subject: Re: [PATCH] regulator: Revert "Use driver_deferred_probe_timeout for
 regulator_init_complete_work"

On Wed, Apr 29, 2020 at 06:27:01PM +0100, Mark Brown wrote:
> On Wed, Apr 29, 2020 at 05:23:49PM +0000, John Stultz wrote:
> > This reverts commit dca0b44957e5 ("regulator: Use
> > driver_deferred_probe_timeout for regulator_init_complete_work"),
> > as we ended up reverting the default deferred_probe_timeout
> > value back to zero, to preserve behavior with 5.6 we need to
> > decouple the regulator timeout which was previously 30 seconds.
> > 
> > This avoids breaking some systems that depend on the regulator
> > timeout but don't require the deferred probe timeout.
> 
> Reviewed-by: Mark Brown <broonie@...nel.org>
> 
> I'm assuming this should go via the same path that the other revert
> went.

I'll be glad to take it that way :)

thanks,

greg k-h

Powered by blists - more mailing lists