summaryrefslogtreecommitdiff
path: root/drivers/mmc
AgeCommit message (Collapse)Author
2016-07-25mmc: dw_mmc: remove the quirks flagsJaehoon Chung
Remove the quirks flag. (DW_MCI_QUIRK_BROKEN_DTO) For removing this, enabled the dto_timer by defaults. It doesn't see any I/O performance degression. In future, dwmmc controller should not use the quirks flag. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: exynos: fix the NULL pointer dereference errorJaehoon Chung
"host->cur_slot" should be assigned to start the request. So it can be the NULL pointer. This patch fixed this error. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()Seung-Woo Kim
This patch removes following UBSAN warnings in dw_mci_setup_bus(). UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [<ffffff90080908a8>] dump_backtrace+0x0/0x380 [<ffffff9008090c3c>] show_stack+0x14/0x20 [<ffffff90087457b8>] dump_stack+0xe0/0x120 [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68 [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc [<ffffff9008d89cb8>] dw_mci_setup_bus+0x3a0/0x438 [...] UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1132:27 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [<ffffff90080908a8>] dump_backtrace+0x0/0x380 [<ffffff9008090c3c>] show_stack+0x14/0x20 [<ffffff90087457b8>] dump_stack+0xe0/0x120 [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68 [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc [<ffffff9008d89c9c>] dw_mci_setup_bus+0x384/0x438 [...] The warnings are caused because of bit shift which is used to filter spamming message for CONFIG_MMC_CLKGATE, but the config is already removed. So this patch just removes the shift. Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: Wait for data transfer after response errors.Doug Anderson
According to the DesignWare state machine description, after we get a "response error" or "response CRC error" we move into data transfer mode. That means that we don't necessarily need to special case trying to deal with the failure right away. We can wait until we are notified that the data transfer is complete (with or without errors) and then we can deal with the failure. It may sound strange to defer dealing with a command that we know will fail anyway, but this appears to fix a bug. During tuning (CMD19) on a specific card on an rk3288-based system, we found that we could get a "response CRC error". Sending the stop command after the "response CRC error" would then throw the system into a confused state causing all future tuning phases to report failure. When in the confused state, the controller would show these (hex codes are interrupt status register): CMD ERR: 0x00000046 (cmd=19) CMD ERR: 0x0000004e (cmd=12) DATA ERR: 0x00000208 DATA ERR: 0x0000020c CMD ERR: 0x00000104 (cmd=19) CMD ERR: 0x00000104 (cmd=12) DATA ERR: 0x00000208 DATA ERR: 0x0000020c ... ... It is inherently difficult to deal with the complexity of trying to correctly send a stop command while a data transfer is taking place since you need to deal with different corner cases caused by the fact that the data transfer could complete (with errors or without errors) during various places in sending the stop command (dw_mci_stop_dma, send_stop_abort, etc) Instead of adding a bunch of extra complexity to deal with this, it seems much simpler to just use the more straightforward (and less error-prone) path of letting the data transfer finish. There shouldn't be any huge benefit to sending the stop command slightly earlier, anyway. Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Alim Akhtar <alim.akhtar@gmail.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: fix 32bit little-endian access of des1 fieldBen Dooks
The IDMAC_SET_BUFFER1_SIZE() macro modifies des1, but does not check if the value being passed is big or little endian desptire the des1 field being marked as __le32. Fix the issue by ensuring the values are changed from the cpu endian to the descriptor endian by using cpu_to_le32. Spotted whilst doing big endian conversion work on Exynos, and stops the mmc worker thread from stalling. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: Consider HLE errors to be data and command errorsDoug Anderson
The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but nothing in the interrupt handler actually handles them and ACKs them. That means that if we ever get an HLE error we'll just keep getting interrupts and we'll wedge things. We really don't expect HLE errors but if we ever get them we shouldn't silently ignore them. Note that I have seen HLE errors while constantly ejecting and inserting cards (ejecting while inserting, etc). Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: k3: add MMC_CAP_CMD23Jérôme Forissier
Enables RPMB support for the on-board eMMC of the HiKey board as well as for eMMC modules connected to the microSD slot. Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: check card present before starting requestShawn Lin
The main reason to add this check is to avoid unnecessary mmc_request like the on-going cmd and the corresponding sbc if the card is removed. Although we have already checked this in dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot for noremovable devices, but there is a timing gap before it really calls dw_mci_get_cd as mmc_detect_change needs some delay here. Another gain here is that we could save some checkings of card status after sd card been removed. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: dw_mmc: remove redundant of set_bit and clear_bitShawn Lin
dw_mci_get_cd have already dealt with these for both of internal card-detect and gpio card-detect. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sh_mmcif: Use a 10s timeout in the error recovery pathUlf Hansson
The current value means an mdelay(1) may execute up to 10000000 times, which translates to around ~2.8 hours. This is probably not what the orignal author had in mind. Let's instead use 10s, which is the same value sh_mmcif is using for other timeouts. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sh_mmcif: Inform the mmc core about the max busy timeoutUlf Hansson
The sh_mmcif driver is already using a 10s request timeout. Let's also inform the mmc core about this value, as there are situations when it needs to know about it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sh_mmcif: Use response type to know when to enable busy detectionUlf Hansson
The sh_mmcif explicity checks for certain commands to decide when to enable HW busy detection. Instead, it should only check the response type as it tells if busy detection is needed. In this way, the mmc core also gets full control whether it thinks busy detection should be done or not. In some specific scenarios, like for ERASE and STOP commands it may decide to fall back to use a CMD13 to poll the card status instead. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sh_mmcif: Enable MMC_CAP2_NO_SD and MMC_CAP2_NO_SDIOUlf Hansson
Enable the capabilities which tells the mmc core to prevent sending SD and SDIO commands during card initialization. In this way, we can also remove the validation of non-supported commands in the ->request() callback. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: core: Allow hosts to specify non-support for SD commandsUlf Hansson
There are host drivers which needs to valdiate for non-supported SD commands and returnn error code for such requests. To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD which these host drivers can set to tell the mmc core to skip sending SD commands during card initialization. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci-msm: fix spelling mistake: "Perpheral" -> "Peripheral"Colin Ian King
trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci: use pr_err for sdhci_dumpregsChuanxiao Dong
sdhci_dumpregs is used to dump registers when error happens. Thus it should use pr_err instead of pr_debug to show more information about the hardware. Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> [Fix whitespace and checkpatch warnings] Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: host: use the defined function to check whether card is removableJaehoon Chung
In linux/mmc/host.h, mmc_card_is_removable() is already defined. It should be maintainted more easier than now. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci-of-arasan: Add ability to export card clockDouglas Anderson
Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock in order to function properly. Let's add the ability to expose this clock. Any PHY that needs to know the clock rate can add a reference and query the clock rate. At the moment we register a CLK_GET_RATE_NOCACHE clock that simply allows querying the clock. This allows us to be less intrusive with regards to the main SDHCI driver, which has complex logic for adjusting the SD clock. Right now we always fully power cycle the PHY when the clock changes and that gives the PHY a good chance to query our clock. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399Douglas Anderson
In the the earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the mechansim for specifying a syscon to properly set corecfg registers in sdhci-of-arasan. Now let's use this mechanism to properly set corecfg_baseclkfreq on rk3399. >From [1] the corecfg_baseclkfreq is supposed to be set to: Base Clock Frequency for SD Clock. This is the frequency of the xin_clk. This is a relatively easy thing to do. Note that we assume that xin_clk is not dynamic and we can check the clock at probe time. If any real devices have a dynamic xin_clk future patches could register for notifiers for the clock. At the moment, setting corecfg_baseclkfreq is only supported for rk3399 since we need a specific map for each implementation. The code is written in a generic way that should make this easy to extend to other SoCs. Note that a specific compatible string for rk3399 is already in use and so we add that to the table to match rk3399. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci-of-arasan: Always power the PHY off/on when clock changesDouglas Anderson
In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy is supported") we added code to power the PHY off and on whenever the clock was changed but we avoided doing the power cycle code when the clock was low speed. Let's now do it always. Although there may be other reasons for power cycling the PHY when the clock changes, one of the main reasons is that we need to give the DLL a chance to re-lock with the new clock. One of the things that the DLL is for is tuning the Receive Clock in HS200 mode and STRB in HS400 mode. Thus it is clear that we should make sure we power cycle the PHY (and wait for the DLL to lock) when we know we'll be in one of these two speed modes. That's what the original code did, though it used the clock rate rather than the speed mode. However, even in speed modes other than HS200,/HS400 the DLL is used for something since it can be clearly observed that the PHY doesn't function properly if you leave the DLL off. Although it appears less important to power cycle the PHY and wait for the DLL to lock when not in HS200/HS400 modes (no bugs were reported), it still seems wise to let the locking always happen nevertheless. Note: as part of this, we make sure that we never try to turn the PHY on when the clock is off (when the clock rate is 0). The PHY cannot work when the clock is off since its DLL can't lock. This change requires ("phy: rockchip-emmc: Increase lock time allowance") and will cause problems if picked without that change. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci-brcmstb: Add driver for Broadcom BRCMSTB SoCsAl Cooper
Add SDHCI driver for Broadcom BRCMSTB SoCs. This driver works with all ARM based SoCs and the 7425, 7429 and 7435 MIPS based SoCs. The driver disables all UHS speed modes by default and relies on the Device Tree node properties to enable these modes for SoC/Board combinations that support them. Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: block: Fix tag condition with packed writesAdrian Hunter
Apparently a cut-and-paste error, 'do_data_tag' is using 'brq' for data size even though 'brq' has not been set up. Instead use blk_rq_sectors(). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: core: Disable HPI for certain Hynix eMMC cardsPratibhasagar V
Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used and hence this patch disables the HPI feature for such buggy cards. As some of the other features like BKOPs/Cache/Sanitize are dependent on HPI feature, those features would also get disabled if HPI is disabled. Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> [gdavis: Forward port and cleanup] Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: core: Only change mode if mmc_select_bus_width() is successfulPeter Griffin
mmc_select_bus_width() returns bus width (4 or 8) on success or zero if unsupported. So only change mode if setting the bus width is successful. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: Set pref erase size based on sizeGwendal Grignou
If available, eMMC stack uses HC_ERASE_GRP_SIZE as the preferred erase size. As some high capacity eMMC (64MB) reports this size to 512kB, the discard operations end up taking very long time. Improve the behaviour by instead calculating the preferred erase size based on the eMMC size. In this way the discard operations becomes faster. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> [Ulf: Updated changelog and improved comment in code] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci-bcm2835: remove driverStefan Wahren
The sdhci-bcm2835 is no more needed since it has been replaced by sdhci-iproc. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: mmc: Fix HS switch failure in mmc_select_hs400()Ziyuan Xu
To slove the issue which was found on gru board for hs400. [ 4.616946] sdhci: Secure Digital Host Controller Interface driver [ 4.623135] sdhci: Copyright(c) Pierre Ossman [ 4.722575] sdhci-pltfm: SDHCI platform and OF driver helper [ 4.730962] sdhci-arasan fe330000.sdhci: No vmmc regulator found [ 4.737444] sdhci-arasan fe330000.sdhci: No vqmmc regulator found [ 4.774930] mmc0: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA [ 4.980295] mmc0: switch to high-speed from hs200 failed, err:-84 [ 4.986487] mmc0: error -84 whilst initialising MMC card We should change HS400 mode selection timing to meet JEDEC specification. The JEDEC 5.1 said that change the frequency to <= 52MHZ after HS_TIMING switch. Refer to section 6.6.2.3 "HS400" timing mode selection: Set the "Timing Interface" parameter in the HS_TIMING[185] field of the Extended CSD register to 0x1 to switch to High Speed mode and then set the clock frequency to a value not greater than 52MHZ. Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: mmc: fix switch timeout issue caused by jiffies precisionChaotian Jing
with CONFIG_HZ=100, the precision of jiffies is 10ms, and the generic_cmd6_time of some card is also 10ms. then, may be current time is only 5ms, but already timed out caused by jiffies precision. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: mmc: do not use CMD13 to get status after speed mode switchChaotian Jing
Per JEDEC spec, it is not recommended to use CMD13 to get card status after speed mode switch. below are two reason about this: 1. CMD13 cannot be guaranteed due to the asynchronous operation. Therefore it is not recommended to use CMD13 to check busy completion of the timing change indication. 2. After switch to HS200, CMD13 will get response of 0x800, and even the busy signal gets de-asserted, the response of CMD13 is aslo 0x800. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()Chaotian Jing
Some MMC hosts do not support MMC_CAP_WAIT_WHILE_BUSY, but implements the ->card_busy() callback. In such cases, extend __mmc_switch() to use this method to check card status after switch command. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci: Fix sdhci_card_busy()Adrian Hunter
host->card_busy() was introduced for SD voltage switching which checks all 4 data lines. Increasingly, host->card_busy is being used to poll the the busy signal which is only data line 0 (DAT[0]). The current logic in sdhci_card_busy() does not work in that case because it returns false if any of the data lines is high. It also ignores possibilities: - data lines 1-3 are not connected and could show at any level - data lines 1-2 can be used by SDIO for other purposes According to the SD specification, it is OK to check any of the data lines for voltage switching, so change to use DAT[0] only. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: tmio: make a cast explicitWolfram Sang
Sparse complains about the implicit cast. Making it explicit is indeed better coding style. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci-of-arasan: implement enhanced strobe callbackShawn Lin
Currently sdhci-arasan 5.1 can support enhanced strobe function, and we now limit it just for "arasan,sdhci-5.1". Add mmc-hs400-enhanced-strobe in DT to enable the function if we're sure our controller can support it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: debugfs: add HS400 enhanced strobe descriptionShawn Lin
We introduce HS400 with enhanced strobe function, so we need to add it for debug show. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: core: implement enhanced strobe supportShawn Lin
Controllers use data strobe line to latch data from devices under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC introduces enhanced strobe mode for latching cmd response from emmc devices to host controllers. This new feature is optional, so it depends both on device's cap and host's cap to decide whether to use it or not. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: core: add mmc-hs400-enhanced-strobe supportShawn Lin
This patch introduce mmc-hs400-enhanced-strobe for platforms which want to enable enhanced strobe function from DT if the mmc host controller claims to support enhanced strobe. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci: fix wakeup configurationLudovic Desroches
Activating wakeup event is not enough to get a wakeup signal. The corresponding events have to be enabled in the Interrupt Status Enable Register too. It follows the specification and is needed at least by sdhci-of-at91. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: block: correct 4KB alignment checkYuan, Juntao
In sectors alignment check, brq->data.blocks means sectors of the previous mqrq since data.blocks for mqrq_cur hasn't been updated yet. data.blocks will be updated later in mmc_blk_packed_hdr_wrq_prep or mmc_blk_rw_rq_prep. static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, ...... ...... struct mmc_blk_request *brq = &mq->mqrq_cur->brq; Signed-off-by: Yuan Juntao <juntao.yuan@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sdhci: remove comment regarding timeout during tuningSimon Horman
Since commit 7ce45e950624 ("mmc: sdhci: SD tuning is broken for some controllers") sdhci_execute_tuning() no longer includes a timeout in its loop counter(s) so remove portion of the comment regarding this. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25mmc: sh_mobile_sdhi: properly document R-Car versionsWolfram Sang
Replace hardcoded values with meaningful names and document what we know. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-18mmc: pxamci: fix potential oopsRobert Jarzmik
As reported by Dan in his report in [1], there is a potential NULL pointer derefence if these conditions are met : - there is no platform_data provided, ie. host->pdata = NULL Fix this by only using the platform data ro_invert when a gpio for read-only is provided by the platform data. This doesn't appear yet as every pxa board provides a platform_data, and calls pxa_set_mci_info() with a non NULL pointer. [1] [bug report] mmc: pxamci: fix card detect with slot-gpio API. The commit fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio API") from Sep 26, 2015, leads to the following static checker warning: drivers/mmc/host/pxamci.c:809 pxamci_probe() warn: variable dereferenced before check 'host->pdata' (see line 798) Fixes: fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio API") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-18mmc: block: fix packed command header endiannessTaras Kondratiuk
The code that fills packed command header assumes that CPU runs in little-endian mode. Hence the header is malformed in big-endian mode and causes MMC data transfer errors: [ 563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40 [ 563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1 Convert header data to LE. Signed-off-by: Taras Kondratiuk <takondra@cisco.com> Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-18mmc: block: fix free of uninitialized 'idata->buf'Ville Viinikka
Set 'idata->buf' to NULL so that it never gets returned without initialization. This fixes a bug where mmc_blk_ioctl_cmd() would free both 'idata' and 'idata->buf' but 'idata->buf' was returned uninitialized. Fixes: 1ff8950c0433 ("mmc: block: change to use kmalloc when copy data from userspace") Signed-off-by: Ville Viinikka <ville@tuxera.com> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-07timers: Remove set_timer_slack() leftoversThomas Gleixner
We now have implicit batching in the timer wheel. The slack API is no longer used, so remove it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andrew F. Davis <afd@ti.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Chris Mason <clm@fb.com> Cc: David S. Miller <davem@davemloft.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: George Spelvin <linux@sciencehorizons.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: John Stultz <john.stultz@linaro.org> Cc: Josh Triplett <josh@joshtriplett.org> Cc: Len Brown <lenb@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mathias Nyman <mathias.nyman@intel.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@redhat.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: linux-block@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: netdev@vger.kernel.org Cc: rt@linutronix.de Link: http://lkml.kernel.org/r/20160704094342.189813118@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-22mmc: move 'parent' tracking to mmc_blk_dataDan Williams
In preparation for the removal of 'driverfs_dev' from 'struct gendisk', carry this data in mmc_blk_data. It is used for registration of parent disks and partitions. Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-06-09block: add a separate operation type for secure eraseChristoph Hellwig
Instead of overloading the discard support with the REQ_SECURE flag. Use the opportunity to rename the queue flag as well, and remove the dead checks for this flag in the RAID 1 and RAID 10 drivers that don't claim support for secure erase. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
2016-06-08x86, mmc: Use Intel family name macros for mmc driverDave Hansen
Another straightforward replacement of magic numbers. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: jacob.jun.pan@intel.com Cc: linux-mmc@vger.kernel.org Link: http://lkml.kernel.org/r/20160603001951.9EEA53D8@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-07block, drivers: add REQ_OP_FLUSH operationMike Christie
This adds a REQ_OP_FLUSH operation that is sent to request_fn based drivers by the block layer's flush code, instead of sending requests with the request->cmd_flags REQ_FLUSH bit set. Signed-off-by: Mike Christie <mchristi@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2016-06-07drivers: use req op accessorMike Christie
The req operation REQ_OP is separated from the rq_flag_bits definition. This converts the block layer drivers to use req_op to get the op from the request struct. Signed-off-by: Mike Christie <mchristi@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2016-06-02mmc: sunxi: Re-enable eMMC HS-DDR modes on Allwinner A80Chen-Yu Tsai
Now the the HS-DDR mode clock timings have been corrected, we can re-enable these modes on the A80. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>