linux-kernel - Re: [RFC 1/2] mmc: read mmc alias from device tree

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: <CAD=FV=VF55LhuALjRSGT7KuzEACnAM0A6ThuPjXBkxEcyWij5A@mail.gmail.com>
Date:	Fri, 13 Mar 2015 13:08:55 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	stefan@...er.ch
Cc:	Chris Ball <chris@...ntf.net>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [RFC 1/2] mmc: read mmc alias from device tree

Hi,

On Tue, Apr 1, 2014 at 1:35 PM,  <stefan@...er.ch> wrote:
> From: Stefan Agner <stefan@...er.ch>
>
> To get the SD/MMC host device ID, read the alias from the device
> tree.
>
> This is useful in case a SoC has multipe SD/MMC host controllers while
> the second controller should logically be the first device (e.g. if
> the second controller is connected to an internal eMMC). Combined
> with block device numbering using MMC/SD host device ID, this
> results in predictable name assignment of the internal eMMC block
> device.
>
> Signed-off-by: Stefan Agner <stefan@...er.ch>
> ---
>  drivers/mmc/core/host.c | 24 +++++++++++++++++++-----
>  1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 49bc403..29f44cf 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -448,8 +448,8 @@ EXPORT_SYMBOL(mmc_of_parse);
>   */
>  struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
>  {
> -       int err;
>         struct mmc_host *host;
> +       int of_id = -1, id = -1;
>
>         host = kzalloc(sizeof(struct mmc_host) + extra, GFP_KERNEL);
>         if (!host)
> @@ -459,12 +459,26 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
>         host->rescan_disable = 1;
>         idr_preload(GFP_KERNEL);
>         spin_lock(&mmc_host_lock);
> -       err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
> -       if (err >= 0)
> -               host->index = err;
> +
> +       if (dev->of_node)
> +               of_id = of_alias_get_id(dev->of_node, "mmc");

Not that there's much chance of such an old patch landing, but just in
case anyone finds this Dmitry points out that this causes a
"scheduling while atomic".  A fix is to move the "of_alias_get_id" up
above the spin_lock():

https://chromium-review.googlesource.com/#/c/259916/

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/