1. 15 3月, 2018 1 次提交
  2. 18 12月, 2017 1 次提交
  3. 11 12月, 2017 16 次提交
  4. 23 11月, 2017 3 次提交
  5. 30 10月, 2017 6 次提交
    • A
      mmc: block: Prepare CQE data · 93482b3d
      Adrian Hunter 提交于
      Enhance mmc_blk_data_prep() to support CQE requests. That means adding
      some things that for non-CQE requests would be encoded into the command
      arguments - such as the block address, reliable-write flag, and data tag
      flag. Also the request tag is needed to provide the command queue task id,
      and a comment is added to explain the future possibility of defining a
      priority.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      93482b3d
    • A
      mmc: block: Use local variables in mmc_blk_data_prep() · d3377c01
      Adrian Hunter 提交于
      Use local variables in mmc_blk_data_prep() in preparation for adding CQE
      support which doesn't use the output variables.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d3377c01
    • A
      mmc: core: Introduce host claiming by context · 6c0cedd1
      Adrian Hunter 提交于
      Currently the host can be claimed by a task.  Change this so that the host
      can be claimed by a context that may or may not be a task.  This provides
      for the host to be claimed by a block driver queue to support blk-mq, while
      maintaining compatibility with the existing use of mmc_claim_host().
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6c0cedd1
    • L
      mmc: block: Fix bug when removing RPMB chardev · 1c87f735
      Linus Walleij 提交于
      I forgot to account for the fact that the device core holds a
      reference to a device added with device_initialize() that need
      to be released with a corresponding put_device() to reach a 0
      refcount at the end of the lifecycle.
      
      This led to a NULL pointer reference when freeing the device
      when e.g. unbidning the host device in sysfs.
      
      Fix this and use the device .release() callback to free the
      IDA and free:ing the memory used by the RPMB device.
      
      Before this patch:
      
      /sys/bus/amba/drivers/mmci-pl18x$ echo 80114000.sdi4_per2 > unbind
      [   29.797332] mmc3: card 0001 removed
      [   29.810791] Unable to handle kernel NULL pointer dereference at
                     virtual address 00000050
      [   29.818878] pgd = de70c000
      [   29.821624] [00000050] *pgd=1e70a831, *pte=00000000, *ppte=00000000
      [   29.827911] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      [   29.833282] Modules linked in:
      [   29.836334] CPU: 1 PID: 154 Comm: sh Not tainted
                     4.14.0-rc3-00039-g83318e309566-dirty #736
      [   29.844604] Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
      [   29.851562] task: de572700 task.stack: de742000
      [   29.856079] PC is at kernfs_find_ns+0x8/0x100
      [   29.860443] LR is at kernfs_find_and_get_ns+0x30/0x48
      
      After this patch:
      
      /sys/bus/amba/drivers/mmci-pl18x$ echo 80005000.sdi4_per2 > unbind
      [   20.623382] mmc3: card 0001 removed
      
      Fixes: 97548575 ("mmc: block: Convert RPMB to a character device")
      Reported-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      1c87f735
    • L
      mmc: block: Delete mmc_access_rpmb() · 14f4ca7e
      Linus Walleij 提交于
      This function is used by the block layer queue to bail out of
      requests if the current request is towards an RPMB
      "block device".
      
      This was done to avoid boot time scanning of this "block
      device" which was never really a block device, thus duct-taping
      over the fact that it was badly engineered.
      
      This problem is now gone as we removed the offending RPMB block
      device in another patch and replaced it with a character
      device.
      
      Cc: Tomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      14f4ca7e
    • L
      mmc: block: Convert RPMB to a character device · 97548575
      Linus Walleij 提交于
      The RPMB partition on the eMMC devices is a special area used
      for storing cryptographically safe information signed by a
      special secret key. To write and read records from this special
      area, authentication is needed.
      
      The RPMB area is *only* and *exclusively* accessed using
      ioctl():s from userspace. It is not really a block device,
      as blocks cannot be read or written from the device, also
      the signed chunks that can be stored on the RPMB are actually
      256 bytes, not 512 making a block device a real bad fit.
      
      Currently the RPMB partition spawns a separate block device
      named /dev/mmcblkNrpmb for each device with an RPMB partition,
      including the creation of a block queue with its own kernel
      thread and all overhead associated with this. On the Ux500
      HREFv60 platform, for example, the two eMMCs means that two
      block queues with separate threads are created for no use
      whatsoever.
      
      I have concluded that this block device design for RPMB is
      actually pretty wrong. The RPMB area should have been designed
      to be accessed from /dev/mmcblkN directly, using ioctl()s on
      the main block device. It is however way too late to change
      that, since userspace expects to open an RPMB device in
      /dev/mmcblkNrpmb and we cannot break userspace.
      
      This patch tries to amend the situation using the following
      strategy:
      
      - Stop creating a block device for the RPMB partition/area
      
      - Instead create a custom, dynamic character device with
        the same name.
      
      - Make this new character device support exactly the same
        set of ioctl()s as the old block device.
      
      - Wrap the requests back to the same ioctl() handlers, but
        issue them on the block queue of the main partition/area,
        i.e. /dev/mmcblkN
      
      We need to create a special "rpmb" bus type in order to get
      udev and/or busybox hot/coldplug to instantiate the device
      node properly.
      
      Before the patch, this appears in 'ps aux':
      
      101 root       0:00 [mmcqd/2rpmb]
      123 root       0:00 [mmcqd/3rpmb]
      
      After applying the patch these surplus block queue threads
      are gone, but RPMB is as usable as ever using the userspace
      MMC tools, such as 'mmc rpmb read-counter'.
      
      We get instead those dynamice devices in /dev:
      
      brw-rw----    1 root     root      179,   0 Jan  1  2000 mmcblk0
      brw-rw----    1 root     root      179,   1 Jan  1  2000 mmcblk0p1
      brw-rw----    1 root     root      179,   2 Jan  1  2000 mmcblk0p2
      brw-rw----    1 root     root      179,   5 Jan  1  2000 mmcblk0p5
      brw-rw----    1 root     root      179,   8 Jan  1  2000 mmcblk2
      brw-rw----    1 root     root      179,  16 Jan  1  2000 mmcblk2boot0
      brw-rw----    1 root     root      179,  24 Jan  1  2000 mmcblk2boot1
      crw-rw----    1 root     root      248,   0 Jan  1  2000 mmcblk2rpmb
      brw-rw----    1 root     root      179,  32 Jan  1  2000 mmcblk3
      brw-rw----    1 root     root      179,  40 Jan  1  2000 mmcblk3boot0
      brw-rw----    1 root     root      179,  48 Jan  1  2000 mmcblk3boot1
      brw-rw----    1 root     root      179,  33 Jan  1  2000 mmcblk3p1
      crw-rw----    1 root     root      248,   1 Jan  1  2000 mmcblk3rpmb
      
      Notice the (248,0) and (248,1) character devices for RPMB.
      
      Cc: Tomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      97548575
  6. 04 10月, 2017 1 次提交
    • L
      mmc: Delete bounce buffer handling · de3ee99b
      Linus Walleij 提交于
      In may, Steven sent a patch deleting the bounce buffer handling
      and the CONFIG_MMC_BLOCK_BOUNCE option.
      
      I chose the less invasive path of making it a runtime config
      option, and we merged that successfully for kernel v4.12.
      
      The code is however just standing in the way and taking up
      space for seemingly no gain on any systems in wide use today.
      
      Pierre says the code was there to improve speed on TI SDHCI
      controllers on certain HP laptops and possibly some Ricoh
      controllers as well. Early SDHCI controllers lacked the
      scatter-gather feature, which made software bounce buffers
      a significant speed boost.
      
      We are clearly talking about the list of SDHCI PCI-based
      MMC/SD card readers found in the pci_ids[] list in
      drivers/mmc/host/sdhci-pci-core.c.
      
      The TI SDHCI derivative is not supported by the upstream
      kernel. This leaves the Ricoh.
      
      What we can however notice is that the x86 defconfigs in the
      kernel did not enable CONFIG_MMC_BLOCK_BOUNCE option, which
      means that any such laptop would have to have a custom
      configured kernel to actually take advantage of this
      bounce buffer speed-up. It simply seems like there was
      a speed optimization for the Ricoh controllers that noone
      was using. (I have not checked the distro defconfigs but
      I am pretty sure the situation is the same there.)
      
      Bounce buffers increased performance on the OMAP HSMMC
      at one point, and was part of the original submission in
      commit a45c6cb8 ("[ARM] 5369/1: omap mmc: Add new
         omap hsmmc controller for 2430 and 34xx, v3")
      
      This optimization was removed in
      commit 0ccd76d4 ("omap_hsmmc: Implement scatter-gather
         emulation")
      which found that scatter-gather emulation provided even
      better performance.
      
      The same was introduced for SDHCI in
      commit 2134a922 ("sdhci: scatter-gather (ADMA) support")
      
      I am pretty positively convinced that software
      scatter-gather emulation will do for any host controller what
      the bounce buffers were doing. Essentially, the bounce buffer
      was a reimplementation of software scatter-gather-emulation in
      the MMC subsystem, and it should be done away with.
      
      Cc: Pierre Ossman <pierre@ossman.eu>
      Cc: Juha Yrjola <juha.yrjola@solidboot.com>
      Cc: Steven J. Hill <Steven.Hill@cavium.com>
      Cc: Shawn Lin <shawn.lin@rock-chips.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Suggested-by: NSteven J. Hill <Steven.Hill@cavium.com>
      Suggested-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      de3ee99b
  7. 30 8月, 2017 8 次提交
    • S
      mmc: block: cast a informative log for no devidx available · e7b42769
      Shawn Lin 提交于
      The intention for this patch is to help folks debug the failure
      like this:
      
      dwmmc_rockchip fe320000.dwmmc: IDMAC supports 32-bit address mode.
      dwmmc_rockchip fe320000.dwmmc: Using internal DMA controller.
      dwmmc_rockchip fe320000.dwmmc: Version ID is 270a
      dwmmc_rockchip fe320000.dwmmc: DW MMC controller at irq 28,32 bit
      host data width,256 deep fifo
      dwmmc_rockchip fe320000.dwmmc: Got CD GPIO
      mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual
      400000HZ div = 0)
      mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz,
      actual 50000000HZ div = 0)
      mmc0: new high speed SDHC card at address 0007
      mmcblk: probe of mmc0:0007 failed with error -28
      
      The reason may be some buggy userspace daemon miss the disk remove
      uevent sometimes so it would finally make the SD card not work.
      So from the dmesg it only shows a errno of -28 but still don't understand
      what happened.
      
      For quick reproduce this, we could set max_devices to 8 and run
      
      for i in $(seq 1 9); do
        echo "========================" $i
        echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/unbind
        sleep .5
        echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/bind
        sleep .5
        mount -t vfat /dev/mmcblk0 /mnt
        sleep .5
      done
      
      Another possible reason would be the device has more partitions than
      what we support, so that they have to increase their max_devices.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      e7b42769
    • L
      mmc: block: Reparametrize mmc_blk_ioctl_[multi]_cmd() · 2fe20bae
      Linus Walleij 提交于
      Instead of passing a block device to
      mmc_blk_ioctl[_multi]_cmd(), let's pass struct mmc_blk_data()
      so we operate ioctl()s on the MMC block device representation
      rather than the vanilla block device.
      
      This saves a little duplicated code and makes it possible to
      issue ioctl()s not targeted for a specific block device but
      rather for a specific partition/area.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2fe20bae
    • L
      mmc: block: Refactor mmc_blk_part_switch() · 1f797edc
      Linus Walleij 提交于
      Instead of passing a struct mmc_blk_data * to mmc_blk_part_switch()
      let's pass the actual partition type we want to switch to. This
      is necessary in order not to have a block device with a backing
      mmc_blk_data and request queue and all for every hardware partition,
      such as RPMB.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      1f797edc
    • L
      mmc: block: Move duplicate check · 61fe0e2b
      Linus Walleij 提交于
      mmc_blk_ioctl() calls either mmc_blk_ioctl_cmd() or
      mmc_blk_ioctl_multi_cmd() and each of these make the same
      check. Factor it into a new helper function, call it on
      both branches of the switch() statement and save a chunk
      of duplicate code.
      
      Cc: Shawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      61fe0e2b
    • L
      mmc: debugfs: Move block debugfs into block module · 627c3ccf
      Linus Walleij 提交于
      If we don't have the block layer enabled, we do not present card
      status and extcsd in the debugfs.
      
      Debugfs is not ABI, and maintaining files of no relevance for
      non-block devices comes at a high maintenance cost if we shall
      support it with the block layer compiled out.
      
      The debugfs entries suffer from all the same starvation
      issues as the other userspace things, under e.g. a heavy
      dd operation.
      
      The expected number of debugfs users utilizing these two
      debugfs files is already low as there is an ioctl() to get the
      same information using the mmc-tools, and of these few users
      the expected number of people using it on SDIO or combo cards
      are expected to be zero.
      
      It is therefore logical to move this over to the block layer
      when it is enabled, using the new custom requests and issue
      it using the block request queue.
      
      On the other hand it moves some debugfs code from debugfs.c
      and into block.c.
      
      Tested during heavy dd load by cat:in the status file.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      627c3ccf
    • L
      mmc: block: Anonymize the drv op data pointer · 69f7599e
      Linus Walleij 提交于
      We have a data pointer for the ioctl() data, but we need to
      pass other data along with the DRV_OP:s, so make this a
      void * so it can be reused.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      69f7599e
    • S
      mmc: block: remove unused struct mmc_card *card · 292876ef
      Shawn Lin 提交于
      It was never used and introduced a long standing compile
      warning:
      
      drivers/mmc/core/block.c: In function 'power_ro_lock_store':
      drivers/mmc/core/block.c:191:19: warning: variable 'card' set but not
      used [-Wunused-but-set-variable]
      
      Remove it to fix the warning.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      292876ef
    • A
      mmc: block: Fix block status codes · a7c17d8a
      Adrian Hunter 提交于
      Commit 2a842aca ("block: introduce new block status code type") changed
      the error type but not in patches merged through the mmc tree, like
      commit 0493f6fe ("mmc: block: Move boot partition locking into a driver
      op"). Fix one error code that is incorrect and also use BLK_STS_OK in
      preference to 0.
      
      Fixes: 17ece345 ("Merge tag 'mmc-v4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc")
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a7c17d8a
  8. 21 8月, 2017 1 次提交
  9. 09 8月, 2017 1 次提交
    • M
      mmc: block: fix lockdep splat when removing mmc_block module · 3f8b23a0
      Michał Mirosław 提交于
      Fix lockdep splat introduced in v4.13-rc4.
      
      [  266.297226] ------------[ cut here ]------------
      [  266.300078] WARNING: CPU: 2 PID: 176 at /mnt/src/jaja/git/tf300t/include/linux/blkdev.h:657 mmc_blk_remove_req+0xd0/0xe8 [mmc_block]
      [  266.302937] Modules linked in: mmc_block(-) sdhci_tegra sdhci_pltfm sdhci pwrseq_simple pwrseq_emmc mmc_core
      [  266.305941] CPU: 2 PID: 176 Comm: rmmod Tainted: G        W       4.13.0-rc4mq-00208-gb691e67724b8-dirty #694
      [  266.308852] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
      [  266.311719] [<b011144c>] (unwind_backtrace) from [<b010ca54>] (show_stack+0x18/0x1c)
      [  266.314664] [<b010ca54>] (show_stack) from [<b062e3f4>] (dump_stack+0x84/0x98)
      [  266.317644] [<b062e3f4>] (dump_stack) from [<b01214f4>] (__warn+0xf4/0x10c)
      [  266.320542] [<b01214f4>] (__warn) from [<b01215d4>] (warn_slowpath_null+0x28/0x30)
      [  266.323534] [<b01215d4>] (warn_slowpath_null) from [<af067858>] (mmc_blk_remove_req+0xd0/0xe8 [mmc_block])
      [  266.326568] [<af067858>] (mmc_blk_remove_req [mmc_block]) from [<af068f40>] (mmc_blk_remove_parts.constprop.6+0x50/0x64 [mmc_block])
      [  266.329678] [<af068f40>] (mmc_blk_remove_parts.constprop.6 [mmc_block]) from [<af0693b8>] (mmc_blk_remove+0x24/0x140 [mmc_block])
      [  266.332894] [<af0693b8>] (mmc_blk_remove [mmc_block]) from [<af0052ec>] (mmc_bus_remove+0x20/0x28 [mmc_core])
      [  266.336198] [<af0052ec>] (mmc_bus_remove [mmc_core]) from [<b046aa64>] (device_release_driver_internal+0x164/0x200)
      [  266.339367] [<b046aa64>] (device_release_driver_internal) from [<b046ab54>] (driver_detach+0x40/0x74)
      [  266.342537] [<b046ab54>] (driver_detach) from [<b046982c>] (bus_remove_driver+0x68/0xdc)
      [  266.345660] [<b046982c>] (bus_remove_driver) from [<af06ad40>] (mmc_blk_exit+0xc/0x2cc [mmc_block])
      [  266.348875] [<af06ad40>] (mmc_blk_exit [mmc_block]) from [<b01aee30>] (SyS_delete_module+0x1c4/0x254)
      [  266.352068] [<b01aee30>] (SyS_delete_module) from [<b0108480>] (ret_fast_syscall+0x0/0x34)
      [  266.355308] ---[ end trace f68728a0d3053b72 ]---
      
      Fixes: 7c84b8b4 ("mmc: block: bypass the queue even if usage is present for hotplug")
      Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      3f8b23a0
  10. 03 8月, 2017 1 次提交
    • S
      mmc: block: bypass the queue even if usage is present for hotplug · 7c84b8b4
      Shawn Lin 提交于
      The commit 304419d8 ("mmc: core: Allocate per-request data using the
      block layer core") refactored mechanism of queue handling caused
      mmc_init_request() can be called just after mmc_cleanup_queue() caused null
      pointer dereference.
      
      Another commit bbdc74dc ("mmc: block: Prevent new req entering queue
      after its cleanup") tried to fix the problem. However it actually miss one
      corner case.
      
      We could still reproduce the issue mentioned with these steps:
      (1) insert a SD card and mount it
      (2) hotplug it, so it will leave md->usage still be counted
      (3) reboot the system which will sync data and umount the card
      
      [Unable to handle kernel NULL pointer dereference at virtual address
      00000000
      [user pgtable: 4k pages, 48-bit VAs, pgd = ffff80007bab3000
      [[0000000000000000] *pgd=000000007a828003, *pud=0000000078dce003,
      *pmd=000000007aab6003, *pte=0000000000000000
      [Internal error: Oops: 96000007 [#1] PREEMPT SMP
      [Modules linked in:
      [CPU: 3 PID: 3507 Comm: umount Tainted: G        W
      4.13.0-rc1-next-20170720-00012-g9d9bf45 #33
      [Hardware name: Firefly-RK3399 Board (DT)
      [task: ffff80007a1de200 task.stack: ffff80007a01c000
      [PC is at mmc_init_request+0x14/0xc4
      [LR is at alloc_request_size+0x4c/0x74
      [pc : [<ffff0000087d7150>] lr : [<ffff000008378fe0>] pstate: 600001c5
      [sp : ffff80007a01f8f0
      
      ....
      
      [[<ffff0000087d7150>] mmc_init_request+0x14/0xc4
      [[<ffff000008378fe0>] alloc_request_size+0x4c/0x74
      [[<ffff00000817ac28>] mempool_create_node+0xb8/0x17c
      [[<ffff00000837aadc>] blk_init_rl+0x9c/0x120
      [[<ffff000008396580>] blkg_alloc+0x110/0x234
      [[<ffff000008396ac8>] blkg_create+0x424/0x468
      [[<ffff00000839877c>] blkg_lookup_create+0xd8/0x14c
      [[<ffff0000083796bc>] generic_make_request_checks+0x368/0x3b0
      [[<ffff00000837b050>] generic_make_request+0x1c/0x240
      
      So mmc_blk_put wouldn't calling blk_cleanup_queue which actually the
      QUEUE_FLAG_DYING and QUEUE_FLAG_BYPASS should stay. Block core expect
      blk_queue_bypass_{start, end} internally to bypass/drain the queue before
      actually dying the queue, so it didn't expose API to set the queue bypass.
      I think we should set QUEUE_FLAG_BYPASS whenever queue is removed, although
      the md->usage is still counted, as no dispatch queue could be found then.
      
      Fixes: 304419d8 ("mmc: core: Allocate per-request data using the block layer core")
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      7c84b8b4
  11. 13 7月, 2017 1 次提交
    • G
      mmc: block: Prevent new req entering queue after its cleanup · bbdc74dc
      Grzegorz Sluja 提交于
      The commit 304419d8 ("mmc: core: Allocate per-request data using the
      block layer core"), refactored the mechanism of queue handling, but also
      made mmc_init_request() to be called after mmc_cleanup_queue(). This
      triggers a null pointer dereference:
      
      [  683.123791] BUG: unable to handle kernel NULL pointer dereference at (null)
      [  683.123801] IP: mmc_init_request+0x2c/0xf0 [mmc_block]
      ...
      [  683.123905] Call Trace:
      [  683.123913]  alloc_request_size+0x4f/0x70
      [  683.123919]  mempool_alloc+0x5f/0x150
      [  683.123925]  ? __enqueue_entity+0x6c/0x70
      [  683.123928]  get_request+0x3ad/0x720
      [  683.123933]  ? prepare_to_wait_event+0x110/0x110
      [  683.123937]  blk_queue_bio+0xc1/0x3a0
      [  683.123940]  generic_make_request+0xf8/0x2a0
      [  683.123942]  submit_bio+0x75/0x150
      [  683.123947]  submit_bio_wait+0x51/0x70
      [  683.123951]  blkdev_issue_flush+0x5c/0x90
      [  683.123956]  ext4_sync_fs+0x171/0x1b0
      [  683.123961]  sync_filesystem+0x73/0x90
      [  683.123965]  fsync_bdev+0x24/0x50
      [  683.123971]  invalidate_partition+0x24/0x50
      [  683.123973]  del_gendisk+0xb2/0x2a0
      [  683.123977]  mmc_blk_remove_req.part.38+0x71/0xa0 [mmc_block]
      [  683.123980]  mmc_blk_remove+0xba/0x190 [mmc_block]
      [  683.123990]  mmc_bus_remove+0x1a/0x20 [mmc_core]
      [  683.123995]  device_release_driver_internal+0x141/0x200
      [  683.123999]  device_release_driver+0x12/0x20
      [  683.124001]  bus_remove_device+0xfd/0x170
      [  683.124004]  device_del+0x1e8/0x330
      [  683.124012]  mmc_remove_card+0x60/0xc0 [mmc_core]
      [  683.124019]  mmc_remove+0x19/0x30 [mmc_core]
      [  683.124025]  mmc_stop_host+0xfb/0x1a0 [mmc_core]
      [  683.124032]  mmc_remove_host+0x1a/0x40 [mmc_core]
      [  683.124037]  sdhci_remove_host+0x2e/0x1c0 [mmc_sdhci]
      [  683.124042]  sdhci_pci_remove_slot+0x3f/0x80 [sdhci_pci]
      [  683.124045]  sdhci_pci_remove+0x39/0x70 [sdhci_pci]
      [  683.124049]  pci_device_remove+0x39/0xc0
      [  683.124052]  device_release_driver_internal+0x141/0x200
      [  683.124056]  driver_detach+0x3f/0x80
      [  683.124059]  bus_remove_driver+0x55/0xd0
      [  683.124062]  driver_unregister+0x2c/0x50
      [  683.124065]  pci_unregister_driver+0x29/0x90
      [  683.124069]  sdhci_driver_exit+0x10/0x4f3 [sdhci_pci]
      [  683.124073]  SyS_delete_module+0x171/0x250
      [  683.124078]  entry_SYSCALL_64_fastpath+0x1e/0xa9
      
      Fix this by setting the queue DYING flag before cleanup the queue, as it
      prevents new reqs from entering the queue.
      Signed-off-by: NGrzegorz Sluja <grzegorzx.sluja@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Fixes: 304419d8 ("mmc: core: Allocate per-request data using the...")
      [Ulf: Updated the changelog]
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      bbdc74dc