<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/mmc/host, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/mmc/host?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/mmc/host?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-11-09T12:01:33Z</updated>
<entry>
<title>mmc: sdhci-esdhc-imx: use the correct host caps for MMC_CAP_8_BIT_DATA</title>
<updated>2022-11-09T12:01:33Z</updated>
<author>
<name>Haibo Chen</name>
<email>haibo.chen@nxp.com</email>
</author>
<published>2022-11-08T07:45:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f002f45a00ee14214d96b18b9a555fe2c56afb20'/>
<id>urn:sha1:f002f45a00ee14214d96b18b9a555fe2c56afb20</id>
<content type='text'>
MMC_CAP_8_BIT_DATA belongs to struct mmc_host, not struct sdhci_host.
So correct it here.

Fixes: 1ed5c3b22fc7 ("mmc: sdhci-esdhc-imx: Propagate ESDHC_FLAG_HS400* only on 8bit bus")
Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/1667893503-20583-1-git-send-email-haibo.chen@nxp.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci_am654: Fix SDHCI_RESET_ALL for CQHCI</title>
<updated>2022-11-07T12:33:43Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-10-26T19:42:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=162503fd1c3a1d4e14dbe7f399c1d1bec1c8abbc'/>
<id>urn:sha1:162503fd1c3a1d4e14dbe7f399c1d1bec1c8abbc</id>
<content type='text'>
[[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

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 this may
occur in some suspend or error recovery scenarios.

Include this fix by way of 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: f545702b74f9 ("mmc: sdhci_am654: Add Support for Command Queuing Engine to J721E")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221026124150.v4.6.I35ca9d6220ba48304438b992a76647ca8e5b126f@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-tegra: Fix SDHCI_RESET_ALL for CQHCI</title>
<updated>2022-11-07T12:33:38Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-10-26T19:42:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=836078449464e6af3b66ae6652dae79af176f21e'/>
<id>urn:sha1:836078449464e6af3b66ae6652dae79af176f21e</id>
<content type='text'>
[[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

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 this may
occur in some suspend or error recovery scenarios.

Include this fix by way of 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: 3c4019f97978 ("mmc: tegra: HW Command Queue Support for Tegra SDMMC")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221026124150.v4.5.I418c9eaaf754880fcd2698113e8c3ef821a944d7@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mms: sdhci-esdhc-imx: Fix SDHCI_RESET_ALL for CQHCI</title>
<updated>2022-11-07T12:33:32Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-10-26T19:42:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=fb1dec44c6750bb414f47b929c8c175a1a127c31'/>
<id>urn:sha1:fb1dec44c6750bb414f47b929c8c175a1a127c31</id>
<content type='text'>
[[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

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 this may
occur in some suspend or error recovery scenarios.

Include this fix by way of 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: bb6e358169bf ("mmc: sdhci-esdhc-imx: add CMDQ support")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221026124150.v4.4.I7d01f9ad11bacdc9213dee61b7918982aea39115@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-brcmstb: Fix SDHCI_RESET_ALL for CQHCI</title>
<updated>2022-11-07T12:33:09Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-10-26T19:42:05Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=56baa208f91061ff27ec2d93fbc483f624d373b4'/>
<id>urn:sha1:56baa208f91061ff27ec2d93fbc483f624d373b4</id>
<content type='text'>
[[ NOTE: this is completely untested by the author, but included solely
    because, as noted in commit df57d73276b8 ("mmc: sdhci-pci: Fix
    SDHCI_RESET_ALL for CQHCI for Intel GLK-based controllers"), "other
    drivers using CQHCI might benefit from a similar change, if they
    also have CQHCI reset by SDHCI_RESET_ALL." We've now seen the same
    bug on at least MSM, Arasan, and Intel hardware. ]]

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 this may
occur in some suspend or error recovery scenarios.

Include this fix by way of the new sdhci_and_cqhci_reset() helper.

I only patch the bcm7216 variant even though others potentially *could*
provide the 'supports-cqe' property (and thus enable CQHCI), because
d46ba2d17f90 ("mmc: sdhci-brcmstb: Add support for Command Queuing
(CQE)") and some Broadcom folks confirm that only the 7216 variant
actually supports it.

This patch depends on (and should not compile without) the patch
entitled "mmc: cqhci: Provide helper for resetting both SDHCI and
CQHCI".

Fixes: d46ba2d17f90 ("mmc: sdhci-brcmstb: Add support for Command Queuing (CQE)")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221026124150.v4.3.I6a715feab6d01f760455865e968ecf0d85036018@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-of-arasan: Fix SDHCI_RESET_ALL for CQHCI</title>
<updated>2022-11-07T12:28:47Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-10-26T19:42:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=5d249ac37fc2396e8acc1adb0650cdacae5a990d'/>
<id>urn:sha1:5d249ac37fc2396e8acc1adb0650cdacae5a990d</id>
<content type='text'>
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() -&gt; mmc_power_off().
Typically we will eventually deactivate CQE (cqhci_suspend() -&gt;
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: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20221026124150.v4.2.I29f6a2189e84e35ad89c1833793dca9e36c64297@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI</title>
<updated>2022-11-07T12:28:47Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-10-26T19:42:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=ebb5fd38f41132e6924cb33b647337f4a5d5360c'/>
<id>urn:sha1:ebb5fd38f41132e6924cb33b647337f4a5d5360c</id>
<content type='text'>
Several SDHCI drivers need to deactivate command queueing in their reset
hook (see sdhci_cqhci_reset() / sdhci-pci-core.c, for example), and
several more are coming.

Those reset implementations have some small subtleties (e.g., ordering
of initialization of SDHCI vs. CQHCI might leave us resetting with a
NULL -&gt;cqe_private), and are often identical across different host
drivers.

We also don't want to force a dependency between SDHCI and CQHCI, or
vice versa; non-SDHCI drivers use CQHCI, and SDHCI drivers might support
command queueing through some other means.

So, implement a small helper, to avoid repeating the same mistakes in
different drivers. Simply stick it in a header, because it's so small it
doesn't deserve its own module right now, and inlining to each driver is
pretty reasonable.

This is marked for -stable, as it is an important prerequisite patch for
several SDHCI controller bugfixes that follow.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20221026124150.v4.1.Ie85faa09432bfe1b0890d8c24ff95e17f3097317@changeid
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci_am654: 'select', not 'depends' REGMAP_MMIO</title>
<updated>2022-10-26T09:48:03Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-10-24T18:02:59Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8d280b1df87e0b3d1355aeac7e62b62214b93f1c'/>
<id>urn:sha1:8d280b1df87e0b3d1355aeac7e62b62214b93f1c</id>
<content type='text'>
REGMAP_MMIO is not user-configurable, so we can only satisfy this
dependency by enabling some other Kconfig symbol that properly 'select's
it. Use select like everybody else.

Noticed when trying to enable this driver for compile testing.

Fixes: 59592cc1f593 ("mmc: sdhci_am654: Add dependency on MMC_SDHCI_AM654")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221024180300.2292208-1-briannorris@chromium.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-pci-core: Disable ES for ASUS BIOS on Jasper Lake</title>
<updated>2022-10-17T09:51:34Z</updated>
<author>
<name>Patrick Thompson</name>
<email>ptf@google.com</email>
</author>
<published>2022-10-13T21:00:17Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=9dc0033e4658d6f9d9952c3c0c6be3ec25bc2985'/>
<id>urn:sha1:9dc0033e4658d6f9d9952c3c0c6be3ec25bc2985</id>
<content type='text'>
Enhanced Strobe (ES) does not work correctly on the ASUS 1100 series of
devices. Jasper Lake eMMCs (pci_id 8086:4dc4) are supposed to support
ES. There are also two system families under the series, thus this is
being scoped to the ASUS BIOS.

The failing ES prevents the installer from writing to disk. Falling back
to HS400 without ES fixes the issue.

Signed-off-by: Patrick Thompson &lt;ptf@google.com&gt;
Fixes: 315e3bd7ac19 ("mmc: sdhci-pci: Add support for Intel JSL")
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221013210017.3751025-1-ptf@google.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-esdhc-imx: Propagate ESDHC_FLAG_HS400* only on 8bit bus</title>
<updated>2022-10-17T09:51:34Z</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2022-10-13T09:32:48Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=1ed5c3b22fc78735c539e4767832aea58db6761c'/>
<id>urn:sha1:1ed5c3b22fc78735c539e4767832aea58db6761c</id>
<content type='text'>
The core issues the warning "drop HS400 support since no 8-bit bus" when
one of the ESDHC_FLAG_HS400* flags is set on a non 8bit capable host. To
avoid this warning set these flags only on hosts that actually can do
8bit, i.e. have bus-width = &lt;8&gt; set in the device tree.

Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Reviewed-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Fixes: 029e2476f9e6 ("mmc: sdhci-esdhc-imx: add HS400_ES support for i.MX8QXP")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221013093248.2220802-1-s.hauer@pengutronix.de
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
</feed>
