Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43 |
|
#
b76028c7 |
| 27-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
mmc: omap_hsmmc: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do err
mmc: omap_hsmmc: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Link: https://lore.kernel.org/r/20230727070051.17778-11-frank.li@vivo.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38 |
|
#
9a2fdd2e |
| 04-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
mmc: omap_hsmmc: Use devm_platform_get_and_ioremap_resource()
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactl
mmc: omap_hsmmc: Use devm_platform_get_and_ioremap_resource()
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com> Link: https://lore.kernel.org/r/20230704131939.22562-2-frank.li@vivo.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.37, v6.1.36, v6.4, v6.1.35 |
|
#
fb51b74a |
| 17-Jun-2023 |
Sergey Shtylyov <s.shtylyov@omp.ru> |
mmc: omap_hsmmc: fix deferred probing
The driver overrides the error codes returned by platform_get_irq() to -ENXIO, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instea
mmc: omap_hsmmc: fix deferred probing
The driver overrides the error codes returned by platform_get_irq() to -ENXIO, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instead of the deferred probing. Switch to propagating the error codes upstream.
Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/20230617203622.6812-7-s.shtylyov@omp.ru Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17 |
|
#
ca6b5fe2 |
| 10-Mar-2023 |
Rob Herring <robh@kernel.org> |
mmc: Use of_property_read_bool() for boolean properties
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_
mmc: Use of_property_read_bool() for boolean properties
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool().
Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144715.1543836-1-robh@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78 |
|
#
a525cad2 |
| 08-Nov-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
mmc: omap_hsmmc: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is
mmc: omap_hsmmc: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del().
Fix this by checking the return value and goto error path wihch will call mmc_free_host().
Fixes: a45c6cb81647 ("[ARM] 5369/1: omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221108121316.340354-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2 |
|
#
dfb654f1 |
| 10-Nov-2021 |
H. Nikolaus Schaller <hns@goldelico.com> |
mmc: omap_hsmmc: Revert special init for wl1251
Due to recent changes to the mmc core, card quirks can be applied based upon a compatible string in child OF node. The quirk needed for wl1251 (SDIO c
mmc: omap_hsmmc: Revert special init for wl1251
Due to recent changes to the mmc core, card quirks can be applied based upon a compatible string in child OF node. The quirk needed for wl1251 (SDIO card) is managed in the core, therefore there is no longer any reason to deal with this in omap_hsmmc too, so let's remove it.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/77d313b97d1e18b0eb7ed2d88d718d960f329bb0.1636564631.git.hns@goldelico.com [Ulf: Re-wrote the commit message to make it more clear] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5 |
|
#
8c2db344 |
| 16-Sep-2021 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
dt-bindings: mmc: update mmc-card.yaml reference
The recent change ("dt-bindings: mmc: Convert MMC Card binding to a schema") renamed: Documentation/devicetree/bindings/mmc/mmc-card.txt to: Document
dt-bindings: mmc: update mmc-card.yaml reference
The recent change ("dt-bindings: mmc: Convert MMC Card binding to a schema") renamed: Documentation/devicetree/bindings/mmc/mmc-card.txt to: Documentation/devicetree/bindings/mmc/mmc-card.yaml.
Let's update its cross-reference accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/820bb7a1d7e0e51cbea72c9bee6bce806427d1f3.1631785820.git.mchehab+huawei@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63 |
|
#
c88cb98e |
| 06-Sep-2021 |
Cai Huoqing <caihuoqing@baidu.com> |
mmc: omap_hsmmc: Make use of the helper macro SET_RUNTIME_PM_OPS()
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNT
mmc: omap_hsmmc: Make use of the helper macro SET_RUNTIME_PM_OPS()
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little more concise.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210907025940.1535-1-caihuoqing@baidu.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
eab234fc |
| 15-Jan-2021 |
Yang Li <abaci-bugfix@linux.alibaba.com> |
mmc: omap_hsmmc: Simplify bool comparison and conversion
Fix the following coccicheck warning: ./drivers/mmc/host/omap_hsmmc.c:297:6-25: WARNING: Comparison of 0/1 to bool variable
According to the
mmc: omap_hsmmc: Simplify bool comparison and conversion
Fix the following coccicheck warning: ./drivers/mmc/host/omap_hsmmc.c:297:6-25: WARNING: Comparison of 0/1 to bool variable
According to the context, vqmmc_enabled is more suitable for bool type.
Reported-by: Abaci Robot<abaci@linux.alibaba.com> Signed-off-by: Yang Li <abaci-bugfix@linux.alibaba.com> Link: https://lore.kernel.org/r/1610704281-11036-1-git-send-email-abaci-bugfix@linux.alibaba.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7 |
|
#
21b2cec6 |
| 03-Sep-2020 |
Douglas Anderson <dianders@chromium.org> |
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4
This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous probe") but applied to a whole pile of drivers. This batch
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4
This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous probe") but applied to a whole pile of drivers. This batch converts the drivers that appeared to be around in the v4.4 timeframe.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # SH_MMCIF Tested-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200903162412.1.Id501e96fa63224f77bb86b2135a5e8324ffb9c43@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.8.6, v5.4.62 |
|
#
77811ffa |
| 03-Sep-2020 |
Xu Wang <vulab@iscas.ac.cn> |
mmc: omap-hsmmc: remove redundant null check
Because clk_disable_unprepare already checked NULL clock parameter, so the additional checks are unnecessary, just remove them.
Signed-off-by: Xu Wang <
mmc: omap-hsmmc: remove redundant null check
Because clk_disable_unprepare already checked NULL clock parameter, so the additional checks are unnecessary, just remove them.
Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Link: https://lore.kernel.org/r/20200903084825.85616-1-vulab@iscas.ac.cn Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40 |
|
#
1be64c79 |
| 08-May-2020 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: host: Drop redundant MMC_CAP_ERASE
The MMC_CAP_ERASE bit is no longer used by the mmc core as erase, discard and trim operations are now always supported. Therefore, drop the bit and move all m
mmc: host: Drop redundant MMC_CAP_ERASE
The MMC_CAP_ERASE bit is no longer used by the mmc core as erase, discard and trim operations are now always supported. Therefore, drop the bit and move all mmc hosts away from using it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com> Link: https://lore.kernel.org/r/20200508112902.23575-1-ulf.hansson@linaro.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
show more ...
|
Revision tags: v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3 |
|
#
9f888b55 |
| 06-Dec-2019 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: omap_hsmmc: Convert to pinctrl_select_default_state()
Let's drop the boilerplate code for managing the default pinctrl state and convert into using the new pinctrl_select_default_state().
Addi
mmc: omap_hsmmc: Convert to pinctrl_select_default_state()
Let's drop the boilerplate code for managing the default pinctrl state and convert into using the new pinctrl_select_default_state().
Additionally, move away from using pinctrl_pm_select_default_state() as it's scheduled for removal and use pinctrl_select_default_state() instead.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191206170821.29711-6-ulf.hansson@linaro.org
show more ...
|
Revision tags: v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10 |
|
#
4d219f4c |
| 07-Nov-2019 |
H. Nikolaus Schaller <hns@goldelico.com> |
mmc: host: omap-hsmmc: remove init_card pdata callback from pdata
Now as we have removed the last user (pandora_wl1251_init_card) of this callback, we can remove it from the hsmmc code.
Suggested-b
mmc: host: omap-hsmmc: remove init_card pdata callback from pdata
Now as we have removed the last user (pandora_wl1251_init_card) of this callback, we can remove it from the hsmmc code.
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
f6498b92 |
| 07-Nov-2019 |
H. Nikolaus Schaller <hns@goldelico.com> |
mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card
Pandora_wl1251_init_card was used to do special pdata based setup of the sdio mmc interface. This do
mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card
Pandora_wl1251_init_card was used to do special pdata based setup of the sdio mmc interface. This does no longer work with v4.7 and later. A fix requires a device tree based mmc3 setup.
Therefore we move the special setup to omap_hsmmc.c instead of calling some pdata supplied init_card function.
The new code checks for a DT child node compatible to wl1251 so it will not affect other MMC3 use cases.
Generally, this code was and still is a hack and should be moved to mmc core to e.g. read such properties from optional DT child nodes.
Fixes: 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: <stable@vger.kernel.org> # v4.7+ [Ulf: Fixed up some checkpatch complaints] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10 |
|
#
7fc13b87 |
| 23-Apr-2019 |
Kefeng Wang <wangkefeng.wang@huawei.com> |
mmc: omap_hsmmc: Use dev_get_drvdata()
Using dev_get_drvdata directly.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
Revision tags: v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9 |
|
#
0b479790 |
| 11-Dec-2018 |
Russell King <rmk+kernel@armlinux.org.uk> |
mmc: omap_hsmmc: fix DMA API warning
While booting with rootfs on MMC, the following warning is encountered on OMAP4430:
omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer
mmc: omap_hsmmc: fix DMA API warning
While booting with rootfs on MMC, the following warning is encountered on OMAP4430:
omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer than device claims to support [len=69632] [max=65536]
This is because the DMA engine has a default maximum segment size of 64K but HSMMC sets:
mmc->max_blk_size = 512; /* Block Length at max can be 1024 */ mmc->max_blk_count = 0xFFFF; /* No. of Blocks is 16 bits */ mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count; mmc->max_seg_size = mmc->max_req_size;
which ends up telling the block layer that we support a maximum segment size of 65535*512, which exceeds the advertised DMA engine capabilities.
Fix this by clamping the maximum segment size to the lower of the maximum request size and of the DMA engine device used for either DMA channel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.19.8, v4.19.7 |
|
#
8ceb2943 |
| 01-Dec-2018 |
Yangtao Li <tiny.windzz@gmail.com> |
mmc: convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
Revision tags: v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10 |
|
#
e63201f1 |
| 24-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
mmc: omap_hsmmc: Delete platform data GPIO CD and WP
The OMAP HSMMC driver has some elaborate and hairy handling for passing GPIO card detect and write protect lines from a boardfile into the driver
mmc: omap_hsmmc: Delete platform data GPIO CD and WP
The OMAP HSMMC driver has some elaborate and hairy handling for passing GPIO card detect and write protect lines from a boardfile into the driver: the machine defines a struct omap2_hsmmc_info that is copied into struct omap_hsmmc_platform_data by omap_hsmmc_pdata_init() in arch/arm/mach-omap2/hsmmc.c.
However the .gpio_cd and .gpio_wp fields are not copied from omap2_hsmmc_info to omap_hsmmc_platform_data by omap_hsmmc_pdata_init() so they remain unused. The only platform defining omap2_hsmmc_info also define both to -1, unused.
It turn out there are no boardfiles passing any valid GPIO lines into the OMAP HSMMC driver at all. And since we are not going to add any more OMAP2 boardfiles, we can delete this card detect and write protect handling altogether.
This seems to also fix a bug: the card detect callback mmc_gpio_get_cd() in the slot GPIO core needs to be called by drivers utilizing slot GPIO. It appears the the boardfile quirks were not doing this right, so this would only get called for boardfiles, i.e. since no boardfile was using it, never.
Just assign mmc_gpio_get_cd() unconditionally to omap_hsmmc_ops .get_cd() so card detects from the device tree works. AFAICT card detect with GPIO lines assigned from mmc_of_parse() are not working at the moment, but that is no regression since it probably never worked.
Cc: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
7838a8dd |
| 24-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
mmc: omap_hsmmc: Kill off cover detection
Cover detection appears to be a feature protecting the SD card on mobile phones with a slide-cover, such as some Nokia phones. The idea seems to be to not a
mmc: omap_hsmmc: Kill off cover detection
Cover detection appears to be a feature protecting the SD card on mobile phones with a slide-cover, such as some Nokia phones. The idea seems to be to not allow access to the SD card when the cover is open.
It is only usable with platform data from board files, but no board file in the kernel is using it, yet it takes up a sizeable chunk of code in the OMAP HSMMC driver.
Since we do not add new board files for the OMAPs any target that need this should anyway reimplement it properly using the device tree, so delete this legacy code.
The driver is marked as orphan in MAINTAINERS by the way.
Cc: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.18.9, v4.18.7, v4.18.6 |
|
#
3c398f3c |
| 02-Sep-2018 |
Andreas Kemnade <andreas@kemnade.info> |
mmc: omap_hsmmc: fix wakeirq handling on removal
after unbinding mmc I get things like this: [ 185.294067] mmc1: card 0001 removed [ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -
mmc: omap_hsmmc: fix wakeirq handling on removal
after unbinding mmc I get things like this: [ 185.294067] mmc1: card 0001 removed [ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13
The wakeirq stays in /proc-interrupts
rebinding shows this: [ 289.795959] genirq: Flags mismatch irq 112. 0000200a (480b4000.mmc:wakeup) vs. 0000200a (480b4000.mmc:wakeup) [ 289.808959] omap_hsmmc 480b4000.mmc: Unable to request wake IRQ [ 289.815338] omap_hsmmc 480b4000.mmc: no SDIO IRQ support, falling back to polling
That bug seems to be introduced by switching from devm_request_irq() to generic wakeirq handling.
So let us cleanup at removal.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Fixes: 5b83b2234be6 ("mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq") Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14 |
|
#
3b649a73 |
| 14-Oct-2017 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: omap_hsmmc: catch all errors when getting regulators
Bail out everytime when mmc_regulator_get_supply() returns an errno, not only when probing gets deferred. This is currently a no-op, because
mmc: omap_hsmmc: catch all errors when getting regulators
Bail out everytime when mmc_regulator_get_supply() returns an errno, not only when probing gets deferred. This is currently a no-op, because this function only returns -EPROBE_DEFER or 0 right now. But if it will throw another error somewhen, it will be for a reason. (This still doesn't change that getting regulators is optional, so 0 can still mean no regulators found). So, let us a) be future proof and b) have driver code which is easier to understand.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.13.5, v4.13 |
|
#
66162bec |
| 31-Aug-2017 |
Kishon Vijay Abraham I <kishon@ti.com> |
mmc: host: omap_hsmmc: Remove setting PBIAS voltage
PBIAS voltage should be set along with setting vqmmc voltage and these voltages should be set as part of start_signal_voltage_switch callback. How
mmc: host: omap_hsmmc: Remove setting PBIAS voltage
PBIAS voltage should be set along with setting vqmmc voltage and these voltages should be set as part of start_signal_voltage_switch callback. However since omap_hsmmc is about to be deprecated, remove setting of PBIAS voltage leaving the PBIAS voltage to be at the reset value of 3.3V (we'll never have to change this to 1.8V since UHS mode support will not be added to omap_hsmmc). This will let pbias regulator driver to be fixed to support a maximum voltage of 3.3V.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.12 |
|
#
94424004 |
| 22-Jun-2017 |
Will Newton <will.newton@gmail.com> |
mmc: omap_hsmmc: Reduce max_segs for reliability
Reduce max_segs to 64, a value that allows allocation of an entire EDMA descriptor list within a single page - EDMA descriptors are 40 bytes and the
mmc: omap_hsmmc: Reduce max_segs for reliability
Reduce max_segs to 64, a value that allows allocation of an entire EDMA descriptor list within a single page - EDMA descriptors are 40 bytes and the header is much larger. This avoids doing a higher order GFP_ATOMIC allocation in edma_prep_slave_sg when setting up a transfer which can potentially fail due to fragmentation under heavy I/O load.
The current value of 1024 is unusually high in comparison to other mmc host drivers which mostly use values of between 1 and 256. The EDMA driver at present splits lists above 20 segments in any case so reducing the size of lists we pass to it shouldn't add much overhead.
Signed-off-by: Will Newton <willn@resin.io> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
6bba4064 |
| 29-Jun-2017 |
Arvind Yadav <arvind.yadav.cs@gmail.com> |
mmc: omap_hsmmc: constify dev_pm_ops structures
dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by <linux/device.h> work with const dev_pm_ops. So ma
mmc: omap_hsmmc: constify dev_pm_ops structures
dev_pm_ops are not supposed to change at runtime. All functions working with dev_pm_ops provided by <linux/device.h> work with const dev_pm_ops. So mark the non-const structs as const.
File size before: text data bss dec hex filename 11586 624 0 12210 2fb2 drivers/mmc/host/omap_hsmmc.o
File size After adding 'const': text data bss dec hex filename 11778 432 0 12210 2fb2 drivers/mmc/host/omap_hsmmc.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|