linux.git/drivers/mmc/core, branch v6.7-rc2 Linux kernel source tree Revert "mmc: core: Capture correct oemid-bits for eMMC cards" 2023-11-03T11:06:31+00:00 Dominique Martinet dominique.martinet@atmark-techno.com 2023-11-03T00:42:20+00:00 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff. The commit above made quirks with an OEMID fail to be applied, as they were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP macros but the field would only contain the bottom 8 bits. eMMC v5.1A might have bogus values in OEMID's higher bits so another fix will be made, but it has been decided to revert this until that is ready. Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards") Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com> Cc: stable@vger.kernel.org Cc: Alex Fetters <Alex.Fetters@garmin.com> Reviewed-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff.

The commit above made quirks with an OEMID fail to be applied, as they
were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP
macros but the field would only contain the bottom 8 bits.

eMMC v5.1A might have bogus values in OEMID's higher bits so another fix
will be made, but it has been decided to revert this until that is ready.

Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards")
Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org
Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Cc: stable@vger.kernel.org
Cc: Alex Fetters <Alex.Fetters@garmin.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: Add quirk MMC_QUIRK_BROKEN_CACHE_FLUSH for Micron eMMC Q2J54A 2023-11-03T11:01:32+00:00 Bean Huo beanhuo@micron.com 2023-10-30T22:48:09+00:00 ed9009ad300c0f15a3ecfe9613547b1962bde02c Micron MTFC4GACAJCN eMMC supports cache but requires that flush cache operation be allowed only after a write has occurred. Otherwise, the cache flush command or subsequent commands will time out. Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Rafael Beims <rafael.beims@toradex.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231030224809.59245-1-beanhuo@iokpp.de Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Micron MTFC4GACAJCN eMMC supports cache but requires that flush cache
operation be allowed only after a write has occurred. Otherwise, the
cache flush command or subsequent commands will time out.

Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Rafael Beims <rafael.beims@toradex.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231030224809.59245-1-beanhuo@iokpp.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: debugfs: Allow host caps to be modified 2023-10-10T11:44:49+00:00 Vincent Whitchurch vincent.whitchurch@axis.com 2023-09-29T07:45:09+00:00 ff369d7b98426abf7bccb0722253f5d4490f3c17 During board verification, there is a need to test the various supported eMMC/SD speed modes. However, since the framework chooses the best mode supported by the card and the host controller's caps, this currently necessitates changing the devicetree for every iteration. Allow the various speed mode host capabilities to be modified via debugfs in order to allow easier hardware verification. The values to be written are the raw MMC_CAP* values from include/linux/mmc/host.h. This is rather low-level, and these defines are not guaranteed to be stable, but it is perhaps good enough for the intended use case. MMC_CAP_AGGRESSIVE_PM can also be set, in order to be able to re-initialize the card without having to physically remove and re-insert it. /sys/kernel/debug/mmc0# grep timing ios timing spec: 9 (mmc HS200) // Turn on MMC_CAP_AGGRESSIVE_PM and re-trigger runtime suspend /sys/kernel/debug/mmc0# echo $(($(cat caps) | (1 << 7))) > caps /sys/kernel/debug/mmc0# echo on > /sys/bus/mmc/devices/mmc0\:0001/power/control /sys/kernel/debug/mmc0# echo auto > /sys/bus/mmc/devices/mmc0\:0001/power/control // MMC_CAP2_HS200_1_8V_SDR /sys/kernel/debug/mmc0# echo $(($(cat caps2) & ~(1 << 5))) > caps2 /sys/kernel/debug/mmc0# echo on > /sys/bus/mmc/devices/mmc0\:0001/power/control /sys/kernel/debug/mmc0# grep timing ios timing spec: 8 (mmc DDR52) Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20230929-mmc-caps-v2-2-11a4c2d94f15@axis.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
During board verification, there is a need to test the various supported
eMMC/SD speed modes.  However, since the framework chooses the best mode
supported by the card and the host controller's caps, this currently
necessitates changing the devicetree for every iteration.

Allow the various speed mode host capabilities to be modified via
debugfs in order to allow easier hardware verification.  The values to
be written are the raw MMC_CAP* values from include/linux/mmc/host.h.
This is rather low-level, and these defines are not guaranteed to be
stable, but it is perhaps good enough for the intended use case.

MMC_CAP_AGGRESSIVE_PM can also be set, in order to be able to
re-initialize the card without having to physically remove and re-insert
it.

 /sys/kernel/debug/mmc0# grep timing ios
 timing spec:	9 (mmc HS200)

 // Turn on MMC_CAP_AGGRESSIVE_PM and re-trigger runtime suspend
 /sys/kernel/debug/mmc0# echo $(($(cat caps) | (1 << 7))) > caps
 /sys/kernel/debug/mmc0# echo on > /sys/bus/mmc/devices/mmc0\:0001/power/control
 /sys/kernel/debug/mmc0# echo auto > /sys/bus/mmc/devices/mmc0\:0001/power/control

 // MMC_CAP2_HS200_1_8V_SDR
 /sys/kernel/debug/mmc0# echo $(($(cat caps2) & ~(1 << 5))) > caps2
 /sys/kernel/debug/mmc0# echo on > /sys/bus/mmc/devices/mmc0\:0001/power/control
 /sys/kernel/debug/mmc0# grep timing ios
 timing spec:	8 (mmc DDR52)

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20230929-mmc-caps-v2-2-11a4c2d94f15@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Always reselect card type 2023-10-10T11:44:49+00:00 Vincent Whitchurch vincent.whitchurch@axis.com 2023-09-29T07:45:08+00:00 6fff35f0335300af81c96326061f3cf3866ba6b8 We want to allow host caps to be changed dynamically via debugfs, so for these to have an effect, ensure that the card type reselection is always applied even if the card is old. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20230929-mmc-caps-v2-1-11a4c2d94f15@axis.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
We want to allow host caps to be changed dynamically via debugfs, so for
these to have an effect, ensure that the card type reselection is always
applied even if the card is old.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20230929-mmc-caps-v2-1-11a4c2d94f15@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: Merge branch fixes into next 2023-09-27T10:39:29+00:00 Ulf Hansson ulf.hansson@linaro.org 2023-09-27T10:39:29+00:00 09b59829715bc3c929bb300e2bd5d01e37faa3d3 Merge the mmc fixes for v6.6-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.7. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Merge the mmc fixes for v6.6-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.7.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Capture correct oemid-bits for eMMC cards 2023-09-27T10:17:04+00:00 Avri Altman avri.altman@wdc.com 2023-09-27T07:15:00+00:00 84ee19bffc9306128cd0f1c650e89767079efeff The OEMID is an 8-bit binary number rather than 16-bit as the current code parses for. The OEMID occupies bits [111:104] in the CID register, see the eMMC spec JESD84-B51 paragraph 7.2.3. It seems that the 16-bit comes from the legacy MMC specs (v3.31 and before). Let's fix the parsing by simply move to use 8-bit instead of 16-bit. This means we ignore the impact on some of those old MMC cards that may be out there, but on the other hand this shouldn't be a problem as the OEMID seems not be an important feature for these cards. Signed-off-by: Avri Altman <avri.altman@wdc.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230927071500.1791882-1-avri.altman@wdc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
The OEMID is an 8-bit binary number rather than 16-bit as the current code
parses for. The OEMID occupies bits [111:104] in the CID register, see the
eMMC spec JESD84-B51 paragraph 7.2.3. It seems that the 16-bit comes from
the legacy MMC specs (v3.31 and before).

Let's fix the parsing by simply move to use 8-bit instead of 16-bit. This
means we ignore the impact on some of those old MMC cards that may be out
there, but on the other hand this shouldn't be a problem as the OEMID seems
not be an important feature for these cards.

Signed-off-by: Avri Altman <avri.altman@wdc.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230927071500.1791882-1-avri.altman@wdc.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: Merge branch fixes into next 2023-09-27T10:13:24+00:00 Ulf Hansson ulf.hansson@linaro.org 2023-09-27T10:13:24+00:00 3e65dba664d88ed7075ff9dc2090767fa4b3bec8 Merge the mmc fixes for v6.6-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.7. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Merge the mmc fixes for v6.6-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.7.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Allow dynamical updates of the number of requests for hsq 2023-09-27T10:13:18+00:00 Wenchao Chen wenchao.chen@unisoc.com 2023-09-19T07:47:06+00:00 2e2b547950bc09e75afe912f9683be39c2195d9d To allow dynamical updates of the current number of used in-flight requests, let's move away from using a hard-coded value to a use a corresponding variable in the struct mmc_host. This can be valuable when optimizing for certain I/O request sequences, as shown by subsequent changes. Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com> Link: https://lore.kernel.org/r/20230919074707.25517-2-wenchao.chen@unisoc.com [Ulf: Re-wrote the commitmsg to clarify the change] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
To allow dynamical updates of the current number of used in-flight
requests, let's move away from using a hard-coded value to a use a
corresponding variable in the struct mmc_host.

This can be valuable when optimizing for certain I/O request sequences, as
shown by subsequent changes.

Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com>
Link: https://lore.kernel.org/r/20230919074707.25517-2-wenchao.chen@unisoc.com
[Ulf: Re-wrote the commitmsg to clarify the change]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Fix error propagation for some ioctl commands 2023-09-26T13:08:05+00:00 Ulf Hansson ulf.hansson@linaro.org 2023-09-13T11:29:21+00:00 f19c5a73e6f78d69efce66cfdce31148c76a61a6 Userspace has currently no way of checking the internal R1 response error bits for some commands. This is a problem for some commands, like RPMB for example. Typically, we may detect that the busy completion has successfully ended, while in fact the card did not complete the requested operation. To fix the problem, let's always poll with CMD13 for these commands and during the polling, let's also aggregate the R1 response bits. Before completing the ioctl request, let's propagate the R1 response bits too. Reviewed-by: Avri Altman <avri.altman@wdc.com> Co-developed-by: Christian Loehle <christian.loehle@arm.com> Signed-off-by: Christian Loehle <christian.loehle@arm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230913112921.553019-1-ulf.hansson@linaro.org 
Userspace has currently no way of checking the internal R1 response error
bits for some commands. This is a problem for some commands, like RPMB for
example. Typically, we may detect that the busy completion has successfully
ended, while in fact the card did not complete the requested operation.

To fix the problem, let's always poll with CMD13 for these commands and
during the polling, let's also aggregate the R1 response bits. Before
completing the ioctl request, let's propagate the R1 response bits too.

Reviewed-by: Avri Altman <avri.altman@wdc.com>
Co-developed-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230913112921.553019-1-ulf.hansson@linaro.org
mmc: core: sdio: hold retuning if sdio in 1-bit mode 2023-09-26T13:08:05+00:00 Haibo Chen haibo.chen@nxp.com 2023-08-30T09:39:22+00:00 32a9cdb8869dc111a0c96cf8e1762be9684af15b tuning only support in 4-bit mode or 8 bit mode, so in 1-bit mode, need to hold retuning. Find this issue when use manual tuning method on imx93. When system resume back, SDIO WIFI try to switch back to 4 bit mode, first will trigger retuning, and all tuning command failed. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: dfa13ebbe334 ("mmc: host: Add facility to support re-tuning") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230830093922.3095850-1-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
tuning only support in 4-bit mode or 8 bit mode, so in 1-bit mode,
need to hold retuning.

Find this issue when use manual tuning method on imx93. When system
resume back, SDIO WIFI try to switch back to 4 bit mode, first will
trigger retuning, and all tuning command failed.

Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: dfa13ebbe334 ("mmc: host: Add facility to support re-tuning")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230830093922.3095850-1-haibo.chen@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>