linux-stable.git/drivers/mmc/host, branch v4.7.2 Linux kernel stable tree mmc: pxamci: fix potential oops 2016-07-18T09:50:40+00:00 Robert Jarzmik robert.jarzmik@free.fr 2016-07-14T15:05:50+00:00 b3802db5eb72d2a96f4aa4ff0abb937033df2acf As reported by Dan in his report in [1], there is a potential NULL pointer derefence if these conditions are met : - there is no platform_data provided, ie. host->pdata = NULL Fix this by only using the platform data ro_invert when a gpio for read-only is provided by the platform data. This doesn't appear yet as every pxa board provides a platform_data, and calls pxa_set_mci_info() with a non NULL pointer. [1] [bug report] mmc: pxamci: fix card detect with slot-gpio API. The commit fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio API") from Sep 26, 2015, leads to the following static checker warning: drivers/mmc/host/pxamci.c:809 pxamci_probe() warn: variable dereferenced before check 'host->pdata' (see line 798) Fixes: fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio API") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
As reported by Dan in his report in [1], there is a potential NULL
pointer derefence if these conditions are met :
 - there is no platform_data provided, ie. host->pdata = NULL

Fix this by only using the platform data ro_invert when a gpio for
read-only is provided by the platform data.

This doesn't appear yet as every pxa board provides a platform_data, and
calls pxa_set_mci_info() with a non NULL pointer.

[1] [bug report] mmc: pxamci: fix card detect with slot-gpio API.
The commit fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio
API") from Sep 26, 2015, leads to the following static checker warning:

	drivers/mmc/host/pxamci.c:809 pxamci_probe()
	warn: variable dereferenced before check 'host->pdata' (see line 798)

Fixes: fd546ee6a7dc ("mmc: pxamci: fix card detect with slot-gpio API")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: sunxi: Re-enable eMMC HS-DDR modes on Allwinner A80 2016-06-02T08:40:20+00:00 Chen-Yu Tsai wens@csie.org 2016-05-29T07:04:44+00:00 afefc102df1bf5b75d7106771ecbe0ef546edc96 Now the the HS-DDR mode clock timings have been corrected, we can re-enable these modes on the A80. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Now the the HS-DDR mode clock timings have been corrected, we can
re-enable these modes on the A80.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: sunxi: Fix DDR MMC timings for A80 2016-06-02T08:40:02+00:00 Chen-Yu Tsai wens@csie.org 2016-05-29T07:04:43+00:00 0175249efa9310eed79650209600a75ace656bc9 The MMC clock timings were incorrectly calculated, when the conversion from delay value to delay phase was done. The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR unusable. Unfortunately it seems different controllers on the same SoC have different timings. The new settings are taken from mmc2, which is commonly used with eMMC. The settings for the slower timing modes seem to work despite being wrong, so leave them be. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.

The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have different timings. The new settings are taken from mmc2, which is
commonly used with eMMC.

The settings for the slower timing modes seem to work despite being
wrong, so leave them be.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
remove lots of IS_ERR_VALUE abuses 2016-05-27T22:26:11+00:00 Arnd Bergmann arnd@arndb.de 2016-05-27T21:23:25+00:00 287980e49ffc0f6d911601e7e352a812ed27768e Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers 2016-05-23T09:52:41+00:00 Adrian Hunter adrian.hunter@intel.com 2016-05-20T07:33:48+00:00 265984b36ce82fec67957d452dd2b22e010611e4 The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers 2016-05-23T09:52:40+00:00 Adrian Hunter adrian.hunter@intel.com 2016-05-20T07:33:47+00:00 822969369482166050c5b2f7013501505e025c39 The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: dw_mmc: rockchip: Set the drive phase properly 2016-05-23T09:45:47+00:00 Douglas Anderson dianders@chromium.org 2016-05-12T18:31:50+00:00 d4aa908c7978f60557a799ca53b5ae4166fd8355 Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance where the power on default is wrong or where the firmware didn't configure this properly then we'll get a mysterious failure. In commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") we actually started setting this explicitly in the kernel, but that commit wasn't quite right and also wasn't quite enough. See <https://patchwork.kernel.org/patch/9085311/> for some details. Let's explicitly set this phase in dw_mmc. The comments inside this patch try to explain the situation quite throughly, but the high level overview of this is: Before this patch on rk3288 devices tested (after revert of the clock patch described above): * eMMC: 180 degrees * SDMMC/SDIO0/SDIO1: 90 degrees After this patch: * Use 90 degree phase offset usually. * Use 180 degree phase offset for MMC_DDR52, SDR104, HS200. That means we are _changing_ behavior for those devices in this way: * If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90 degrees (vs 180) but otherwise have no change. * For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at 90 degrees (vs 180). It seems fairly unlikely that building modern hardware is using an eMMC that isn't using DDR52 or HS200, of course. * For SDR104 cards we'll now run with 180 degree phase offset (vs 90). It's expected that 90 degree phase offset would have worked OK, but this gives us extra margin. I have tested this by inserting my collection of uSD cards (mostly UHS, though a few not) into a veyron_minnie and confirmed that they still seem to enumerate properly. For a subset of them I tried putting a filesystem on them and also tried running mmc_test. Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Historically for Rockchip devices we've relied on the power-on
default (or perhaps the firmware setting) to get the correct drive
phase for dw_mmc devices.  This worked OK for the most part, but:

* Relying on the setting just "being right" is a bit fragile.

* As soon as there is an instance where the power on default is wrong or
  where the firmware didn't configure this properly then we'll get a
  mysterious failure.

In commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card
initialization") we actually started setting this explicitly in the
kernel, but that commit wasn't quite right and also wasn't quite
enough.  See <https://patchwork.kernel.org/patch/9085311/> for some
details.

Let's explicitly set this phase in dw_mmc.

The comments inside this patch try to explain the situation quite
throughly, but the high level overview of this is:

Before this patch on rk3288 devices tested (after revert of the clock
patch described above):
* eMMC: 180 degrees
* SDMMC/SDIO0/SDIO1: 90 degrees

After this patch:
* Use 90 degree phase offset usually.
* Use 180 degree phase offset for MMC_DDR52, SDR104, HS200.

That means we are _changing_ behavior for those devices in this way:

* If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90
  degrees (vs 180) but otherwise have no change.

* For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at
  90 degrees (vs 180).  It seems fairly unlikely that building modern
  hardware is using an eMMC that isn't using DDR52 or HS200, of course.

* For SDR104 cards we'll now run with 180 degree phase offset (vs 90).
  It's expected that 90 degree phase offset would have worked OK, but
  this gives us extra margin.

I have tested this by inserting my collection of uSD cards (mostly UHS,
though a few not) into a veyron_minnie and confirmed that they still
seem to enumerate properly.  For a subset of them I tried putting a
filesystem on them and also tried running mmc_test.

Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: dw_mmc: fix the wrong max_blk_size 2016-05-23T09:45:42+00:00 Jaehoon Chung jh80.chung@samsung.com 2016-05-04T02:24:14+00:00 225faf871ec24f3fa6daa4d2324b5de56690e1c5 According to DesignWare TRM, BLKSIZ is 16bits. Then it's correct that max_blk_size should be 0xFFFF, not 0x10000. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
According to DesignWare TRM, BLKSIZ is 16bits.
Then it's correct that max_blk_size should be 0xFFFF, not 0x10000.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities 2016-05-23T09:45:34+00:00 Shawn Lin shawn.lin@rock-chips.com 2016-04-26T06:53:59+00:00 d57fe83e0744cdc88236226980c613435ad5c10c Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise failing to create rpmb partition. With it, we can get rpmb successfully: mmc1: new HS200 MMC card at address 0001 mmcblk0: mmc1:0001 DS2016 14.7 GiB mmcblk0boot0: mmc1:0001 DS2016 partition 1 4.00 MiB mmcblk0boot1: mmc1:0001 DS2016 partition 2 4.00 MiB mmcblk0rpmb: mmc1:0001 DS2016 partition 3 4.00 MiB Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise
failing to create rpmb partition. With it, we can
get rpmb successfully:

mmc1: new HS200 MMC card at address 0001
mmcblk0: mmc1:0001 DS2016 14.7 GiB
mmcblk0boot0: mmc1:0001 DS2016 partition 1 4.00 MiB
mmcblk0boot1: mmc1:0001 DS2016 partition 2 4.00 MiB
mmcblk0rpmb: mmc1:0001 DS2016 partition 3 4.00 MiB

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: sdhci-acpi: Ensure connected devices are powered when probing 2016-05-20T14:00:25+00:00 Adrian Hunter adrian.hunter@intel.com 2016-05-19T13:25:42+00:00 e5bbf30733f930a1d17b4ccf19eac88e30a39cc7 Some devices connected to the SDHCI controller may have separate enabling lines that are controlled through GPIO. These devices need to be powered on and enabled before probing. This is to ensure all devices connected can be seen by the controller. Note, for "stable" this patch depends on the following change: commit 78a898d0e395 ("ACPI / PM: Export acpi_device_fix_up_power()") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reported-and-tested-by: Laszlo Fiat <laszlo.fiat@gmail.com> Cc: <stable@vger.kernel.org> # 4.5+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571 Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com 
Some devices connected to the SDHCI controller may have separate enabling
lines that are controlled through GPIO. These devices need to be powered
on and enabled before probing. This is to ensure all devices connected can
be seen by the controller.

Note, for "stable" this patch depends on the following change:
commit 78a898d0e395 ("ACPI / PM: Export acpi_device_fix_up_power()")

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reported-and-tested-by: Laszlo Fiat <laszlo.fiat@gmail.com>
Cc: <stable@vger.kernel.org> # 4.5+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571
Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com