linux-kernel - Re: Removal of regulator-boot-on/always-on when a consumer exists

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]

Message-ID: <CAOMZO5CUrzCG_gpG2exKHJfq+-Yr5xbFGOASZ9B=MZoHxUQ3Hg@mail.gmail.com>
Date:   Mon, 26 Sep 2016 14:26:28 -0300
From:   Fabio Estevam <festevam@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Michael Trimarchi <michael@...rulasolutions.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Removal of regulator-boot-on/always-on when a consumer exists

On Mon, Sep 26, 2016 at 1:57 PM, Mark Brown <broonie@...nel.org> wrote:

> Like I say I can't give you a definitive answer on this without looking
> at the actual hardware and what it needs.  Based on what you're saying
> it sounds like it won't be an issue from the point of view of disrupting
> other users but without knowing the hardware I can't tell if the
> connected device can safely have power removed, sometimes devices don't
> like having only one of many supplies removed.

Ok, let me give you more details: we power the board with an external
5V power supply, then a discrete regulator generates 3.3V to the CAN
transceiver chip.

Software has no influence on this 3.3V rail, which stays powered as
long as the board is powered.

According to Documentation/devicetree/bindings/regulator/regulator.txt:

- regulator-always-on: boolean, regulator should never be disabled
- regulator-boot-on: bootloader/firmware enabled regulator

and the dts looks like:

       reg_3p3v: regulator-3p3v {
               compatible = "regulator-fixed";
               regulator-name = "3P3V";
               regulator-min-microvolt = <3300000>;
               regulator-max-microvolt = <3300000>;
               regulator-boot-on;
               regulator-always-on;
       };
};

&can1 {
       pinctrl-names = "default";
       pinctrl-0 = <&pinctrl_flexcan1>;
       xceiver-supply = <&reg_3p3v>;
};

The flexcan driver (which is the consumer of reg_3p3v) will call
regulator_disable() when can1 is not used. Calling regulator_disable
on reg_3p3v will not physically remove power from the 3.3V, so should
we use "regulator-always-on" or not in this case?

About "regulator-boot-on": since it was not the bootloader/firmware
that was responsible for enabling such regulator, I think this could
be removed from the dts.

Thanks for the clarification.