linux-kernel - Re: [PATCH v10 0/8] Cavium MMC driver

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:   Thu, 19 Jan 2017 09:47:33 -0800
From:   David Daney <ddaney@...iumnetworks.com>
To:     Jan Glauber <jan.glauber@...iumnetworks.com>,
        Ulf Hansson <ulf.hansson@...aro.org>
CC:     "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Steven J . Hill" <Steven.Hill@...ium.com>
Subject: Re: [PATCH v10 0/8] Cavium MMC driver

On 01/19/2017 06:50 AM, Jan Glauber wrote:
[...]
>
>> 4) GPIO powers should be modelled as GPIO regulators. I believe we
>> have discussed this earlier as well (I don't really recall in detail
>> about the last things). It gives us the opportunity to via the
>> regulator framework to find out the supported voltage levels. This is
>> the generic method which is used by mmc drivers, you need to adopt to
>> this as well.
>
> I've added a fixed regulator to DT:
>
>         vcc_3v3: regulator-vcc_3v3 {
>                 compatible = "regulator-fixed";
>                 regulator-name = "VCC_3V3";

Very minor point not really directly related to the MMC driver: 
"VCC_3V3" implies a general purpose supply for many things on the board. 
  This is not the case for these boards.  The "regulator" controls power 
only to eMMC and SD devices, so a name that conveys that function should 
be invented.

Actually on some boards GPIO 8 doesn't even control a regulator, but 
instead only activates a bus isolator on the control and data signals to 
the eMMC and SD devices.  In this case we would be using the regulator 
framework only because the code is already there and it happens to work, 
not because we actually have a regulator.

>                 regulator-min-microvolt = <3300000>;
>                 regulator-max-microvolt = <3300000>;
>
>                 gpio = <&gpio_6_0 8 0>;
>                 /* enable-gpio = <&gpio_6_0 8 0>; */
>                 enable-active-high;
>         };
>
> This seems to enable the gpio. Is this sufficient or do I need the
> gpio-regulator?
>

Does the "regulator-fixed" allow us to properly turn it on and off?

If not, we may have to switch to "gpio-regulator".  Which ever is 
simplest should be used.

[...]