linux.git/drivers/mmc, branch v4.14-rc4 Linux kernel source tree mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock 2017-10-04T08:50:36+00:00 Gregory CLEMENT gregory.clement@free-electrons.com 2017-10-02T14:58:52+00:00 bb16ea1742c8f35a9349b7508dc45d3a922db5f5 On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock is optional because not all the SoCs need them but at least for Armada 7K/8K it is actually mandatory. The binding documentation is updating accordingly. Without this patch the kernel hand during boot if the mvpp2.2 network driver was not present in the kernel. Indeed the clock needed by the xenon controller was set by the network driver. Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality)" CC: Stable <stable@vger.kernel.org> Tested-by: Zhoujie Wu <zjwu@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
is optional because not all the SoCs need them but at least for Armada
7K/8K it is actually mandatory.

The binding documentation is updating accordingly.

Without this patch the kernel hand during boot if the mvpp2.2 network
driver was not present in the kernel. Indeed the clock needed by the
xenon controller was set by the network driver.

Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core
functionality)"
CC: Stable <stable@vger.kernel.org>
Tested-by: Zhoujie Wu <zjwu@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: meson-gx: include tx phase in the tuning process 2017-10-04T08:42:11+00:00 Jerome Brunet jbrunet@baylibre.com 2017-10-02T12:27:43+00:00 0a44697627d17a66d7dc98f17aeca07ca79c5c20 It has been reported that some platforms (odroid-c2) may require a different tx phase setting to operate at high speed (hs200 and hs400) To improve the situation, this patch includes tx phase in the tuning process. Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function") Reported-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
It has been reported that some platforms (odroid-c2) may require
a different tx phase setting to operate at high speed (hs200 and hs400)

To improve the situation, this patch includes tx phase in the tuning
process.

Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function")
Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: meson-gx: fix rx phase reset 2017-10-04T08:42:03+00:00 Jerome Brunet jbrunet@baylibre.com 2017-10-02T12:27:42+00:00 3e2b0af411d4bf85bc0fbc385756fd5968adb9fd Resetting the phase when POWER_ON is set the set_ios() call means that the phase is reset almost every time the set_ios() is called, while the expected behavior was to reset the phase on a power cycle. This had gone unnoticed until now because in all mode (except hs400) the tuning is done after the last to set_ios(). In such case, the tuning result is used anyway. In HS400, there are a few calls to set_ios() after the tuning is done, overwriting the tuning result. Resetting the phase on POWER_UP instead of POWER_ON solve the problem. Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Resetting the phase when POWER_ON is set the set_ios() call means that the
phase is reset almost every time the set_ios() is called, while the
expected behavior was to reset the phase on a power cycle.

This had gone unnoticed until now because in all mode (except hs400) the
tuning is done after the last to set_ios(). In such case, the tuning
result is used anyway.  In HS400, there are a few calls to set_ios() after
the tuning is done, overwriting the tuning result.

Resetting the phase on POWER_UP instead of POWER_ON solve the problem.

Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: meson-gx: make sure the clock is rounded down 2017-10-04T08:41:42+00:00 Jerome Brunet jbrunet@baylibre.com 2017-10-02T12:27:41+00:00 ca3dcd3ff5b13a31a09a0119dc484b97ec19c4c8 Using CLK_DIVIDER_ROUND_CLOSEST is unsafe as the mmc clock could be rounded to a rate higher the specified rate. Removing this flag ensure that, if the rate needs to be rounded, it will be rounded down. Fixes: 51c5d8447bd7 ("MMC: meson: initial support for GX platforms") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Using CLK_DIVIDER_ROUND_CLOSEST is unsafe as the mmc clock could be
rounded to a rate higher the specified rate. Removing this flag ensure
that, if the rate needs to be rounded, it will be rounded down.

Fixes: 51c5d8447bd7 ("MMC: meson: initial support for GX platforms")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: Delete bounce buffer handling 2017-10-04T08:22:55+00:00 Linus Walleij linus.walleij@linaro.org 2017-09-20T08:56:14+00:00 de3ee99b097dd51938276e3af388cd4ad0f2750a In may, Steven sent a patch deleting the bounce buffer handling and the CONFIG_MMC_BLOCK_BOUNCE option. I chose the less invasive path of making it a runtime config option, and we merged that successfully for kernel v4.12. The code is however just standing in the way and taking up space for seemingly no gain on any systems in wide use today. Pierre says the code was there to improve speed on TI SDHCI controllers on certain HP laptops and possibly some Ricoh controllers as well. Early SDHCI controllers lacked the scatter-gather feature, which made software bounce buffers a significant speed boost. We are clearly talking about the list of SDHCI PCI-based MMC/SD card readers found in the pci_ids[] list in drivers/mmc/host/sdhci-pci-core.c. The TI SDHCI derivative is not supported by the upstream kernel. This leaves the Ricoh. What we can however notice is that the x86 defconfigs in the kernel did not enable CONFIG_MMC_BLOCK_BOUNCE option, which means that any such laptop would have to have a custom configured kernel to actually take advantage of this bounce buffer speed-up. It simply seems like there was a speed optimization for the Ricoh controllers that noone was using. (I have not checked the distro defconfigs but I am pretty sure the situation is the same there.) Bounce buffers increased performance on the OMAP HSMMC at one point, and was part of the original submission in commit a45c6cb81647 ("[ARM] 5369/1: omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3") This optimization was removed in commit 0ccd76d4c236 ("omap_hsmmc: Implement scatter-gather emulation") which found that scatter-gather emulation provided even better performance. The same was introduced for SDHCI in commit 2134a922c6e7 ("sdhci: scatter-gather (ADMA) support") I am pretty positively convinced that software scatter-gather emulation will do for any host controller what the bounce buffers were doing. Essentially, the bounce buffer was a reimplementation of software scatter-gather-emulation in the MMC subsystem, and it should be done away with. Cc: Pierre Ossman <pierre@ossman.eu> Cc: Juha Yrjola <juha.yrjola@solidboot.com> Cc: Steven J. Hill <Steven.Hill@cavium.com> Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Suggested-by: Steven J. Hill <Steven.Hill@cavium.com> Suggested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
In may, Steven sent a patch deleting the bounce buffer handling
and the CONFIG_MMC_BLOCK_BOUNCE option.

I chose the less invasive path of making it a runtime config
option, and we merged that successfully for kernel v4.12.

The code is however just standing in the way and taking up
space for seemingly no gain on any systems in wide use today.

Pierre says the code was there to improve speed on TI SDHCI
controllers on certain HP laptops and possibly some Ricoh
controllers as well. Early SDHCI controllers lacked the
scatter-gather feature, which made software bounce buffers
a significant speed boost.

We are clearly talking about the list of SDHCI PCI-based
MMC/SD card readers found in the pci_ids[] list in
drivers/mmc/host/sdhci-pci-core.c.

The TI SDHCI derivative is not supported by the upstream
kernel. This leaves the Ricoh.

What we can however notice is that the x86 defconfigs in the
kernel did not enable CONFIG_MMC_BLOCK_BOUNCE option, which
means that any such laptop would have to have a custom
configured kernel to actually take advantage of this
bounce buffer speed-up. It simply seems like there was
a speed optimization for the Ricoh controllers that noone
was using. (I have not checked the distro defconfigs but
I am pretty sure the situation is the same there.)

Bounce buffers increased performance on the OMAP HSMMC
at one point, and was part of the original submission in
commit a45c6cb81647 ("[ARM] 5369/1: omap mmc: Add new
   omap hsmmc controller for 2430 and 34xx, v3")

This optimization was removed in
commit 0ccd76d4c236 ("omap_hsmmc: Implement scatter-gather
   emulation")
which found that scatter-gather emulation provided even
better performance.

The same was introduced for SDHCI in
commit 2134a922c6e7 ("sdhci: scatter-gather (ADMA) support")

I am pretty positively convinced that software
scatter-gather emulation will do for any host controller what
the bounce buffers were doing. Essentially, the bounce buffer
was a reimplementation of software scatter-gather-emulation in
the MMC subsystem, and it should be done away with.

Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Juha Yrjola <juha.yrjola@solidboot.com>
Cc: Steven J. Hill <Steven.Hill@cavium.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Suggested-by: Steven J. Hill <Steven.Hill@cavium.com>
Suggested-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: add driver strength selection when selecting hs400es 2017-10-02T08:11:22+00:00 Chanho Min chanho.min@lge.com 2017-09-26T00:03:40+00:00 fb458864d9a78cc433fec7979acbe4078c82d7a8 The driver strength selection is missed and required when selecting hs400es. So, It is added here. Fixes: 81ac2af65793ecf ("mmc: core: implement enhanced strobe support") Cc: stable@vger.kernel.org Signed-off-by: Hankyung Yu <hankyung.yu@lge.com> Signed-off-by: Chanho Min <chanho.min@lge.com> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
The driver strength selection is missed and required when selecting
hs400es. So, It is added here.

Fixes: 81ac2af65793ecf ("mmc: core: implement enhanced strobe support")
Cc: stable@vger.kernel.org
Signed-off-by: Hankyung Yu <hankyung.yu@lge.com>
Signed-off-by: Chanho Min <chanho.min@lge.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge tag 'mmc-v4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc 2017-09-26T23:54:22+00:00 Linus Torvalds torvalds@linux-foundation.org 2017-09-26T23:54:22+00:00 dc972a67cc54585bd83ad811c4e9b6ab3dcd427e Pull MMC fixes from Ulf Hansson: - sdhci-pci: Fix voltage switch for some Intel host controllers - tmio: remove broken and noisy debug macro * tag 'mmc-v4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-pci: Fix voltage switch for some Intel host controllers mmc: tmio: remove broken and noisy debug macro 
Pull MMC fixes from Ulf Hansson:

  - sdhci-pci: Fix voltage switch for some Intel host controllers

  - tmio: remove broken and noisy debug macro

* tag 'mmc-v4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: sdhci-pci: Fix voltage switch for some Intel host controllers
  mmc: tmio: remove broken and noisy debug macro
mmc: sdhci-pci: Fix voltage switch for some Intel host controllers 2017-09-22T09:06:45+00:00 Adrian Hunter adrian.hunter@intel.com 2017-09-18T12:16:08+00:00 6ae033689d7b1a419def78e8e990b0eab8bb6419 Some Intel host controllers (e.g. CNP) use an ACPI device-specific method to ensure correct voltage switching. Fix voltage switch for those, by adding a call to the DSM. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Some Intel host controllers (e.g. CNP) use an ACPI device-specific method
to ensure correct voltage switching. Fix voltage switch for those, by
adding a call to the DSM.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: tmio: remove broken and noisy debug macro 2017-09-22T08:53:31+00:00 Wolfram Sang wsa+renesas@sang-engineering.com 2017-09-14T12:30:43+00:00 e87be9b29c22852ec300826e3b1d551b00c1eb7a Some change for v4.14 broke the debug output for TMIO. But since it was not helpful to me and too noisy for my taste anyhow, let's just remove it instead of fixing it. We'll find something better if we'd need it... Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Some change for v4.14 broke the debug output for TMIO. But since it was
not helpful to me and too noisy for my taste anyhow, let's just remove
it instead of fixing it. We'll find something better if we'd need it...

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: cavium: Fix use-after-free in of_platform_device_destroy 2017-09-08T13:38:22+00:00 Jan Glauber jglauber@cavium.com 2017-09-07T11:24:17+00:00 b917c6d18c031cfce11ec35139033845f205b1d0 KASAN reported the following: [ 19.338655] ================================================================== [ 19.345946] BUG: KASAN: use-after-free in of_platform_device_destroy+0x88/0x100 [ 19.345966] Read of size 8 at addr fffffe01aa6f1468 by task systemd-udevd/264 [ 19.345983] CPU: 1 PID: 264 Comm: systemd-udevd Not tainted 4.13.0-jang+ #737 [ 19.345989] Hardware name: Cavium ThunderX CN81XX board (DT) [ 19.345995] Call trace: [ 19.346013] [<fffffc800808b1b0>] dump_backtrace+0x0/0x368 [ 19.346026] [<fffffc800808b6bc>] show_stack+0x24/0x30 [ 19.346040] [<fffffc8008cbb944>] dump_stack+0xa4/0xc8 [ 19.346057] [<fffffc80082c2870>] print_address_description+0x68/0x258 [ 19.346070] [<fffffc80082c2d70>] kasan_report+0x238/0x2f8 [ 19.346082] [<fffffc80082c14a8>] __asan_load8+0x88/0xb8 [ 19.346098] [<fffffc8008aacee0>] of_platform_device_destroy+0x88/0x100 [ 19.346131] [<fffffc8000e02fa4>] thunder_mmc_probe+0x314/0x550 [thunderx_mmc] [ 19.346147] [<fffffc800879d560>] pci_device_probe+0x158/0x1f8 [ 19.346162] [<fffffc800886e53c>] driver_probe_device+0x394/0x5f8 [ 19.346174] [<fffffc800886e8f4>] __driver_attach+0x154/0x158 [ 19.346185] [<fffffc800886b12c>] bus_for_each_dev+0xdc/0x140 [ 19.346196] [<fffffc800886d9f8>] driver_attach+0x38/0x48 [ 19.346207] [<fffffc800886d148>] bus_add_driver+0x290/0x3c8 [ 19.346219] [<fffffc800886fc5c>] driver_register+0xbc/0x1a0 [ 19.346232] [<fffffc800879b78c>] __pci_register_driver+0xc4/0xd8 [ 19.346260] [<fffffc8000e80024>] thunder_mmc_driver_init+0x24/0x10000 [thunderx_mmc] [ 19.346273] [<fffffc8008083a80>] do_one_initcall+0x98/0x1c0 [ 19.346289] [<fffffc8008177b54>] do_init_module+0xe0/0x2cc [ 19.346303] [<fffffc8008175cf0>] load_module+0x3238/0x35c0 [ 19.346318] [<fffffc8008176438>] SyS_finit_module+0x190/0x1a0 [ 19.346329] [<fffffc80080834a0>] __sys_trace_return+0x0/0x4 This is caused by: platform_device_register() -> platform_device_unregister(to_platform_device(dev)) freeing struct device -> of_node_clear_flag(dev->of_node, ...) writing to the freed device The issue is solved by increasing the reference count before calling of_platform_device_destroy() so freeing the device is postponed after the call. Fixes: 8fb83b142823 ("mmc: cavium: Fix probing race with regulator") Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
KASAN reported the following:

[   19.338655] ==================================================================
[   19.345946] BUG: KASAN: use-after-free in of_platform_device_destroy+0x88/0x100
[   19.345966] Read of size 8 at addr fffffe01aa6f1468 by task systemd-udevd/264

[   19.345983] CPU: 1 PID: 264 Comm: systemd-udevd Not tainted 4.13.0-jang+ #737
[   19.345989] Hardware name: Cavium ThunderX CN81XX board (DT)
[   19.345995] Call trace:
[   19.346013] [<fffffc800808b1b0>] dump_backtrace+0x0/0x368
[   19.346026] [<fffffc800808b6bc>] show_stack+0x24/0x30
[   19.346040] [<fffffc8008cbb944>] dump_stack+0xa4/0xc8
[   19.346057] [<fffffc80082c2870>] print_address_description+0x68/0x258
[   19.346070] [<fffffc80082c2d70>] kasan_report+0x238/0x2f8
[   19.346082] [<fffffc80082c14a8>] __asan_load8+0x88/0xb8
[   19.346098] [<fffffc8008aacee0>] of_platform_device_destroy+0x88/0x100
[   19.346131] [<fffffc8000e02fa4>] thunder_mmc_probe+0x314/0x550 [thunderx_mmc]
[   19.346147] [<fffffc800879d560>] pci_device_probe+0x158/0x1f8
[   19.346162] [<fffffc800886e53c>] driver_probe_device+0x394/0x5f8
[   19.346174] [<fffffc800886e8f4>] __driver_attach+0x154/0x158
[   19.346185] [<fffffc800886b12c>] bus_for_each_dev+0xdc/0x140
[   19.346196] [<fffffc800886d9f8>] driver_attach+0x38/0x48
[   19.346207] [<fffffc800886d148>] bus_add_driver+0x290/0x3c8
[   19.346219] [<fffffc800886fc5c>] driver_register+0xbc/0x1a0
[   19.346232] [<fffffc800879b78c>] __pci_register_driver+0xc4/0xd8
[   19.346260] [<fffffc8000e80024>] thunder_mmc_driver_init+0x24/0x10000 [thunderx_mmc]
[   19.346273] [<fffffc8008083a80>] do_one_initcall+0x98/0x1c0
[   19.346289] [<fffffc8008177b54>] do_init_module+0xe0/0x2cc
[   19.346303] [<fffffc8008175cf0>] load_module+0x3238/0x35c0
[   19.346318] [<fffffc8008176438>] SyS_finit_module+0x190/0x1a0
[   19.346329] [<fffffc80080834a0>] __sys_trace_return+0x0/0x4

This is caused by:

  platform_device_register()
   -> platform_device_unregister(to_platform_device(dev))
	freeing struct device
   -> of_node_clear_flag(dev->of_node, ...)
	writing to the freed device

The issue is solved by increasing the reference count before calling
of_platform_device_destroy() so freeing the device is postponed after
the call.

Fixes: 8fb83b142823 ("mmc: cavium: Fix probing race with regulator")
Signed-off-by: Jan Glauber <jglauber@cavium.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>