linux-stable.git/drivers/mmc/host, branch v4.13.2

mmc: sdhci-xenon: add set_power callback

2017-08-30T12:11:47+00:00

Xenon sdh controller requests proper SD bus voltage select
bits programmed even with vmmc power supply. Any reserved
value(100b-000b) programmed in this field will lead to controller
ignore SD bus power bit and keep its value at zero.
Add set_power callback to handle this.

Signed-off-by: Zhoujie Wu 
Acked-by: Adrian Hunter 
Tested-by: Gregory CLEMENT 
Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality")
Cc: 
Signed-off-by: Ulf Hansson

mmc: host: omap_hsmmc: Add CMD23 capability to omap_hsmmc driver

2017-08-08T08:11:07+00:00

omap_hsmmc driver always relied on CMD12 to stop transmission.
However if CMD12 is not issued at the correct timing, the card will
indicate a out of range error. With certain cards in some of the
DRA7 based boards, -EIO error is observed. By Adding CMD23 capability,
the MMC core will send MMC_SET_BLOCK_COUNT command before
MMC_READ_MULTIPLE_BLOCK/MMC_WRITE_MULTIPLE_BLOCK commands.

commit a04e6bae9e6f12 ("mmc: core: check also R1 response for
stop commands") exposed this bug in omap_hsmmc driver.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Ulf Hansson

mmc: sdhci-of-at91: force card detect value for non removable devices

2017-08-03T08:50:55+00:00

When the device is non removable, the card detect signal is often used
for another purpose i.e. muxed to another SoC peripheral or used as a
GPIO. It could lead to wrong behaviors depending the default value of
this signal if not muxed to the SDHCI controller.

Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Signed-off-by: Ludovic Desroches 
Acked-by: Adrian Hunter 
Cc: 
Signed-off-by: Ulf Hansson

mmc: dw_mmc: fix the wrong condition check of getting num-slots from DT

2017-07-27T13:57:30+00:00

Change to print the information about when the deprecated "num-slots" DT
binding is being used, as to avoid confusion when browsing the log:

dwmmc_rockchip fe320000.dwmmc: 'num-slots' was deprecated.

Signed-off-by: Shawn Lin 
Fixes: d30a8f7bdf64 ("mmc: dw_mmc: deprecated the "num-slots" property")
Signed-off-by: Ulf Hansson

mmc: host: omap_hsmmc: remove unused platform callbacks

2017-07-17T13:05:52+00:00

Remove unused callbacks in the omap_hsmmc_platform_data structure

Signed-off-by: Faiz Abbas 
Acked-by: Tony Lindgren 
Signed-off-by: Ulf Hansson

mmc: sunxi: Keep default timing phase settings for new timing mode

2017-07-17T10:29:53+00:00

The register for the "new timing mode" also has bit fields for setting
output and sample timing phases. According to comments in Allwinner's
BSP kernel, the default values are good enough.

Keep the default values already in the hardware when setting new timing
mode, instead of overwriting the whole register.

Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC
controllers")
Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
Cc: 
Signed-off-by: Ulf Hansson

Merge tag 'mmc-v4.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

2017-07-14T20:10:06+00:00

Pull MMC fixes from Ulf Hansson:
 "Here are a couple of mmc fixes intended for v4.13 rc1.

  MMC core:
   - Restore some behaviour of MMC_IOC_MULTI_CMD commands
   - Fix using un-initialized variable in mmc_blk_issue_drv_op()
   - Fix mmc block queue cleanup

  MMC host:
   - sdhci-acpi: Workaround conflict with PCI wifi on GPD Win handheld
   - tmio-mmc: Fix bad pointer math"

* tag 'mmc-v4.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: tmio-mmc: fix bad pointer math
  mmc: block: Prevent new req entering queue after its cleanup
  mmc: block: Let MMC_IOC_MULTI_CMD return zero again for zero entries
  mmc: block: Initialize ret in mmc_blk_issue_drv_op() for MMC_DRV_OP_IOCTL
  mmc: sdhci-acpi: Workaround conflict with PCI wifi on GPD Win handheld

mmc: tmio-mmc: fix bad pointer math

2017-07-13T09:56:35+00:00

The existing code gives an incorrect pointer value.
The buffer pointer 'buf' was of type unsigned short *, and 'count' was a
number in bytes. A cast of buf should have been used.

However, instead of casting, just change the code to use u32 pointers.

Reported-by: Dan Carpenter 
Fixes: 8185e51f358a: ("mmc: tmio-mmc: add support for 32bit data port")
Signed-off-by: Chris Brandt 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Wolfram Sang 
Cc: 
Signed-off-by: Ulf Hansson

mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic

2017-07-12T23:26:03+00:00

__GFP_REPEAT was designed to allow retry-but-eventually-fail semantic to
the page allocator.  This has been true but only for allocations
requests larger than PAGE_ALLOC_COSTLY_ORDER.  It has been always
ignored for smaller sizes.  This is a bit unfortunate because there is
no way to express the same semantic for those requests and they are
considered too important to fail so they might end up looping in the
page allocator for ever, similarly to GFP_NOFAIL requests.

Now that the whole tree has been cleaned up and accidental or misled
usage of __GFP_REPEAT flag has been removed for !costly requests we can
give the original flag a better name and more importantly a more useful
semantic.  Let's rename it to __GFP_RETRY_MAYFAIL which tells the user
that the allocator would try really hard but there is no promise of a
success.  This will work independent of the order and overrides the
default allocator behavior.  Page allocator users have several levels of
guarantee vs.  cost options (take GFP_KERNEL as an example)

 - GFP_KERNEL & ~__GFP_RECLAIM - optimistic allocation without _any_
   attempt to free memory at all. The most light weight mode which even
   doesn't kick the background reclaim. Should be used carefully because
   it might deplete the memory and the next user might hit the more
   aggressive reclaim

 - GFP_KERNEL & ~__GFP_DIRECT_RECLAIM (or GFP_NOWAIT)- optimistic
   allocation without any attempt to free memory from the current
   context but can wake kswapd to reclaim memory if the zone is below
   the low watermark. Can be used from either atomic contexts or when
   the request is a performance optimization and there is another
   fallback for a slow path.

 - (GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) -
   non sleeping allocation with an expensive fallback so it can access
   some portion of memory reserves. Usually used from interrupt/bh
   context with an expensive slow path fallback.

 - GFP_KERNEL - both background and direct reclaim are allowed and the
   _default_ page allocator behavior is used. That means that !costly
   allocation requests are basically nofail but there is no guarantee of
   that behavior so failures have to be checked properly by callers
   (e.g. OOM killer victim is allowed to fail currently).

 - GFP_KERNEL | __GFP_NORETRY - overrides the default allocator behavior
   and all allocation requests fail early rather than cause disruptive
   reclaim (one round of reclaim in this implementation). The OOM killer
   is not invoked.

 - GFP_KERNEL | __GFP_RETRY_MAYFAIL - overrides the default allocator
   behavior and all allocation requests try really hard. The request
   will fail if the reclaim cannot make any progress. The OOM killer
   won't be triggered.

 - GFP_KERNEL | __GFP_NOFAIL - overrides the default allocator behavior
   and all allocation requests will loop endlessly until they succeed.
   This might be really dangerous especially for larger orders.

Existing users of __GFP_REPEAT are changed to __GFP_RETRY_MAYFAIL
because they already had their semantic.  No new users are added.
__alloc_pages_slowpath is changed to bail out for __GFP_RETRY_MAYFAIL if
there is no progress and we have already passed the OOM point.

This means that all the reclaim opportunities have been exhausted except
the most disruptive one (the OOM killer) and a user defined fallback
behavior is more sensible than keep retrying in the page allocator.

[akpm@linux-foundation.org: fix arch/sparc/kernel/mdesc.c]
[mhocko@suse.com: semantic fix]
  Link: http://lkml.kernel.org/r/20170626123847.GM11534@dhcp22.suse.cz
[mhocko@kernel.org: address other thing spotted by Vlastimil]
  Link: http://lkml.kernel.org/r/20170626124233.GN11534@dhcp22.suse.cz
Link: http://lkml.kernel.org/r/20170623085345.11304-3-mhocko@kernel.org
Signed-off-by: Michal Hocko 
Acked-by: Vlastimil Babka 
Cc: Alex Belits 
Cc: Chris Wilson 
Cc: Christoph Hellwig 
Cc: Darrick J. Wong 
Cc: David Daney 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: NeilBrown 
Cc: Ralf Baechle 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mmc: sdhci-acpi: Workaround conflict with PCI wifi on GPD Win handheld

2017-07-11T12:11:59+00:00

GPDwin uses PCI wifi which conflicts with SDIO's use of
acpi_device_fix_up_power() on child device nodes. Specifically
acpi_device_fix_up_power() causes the wifi module to get turned off.
Identifying GPDwin is problematic, but since SDIO is only used for wifi,
the presence of the PCI wifi card in the expected slot with an ACPI
companion node, is used to indicate that acpi_device_fix_up_power() should
be avoided.

Signed-off-by: Adrian Hunter 
Acked-by: Hans de Goede 
Tested-by: Hans de Goede 
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson