lwn.git/drivers/mmc, branch docs-for-linus

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11+00:00

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 Cc: Andrzej Hajda Cc: Andrew Morton Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla # For nvmem part Signed-off-by: Linus Torvalds

Merge tag 'mmc-v4.7-rc1' of git://git.linaro.org/people/ulf.hansson/mmc

2016-05-26T16:36:10+00:00

Pull MMC fixes from Ulf Hansson: "Here are some mmc fixes intended for v4.7 rc1. They are based on a commit earlier in the merge window and have been tested in linux-next for a while. MMC core: - Prevent re-tuning while serving requests for RPMB partitions - Extend timeout for long read time quirk to support more eMMCs MMC host: - sdhci-acpi: Ensure connected devices are powered when probing - sdhci-pci|acpi: Remove unreliable MMC_CAP_BUS_WIDTH_TEST for Intel HWs - dw_mmc: Correct the assigning of max_blk_size - dw_mmc-rockchip: Allow RPMB partitions to be created - dw_mmc-rockchip: Set the drive phase properly" * tag 'mmc-v4.7-rc1' of git://git.linaro.org/people/ulf.hansson/mmc: mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers mmc: longer timeout for long read time quirk mmc: dw_mmc: rockchip: Set the drive phase properly mmc: dw_mmc: fix the wrong max_blk_size mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities mmc: sdhci-acpi: Ensure connected devices are powered when probing ACPI / PM: Export acpi_device_fix_up_power() mmc: block: Pause re-tuning while switched to the RPMB partition mmc: block: Always switch back to main area after RPMB access mmc: core: Add a facility to "pause" re-tuning

mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers

2016-05-23T09:52:41+00:00

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 Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson

mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers

2016-05-23T09:52:40+00:00

mmc: longer timeout for long read time quirk

2016-05-23T09:52:40+00:00

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to MMC_SEND_EXT_CSD in 450-600ms. This patch will... () Increase the long read time quirk timeout from 300ms to 600ms. Original author of that quirk says 300ms was only a guess and that the number may need to be raised in the future. () Add this specific MMC to the quirk Signed-off-by: Matt Gumbel Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson

mmc: dw_mmc: rockchip: Set the drive phase properly

2016-05-23T09:45:47+00:00

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 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 Reviewed-by: Shawn Lin Tested-by: Heiko Stuebner Tested-by: Enric Balletbo i Serra Signed-off-by: Jaehoon Chung Signed-off-by: Ulf Hansson

mmc: dw_mmc: fix the wrong max_blk_size

2016-05-23T09:45:42+00:00

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 Reviewed-by: Shawn Lin Signed-off-by: Ulf Hansson

mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities

2016-05-23T09:45:34+00:00

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 Signed-off-by: Jaehoon Chung Signed-off-by: Ulf Hansson

Merge tag 'tty-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2016-05-21T03:57:27+00:00

Pull tty and serial driver updates from Greg KH: "Here's the large TTY and Serial driver update for 4.7-rc1. A few new serial drivers are added here, and Peter has fixed a bunch of long-standing bugs in the tty layer and serial drivers as normal. Full details in the shortlog. All of these have been in linux-next for a while with no reported issues" * tag 'tty-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (88 commits) MAINTAINERS: 8250: remove website reference serial: core: Fix port mutex assert if lockdep disabled serial: 8250_dw: fix wrong logic in dw8250_check_lcr() tty: vt, finish looping on duplicate tty: vt, return error when con_startup fails QE-UART: add "fsl,t1040-ucc-uart" to of_device_id serial: mctrl_gpio: Drop support for out1-gpios and out2-gpios serial: 8250dw: Add device HID for future AMD UART controller Fix OpenSSH pty regression on close serial: mctrl_gpio: add IRQ locking serial: 8250: Integrate Fintek into 8250_base serial: mps2-uart: add support for early console serial: mps2-uart: add MPS2 UART driver dt-bindings: document the MPS2 UART bindings serial: sirf: Use generic uart-has-rtscts DT property serial: sirf: Introduce helper variable struct device_node *np serial: mxs-auart: Use generic uart-has-rtscts DT property serial: imx: Use generic uart-has-rtscts DT property doc: DT: Add Generic Serial Device Tree Bindings serial: 8250: of: Make tegra_serial_handle_break() static ...

mmc: sdhci-acpi: Ensure connected devices are powered when probing

2016-05-20T14:00:25+00:00

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 Reported-and-tested-by: Laszlo Fiat Cc: # 4.5+ Signed-off-by: Ulf Hansson Reported-by: Laszlo Fiat Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571 Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com