lwn.git/drivers/mmc/host/sdhci-st.c, branch v6.6-rc3

mmc: sdhci-st: Use sdhci_pltfm_remove()

2023-08-15T11:35:56+00:00

Use sdhci_pltfm_remove() instead of sdhci_pltfm_unregister() because sdhci_pltfm_unregister() is going to be removed. Signed-off-by: Adrian Hunter Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230811130351.7038-15-adrian.hunter@intel.com Signed-off-by: Ulf Hansson

mmc: sdhci-st: Convert to platform remove callback returning void

2023-08-15T10:45:06+00:00

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 Signed-off-by: Yangtao Li Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20230727070051.17778-46-frank.li@vivo.com Signed-off-by: Ulf Hansson

mmc: sdhci-st: Use devm_platform_ioremap_resource_byname()

2023-08-09T11:21:48+00:00

Convert platform_get_resource_byname() + devm_ioremap_resource() to a single call to devm_platform_ioremap_resource_byname(), as this is exactly what this function does. Signed-off-by: Li Zetao Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20230802094028.976612-1-lizetao1@huawei.com Signed-off-by: Ulf Hansson

mmc: sdhci-st: Obviously always return success in remove callback

2022-07-12T10:25:38+00:00

sdhci_pltfm_unregister() returns 0 unconditionally and returning an error in a platform remove callback isn't very sensible. (The only effect of the latter is that the device core emits a generic warning and then removes the device anyhow.) So return 0 unconditionally to make it obvious there is no error forwarded to the upper layers. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20220610211257.102071-5-u.kleine-koenig@pengutronix.de Signed-off-by: Ulf Hansson

mmc: sdhci-st: Remove unnecessary error log

2021-04-12T11:52:48+00:00

devm_ioremap_resource() has recorded error log, so it's unnecessary to record log again. Reported-by: Hulk Robot Signed-off-by: Laibin Qiu Reviewed-by: Patrice Chotard Link: https://lore.kernel.org/r/20210409023801.3326572-1-qiulaibin@huawei.com Signed-off-by: Ulf Hansson

mmc: sdhci-st: simplify optional reset handling

2021-03-30T09:42:02+00:00

As of commit bb475230b8e5 ("reset: make optional functions really optional"), the reset framework API calls use NULL pointers to describe optional, non-present reset controls. This allows to return errors from devm_reset_control_get_optional and to call reset_control_(de)assert unconditionally. Signed-off-by: Philipp Zabel Link: https://lore.kernel.org/r/20210305090827.19124-1-p.zabel@pengutronix.de Signed-off-by: Ulf Hansson

mmc: sdhci-st: drop of_match_ptr from of_device_id table

2020-11-24T10:26:55+00:00

The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). This fixes compile warning (!CONFIG_OF on x86_64): drivers/mmc/host/sdhci-st.c:512:34: warning: ‘st_sdhci_match’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201120162344.485921-2-krzk@kernel.org Signed-off-by: Ulf Hansson

mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4

2020-09-07T12:20:17+00:00

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 Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang # SH_MMCIF Tested-by: Thierry Reding Link: https://lore.kernel.org/r/20200903162412.1.Id501e96fa63224f77bb86b2135a5e8324ffb9c43@changeid Signed-off-by: Ulf Hansson

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174

2019-05-30T18:26:41+00:00

Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 655 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Reviewed-by: Kate Stewart Reviewed-by: Richard Fontana Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-*: Don't emit error msg if sdhci_add_host() fails

2018-05-29T10:24:26+00:00

I noticed below error msg with sdhci-pxav3 on some berlin platforms: [.....] sdhci-pxav3 f7ab0000.sdhci failed to add host It is due to getting related vmmc or vqmmc regulator returns -EPROBE_DEFER. It doesn't matter at all but it's confusing. >From another side, if driver probing fails and the error number isn't -EPROBE_DEFER, the core will tell us something as below: [.....] sdhci-pxav3: probe of f7ab0000.sdhci failed with error -EXX So it's not necessary to emit error msg if sdhci_add_host() fails. And some other sdhci host drivers also have this issue, let's fix them together. Signed-off-by: Jisheng Zhang Acked-by: Adrian Hunter Acked-by: Viresh Kumar Acked-by: Patrice Chotard Signed-off-by: Ulf Hansson