summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2018-03-22mmc: renesas_sdhi: replace EXT_ACC with HOST_MODEMasaharu Hayakawa1-3/+3
All our documentation says HOST_MODE, we don't really know where EXT_ACC came from. Rename it to reduce the confusion. Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-22mmc: update sdio_claim_irq documentationJoel Cunningham1-2/+2
Update documentation for sdio_claim_irq to downgrade the wording about doing recursive claims in an IRQ handler from 'must not' to 'should not'. This clarifies that recursive claims are supported, but not the recommended (best) practice Signed-off-by: Joel Cunningham <joel.cunningham@garmin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-22mmc: Export host capabilities to debugfs.Abbas Raza1-0/+6
This patch exports the host capabilities to debugfs Signed-off-by: Abbas Raza <Abbas_Raza@mentor.com> Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> [Harish: Added caps2, moved creation to mmc_add_host_debugfs] Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-21Merge branch 'fixes' into nextUlf Hansson1-1/+1
2018-03-21mmc: sdhci-acpi: Fix IRQ 0Adrian Hunter1-1/+1
Zero is a valid IRQ number and is being used on some CHT tablets. Stop treating it as an error. Reported-by: Luke Ross <luke@lukeross.name> Fixes: 1b7ba57ecc86 ("mmc: sdhci-acpi: Handle return value of platform_get_irq") Cc: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-16Merge branch 'fixes' into nextUlf Hansson1-2/+4
2018-03-16mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occursEvgeniy Didin1-2/+4
It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeout overflow calculation failure: 1. soft-reset is called 2. driver restarts dma 3. descriptors states are checked, one of descriptor is owned by the IDMAC. 4. driver can't use DMA and then switches to PIO mode. Failure was already fixed in: https://www.spinics.net/lists/linux-mmc/msg48125.html. Behaviour while soft-reset is not something we except or even want to happen. So we switch from dw_mci_idmac_reset to dw_mci_idmac_init, so descriptors are cleaned before starting dma. And while at it explicitly zero des0 which otherwise might contain garbage as being allocated by dmam_alloc_coherent(). Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Cc: linux-snps-arc@lists.infradead.org Cc: <stable@vger.kernel.org> # 4.4+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15Merge branch 'fixes' into nextUlf Hansson1-1/+7
2018-03-15mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cardsDirk Behme2-0/+7
Certain Micron eMMC v4.5 cards might get broken when HPI feature is used and hence this patch disables the HPI feature for such buggy cards. In U-Boot, these cards are reported as Manufacturer: Micron (ID: 0xFE) OEM: 0x4E Name: MMC32G Revision: 19 (0x13) Serial: 959241022 Manufact. date: 8/2015 (0x82) CRC: 0x00 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.5 High Capacity: Yes Capacity: 29.1 GiB Boot Partition Size: 16 MiB Bus Width: 8-bit According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by Micron. Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Mark Craske <Mark_Craske@mentor.com> Cc: <stable@vger.kernel.org> # 4.8+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: block: fix updating ext_csd caches on ioctl callBastian Stender1-0/+19
PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the currently active partition in mmc_blk_data->part_curr. These caches do not always reflect changes if the ioctl call modifies the PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE. Write the PARTITION_CONFIG value extracted from the ioctl call to the cache and update the currently active partition accordingly. This ensures that the user space cannot change the values behind the kernel's back. The next call to mmc_blk_part_switch() will operate on the data set by the ioctl and reflect the changes appropriately. Signed-off-by: Bastian Stender <bst@pengutronix.de> Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: sunxi: Set our device drvdata earlierMaxime Ripard1-1/+1
As soon as the pm_runtime_enable hook is called, our runtime_suspend and runtime_resume hooks can be called as well. However, we only set the device drvdata that we will use after we have registered into the MMC core. Move that earlier so that we don't have a race that could lead to a crash. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: sunxi: Move the reset deassertion before enabling the clocksMaxime Ripard1-18/+18
As per Allwinner guidelines, the reset line should be deasserted before turning the clocks on. Implement it in our driver as well. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: sunxi: Move resources management to separate functionsMaxime Ripard1-60/+82
We've had all our resources management, and especially the clocks and reset sequence, done directly as part of the probe. As we want to implement runtime_pm, we'll obviously want to have that moved outside of the probe so that we can call do it in our runtime suspend and resume hooks without too much duplication. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: add support for hi3798cv200 specific extensions of dw-mshctianshuliang4-0/+218
Hi3798CV200 SoC extends the dw-mshc controller for additional clock and bus control. Add support for these extensions. Signed-off-by: tianshuliang <tianshuliang@hisilicon.com> Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: core: Export card RCA register via sysfsHarish Jenny K N2-0/+4
This patch exports RCA register to sysfs which will help in reading the disk identification information. Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cardsDirk Behme2-0/+7
Certain Micron eMMC v4.5 cards might get broken when HPI feature is used and hence this patch disables the HPI feature for such buggy cards. In U-Boot, these cards are reported as Manufacturer: Micron (ID: 0xFE) OEM: 0x4E Name: MMC32G Revision: 19 (0x13) Serial: 959241022 Manufact. date: 8/2015 (0x82) CRC: 0x00 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.5 High Capacity: Yes Capacity: 29.1 GiB Boot Partition Size: 16 MiB Bus Width: 8-bit According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by Micron. Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Mark Craske <Mark_Craske@mentor.com> Cc: <stable@vger.kernel.org> # 4.8+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433Jaehoon Chung1-1/+7
Before enabling the clock, dwmmc exynos driver is trying to access the register. Then the kernel panic can be occurred. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: block: fix updating ext_csd caches on ioctl callBastian Stender1-0/+19
PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the currently active partition in mmc_blk_data->part_curr. These caches do not always reflect changes if the ioctl call modifies the PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE. Write the PARTITION_CONFIG value extracted from the ioctl call to the cache and update the currently active partition accordingly. This ensures that the user space cannot change the values behind the kernel's back. The next call to mmc_blk_part_switch() will operate on the data set by the ioctl and reflect the changes appropriately. Signed-off-by: Bastian Stender <bst@pengutronix.de> Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: renesas_sdhi: fix WP detectionWolfram Sang2-4/+0
Commit "mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag" activated MMC_CAP2_NO_WRITE_PROTECT for Renesas SDHI which incorrectly disabled WP altogether instead of only disabling the internal mechanism. Since the whole WP handling has been reworked, we can simply disable this capability to re-enable WP GPIOs. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: core: Use memdup_user() rather than duplicating its implementationMarkus Elfring1-11/+4
Reuse existing functionality from memdup_user() instead of keeping duplicate source code. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc-rockchip: correct property names in debugJohn Keeping1-2/+2
Following up the device tree fixed in commits e78c637127ee ("ARM: dts: rockchip: Fix DWMMC clocks") and ca9eee95a2de ("arm64: dts: rockchip: Fix DWMMC clocks", 2018-02-15), avoid confusion by using the correct property name in the debug output if clocks are not found. Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: sd: Remove redundant err assignment from mmc_read_switchShawn Lin1-2/+0
Variable err would be firstly initialized by the return value of mmc_sd_switch(). Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: sdio: Check the return value of sdio_enable_4bit_busShawn Lin1-5/+4
Since we could move card->host->caps & MMC_CAP_4_BIT_DATA ahead of mmc_sdio_init_uhs_card, in mmc_host_uhs(). So there we could save this bit to check that. Also, if the process of sdio_enable_4bit_bus goes wrong, we should bails out early. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: core: Don't try UHS-I mode if 4-bit mode isn't supportedShawn Lin2-12/+7
Per SD specification physical layer v4.0, section 3.9.4, it says "UHS-I supports only 4-bit mode. Host shall select 4-bit mode by ACMD6. However mmc_sd_init_uhs_card() still go ahead to initialize the cards anyway, whether card or host won't support 4-bit mode. This breaks the platforms which could support UHS-I mode but on some certain boards only support 1-bit mode with a UHS-I card inserted, as all the tuning process is broken due to this. Alternatively, we should check the return value from mmc_set_bus_width() to see if host could finish the request to switch the bus width on its side. But that needs more thing to do than this patch that just bails out early to try high speed mode if 4-bit mode isn't available for whatever reason. And this patch could also fix the same problem for sdio since R4_18V_PRESENT won't be set for ocr when mmc_sdio_init_card() finds mmc_host_uhs() is false. Note that this patch doesn't keep the checking of card->scr.sda_spec3 and comparing card->scr.bus_widths with SD_SCR_BUS_WIDTH_4 within mmc_sd_init_uhs_card() since if the sd cards response with SD_ROCR_S18A, it definitely supports UHS-I mode, which implicitly means these checkings are always true. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: remove the deprecated "num-slots"Jaehoon Chung3-7/+0
'num-slots' property had already deprecated. Remove the 'nom-slots' property that is kept to maintain the compatibility. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-15mmc: dw_mmc: remove the deprecated "clock-freq-min-max" propertyJaehoon Chung1-11/+4
'clock-freq-min-max' property had already deprecated. Remove the 'clock-freq-min-max' property that is kept to maintain the compatibility. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05Merge branch 'fixes' into nextUlf Hansson1-3/+6
2018-03-05mmc: mediatek: add support for MT7622 SoCSean Wang1-0/+12
Just applying the existing logic and adding its own characteristics into the space pointed by an extra entry of struct of_device_id to have support of MT7622 SoC. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Tested-by: Jumin Li <jumin.li@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-pci: Respect PM flags when enabling card detect GPIO IRQ wakeupAdrian Hunter2-6/+19
Commit 03dbaa04a2e5 ("mmc: slot-gpio: Add support to enable irq wake on cd_irq") enabled wakeup at initialization. However, users also want to control it from sysfs power/wakeup attribute. That means the driver needs to check the PM flags before enabling it in the suspend callback. Add support for that in sdhci-pci, which is the only driver presently using the MMC_CAP_CD_WAKE flag, and remove the enabling in mmc_gpiod_request_cd_irq() Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: slot-gpio: Add a function to enable/disable card detect IRQ wakeupAdrian Hunter2-2/+22
Commit 03dbaa04a2e5 ("mmc: slot-gpio: Add support to enable irq wake on cd_irq") enabled wakeup at initialization. However drivers may wish to enable and disable based on different criteria. Add a helper function mmc_gpio_set_cd_wake() to make it easy for drivers to do that. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci: Do not unnecessarily enable wakeup for SDIO card interruptAdrian Hunter1-2/+7
Do not enable wakeup for SDIO card interrupt unless the SDIO function driver has requested it which is indicated by mmc_card_wake_sdio_irq(). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci: Do not unnecessarily enable wakeup for card detect interruptAdrian Hunter1-1/+9
Do not unnecessarily enable card detect wakeup in the cases that the card is not removable or a GPIO is used for card detect. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: sdhci-pci: Get rid of glk_cqe_enable()Adrian Hunter1-19/+1
Now that tuning no longer leaves the Buffer Read Enable bit set (refer intel_execute_tuning()), glk_cqe_enable() is no longer needed. Get rid of it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: ushc: Remove bogus check of usb_submit_urbShawn Lin1-2/+0
Not sure why it was there in the first place, but it's obviously useless check, so let's remove it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: dw_mmc: update kernel-doc comments for dw_mciAlexey Roslyakov1-10/+9
cur_slot and num_slots has been removed from struct dw_mci in 42f989c002f2. Unfortunately, inline documentation was not updated so far. Fix @lock field documentation in Locking section. Move @mrq field of struct dw_mci_slot mention closer to it description, so no one could miss this slightest detail. Couple of code style fixes as a bonus. Signed-off-by: Alexey Roslyakov <alexey.roslyakov@gmail.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: dw_mmc: Remove prev_state and state assignment for STATE_SENDING_CMDShawn Lin1-1/+0
Clang reports a compile warning: drivers/mmc/host/dw_mmc.c:2124:5: warning: Value stored to 'prev_state' is never read By checking the code, prev_state and state assignment for STATE_SENDING_CMD is indeed never used after jumping to unlock tag. So remove it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: dw_mmc: Convert to use DEFINE_SHOW_ATTRIBUTEShawn Lin1-26/+2
Use the newly added macro to simply to the code. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: core: Re-use DEFINE_SHOW_ATTRIBUTE() macroAndy Shevchenko1-12/+1
...instead of open coding file operations followed by custom ->open() callbacks per each attribute. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Avri Altman <avri.altman@wdc.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: remove useless TMIO_MASK_CMD handling in tmio_mmc_host_probe()Masahiro Yamada1-3/+0
TMIO_MASK_CMD is properly enabled in tmio_mmc_start_command(). We have no reason to set it up in tmio_mmc_host_probe(). (If we really wanted to set it in the probe, we would have to do likewise when resuming.) Even worse, the following code is extremely confusing: _host->sdcard_irq_mask &= ~irq_mask; The logic is opposite between "->sdcard_irq_mask" and "irq_mask". The intention is not clear at a glance. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: clear force_pio flag before starting data transferMasahiro Yamada1-3/+1
Currently, force_pio is cleared when the driver exits. Then, it resulted in clearing it in multiple places since MMC drivers in general have multiple exit points. tmio_mmc_reset_work - bails out on timeout tmio_process_mrq - error out when it cannot send a command tmio_mmc_finish_request - successful exit This is error-prone since we may miss to cover all bail-out points. To simplify the code, the data structure should be initialized just before used since we have a single entrance. force_pio is only used for data transfer, so tmio_mmc_start_data() will be a suitable place to clear this flag. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: move TMIO_MASK_{READOP, WRITEOP} handling to correct placeMasahiro Yamada3-20/+10
As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ} are asserted for DMA mode as well as for PIO. I need to disable the those IRQs in dma_ops->start hook, otherwise the DMA transfer fails with the following error message: PIO IRQ in DMA mode! Renesas chips are the same cases since I see their dma_ops->start hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!). If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling should be entirely moved to the core. tmio_mmc_cmd_irq() will be a suitable place to disable them. The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd. /* Unmask the IRQs we want to know about */ if (!_host->chan_rx) irq_mask |= TMIO_MASK_READOP; if (!_host->chan_tx) irq_mask |= TMIO_MASK_WRITEOP; At this point, _host->{chan_rx,chan_tx} are _always_ NULL because tmio_mmc_request_dma() is called after this code. Consequently, TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not. Remove this pointless code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: fix never-detected card insertion bugMasahiro Yamada1-4/+8
The TMIO mmc cannot detect the card insertion in native_hotplug mode if the driver is probed without a card inserted. The reason is obvious; all IRQs are disabled by tmio_mmc_host_probe(), as follows: tmio_mmc_disable_mmc_irqs(_host, TMIO_MASK_ALL); The card event IRQs are first enabled by tmio_mmc_start_command() as follows: if (!host->native_hotplug) irq_mask &= ~(TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT); tmio_mmc_enable_mmc_irqs(host, irq_mask); If the driver is probed without a card, tmio_mmc_start_command() is never called in the first place. So, the card is never detected. The card event IRQs must be enabled in probe/resume functions. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: support IP-builtin card detection logicMasahiro Yamada1-1/+12
A card detect GPIO is set up only for platforms with "cd-gpios" DT property or TMIO_MMC_USE_GPIO_CD flag. However, the driver core always uses mmc_gpio_get_cd, which just fails with -ENOSYS if ctx->cd_gpio is unset. The bit 5 of the status register provides the current signal level of the CD line. Allow to use it if the GPIO is unused. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systemsEvgeniy Didin1-3/+6
The commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") and commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation") made changes, which cause multiply overflow for 32-bit systems. The broken timeout calculations leads to unexpected ETIMEDOUT errors and causes stacktrace splat (such as below) during normal data exchange with SD-card. | Running : 4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1 | - Info: Finished target initialization. | mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd | response 0x900, card status 0x0 DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so code gets compiled on all 32-bit platforms as opposed to usage of DIV_ROUND_UP when we may only compile stuff on a very few arches. Lets cast this multiply to u64 type to prevent the overflow. Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") Fixes: 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation") Tested-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com> Cc: <stable@vger.kernel.org> # 4.14 Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: tmio: deprecate "toshiba, mmc-wrprotect-disable" DT propertyMasahiro Yamada1-0/+5
This property is equivalent to "disable-wp" defined in Documentation/devicetree/bindings/mmc/mmc.txt The TMIO MMC core calls mmc_of_parse(), and it sets MMC_CAP2_NO_WRITE_PROTECT if "disable-wp" property is present. We do not need a vendor-specific property to do the same thing. Let's remove the description from the dt-binding to prevent new boards from using it. I am keeping the driver code for existing DT files, but added comments that this is deprecated. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: remove TMIO_MMC_WRPROTECT_DISABLEMasahiro Yamada1-3/+2
The use of this flag has been replaced with MMC_CAP2_NO_WRITE_PROTECT. No platform defines this flag any more. Remove. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: tmio: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flagMasahiro Yamada1-3/+3
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT. Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection). The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the possibility, if any, would be DT specifies "wp-gpios" property, and gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse(). However, it does not make sense to specify "wp-gpios" property and "toshiba,mmc-wrprotect-disable" at the same time. I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/, and I did not see any Renesas boards with "wp-gpios". So, this conversion should be safe. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flagMasahiro Yamada2-11/+11
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT. The flag is propagated as follows: renesas_sdhi_of_data::capabilities2 -> tmio_mmc_data::capabilities2 -> mmc_host::caps2 Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection). The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the possibility, if any, would be DT specifies "wp-gpios" property, and gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse(). However, it does not make sense to specify "wp-gpios" property and TMIO_MMC_WRPROTECT_DISABLE at the same time. I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/, and I did not see any Renesas boards with "wp-gpios". So, this conversion should be safe. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2018-03-05mmc: sdhci-iproc: Disable preset values for BCM2835Stefan Wahren1-0/+1
According to the BCM2835 datasheet there are no preset value registers. This wasn't an issue before, because we didn't propagate 1.8V support. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-03-05mmc: core: optimize mmc_calc_max_discardSergio Valverde1-1/+1
If the max_discard value is zero, the conditional branch that checks the trim capabilities will never update this value with max_trim. Change the condition statement to also check the max_discard value in order to avoid an unnecessary call to mmc_do_calc_max_discard. Signed-off-by: Sergio Valverde <vlvrdv@gmail.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>