1. 09 Mar, 2021 3 commits
    • Frank Li's avatar
      mmc: cqhci: Fix random crash when remove mmc module/card · f06391c4
      Frank Li authored
      [ 6684.493350] Unable to handle kernel paging request at virtual address ffff800011c5b0f0
      [ 6684.498531] mmc0: card 0001 removed
      [ 6684.501556] Mem abort info:
      [ 6684.509681]   ESR = 0x96000047
      [ 6684.512786]   EC = 0x25: DABT (current EL), IL = 32 bits
      [ 6684.518394]   SET = 0, FnV = 0
      [ 6684.521707]   EA = 0, S1PTW = 0
      [ 6684.524998] Data abort info:
      [ 6684.528236]   ISV = 0, ISS = 0x00000047
      [ 6684.532986]   CM = 0, WnR = 1
      [ 6684.536129] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081b22000
      [ 6684.543923] [ffff800011c5b0f0] pgd=00000000bffff003, p4d=00000000bffff003, pud=00000000bfffe003, pmd=00000000900e1003, pte=0000000000000000
      [ 6684.557915] Internal error: Oops: 96000047 [#1] PREEMPT SMP
      [ 6684.564240] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes crct10dif_ce flexcan can_dev caam error [last unloaded: mmc_core]
      [ 6684.587281] CPU: 0 PID: 79138 Comm: kworker/0:3H Not tainted 5.10.9-01410-g3ba33182767b-dirty #10
      [ 6684.596160] Hardware name: Freescale i.MX8DXL EVK (DT)
      [ 6684.601320] Workqueue: kblockd blk_mq_run_work_fn
      
      [ 6684.606094] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
      [ 6684.612286] pc : cqhci_request+0x148/0x4e8 [cqhci]
      ^GMessage from syslogd@  at Thu Jan  1 01:51:24 1970 ...[ 6684.617085] lr : cqhci_request+0x314/0x4e8 [cqhci]
      [ 6684.626734] sp : ffff80001243b9f0
      [ 6684.630049] x29: ffff80001243b9f0 x28: ffff00002c3dd000
      [ 6684.635367] x27: 0000000000000001 x26: 0000000000000001
      [ 6684.640690] x25: ffff00002c451000 x24: 000000000000000f
      [ 6684.646007] x23: ffff000017e71c80 x22: ffff00002c451000
      [ 6684.651326] x21: ffff00002c0f3550 x20: ffff00002c0f3550
      [ 6684.656651] x19: ffff000017d46880 x18: ffff00002cea1500
      [ 6684.661977] x17: 0000000000000000 x16: 0000000000000000
      [ 6684.667294] x15: 000001ee628e3ed1 x14: 0000000000000278
      [ 6684.672610] x13: 0000000000000001 x12: 0000000000000001
      [ 6684.677927] x11: 0000000000000000 x10: 0000000000000000
      [ 6684.683243] x9 : 000000000000002b x8 : 0000000000001000
      [ 6684.688560] x7 : 0000000000000010 x6 : ffff00002c0f3678
      [ 6684.693886] x5 : 000000000000000f x4 : ffff800011c5b000
      [ 6684.699211] x3 : 000000000002d988 x2 : 0000000000000008
      [ 6684.704537] x1 : 00000000000000f0 x0 : 0002d9880008102f
      [ 6684.709854] Call trace:
      [ 6684.712313]  cqhci_request+0x148/0x4e8 [cqhci]
      [ 6684.716803]  mmc_cqe_start_req+0x58/0x68 [mmc_core]
      [ 6684.721698]  mmc_blk_mq_issue_rq+0x460/0x810 [mmc_block]
      [ 6684.727018]  mmc_mq_queue_rq+0x118/0x2b0 [mmc_block]
      
      The problem occurs when cqhci_request() get called after cqhci_disable() as
      it leads to access of allocated memory that has already been freed. Let's
      fix the problem by calling cqhci_disable() a bit later in the remove path.
      Signed-off-by: default avatarFrank Li <Frank.Li@nxp.com>
      Diagnosed-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Link: https://lore.kernel.org/r/20210303174248.542175-1-Frank.Li@nxp.com
      Fixes: f690f440 ("mmc: mmc: Enable CQE's")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      f06391c4
    • Adrian Hunter's avatar
      mmc: core: Fix partition switch time for eMMC · 66fbaccc
      Adrian Hunter authored
      Avoid the following warning by always defining partition switch time:
      
       [    3.209874] mmc1: unspecified timeout for CMD6 - use generic
       [    3.222780] ------------[ cut here ]------------
       [    3.233363] WARNING: CPU: 1 PID: 111 at drivers/mmc/core/mmc_ops.c:575 __mmc_switch+0x200/0x204
      Reported-by: default avatarPaul Fertser <fercerpav@gmail.com>
      Fixes: 1c447116 ("mmc: mmc: Fix partition switch timeout for some eMMCs")
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Link: https://lore.kernel.org/r/168bbfd6-0c5b-5ace-ab41-402e7937c46e@intel.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      66fbaccc
    • Yann Gautier's avatar
      mmc: mmci: Add MMC_CAP_NEED_RSP_BUSY for the stm32 variants · 774514bf
      Yann Gautier authored
      An issue has been observed on STM32MP157C-EV1 board, with an erase command
      with secure erase argument, ending up waiting for ~4 hours before timeout.
      
      The requested busy timeout from the mmc core ends up with 14784000ms (~4
      hours), but the supported host->max_busy_timeout is 86767ms, which leads to
      that the core switch to use an R1 response in favor of the R1B and polls
      for busy with the host->card_busy() ops. In this case the polling doesn't
      work as expected, as we never detects that the card stops signaling busy,
      which leads to the following message:
      
       mmc1: Card stuck being busy! __mmc_poll_for_busy
      
      The problem boils done to that the stm32 variants can't use R1 responses in
      favor of R1B responses, as it leads to an internal state machine in the
      controller to get stuck. To continue to process requests, it would need to
      be reset.
      
      To fix this problem, let's set MMC_CAP_NEED_RSP_BUSY for the stm32 variant,
      which prevent the mmc core from switching to R1 responses. Additionally,
      let's cap the cmd->busy_timeout to the host->max_busy_timeout, thus rely on
      86767ms to be sufficient (~66 seconds was need for this test case).
      
      Fixes: 94fe2580 ("mmc: core: Enable erase/discard/trim support for all mmc hosts")
      Signed-off-by: default avatarYann Gautier <yann.gautier@foss.st.com>
      Link: https://lore.kernel.org/r/20210225145454.12780-1-yann.gautier@foss.st.com
      Cc: stable@vger.kernel.org
      [Ulf: Simplified the code and extended the commit message]
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      774514bf
  2. 06 Mar, 2021 4 commits
  3. 05 Mar, 2021 33 commits