From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Shawn Guo <shawn.guo@linaro.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Ulf Hansson <ulf.hansson@linaro.org>
Subject: [PATCH 4.9 13/20] mmc: sdhci: Map more voltage level to SDHCI_POWER_330
Date: Mon, 1 Nov 2021 10:17:22 +0100 [thread overview]
Message-ID: <20211101082446.973736022@linuxfoundation.org> (raw)
In-Reply-To: <20211101082444.133899096@linuxfoundation.org>
From: Shawn Guo <shawn.guo@linaro.org>
commit 4217d07b9fb328751f877d3bd9550122014860a2 upstream.
On Thundercomm TurboX CM2290, the eMMC OCR reports vdd = 23 (3.5 ~ 3.6 V),
which is being treated as an invalid value by sdhci_set_power_noreg().
And thus eMMC is totally broken on the platform.
[ 1.436599] ------------[ cut here ]------------
[ 1.436606] mmc0: Invalid vdd 0x17
[ 1.436640] WARNING: CPU: 2 PID: 69 at drivers/mmc/host/sdhci.c:2048 sdhci_set_power_noreg+0x168/0x2b4
[ 1.436655] Modules linked in:
[ 1.436662] CPU: 2 PID: 69 Comm: kworker/u8:1 Tainted: G W 5.15.0-rc1+ #137
[ 1.436669] Hardware name: Thundercomm TurboX CM2290 (DT)
[ 1.436674] Workqueue: events_unbound async_run_entry_fn
[ 1.436685] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.436692] pc : sdhci_set_power_noreg+0x168/0x2b4
[ 1.436698] lr : sdhci_set_power_noreg+0x168/0x2b4
[ 1.436703] sp : ffff800010803a60
[ 1.436705] x29: ffff800010803a60 x28: ffff6a9102465f00 x27: ffff6a9101720a70
[ 1.436715] x26: ffff6a91014de1c0 x25: ffff6a91014de010 x24: ffff6a91016af280
[ 1.436724] x23: ffffaf7b1b276640 x22: 0000000000000000 x21: ffff6a9101720000
[ 1.436733] x20: ffff6a9101720370 x19: ffff6a9101720580 x18: 0000000000000020
[ 1.436743] x17: 0000000000000000 x16: 0000000000000004 x15: ffffffffffffffff
[ 1.436751] x14: 0000000000000000 x13: 00000000fffffffd x12: ffffaf7b1b84b0bc
[ 1.436760] x11: ffffaf7b1b720d10 x10: 000000000000000a x9 : ffff800010803a60
[ 1.436769] x8 : 000000000000000a x7 : 000000000000000f x6 : 00000000fffff159
[ 1.436778] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff
[ 1.436787] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6a9101718d80
[ 1.436797] Call trace:
[ 1.436800] sdhci_set_power_noreg+0x168/0x2b4
[ 1.436805] sdhci_set_ios+0xa0/0x7fc
[ 1.436811] mmc_power_up.part.0+0xc4/0x164
[ 1.436818] mmc_start_host+0xa0/0xb0
[ 1.436824] mmc_add_host+0x60/0x90
[ 1.436830] __sdhci_add_host+0x174/0x330
[ 1.436836] sdhci_msm_probe+0x7c0/0x920
[ 1.436842] platform_probe+0x68/0xe0
[ 1.436850] really_probe.part.0+0x9c/0x31c
[ 1.436857] __driver_probe_device+0x98/0x144
[ 1.436863] driver_probe_device+0xc8/0x15c
[ 1.436869] __device_attach_driver+0xb4/0x120
[ 1.436875] bus_for_each_drv+0x78/0xd0
[ 1.436881] __device_attach_async_helper+0xac/0xd0
[ 1.436888] async_run_entry_fn+0x34/0x110
[ 1.436895] process_one_work+0x1d0/0x354
[ 1.436903] worker_thread+0x13c/0x470
[ 1.436910] kthread+0x150/0x160
[ 1.436915] ret_from_fork+0x10/0x20
[ 1.436923] ---[ end trace fcfac44cb045c3a8 ]---
Fix the issue by mapping MMC_VDD_35_36 (and MMC_VDD_34_35) to
SDHCI_POWER_330 as well.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211004024935.15326-1-shawn.guo@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1421,6 +1421,12 @@ void sdhci_set_power_noreg(struct sdhci_
break;
case MMC_VDD_32_33:
case MMC_VDD_33_34:
+ /*
+ * 3.4 ~ 3.6V are valid only for those platforms where it's
+ * known that the voltage range is supported by hardware.
+ */
+ case MMC_VDD_34_35:
+ case MMC_VDD_35_36:
pwr = SDHCI_POWER_330;
break;
default:
next prev parent reply other threads:[~2021-11-01 9:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 9:17 [PATCH 4.9 00/20] 4.9.289-rc1 review Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 01/20] ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 02/20] ARM: 9134/1: remove duplicate memcpy() definition Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 03/20] ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 04/20] powerpc/bpf: Fix BPF_MOD when imm == 1 Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 05/20] ARM: 8819/1: Remove -p from LDFLAGS Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 06/20] usbnet: sanity check for maxpacket Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 07/20] usbnet: fix error return code in usbnet_probe() Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 08/20] ata: sata_mv: Fix the error handling of mv_chip_id() Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 09/20] nfc: port100: fix using -ERRNO as command type mask Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 10/20] Revert "net: mdiobus: Fix memory leak in __mdiobus_register" Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 11/20] mmc: vub300: fix control-message timeouts Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 12/20] mmc: dw_mmc: exynos: fix the finding clock sample value Greg Kroah-Hartman
2021-11-01 9:17 ` Greg Kroah-Hartman [this message]
2021-11-01 9:17 ` [PATCH 4.9 14/20] net: lan78xx: fix division by zero in send path Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 15/20] regmap: Fix possible double-free in regcache_rbtree_exit() Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 16/20] net: batman-adv: fix error handling Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 17/20] nios2: Make NIOS2_DTB_SOURCE_BOOL depend on !COMPILE_TEST Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 18/20] net: nxp: lpc_eth.c: avoid hang when bringing interface down Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 19/20] sctp: use init_tag from inithdr for ABORT chunk Greg Kroah-Hartman
2021-11-01 9:17 ` [PATCH 4.9 20/20] sctp: add vtag check in sctp_sf_violation Greg Kroah-Hartman
2021-11-01 21:22 ` [PATCH 4.9 00/20] 4.9.289-rc1 review Shuah Khan
2021-11-01 23:35 ` Guenter Roeck
2021-11-02 8:36 ` Naresh Kamboju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211101082446.973736022@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=adrian.hunter@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shawn.guo@linaro.org \
--cc=stable@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox