linux-kernel - Re: [PATCH v1 9/9] mmc: sdhci-of-arasan: Add UHS-1 support for Keem Bay SOC

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: <20210125213758.GA1026926@robh.at.kernel.org>
Date:   Mon, 25 Jan 2021 15:37:58 -0600
From:   Rob Herring <robh@...nel.org>
To:     Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@...el.com>
Cc:     ulf.hansson@...aro.org, broonie@...nel.org, lgirdwood@...il.com,
        devicetree@...r.kernel.org, adrian.hunter@...el.com,
        michal.simek@...inx.com, linux-mmc@...r.kernel.org,
        linux-kernel@...r.kernel.org, andriy.shevchenko@...el.com,
        Rashmi.A@...el.com, mahesh.r.vaidya@...el.com
Subject: Re: [PATCH v1 9/9] mmc: sdhci-of-arasan: Add UHS-1 support for Keem
 Bay SOC

On Thu, Jan 14, 2021 at 11:27:00PM +0800, Muhammad Husaini Zulkifli wrote:
> Keem Bay SOC can support dual voltage operations for GPIO SD pins to
> either 1.8V or 3.3V for bus IO line power. In order to operate the GPIOs
> line for Clk, Cmd and Data on Keem Bay hardware, it is important to
> configure the supplied voltage applied to their I/O Rail and the output
> of the I²C expander pin. Final Voltage applied on the GPIOs line are
> dependent by both supplied voltage rail and expander pin output as it is
> been set after passing through the voltage sense resistor.
> 
> Keem Bay hardware is somewhat unique in the way of how IO bus line
> voltage are been controlled.
> 
> Expander pin output is controlled by gpio-regulator. Voltage rail output
> is controlled by Keem Bay SD regulator. Keem Bay SD regulator encapsulated
> the Secure Monitor Calling Convention (SMCCC) to communicate with Trusted
> Firmware during set voltage operation.
> 
> Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@...el.com>
> Acked-by: Adrian Hunter <adrian.hunter@...el.com>
> Acked-by: Andy Shevchenko <andriy.shevchenko@...el.com>
> ---
>  drivers/mmc/host/sdhci-of-arasan.c | 263 +++++++++++++++++++++++++++++
>  1 file changed, 263 insertions(+)

> +	u32 otap_delay, sel_clk_buffer;
> +
> +	phys = of_parse_phandle(dev->of_node, "phys", 0);

Normally, you'd use the phy API here. Though not required from a DT 
perspective.

> +	if (!phys) {
> +		dev_err(dev, "Can't get phys for sd0\n");
> +		return -ENODEV;
> +	}
> +
> +	of_property_read_u32(phys, "intel,keembay-emmc-phy-otap-dly", &otap_delay);
> +	of_property_read_u32(phys, "intel,keembay-emmc-phy-sel-clkbuf", &sel_clk_buffer);

Not doucmented?

For property names, I'd leave out the SoC name. Might want to use it in 
the next chip.

Rob