1. 20 Jun, 2017 25 commits
    • Markus Elfring's avatar
      mmc: core: Delete error messages for failed memory allocations · e1df7ae3
      Markus Elfring authored
      Omit an extra message for memory allocation failures.
      
      This issue was detected by using the Coccinelle software.
      
      Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      e1df7ae3
    • Markus Elfring's avatar
      mmc: atmel-mci: Delete an error message for a failed memory allocation · 9b344ba4
      Markus Elfring authored
      Omit an extra message for a memory allocation failure.
      
      This issue was detected by using the Coccinelle software.
      
      Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      9b344ba4
    • Linus Walleij's avatar
      mmc: queue: delete mmc_req_is_special() · b428e712
      Linus Walleij authored
      commit cdf8a6fb
      "mmc: block: Introduce queue semantics"
      deleted the last user of mmc_req_is_special() and it was
      a horrible hack to classify requests as "special" or
      "not special" to begin with, so delete the helper.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      b428e712
    • Linus Walleij's avatar
      mmc: block: move multi-ioctl() to use block layer · 3ecd8cf2
      Linus Walleij authored
      This switches also the multiple-command ioctl() call to issue
      all ioctl()s through the block layer instead of going directly
      to the device.
      
      We extend the passed argument with an argument count and loop
      over all passed commands in the ioctl() issue function called
      from the block layer.
      
      By doing this we are again loosening the grip on the big host
      lock, since two calls to mmc_get_card()/mmc_put_card() are
      removed.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarAvri Altman <Avri.Altman@sandisk.com>
      3ecd8cf2
    • Linus Walleij's avatar
      mmc: block: move single ioctl() commands to block requests · 614f0388
      Linus Walleij authored
      This wraps single ioctl() commands into block requests using
      the custom block layer request types REQ_OP_DRV_IN and
      REQ_OP_DRV_OUT.
      
      By doing this we are loosening the grip on the big host lock,
      since two calls to mmc_get_card()/mmc_put_card() are removed.
      
      We are storing the ioctl() in/out argument as a pointer in
      the per-request struct mmc_blk_request container. Since we
      now let the block layer allocate this data, blk_get_request()
      will allocate it for us and we can immediately dereference
      it and use it to pass the argument into the block layer.
      
      We refactor the if/else/if/else ladder in mmc_blk_issue_rq()
      as part of the job, keeping some extra attention to the
      case when a NULL req is passed into this function and
      making that pipeline flush more explicit.
      
      Tested on the ux500 with the userspace:
      mmc extcsd read /dev/mmcblk3
      resulting in a successful EXTCSD info dump back to the
      console.
      
      This commit fixes a starvation issue in the MMC/SD stack
      that can be easily provoked in the following way by
      issueing the following commands in sequence:
      
      > dd if=/dev/mmcblk3 of=/dev/null bs=1M &
      > mmc extcs read /dev/mmcblk3
      
      Before this patch, the extcsd read command would hang
      (starve) while waiting for the dd command to finish since
      the block layer was holding the card/host lock.
      
      After this patch, the extcsd ioctl() command is nicely
      interpersed with the rest of the block commands and we
      can issue a bunch of ioctl()s from userspace while there
      is some busy block IO going on without any problems.
      
      Conversely userspace ioctl()s can no longer starve
      the block layer by holding the card/host lock.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarAvri Altman <Avri.Altman@sandisk.com>
      614f0388
    • Linus Walleij's avatar
      mmc: block: Tag is_rpmb as bool · 829043c4
      Linus Walleij authored
      The variable is_rpmb is clearly a bool and even assigned true
      and false, yet declared as an int.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      829043c4
    • Linus Walleij's avatar
      mmc: core: Allocate per-request data using the block layer core · 304419d8
      Linus Walleij authored
      The mmc_queue_req is a per-request state container the MMC core uses
      to carry bounce buffers, pointers to asynchronous requests and so on.
      Currently allocated as a static array of objects, then as a request
      comes in, a mmc_queue_req is assigned to it, and used during the
      lifetime of the request.
      
      This is backwards compared to how other block layer drivers work:
      they usally let the block core provide a per-request struct that get
      allocated right beind the struct request, and which can be obtained
      using the blk_mq_rq_to_pdu() helper. (The _mq_ infix in this function
      name is misleading: it is used by both the old and the MQ block
      layer.)
      
      The per-request struct gets allocated to the size stored in the queue
      variable .cmd_size initialized using the .init_rq_fn() and
      cleaned up using .exit_rq_fn().
      
      The block layer code makes the MMC core rely on this mechanism to
      allocate the per-request mmc_queue_req state container.
      
      Doing this make a lot of complicated queue handling go away. We only
      need to keep the .qnct that keeps count of how many request are
      currently being processed by the MMC layer. The MQ block layer will
      replace also this once we transition to it.
      
      Doing this refactoring is necessary to move the ioctl() operations
      into custom block layer requests tagged with REQ_OP_DRV_[IN|OUT]
      instead of the custom code using the BigMMCHostLock that we have
      today: those require that per-request data be obtainable easily from
      a request after creating a custom request with e.g.:
      
      struct request *rq = blk_get_request(q, REQ_OP_DRV_IN, __GFP_RECLAIM);
      struct mmc_queue_req *mq_rq = req_to_mq_rq(rq);
      
      And this is not possible with the current construction, as the request
      is not immediately assigned the per-request state container, but
      instead it gets assigned when the request finally enters the MMC
      queue, which is way too late for custom requests.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [Ulf: Folded in the fix to drop a call to blk_cleanup_queue()]
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      304419d8
    • Linus Walleij's avatar
      mmc: core: Delete bounce buffer Kconfig option · c3dccb74
      Linus Walleij authored
      This option is activated by all multiplatform configs and what
      not so we almost always have it turned on, and the memory it
      saves is negligible, even more so moving forward. The actual
      bounce buffer only gets allocated only when used, the only
      thing the ifdefs are saving is a little bit of code.
      
      It is highly improper to have this as a Kconfig option that
      get turned on by Kconfig, make this a pure runtime-thing and
      let the host decide whether we use bounce buffers. We add a
      new property "disable_bounce" to the host struct.
      
      Notice that mmc_queue_calc_bouncesz() already disables the
      bounce buffers if host->max_segs != 1, so any arch that has a
      maximum number of segments higher than 1 will have bounce
      buffers disabled.
      
      The option CONFIG_MMC_BLOCK_BOUNCE is default y so the
      majority of platforms in the kernel already have it on, and
      it then gets turned off at runtime since most of these have
      a host->max_segs > 1. The few exceptions that have
      host->max_segs == 1 and still turn off the bounce buffering
      are those that disable it in their defconfig.
      
      Those are the following:
      
      arch/arm/configs/colibri_pxa300_defconfig
      arch/arm/configs/zeus_defconfig
      - Uses MMC_PXA, drivers/mmc/host/pxamci.c
      - Sets host->max_segs = NR_SG, which is 1
      - This needs its bounce buffer deactivated so we set
        host->disable_bounce to true in the host driver
      
      arch/arm/configs/davinci_all_defconfig
      - Uses MMC_DAVINCI, drivers/mmc/host/davinci_mmc.c
      - This driver sets host->max_segs to MAX_NR_SG, which is 16
      - That means this driver anyways disabled bounce buffers
      - No special action needed for this platform
      
      arch/arm/configs/lpc32xx_defconfig
      arch/arm/configs/nhk8815_defconfig
      arch/arm/configs/u300_defconfig
      - Uses MMC_ARMMMCI, drivers/mmc/host/mmci.[c|h]
      - This driver by default sets host->max_segs to NR_SG,
        which is 128, unless a DMA engine is used, and in that case
        the number of segments are also > 1
      - That means this driver already disables bounce buffers
      - No special action needed for these platforms
      
      arch/arm/configs/sama5_defconfig
      - Uses MMC_SDHCI, MMC_SDHCI_PLTFM, MMC_SDHCI_OF_AT91, MMC_ATMELMCI
      - Uses drivers/mmc/host/sdhci.c
      - Normally sets host->max_segs to SDHCI_MAX_SEGS which is 128 and
        thus disables bounce buffers
      - Sets host->max_segs to 1 if SDHCI_USE_SDMA is set
      - SDHCI_USE_SDMA is only set by SDHCI on PCI adapers
      - That means that for this platform bounce buffers are already
        disabled at runtime
      - No special action needed for this platform
      
      arch/blackfin/configs/CM-BF533_defconfig
      arch/blackfin/configs/CM-BF537E_defconfig
      - Uses MMC_SPI (a simple MMC card connected on SPI pins)
      - Uses drivers/mmc/host/mmc_spi.c
      - Sets host->max_segs to MMC_SPI_BLOCKSATONCE which is 128
      - That means this platform already disables bounce buffers at
        runtime
      - No special action needed for these platforms
      
      arch/mips/configs/cavium_octeon_defconfig
      - Uses MMC_CAVIUM_OCTEON, drivers/mmc/host/cavium.c
      - Sets host->max_segs to 16 or 1
      - Setting host->disable_bounce to be sure for the 1 case
      
      arch/mips/configs/qi_lb60_defconfig
      - Uses MMC_JZ4740, drivers/mmc/host/jz4740_mmc.c
      - This sets host->max_segs to 128 so bounce buffers are
        already runtime disabled
      - No action needed for this platform
      
      It would be interesting to come up with a list of the platforms
      that actually end up using bounce buffers. I have not been
      able to infer such a list, but it occurs when
      host->max_segs == 1 and the bounce buffering is not explicitly
      disabled.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c3dccb74
    • Simon Horman's avatar
      mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main module file · 9d08428a
      Simon Horman authored
      Make renesas_sdhi_sys_dmac.c a top-level module file that makes use of
      library code supplied by renesas_sdhi_core.c
      
      This is in order to facilitate adding other variants of SDHI;
      in particular SDHI using different DMA controllers.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      [Arnd: Fixed module build error]
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      9d08428a
    • Simon Horman's avatar
      mmc: renesas-sdhi: rename sh_mobile_sdhi.c => renesas_sdhi_core.c · b5b6a5f4
      Simon Horman authored
      Rename the source file SDHI. A follow-up patch will make it a library
      file used by a different top-level module file.
      
      The name "renesas" is chosen as the SDHI driver is applicable to a wider
      range of SoCs than SH-Mobile it seems to be a more appropriate name.
      However, the SDHI driver source itself, is left as sh_mobile_sdhi to
      avoid unnecessary churn.
      
      the name "core" was chosen to reflect the desired role of this file,
      to provide core functionality to the sdhi driver. A follow-up patch will
      move the file into that role.
      
      Internal symbols have also been renamed to reflect the filename change.
      
      The .name member of struct platform_driver and parameter to
      MODULE_ALIAS() have not been changed in order to avoid the complication
      of potentially breaking SH SoCs which still use platform drivers.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      b5b6a5f4
    • Simon Horman's avatar
      mmc: renesas-sdhi: rename tmio_mmc_dma.c => renesas_sdhi_sys_dmac.c · c2a96987
      Simon Horman authored
      Rename the source file for DMA for SDHI as a follow-up to attaching
      DMA code to the SDHI driver rather than the tmio_core driver.
      
      The name "renesas" is chosen as the SDHI driver is applicable to a wider
      range of SoCs than SH-Mobile it seems to be a more appropriate name.
      However, the SDHI driver source itself, is left as sh_mobile_sdhi to
      avoid unnecessary churn.
      
      The name sys_dmac was chosen to reflect the type of DMA used.
      
      Internal symbols have also been renamed to reflect the filename change.
      
      A follow-up patch will re-organise the SDHI driver removing
      the need for renesas_sdhi_get_dma_ops().
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c2a96987
    • Simon Horman's avatar
      mmc: tmio: rename tmio_mmc_{pio => core}.c · 426e95d1
      Simon Horman authored
      Rename tmio_mmc_pio.c to tmio_mmc_core.c to more accurately reflect its
      function: to provide core code for the tmio-mmc and sh-mobole-sdhi drivers.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      426e95d1
    • Simon Horman's avatar
      mmc: renesas-sdhi, tmio: make dma more modular · 631fa73c
      Simon Horman authored
      Refactor DMA support to allow it to be provided by a set of call-backs
      that are provided by a host driver. The motivation is to allow multiple
      DMA implementations to be provided and instantiated at run-time.
      
      Instantiate the existing DMA implementation from the sh_mobile_sdhi driver
      which appears to match the current use-case. This has the side effect
      of moving the DMA code from the tmio_core to the sh_mobile_sdhi driver.
      
      A follow-up patch will change the source file for the SDHI DMA
      implementation accordingly. Another follow-up patch will re-organise the
      SDHI driver removing the need for tmio_mmc_get_dma_ops().
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      631fa73c
    • Simon Horman's avatar
      mmc: tmio: drop filenames from comment at top of source · b21f13d8
      Simon Horman authored
      Reshuffle the comment at the top of the source
      dropping filenames and moving up human readable strings.
      
      This seems to be somewhat more useful information to start the
      source file with. It is also less fragile, f.e. to file renames.
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      b21f13d8
    • Ulf Hansson's avatar
      Revert "mmc: dw_mmc: Don't allow Runtime PM for SDIO cards" · 0eebf9b9
      Ulf Hansson authored
      This reverts commit a6db2c86 ("mmc: dw_mmc: Don't allow Runtime PM for
      SDIO cards")'
      
      As dw_mmc now is capable of preventing runtime PM suspend while SDIO IRQs
      are enabled, let's drop the less fine-grained method, which is preventing
      runtime PM suspend for all SDIO cards - no matter of whether SDIO IRQs are
      being enabled or not.
      
      In this way we don't keep the host runtime PM resumed, unless it's really
      needed, thus avoiding to waste power.
      
      Especially when SDIO IRQs is supported via a separate out-of-band IRQ line,
      which isn't defined by the SDIO standard, typically the SDIO func driver
      doesn't enable SDIO IRQs via sdio_claim_irq(). So, for these cases we can
      now allow the dwmmc device to be runtime PM suspended in-between requests.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      0eebf9b9
    • Ulf Hansson's avatar
      mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs are enabled · ca8971ca
      Ulf Hansson authored
      To be able to handle SDIO IRQs the dw_mmc device needs to be powered and
      providing clock to the SDIO card. Therefore, we must not allow the device
      to be runtime PM suspended while SDIO IRQs are enabled.
      
      To fix this, let's increase the runtime PM usage count while the mmc core
      enables SDIO IRQs. Later when the mmc core tells dw_mmc to disable SDIO
      IRQs, we drop the usage count to again allow runtime PM suspend.
      
      This now becomes the default behaviour for dw_mmc. In cases where SDIO IRQs
      can be re-routed as GPIO wake-ups during runtime PM suspend, one could
      potentially allow runtime PM suspend. However, that will have to be
      addressed as a separate change on top of this one.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      ca8971ca
    • Ulf Hansson's avatar
      mmc: dw_mmc: Convert to use MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs · 32dba737
      Ulf Hansson authored
      Convert to use the more lightweight method for processing SDIO IRQs, which
      involves the following changes:
      
      - Enable MMC_CAP2_SDIO_IRQ_NOTHREAD when SDIO IRQ is supported and use
        sdio_signal_irq() instead of mmc_signal_sdio_irq().
      - Mask the SDIO IRQ before signaling a new one to be processed.
      - Implement the ->ack_sdio_irq() callback to unmask the SDIO IRQ.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      32dba737
    • Ulf Hansson's avatar
      mmc: sdio: Add API to manage SDIO IRQs from a workqueue · 68269660
      Ulf Hansson authored
      For hosts not supporting MMC_CAP2_SDIO_IRQ_NOTHREAD but MMC_CAP_SDIO_IRQ,
      the SDIO IRQs are processed from a dedicated kernel thread. For these
      cases, the host calls mmc_signal_sdio_irq() from its ISR to signal a new
      SDIO IRQ.
      
      Signaling an SDIO IRQ makes the host's ->enable_sdio_irq() callback to be
      invoked to temporary disable the IRQs, before the kernel thread is woken up
      to process it. When processing of the IRQs are completed, they are
      re-enabled by the kernel thread, again via invoking the host's
      ->enable_sdio_irq().
      
      The observation from this, is that the execution path is being unnecessary
      complex, as the host driver already knows that it needs to temporary
      disable the IRQs before signaling a new one. Moreover, replacing the kernel
      thread with a work/workqueue would not only greatly simplify the code, but
      also make it more robust.
      
      To address the above problems, let's continue to build upon the support for
      MMC_CAP2_SDIO_IRQ_NOTHREAD, as it already implements SDIO IRQs to be
      processed without using the clumsy kernel thread and without the ping-pong
      calls of the host's ->enable_sdio_irq() callback for each processed IRQ.
      
      Therefore, let's add new API sdio_signal_irq(), which enables hosts to
      signal/process SDIO IRQs by using a work/workqueue, rather than using the
      kernel thread.
      
      Add also a new host callback ->ack_sdio_irq(), which the work invokes when
      the SDIO IRQs have been processed. This informs the host about when it
      shall re-enable the SDIO IRQs. Potentially, we could re-use the existing
      ->enable_sdio_irq() callback instead of adding a new one, however it has
      turned out that it's more convenient for hosts to get this information via
      a separate callback.
      
      Hosts that wants to use this new method to signal/process SDIO IRQs, must
      enable MMC_CAP2_SDIO_IRQ_NOTHREAD and implement the ->ack_sdio_irq()
      callback.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      68269660
    • Ulf Hansson's avatar
      mmc: core: Prevent processing SDIO IRQs when none is claimed · e3a84267
      Ulf Hansson authored
      In cases when MMC_CAP2_SDIO_IRQ_NOTHREAD is set, there is a minor window
      for when the mmc host could call sdio_run_irqs(), while in fact an SDIO
      func driver could have decided to released the SDIO IRQ via a call to
      sdio_release_irq(). In this scenario, processing of the SDIO IRQs are done
      even if there is none IRQ claimed, which is not what we want.
      
      To prevent this from happen, close the window by validating that at least
      one SDIO IRQs is claimed, before deciding to process them.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      e3a84267
    • Ulf Hansson's avatar
      mmc: core: Don't do eMMC HW reset when resuming the eMMC card · 52c8212d
      Ulf Hansson authored
      In case if a pwrseq-emmc has been bound to the host, a call to
      mmc_power_up() triggers an eMMC HW reset via the pwrseq_emmc's
      ->post_power_on() callback. This isn't really what we want, as
      mmc_power_up() is called each time when resuming the card.
      
      As a matter of fact, the current approach may also violate the eMMC spec,
      as the involved delays managed in pwrseq_emmc assumes both VCC and VCCQ has
      been turned on, which isn't the case for VCCQ, unless the regulator is
      always on.
      
      Fix this behaviour by aligning to the same procedure used when the mmc host
      implements the ->hw_reset() callback and has the MMC_CAP_HW_RESET flag set.
      In this way the eMMC HW reset is issued at card detection scan, to cope
      with bogus bootloaders and in the error recovery path via the mmc specific
      bus_ops->reset() callback.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      52c8212d
    • Ulf Hansson's avatar
      mmc: pwrseq: Add reset callback to the struct mmc_pwrseq_ops · 773a9ef8
      Ulf Hansson authored
      The ->reset() callback is needed to implement a better support for eMMC HW
      reset. The following changes will take advantage of the new callback.
      Suggested-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      773a9ef8
    • Johan Hovold's avatar
      mmc: vub3000: add missing USB-descriptor endianness conversions · dada0194
      Johan Hovold authored
      Add the missing endianness conversions when printing the USB
      device-descriptor idVendor and idProduct fields during probe.
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      dada0194
    • Andy Shevchenko's avatar
      mmc: atmel-mci: Remove AVR32 bits from the driver · ef4b160f
      Andy Shevchenko authored
      AVR32 is gone. Now it's time to clean up the driver by removing
      leftovers that was used by AVR32 related code.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      ef4b160f
    • Colin Ian King's avatar
      mmc: sdricoh_cs: remove redundant check if len is non-zero · 675a7da8
      Colin Ian King authored
      At the end of either of the read or write loops len is always zero
      and hence the non-zero check on len and return of -EIO is redundant
      and can be removed.
      
      Detected by CoverityScan, CID#114293 ("Logically dead code")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      675a7da8
    • Shubhrajyoti Datta's avatar
      mmc: sdhci-of-arasan: Trivial print fix · 940e698c
      Shubhrajyoti Datta authored
      ret is signed however is printed as unsigned fix the same.
      If printed as a negative number the result is easier to read.
      No functional change.
      Signed-off-by: default avatarShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      940e698c
  2. 19 Jun, 2017 8 commits
    • Linus Torvalds's avatar
      Linux 4.12-rc6 · 41f1830f
      Linus Torvalds authored
      41f1830f
    • Hugh Dickins's avatar
      mm: larger stack guard gap, between vmas · 1be7107f
      Hugh Dickins authored
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: default avatarOleg Nesterov <oleg@redhat.com>
      Original-patch-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1be7107f
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 1132d5e7
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "Stream of fixes has slowed down, only a few this week:
      
         - Some DT fixes for Allwinner platforms, and addition of a clock to
           the R_CCU clock controller that had been missed.
      
         - A couple of small DT fixes for am335x-sl50"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU
        ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU
        ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
        ARM: dts: am335x-sl50: Fix card detect pin for mmc1
        arm64: allwinner: h5: Remove syslink to shared DTSI
        ARM: sunxi: h3/h5: fix the compatible of R_CCU
      1132d5e7
    • Olof Johansson's avatar
      Merge tag 'sunxi-fixes-for-4.12' of... · a1858df9
      Olof Johansson authored
      Merge tag 'sunxi-fixes-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
      
      Allwinner fixes for 4.12
      
      A few fixes around the PRCM support that got in 4.12 with a wrong
      compatible, and a missing clock in the binding.
      
      * tag 'sunxi-fixes-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
        arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU
        ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU
        arm64: allwinner: h5: Remove syslink to shared DTSI
        ARM: sunxi: h3/h5: fix the compatible of R_CCU
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      a1858df9
    • Olof Johansson's avatar
      Merge tag 'omap-for-v4.12/fixes-sl50' of... · 51b6e281
      Olof Johansson authored
      Merge tag 'omap-for-v4.12/fixes-sl50' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
      
      Two fixes for am335x-sl50 to fix a boot time error
      for claiming SPI pins, and to fix a SDIO card detect
      pin for production version of the device.
      
      * tag 'omap-for-v4.12/fixes-sl50' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
        ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
        ARM: dts: am335x-sl50: Fix card detect pin for mmc1
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      51b6e281
    • Linus Torvalds's avatar
      Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost · 3696e4f0
      Linus Torvalds authored
      Pull virtio bugfix from Michael Tsirkin:
       "It turns out balloon does not handle IOMMUs correctly. We should fix
        that at some point, for now let's just disable this configuration"
      
      * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
        virtio_balloon: disable VIOMMU support
      3696e4f0
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · 7d62d947
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "Two driver bugfixes"
      
      * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: ismt: fix wrong device address when unmap the data buffer
        i2c: rcar: use correct length when unmapping DMA
      7d62d947
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · b3ee4edd
      Linus Torvalds authored
      Pull MIPS fixes from Ralf Baechle:
      
       - Three highmem fixes:
          + Fixed mapping initialization
          + Adjust the pkmap location
          + Ensure we use at most one page for PTEs
      
       - Fix makefile dependencies for .its targets to depend on vmlinux
      
       - Fix reversed condition in BNEZC and JIALC software branch emulation
      
       - Only flush initialized flush_insn_slot to avoid NULL pointer
         dereference
      
       - perf: Remove incorrect odd/even counter handling for I6400
      
       - ftrace: Fix init functions tracing
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: .its targets depend on vmlinux
        MIPS: Fix bnezc/jialc return address calculation
        MIPS: kprobes: flush_insn_slot should flush only if probe initialised
        MIPS: ftrace: fix init functions tracing
        MIPS: mm: adjust PKMAP location
        MIPS: highmem: ensure that we don't use more than one page for PTEs
        MIPS: mm: fixed mappings: correct initialisation
        MIPS: perf: Remove incorrect odd/even counter handling for I6400
      b3ee4edd
  3. 18 Jun, 2017 7 commits