linux-stable.git/drivers/mmc/core, branch v4.4.201 Linux kernel stable tree mmc: core: Fix init of SD cards reporting an invalid VDD range 2019-09-06T08:18:17+00:00 Ulf Hansson ulf.hansson@linaro.org 2019-08-27T08:10:43+00:00 e2f1509fca476d763d94eb0026b28c22ab110688 commit 72741084d903e65e121c27bd29494d941729d4a1 upstream. The OCR register defines the supported range of VDD voltages for SD cards. However, it has turned out that some SD cards reports an invalid voltage range, for example having bit7 set. When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from the invalid VDD range, this triggers the core to run a power cycle of the card to try to initialize it at the lowest common supported voltage. Obviously this fails, since the card can't support it. Let's fix this problem, by clearing invalid bits from the read OCR register for SD cards, before proceeding with the VDD voltage negotiation. Cc: stable@vger.kernel.org Reported-by: Philip Langdale <philipl@overt.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Philip Langdale <philipl@overt.org> Tested-by: Philip Langdale <philipl@overt.org> Tested-by: Manuel Presnitz <mail@mpy.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 72741084d903e65e121c27bd29494d941729d4a1 upstream.

The OCR register defines the supported range of VDD voltages for SD cards.
However, it has turned out that some SD cards reports an invalid voltage
range, for example having bit7 set.

When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from
the invalid VDD range, this triggers the core to run a power cycle of the
card to try to initialize it at the lowest common supported voltage.
Obviously this fails, since the card can't support it.

Let's fix this problem, by clearing invalid bits from the read OCR register
for SD cards, before proceeding with the VDD voltage negotiation.

Cc: stable@vger.kernel.org
Reported-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Philip Langdale <philipl@overt.org>
Tested-by: Philip Langdale <philipl@overt.org>
Tested-by: Manuel Presnitz <mail@mpy.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: core: Verify SD bus width 2019-06-11T10:23:54+00:00 Raul E Rangel rrangel@chromium.org 2019-04-29T17:32:39+00:00 dba032038c959b0321fd5d06c7e51f69a46e2db8 [ Upstream commit 9e4be8d03f50d1b25c38e2b59e73b194c130df7d ] The SD Physical Layer Spec says the following: Since the SD Memory Card shall support at least the two bus modes 1-bit or 4-bit width, then any SD Card shall set at least bits 0 and 2 (SD_BUS_WIDTH="0101"). This change verifies the card has specified a bus width. AMD SDHC Device 7806 can get into a bad state after a card disconnect where anything transferred via the DATA lines will always result in a zero filled buffer. Currently the driver will continue without error if the HC is in this condition. A block device will be created, but reading from it will result in a zero buffer. This makes it seem like the SD device has been erased, when in actuality the data is never getting copied from the DATA lines to the data buffer. SCR is the first command in the SD initialization sequence that uses the DATA lines. By checking that the response was invalid, we can abort mounting the card. Reviewed-by: Avri Altman <avri.altman@wdc.com> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9e4be8d03f50d1b25c38e2b59e73b194c130df7d ]

The SD Physical Layer Spec says the following: Since the SD Memory Card
shall support at least the two bus modes 1-bit or 4-bit width, then any SD
Card shall set at least bits 0 and 2 (SD_BUS_WIDTH="0101").

This change verifies the card has specified a bus width.

AMD SDHC Device 7806 can get into a bad state after a card disconnect
where anything transferred via the DATA lines will always result in a
zero filled buffer. Currently the driver will continue without error if
the HC is in this condition. A block device will be created, but reading
from it will result in a zero buffer. This makes it seem like the SD
device has been erased, when in actuality the data is never getting
copied from the DATA lines to the data buffer.

SCR is the first command in the SD initialization sequence that uses the
DATA lines. By checking that the response was invalid, we can abort
mounting the card.

Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mmc: mmc: fix switch timeout issue caused by jiffies precision 2019-04-03T04:23:24+00:00 Chaotian Jing chaotian.jing@mediatek.com 2016-05-19T08:47:42+00:00 695fc282c337c5f520582eaf3bda9b53319384e4 [ Upstream commit 987aa5f8059613bf85cbb6f64ffbd34f5cb7a9d1 ] with CONFIG_HZ=100, the precision of jiffies is 10ms, and the generic_cmd6_time of some card is also 10ms. then, may be current time is only 5ms, but already timed out caused by jiffies precision. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 987aa5f8059613bf85cbb6f64ffbd34f5cb7a9d1 ]

with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.

Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mmc: core: fix using wrong io voltage if mmc_select_hs200 fails 2019-04-03T04:23:18+00:00 Dong Aisheng aisheng.dong@nxp.com 2016-04-20T16:51:30+00:00 1394b1bdfd00560beb1b1ea20b75ee1734007ac8 commit e51534c806609c806d81bfb034f02737461f855c upstream. Currently MMC core will keep going if HS200/HS timing switch failed with -EBADMSG error by the assumption that the old timing is still valid. However, for mmc_select_hs200 case, the signal voltage may have already been switched. If the timing switch failed, we should fall back to the old voltage in case the card is continue run with legacy timing. If fall back signal voltage failed, we explicitly report an EIO error to force retry during the next power cycle. Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e51534c806609c806d81bfb034f02737461f855c upstream.

Currently MMC core will keep going if HS200/HS timing switch failed
with -EBADMSG error by the assumption that the old timing is still valid.

However, for mmc_select_hs200 case, the signal voltage may have already
been switched. If the timing switch failed, we should fall back to
the old voltage in case the card is continue run with legacy timing.

If fall back signal voltage failed, we explicitly report an EIO error
to force retry during the next power cycle.

Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: core: shut up "voltage-ranges unspecified" pr_info() 2019-04-03T04:23:17+00:00 Russell King rmk+kernel@arm.linux.org.uk 2016-01-29T09:43:50+00:00 f2427238c9ed72e7a8c56c0d342c3b283adce4c6 commit 10a16a01d8f72e80f4780e40cf3122f4caffa411 upstream. Each time a driver such as sdhci-esdhc-imx is probed, we get a info printk complaining that the DT voltage-ranges property has not been specified. However, the DT binding specifically says that the voltage-ranges property is optional. That means we should not be complaining that DT hasn't specified this property: by indicating that it's optional, it is valid not to have the property in DT. Silence the warning if the property is missing. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 10a16a01d8f72e80f4780e40cf3122f4caffa411 upstream.

Each time a driver such as sdhci-esdhc-imx is probed, we get a info
printk complaining that the DT voltage-ranges property has not been
specified.

However, the DT binding specifically says that the voltage-ranges
property is optional.  That means we should not be complaining that
DT hasn't specified this property: by indicating that it's optional,
it is valid not to have the property in DT.

Silence the warning if the property is missing.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: sanitize 'bus width' in debug output 2019-04-03T04:23:17+00:00 Wolfram Sang wsa+renesas@sang-engineering.com 2016-01-29T08:27:50+00:00 6a0f5752f1fd5e98c87392e61e437907c149ed63 commit ed9feec72fc1fa194ebfdb79e14561b35decce63 upstream. The bus width is sometimes the actual bus width, and sometimes indices to different arrays encoding the bus width. In my debugging case "2" could mean 8-bit as well as 4-bit, which was extremly confusing. Let's use the human-readable actual bus width in all places. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ed9feec72fc1fa194ebfdb79e14561b35decce63 upstream.

The bus width is sometimes the actual bus width, and sometimes indices
to different arrays encoding the bus width. In my debugging case "2"
could mean 8-bit as well as 4-bit, which was extremly confusing. Let's
use the human-readable actual bus width in all places.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: make MAN_BKOPS_EN message a debug 2019-04-03T04:23:17+00:00 Wolfram Sang wsa+renesas@sang-engineering.com 2016-01-25T19:18:12+00:00 40c01c8301b85d9454e4fb3b5dca436435266937 commit 4ec96b4cbde8d5714a4477b5a2562c3dd40bc5fa upstream. IMO this info is only useful for developers. Most users won't need this information, since there is not much they can do about it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4ec96b4cbde8d5714a4477b5a2562c3dd40bc5fa upstream.

IMO this info is only useful for developers. Most users won't need this
information, since there is not much they can do about it.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: debugfs: Add a restriction to mmc debugfs clock setting 2019-04-03T04:23:17+00:00 Chuanxiao Dong chuanxiao.dong@intel.com 2016-01-21T12:57:51+00:00 282d5f0567be5abcc57a38ada569460ef63b5be9 commit e5905ff1281f0a0f5c9863c430ac1ed5faaf5707 upstream. Clock frequency values written to an mmc host should not be less than the minimum clock frequency which the mmc host supports. Signed-off-by: Yuan Juntao <juntaox.yuan@intel.com> Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e5905ff1281f0a0f5c9863c430ac1ed5faaf5707 upstream.

Clock frequency values written to an mmc host should not be less than
the minimum clock frequency which the mmc host supports.

Signed-off-by: Yuan Juntao <juntaox.yuan@intel.com>
Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: pwrseq_simple: Make reset-gpios optional to match doc 2019-04-03T04:23:17+00:00 Martin Fuzzey mfuzzey@parkeon.com 2016-01-20T15:08:03+00:00 c8816bb0ed6dc34c888021a34891385c0a84566f commit 64a67d4762ce3ce4c9466eadd152d825fbf84967 upstream. The DT binding doc says reset-gpios is an optional property but the code currently bails out if it is omitted. This is a regression since it breaks previously working device trees. Fix it by restoring the original documented behaviour. Fixes: ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API") Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 64a67d4762ce3ce4c9466eadd152d825fbf84967 upstream.

The DT binding doc says reset-gpios is an optional property but the code
currently bails out if it is omitted.

This is a regression since it breaks previously working device trees.
Fix it by restoring the original documented behaviour.

Fixes: ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API")
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: core: Reset HPI enabled state during re-init and in case of errors 2019-01-13T09:05:27+00:00 Ulf Hansson ulf.hansson@linaro.org 2018-12-10T16:52:36+00:00 f2eca86effbeba30190f368f70b26779a04c3bad commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream. During a re-initialization of the eMMC card, we may fail to re-enable HPI. In these cases, that isn't properly reflected in the card->ext_csd.hpi_en bit, as it keeps being set. This may cause following attempts to use HPI, even if's not enabled. Let's fix this! Fixes: eb0d8f135b67 ("mmc: core: support HPI send command") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream.

During a re-initialization of the eMMC card, we may fail to re-enable HPI.
In these cases, that isn't properly reflected in the card->ext_csd.hpi_en
bit, as it keeps being set. This may cause following attempts to use HPI,
even if's not enabled. Let's fix this!

Fixes: eb0d8f135b67 ("mmc: core: support HPI send command")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>