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  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:   Thu, 13 Apr 2017 23:46:15 +0300
From:   Leonard Crestez <>
To:     Mark Brown <>
CC:     Sascha Hauer <>,
        Liam Girdwood <>,
        Viresh Kumar <>,
        "Rafael J. Wysocki" <>,
        Shawn Guo <>,
        Robin Gong <>,
        Anson Huang <>,
        Irina Tirdea <>,
        Rob Herring <>,
        Mark Rutland <>,
        Fabio Estevam <>,
        "Octavian Purdila" <>,
        <>, <>,
        <>, <>
Subject: Re: [RFC 4/8] regulator: core: Check enabling bypass respects

On Fri, 2017-04-07 at 12:22 +0100, Mark Brown wrote:
> On Fri, Apr 07, 2017 at 01:51:52PM +0300, Leonard Crestez wrote:

> > It currently seems to work how I expect but from your statement it's
> > not clear if it's entirely intentional.

> The current behaviour of bypassed regulators is intentional.

I did not mean to imply that there is something wrong with bypassed
regulators. I just wanted more information about how regulators (non-
bypassed) pick their voltage when consumers allow a range.

After some more reading through the code it seems that the driver
itself receives the range (either through set_voltage or map_voltage)
and gets to make the choice.

So it seems fine for my concerns, sorry to bother you.


Powered by blists - more mailing lists