linux-kernel - [PATCH v2 4/6] mmc: core: Fixup storing of OCR for MMC_QUIRK_NONSTD

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <e7936cff7fc24d187ef2680d3b4edb0ade58f293.1636564631.git.hns@goldelico.com>
Date:   Wed, 10 Nov 2021 18:17:09 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Jérôme Pouiller 
        <jerome.pouiller@...abs.com>, Avri Altman <avri.altman@....com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Tony Lindgren <tony@...mide.com>,
        Bean Huo <beanhuo@...ron.com>,
        "H. Nikolaus Schaller" <hns@...delico.com>,
        Kiwoong Kim <kwmad.kim@...sung.com>,
        Tian Tao <tiantao6@...ilicon.com>,
        Andreas Kemnade <andreas@...nade.info>,
        Yang Li <abaci-bugfix@...ux.alibaba.com>
Cc:     notasas@...il.com, linux-mmc@...r.kernel.org,
        linux-kernel@...r.kernel.org, letux-kernel@...nphoenux.org,
        kernel@...a-handheld.com, linux-omap@...r.kernel.org
Subject: [PATCH v2 4/6] mmc: core: Fixup storing of OCR for MMC_QUIRK_NONSTD_SDIO

From: Ulf Hansson <ulf.hansson@...aro.org>

The mmc core takes a specific path to support initializing of a
non-standard SDIO card. This is triggered by looking for the card-quirk,
MMC_QUIRK_NONSTD_SDIO.

In mmc_sdio_init_card() this gets rather messy, as it causes the code to
bail out earlier, compared to the usual path. This leads to that the OCR
doesn't get saved properly in card->ocr. Fortunately, only omap_hsmmc has
been using the MMC_QUIRK_NONSTD_SDIO and is dealing with the issue, by
assigning a hardcoded value (0x80) to card->ocr from an ->init_card() ops.

To make the behaviour consistent, let's instead rely on the core to save
the OCR in card->ocr during initialization.

Reported-by: H. Nikolaus Schaller <hns@...delico.com>
Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
---
 drivers/mmc/core/sdio.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index cf8ee66990508..41164748723d2 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -709,6 +709,8 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 		host->ops->init_card(host, card);
 	mmc_fixup_device(card, sdio_card_init_methods);
 
+	card->ocr = ocr_card;
+
 	/*
 	 * If the host and card support UHS-I mode request the card
 	 * to switch to 1.8V signaling level.  No 1.8v signalling if
@@ -821,7 +823,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 			goto mismatch;
 		}
 	}
-	card->ocr = ocr_card;
+
 	mmc_fixup_device(card, sdio_fixup_methods);
 
 	if (card->type == MMC_TYPE_SD_COMBO) {
-- 
2.33.0