From patchwork Thu Apr 28 23:06:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 8975841 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 9ABDA9F441 for ; Thu, 28 Apr 2016 23:07:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BAFA620251 for ; Thu, 28 Apr 2016 23:07:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C91342026C for ; Thu, 28 Apr 2016 23:07:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752236AbcD1XHu (ORCPT ); Thu, 28 Apr 2016 19:07:50 -0400 Received: from mail-pf0-f169.google.com ([209.85.192.169]:33761 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752758AbcD1XHf (ORCPT ); Thu, 28 Apr 2016 19:07:35 -0400 Received: by mail-pf0-f169.google.com with SMTP id 206so39970365pfu.0 for ; Thu, 28 Apr 2016 16:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Kr3OmQpYNyA5/t+78k45VOiF1SbfhDKe63dfkm8Ebno=; b=cIYuzaiJasaN4Vv95lweUDX9dGXx0AJgNwM98UNGrTUoU3jMaa//oK/Hvgya2BKO/U i+C1uNl8rTlKk4u5jeVDsxBLNsQW/Q2PksxawLrZyJzk+sWkGDEMpMIXI3+FyhnRWNfa qb96vhEucN9K9D9gmcK8afOrACQ+a1yR5APbg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Kr3OmQpYNyA5/t+78k45VOiF1SbfhDKe63dfkm8Ebno=; b=PY02Bozn3bPqLnq6ddAkBBLg3yONANwLeC0ZmpUZgSisRDt150FSUuxfiGvjO+G0lS 5+GeJ1Wb9bh8wO/ELcRjTkyomHFvSo5NVukIicsEOEMuDiGHh/CsAxrniEpescKuiFpX MNQVFOJDEnK7lqjYyTdKqX50r+/59xDNZFciSaZsZr+a8d7djwlZ5/Zxll8zLxeeGyIC BrVUj2nU3URRhxTE5DnufPQut6i7cwX/iShwKOtDcz7SYlrlX04+kiRQficie+n9l5dw kdotL2FakuAI3/vse2uSD4kSa6uW2UdGpuOoyZbq439SjXD2mWR5gHCqqFumQ2KYUbVj FBOw== X-Gm-Message-State: AOPr4FVeVyCdJbaFdZNtpl2JbAFHYc2cimFWs3FZt6SKeFm2pD6mMWdicj+sqL1VncsFlA== X-Received: by 10.98.51.2 with SMTP id z2mr24519451pfz.118.1461884855086; Thu, 28 Apr 2016 16:07:35 -0700 (PDT) Received: from tictac.mtv.corp.google.com ([172.22.65.76]) by smtp.gmail.com with ESMTPSA id lg8sm103564pab.48.2016.04.28.16.07.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 16:07:34 -0700 (PDT) From: Douglas Anderson To: ulf.hansson@linaro.org, jh80.chung@samsung.com Cc: shawn.lin@rock-chips.com, adrian.hunter@intel.com, stefan@agner.ch, linux-mmc@vger.kernel.org, computersforpeace@gmail.com, dmitry.torokhov@gmail.com, Douglas Anderson , justin.wang@spreadtrum.com, huangtao@rock-chips.com, lporzio@micron.com, ksumrall@android.com, jonathanh@nvidia.com, chuanxiao.dong@intel.com, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] mmc: use SD/MMC host ID for block device name ID Date: Thu, 28 Apr 2016 16:06:45 -0700 Message-Id: <1461884805-29466-4-git-send-email-dianders@chromium.org> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 In-Reply-To: <1461884805-29466-1-git-send-email-dianders@chromium.org> References: <1461884805-29466-1-git-send-email-dianders@chromium.org> Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Stefan Agner By using the SD/MMC host device ID as a starting point for block device numbering, one can reliably predict the first block device name (at least for the first controller). This is especially useful for SoCs with multiple SD/MMC host controller, where the controller with index 0 is connected to a eMMC device. Usually the first controller gets the first block device name ID, however this is not guaranteed. Also if the first controller is aliased as second controller and visa-versa (using device tree aliases), the block device name ID assignation is not ordered by the SD/MMC host device ID (since mmc_rescan is called in order of the memory mapped pheripherial addresses). Signed-off-by: Stefan Agner Signed-off-by: Douglas Anderson --- drivers/mmc/card/block.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 9fef7f04c4e6..bcf4fdbb5221 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -2215,7 +2215,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, * index anymore so we keep track of a name index. */ if (!subname) { - md->name_idx = find_first_zero_bit(name_use, max_devices); + md->name_idx = find_next_zero_bit(name_use, max_devices, + card->host->index); __set_bit(md->name_idx, name_use); } else md->name_idx = ((struct mmc_blk_data *)