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 |
|
#
ef1c3a7e |
| 11-Aug-2023 |
Adrian Hunter <adrian.hunter@intel.com> |
mmc: sdhci-of-arasan: Use sdhci_pltfm_remove()
Use sdhci_pltfm_remove() instead of sdhci_pltfm_unregister() because sdhci_pltfm_unregister() is going to be removed.
Signed-off-by: Adrian Hunter <ad
mmc: sdhci-of-arasan: Use sdhci_pltfm_remove()
Use sdhci_pltfm_remove() instead of sdhci_pltfm_unregister() because sdhci_pltfm_unregister() is going to be removed.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230811130351.7038-9-adrian.hunter@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.45, v6.1.44, v6.1.43 |
|
#
3de205a0 |
| 27-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
mmc: sdhci-of-arasan: 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 d
mmc: sdhci-of-arasan: 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> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20230727070051.17778-25-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 |
|
#
c62da8a8 |
| 18-Jul-2023 |
Rob Herring <robh@kernel.org> |
mmc: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that mer
mmc: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230718143054.1065288-1-robh@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, 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 |
|
#
9fab9389 |
| 03-Apr-2023 |
Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> |
mmc: sdhci-of-arasan: Skip setting clock delay for 400KHz
Clock delay settings are not defined for 400KHz, so add frequency check to skip calling the clock delay settings when frequency is <=400KHz.
mmc: sdhci-of-arasan: Skip setting clock delay for 400KHz
Clock delay settings are not defined for 400KHz, so add frequency check to skip calling the clock delay settings when frequency is <=400KHz.
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230403102551.3763054-4-sai.krishna.potthuri@amd.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
b095f4f5 |
| 03-Apr-2023 |
Swati Agarwal <swati.agarwal@amd.com> |
mmc: sdhci-of-arasan: Add support for eMMC5.1 on Xilinx Versal Net platform
Add support for eMMC5.1 on Xilinx Versal Net platform - Add new compatible string(xlnx,versal-net-emmc). - Add support for
mmc: sdhci-of-arasan: Add support for eMMC5.1 on Xilinx Versal Net platform
Add support for eMMC5.1 on Xilinx Versal Net platform - Add new compatible string(xlnx,versal-net-emmc). - Add support for PHY which is part of Host Controller register space. - Add DLL and Delay Chain mode support and corresponding tap delays for all eMMC modes. - Add Strobe select tap for HS400 mode.
Signed-off-by: Swati Agarwal <swati.agarwal@amd.com> Co-developed-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230403102551.3763054-3-sai.krishna.potthuri@amd.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.22, v6.1.21, v6.1.20 |
|
#
189f7370 |
| 16-Mar-2023 |
A, Rashmi <rashmi.a@intel.com> |
mmc: sdhci-of-arasan: Remove Intel Thunder Bay SOC support
Remove Thunder Bay specific code as the product got cancelled and there are no end customers or users.
Signed-off-by: A, Rashmi <rashmi.a@
mmc: sdhci-of-arasan: Remove Intel Thunder Bay SOC support
Remove Thunder Bay specific code as the product got cancelled and there are no end customers or users.
Signed-off-by: A, Rashmi <rashmi.a@intel.com> Reviewed-by: Hunter, Adrian <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230316120549.21486-2-rashmi.a@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17 |
|
#
66756ca3 |
| 10-Mar-2023 |
Rob Herring <robh@kernel.org> |
mmc: arasan: Use of_property_present() for testing DT property presence
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_p
mmc: arasan: Use of_property_present() for testing DT property presence
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. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more.
Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144714.1543767-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 |
|
#
4453d51e |
| 23-Feb-2023 |
Swati Agarwal <swati.agarwal@amd.com> |
mmc: sdhci-of-arasan: Add support to request the "gate" clock
Add support to read the optional "gate" clock property and request the clock which will be used to ungate the DLL clock.
For Xilinx pla
mmc: sdhci-of-arasan: Add support to request the "gate" clock
Add support to read the optional "gate" clock property and request the clock which will be used to ungate the DLL clock.
For Xilinx platforms which has DLL module, dll clock must be ungated/enabled when SD controller operates at higher frequencies like 50 MHz, 100 MHz and 200 MHz. This will be done by explicitly requesting gate clock from the driver.
Signed-off-by: Swati Agarwal <swati.agarwal@amd.com> Acked-by: Michal Simek <michal.simek@amd.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230223141402.23979-1-swati.agarwal@amd.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3 |
|
#
0614b0ae |
| 19-Oct-2022 |
Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> |
mmc: sdhci-of-arasan: Add support for dynamic configuration
Add dynamic configuration support for Xilinx ZynqMP which takes care of configuring the SD secure space configuration registers using EEMI
mmc: sdhci-of-arasan: Add support for dynamic configuration
Add dynamic configuration support for Xilinx ZynqMP which takes care of configuring the SD secure space configuration registers using EEMI APIs, performing SD reset assert and deassert. High level sequence: - Check for the PM dynamic configuration support, if no error proceed with SD dynamic configurations(next steps) otherwise skip the dynamic configuration. - Put the SD Controller in reset. - Configure SD Fixed configurations. - Configure the SD Slot Type. - Configure the BASE_CLOCK. - Configure the 8-bit support. - Bring the SD Controller out of reset. - Wait for 1msec delay.
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Acked-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20221019054857.8286-1-sai.krishna.potthuri@amd.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
5d249ac3 |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger vario
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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 |
|
#
869f9875 |
| 10-Jun-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
mmc: sdhci-of-arasan: Obviously always return success in remove callback
sdhci_pltfm_unregister() returns 0 unconditionally and returning an error in a platform remove callback isn't very sensible.
mmc: sdhci-of-arasan: Obviously always return success in remove callback
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 <u.kleine-koenig@pengutronix.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20220610211257.102071-4-u.kleine-koenig@pengutronix.de Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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 |
|
#
ded2c4c3 |
| 12-May-2022 |
Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> |
mmc: sdhci-of-arasan: Add NULL check for data field
Add NULL check for data field retrieved from of_device_get_match_data() before dereferencing the data. Addresses-coverity: CID 305057:Dereference
mmc: sdhci-of-arasan: Add NULL check for data field
Add NULL check for data field retrieved from of_device_get_match_data() before dereferencing the data. Addresses-coverity: CID 305057:Dereference null return value (NULL_RETURNS)
Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1652339993-27280-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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, 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, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14 |
|
#
39013f09 |
| 29-Aug-2021 |
Rashmi A <rashmi.a@intel.com> |
mmc: sdhci-of-arasan: Add intel Thunder Bay SOC support to the arasan eMMC driver
Intel Thunder Bay SoC eMMC controller is based on Arasan eMMC 5.1 host controller IP
Signed-off-by: Rashmi A <rashm
mmc: sdhci-of-arasan: Add intel Thunder Bay SOC support to the arasan eMMC driver
Intel Thunder Bay SoC eMMC controller is based on Arasan eMMC 5.1 host controller IP
Signed-off-by: Rashmi A <rashmi.a@intel.com> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20210829182443.30802-2-rashmi.a@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
ad01f16c |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that p
mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI
commit 5d249ac37fc2396e8acc1adb0650cdacae5a990d upstream.
SDHCI_RESET_ALL resets will reset the hardware CQE state, but we aren't tracking that properly in software. When out of sync, we may trigger various timeouts.
It's not typical to perform resets while CQE is enabled, but one particular case I hit commonly enough: mmc_suspend() -> mmc_power_off(). Typically we will eventually deactivate CQE (cqhci_suspend() -> cqhci_deactivate()), but that's not guaranteed -- in particular, if we perform a partial (e.g., interrupted) system suspend.
The same bug was already found and fixed for two other drivers, in v5.7 and v5.9:
5cf583f1fb9c ("mmc: sdhci-msm: Deactivate CQE during SDHC reset") df57d73276b8 ("mmc: sdhci-pci: Fix SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers")
The latter is especially prescient, saying "other drivers using CQHCI might benefit from a similar change, if they also have CQHCI reset by SDHCI_RESET_ALL."
So like these other patches, deactivate CQHCI when resetting the controller. Do this via the new sdhci_and_cqhci_reset() helper.
This patch depends on (and should not compile without) the patch entitled "mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI".
Fixes: 84362d79f436 ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|