From patchwork Fri Jul 20 11:30:48 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dirk Behme X-Patchwork-Id: 1220391 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 6B865DF24C for ; Fri, 20 Jul 2012 11:38:51 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SsBUC-0000qO-Dd; Fri, 20 Jul 2012 11:35:08 +0000 Received: from smtp2-v.fe.bosch.de ([139.15.237.6]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1SsBSe-0000dR-Hf for linux-arm-kernel@lists.infradead.org; Fri, 20 Jul 2012 11:33:36 +0000 Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.30]) by imta24.fe.bosch.de (Postfix) with ESMTP id 85981B00212; Fri, 20 Jul 2012 13:33:27 +0200 (CEST) Received: from localhost (vsgw4.fe.internet.bosch.com [10.4.98.12]) by vsmta13.fe.internet.bosch.com (Postfix) with SMTP id 7A65E384032F; Fri, 20 Jul 2012 13:33:27 +0200 (CEST) Received: from FE-HUB1001.de.bosch.com (10.4.103.109) by si-hub04.de.bosch.com (10.3.153.46) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 20 Jul 2012 13:33:21 +0200 Received: from [10.34.217.145] (10.34.217.145) by FE-HUB1001.de.bosch.com (10.4.103.109) with Microsoft SMTP Server id 14.2.309.2; Fri, 20 Jul 2012 13:33:21 +0200 Message-ID: <50094168.2090900@de.bosch.com> Date: Fri, 20 Jul 2012 13:30:48 +0200 From: Dirk Behme Organization: Robert Bosch Car Multimedia GmbH User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jassi Brar , "linux-mmc@vger.kernel.org" Subject: Re: Devicetree: Initialization order of mmc block devices? References: <5006571A.7060103@de.bosch.com> <50068696.8070408@de.bosch.com> <5006C40D.300@de.bosch.com> In-Reply-To: X-Originating-IP: [10.34.217.145] X-Spam-Note: CRM114 invocation failed X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [139.15.237.6 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , "Wohlrab Knut \(CM-AI/PJ-CA31\)" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On 19.07.2012 22:45, Jassi Brar wrote: > On 18 July 2012 19:41, Knut Wohlrab wrote: >> On 07/18/2012 03:47 PM, Jassi Brar wrote: >>> On 18 July 2012 15:19, Knut Wohlrab wrote: >>> >>>> If a SD card is inserted at boot time, its "mmcblk0", the embedded >>>> MMC (eMMC) device "mmcblk1". This makes it difficult to give the kernel >>>> the >>>> correct device for the eMMC root file system ("root=/dev/mmcblk?p1 ..."). >>>> >>> How about root=UUID= ? >> Because we are talking about an embedded device, it is very difficult to get >> a UUID of a eMMC partition into kernel command line with U-Boot. Handling of >> UUID is also a big effort at board manufacturing. >> > I don't realize how bad is it if a common UUID is used on each cloned > eMMC(non-removable) of every instance of a device. But of course only > you know what's best for your product. > >> This problem can occur on many devices with embedded MMC and removable SD, >> e.g. smart phones. So I think we should find an solution to define MMC scan >> order or device number/name in a device tree. >> > I assume your issue is that due to async nature of mmc scanning, the > eMMC is detected later than external card, despite being the probe for > eMMC's slot initiated first ? > If so, we can do by simply associating 'N' of 'mmcblkN' with the slot > index i.e, mmc_host.index (instead of mmc_blk_data.name_idx). Which is > always in the order of probe calling. And we don't need to modify, or > expect more of, DT for that. Do you mean something like set_capacity(md->disk, size); ? A first quick test looks promising. We will go on testing this. > Though I suspect there must be some > serious reason why it's not already done that way. Anybody with an idea? Any serious reason? Many thanks and best regards Dirk diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -1536,7 +1536,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, */ snprintf(md->disk->disk_name, sizeof(md->disk->disk_name), - "mmcblk%d%s", md->name_idx, subname ? subname : ""); + "mmcblk%d%s", card->host->index, subname ? subname : ""); blk_queue_logical_block_size(md->queue.queue, 512);