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: 1220411 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 7C8B8DF24C for ; Fri, 20 Jul 2012 11:43:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751576Ab2GTLnu (ORCPT ); Fri, 20 Jul 2012 07:43:50 -0400 Received: from imta21.fe.bosch.de ([139.15.243.226]:51547 "EHLO imta21.fe.bosch.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751880Ab2GTLnu (ORCPT ); Fri, 20 Jul 2012 07:43:50 -0400 X-Greylist: delayed 576 seconds by postgrey-1.27 at vger.kernel.org; Fri, 20 Jul 2012 07:43:50 EDT Received: from smtp2-v.fe.bosch.de (imta24.fe.bosch.de [139.15.243.27]) by imta21.fe.bosch.de (Postfix) with ESMTP id C27DE2802D6 for ; Fri, 20 Jul 2012 13:34:13 +0200 (CEST) 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" CC: "Wohlrab Knut (CM-AI/PJ-CA31)" , "linux-arm-kernel@lists.infradead.org" , Arnd Bergmann 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] Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.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 --- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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);