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 22:38:05 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Jan Glauber <jan.glauber@...iumnetworks.com>
Cc:     "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        David Daney <ddaney@...iumnetworks.com>,
        "Steven J . Hill" <Steven.Hill@...ium.com>
Subject: Re: [PATCH v10 0/8] Cavium MMC driver

[...]

> I've added a fixed regulator to DT:
>
>         vcc_3v3: regulator-vcc_3v3 {
>                 compatible = "regulator-fixed";
>                 regulator-name = "VCC_3V3";
>                 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?

Looks good to me.

[...]

>> > In porting the driver to arm64 I run into some issues.
>> >
>> > 1. mmc_parse_of is not capable of supporting multiple slots behind one
>> >    controller. On arm64 the host controller is presented as one PCI device.
>> >    There are no devices per slot as with the platform variant, so I
>> >    needed to create dummy devices to make mmc_parse_of work.
>> >    IMHO it would be cleaner if mmc_parse_of could be extended to cover
>> >    the multiple slots case.
>>
>> Yes. I agree that this make sense!
>> Seems like we could try to make use of the struct device_node instead
>> of the struct device.
>>
>> I will try to come up with an idea, I keep you posted.
>>
>> >
>> > 2. Without setting MMC_CAP_1_8V_DDR DDR mode is not usable for eMMC.
>> >    I would prefer to introduce a new cap flag, MMC_CAP_3_3V_DDR,
>> >    if possible. Currently I need to add "mmc-ddr-1_8v" to DTS,
>> >    which seems odd for a 3.3v only host controller.
>>
>> This keep coming back. Both DT bindings and changing to the mmc core
>> has been posted.
>>
>> Allow me to help out and re-post a new series. You can build on top of
>> them - I will keep you on cc.
>
> Any news here? Can you give me a pointer?

For 1), I need some more time. Feel free to try it out your self.

For 2), I am working on it. Likely in the beginning of next week I
will post something.

[...]

Kind regards
Uffe