linux-kernel - Re: [PATCH v12 1/9] dt-bindings: mmc: Add Cavium SOCs MMC bindings

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:   Fri, 17 Mar 2017 09:31:23 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Jan Glauber <jglauber@...ium.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>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        David Daney <david.daney@...ium.com>
Subject: Re: [PATCH v12 1/9] dt-bindings: mmc: Add Cavium SOCs MMC bindings

On 10 March 2017 at 14:24, Jan Glauber <jglauber@...ium.com> wrote:
> Add description of Cavium Octeon and ThunderX SOC device tree bindings.
>
> CC: Ulf Hansson <ulf.hansson@...aro.org>
> CC: Rob Herring <robh+dt@...nel.org>
> CC: Mark Rutland <mark.rutland@....com>
> CC: devicetree@...r.kernel.org
>
> Signed-off-by: Jan Glauber <jglauber@...ium.com>
> Signed-off-by: David Daney <david.daney@...ium.com>
> Signed-off-by: Steven J. Hill <steven.hill@...ium.com>
> Acked-by: Rob Herring <robh+dt@...nel.org>
> ---
>  .../devicetree/bindings/mmc/cavium-mmc.txt         | 58 ++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mmc/cavium-mmc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/cavium-mmc.txt b/Documentation/devicetree/bindings/mmc/cavium-mmc.txt
> new file mode 100644
> index 0000000..225c2be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/cavium-mmc.txt
> @@ -0,0 +1,58 @@
> +* Cavium Octeon & ThunderX MMC controller
> +
> +The highspeed MMC host controller on Caviums SoCs provides an interface
> +for MMC and SD types of memory cards.
> +
> +Supported maximum speeds are the ones of the eMMC standard 4.41 as well
> +as the speed of SD standard 4.0. Only 3.3 Volt is supported.
> +
> +Required properties:
> + - compatible : should be one of:
> +   cavium,octeon-6130-mmc
> +   cavium,octeon-6130-mmc-slot
> +   cavium,octeon-7890-mmc
> +   cavium,octeon-7890-mmc-slot
> +   cavium,thunder-8190-mmc
> +   cavium,thunder-8190-mmc-slot
> +   cavium,thunder-8390-mmc
> +   cavium,thunder-8390-mmc-slot
> + - reg : mmc controller base registers
> + - clocks : phandle
> +
> +Optional properties:
> + - for cd, bus-width and additional generic mmc parameters
> +   please refer to mmc.txt within this directory
> + - cavium,cmd-clk-skew : number of coprocessor clocks before sampling command
> + - cavium,dat-clk-skew : number of coprocessor clocks before sampling data
> +
> +Deprecated properties:
> +- spi-max-frequency : use max-frequency instead
> +- cavium,bus-max-width : use bus-width instead
> +
> +Examples:
> +       mmc_1_4: mmc@1,4 {
> +               compatible = "cavium,thunder-8390-mmc";
> +               reg = <0x0c00 0 0 0 0>; /* DEVFN = 0x0c (1:4) */
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +               clocks = <&sclk>;
> +
> +               mmc-slot@0 {
> +                       compatible = "cavium,thunder-8390-mmc-slot";
> +                       reg = <0>;

Just realized that I forgotten to follow up about the details for I
think we should generally describe slots nodes in DT.

Currently we treat a child node of a host device node, with reg=0 as
being an embedded mmc card [1] (in case it has the "mmc-card"
compatible set).
When reg is 1->7, those are reserved for SDIO function nodes [2] (as
those can be exactly 7, according to the SDIO spec).

Let's take the above into account and consider that a slot node may
also require a its own child node as to describe an embedded mmc card
or SDIO funcs. In this context I don't think it makes sense to use SoC
specific compatibles for slot nodes, instead I suggest we use only
"mmc-slot".

Does that makes sense?

> +                       vmmc-supply = <&mmc_supply_3v3>;
> +                       max-frequency = <42000000>;
> +                       bus-width = <4>;
> +                       cap-sd-highspeed;
> +               };
> +
> +               mmc-slot@1 {
> +                       compatible = "cavium,thunder-8390-mmc-slot";
> +                       reg = <1>;
> +                       vmmc-supply = <&mmc_supply_3v3>;
> +                       max-frequency = <42000000>;
> +                       bus-width = <8>;
> +                       cap-mmc-highspeed;
> +                       non-removable;
> +               };
> +       };
> --
> 2.9.0.rc0.21.g7777322
>

Kind regards
Uffe