linux-toradex.git/drivers/mmc/host, branch v4.12

mmc: meson-gx: work around broken SDIO with certain WiFi chips

2017-06-12T06:58:16+00:00

There have been reports about SDIO failing with certain WiFi chips in
descriptor chain mode. SD / eMMC are working fine.

So let's fall back to bounce buffer mode for command SD_IO_RW_EXTENDED.
This was reported to fix the error.

Fixes: 79ed05e329c3 "mmc: meson-gx: add support for descriptor chain mode"
Signed-off-by: Heiner Kallweit 
Tested-by: Martin Blumenstingl 
Signed-off-by: Ulf Hansson

mmc: sdhci-iproc: suppress spurious interrupt with Multiblock read

2017-05-22T16:18:04+00:00

The stingray SDHCI hardware supports ACMD12 and automatically
issues after multi block transfer completed.

If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen
on multi block read command with below error message:

Got data interrupt 0x00000002 even though no data
operation was in progress.

This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable
ACM12 support in SDHCI hardware and suppress spurious interrupt.

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Adrian Hunter 
Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Cc: 
Signed-off-by: Ulf Hansson

mmc: cavium: Fix probing race with regulator

2017-05-22T16:01:46+00:00

If the regulator probing is not yet finished this driver
might catch a -EPROBE_DEFER. Returning after this condition
did not remove the created platform device. On a repeated
call to the probe function the of_platform_device_create
fails.

Calling of_platform_device_destroy after EPROBE_DEFER resolves
this bug.

Signed-off-by: Jan Glauber 
Signed-off-by: Ulf Hansson

mmc: cavium: Prevent crash with incomplete DT

2017-05-22T16:01:46+00:00

In case the DT specifies neither a regulator nor a gpio
for the shared power the driver will crash accessing the regulator.
Prevent the crash by checking the regulator before use.

Use mmc_regulator_get_supply() instead of open coding the same
logic.

Signed-off-by: Jan Glauber 
Signed-off-by: Ulf Hansson

mmc: cavium-octeon: Use proper GPIO name for power control

2017-05-19T07:17:44+00:00

The devm_gpiod_get_optional() function appends a "-gpios" to the
string passed to it, so if we want to find the "power-gpios" signal,
we must pass "power" to this function.

Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.")
Signed-off-by: David Daney 
[jglauber@cavium.com: removed point after subject line]
Signed-off-by: Jan Glauber 
Signed-off-by: Ulf Hansson

mmc: cavium-octeon: Fix interrupt enable code

2017-05-19T07:17:44+00:00

OCTEON SoCs with CIU3 do not have interrupt masking local to the MMC
bus interface.  Unfortunately, some even have a diagnostic register at
the same address of the enable register, which causes the interrupts
to fire immediately if stored to, thus breaking the driver.  The proper
action on these SoCs is not to touch this register.

Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.")
Signed-off-by: David Daney 
[jglauber@cavium.com: removed point after subject line]
Signed-off-by: Jan Glauber 
Signed-off-by: Ulf Hansson

mmc: sdhci-xenon: kill xenon_clean_phy()

2017-05-19T06:58:21+00:00

Currently, the xenon_clean_phy() is only used for freeing phy_params.
The phy_params is allocated by devm_kzalloc(), there's no need to free
is explicitly.

Signed-off-by: Jisheng Zhang 
Acked-by: Hu Ziji 
Acked-by: Adrian Hunter

Merge tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs

2017-05-11T02:13:03+00:00

Pull hw lockdown support from David Howells:
 "Annotation of module parameters that configure hardware resources
  including ioports, iomem addresses, irq lines and dma channels.

  This allows a future patch to prohibit the use of such module
  parameters to prevent that hardware from being abused to gain access
  to the running kernel image as part of locking the kernel down under
  UEFI secure boot conditions.

  Annotations are made by changing:

        module_param(n, t, p)
        module_param_named(n, v, t, p)
        module_param_array(n, t, m, p)

  to:

        module_param_hw(n, t, hwtype, p)
        module_param_hw_named(n, v, t, hwtype, p)
        module_param_hw_array(n, t, hwtype, m, p)

  where the module parameter refers to a hardware setting

  hwtype specifies the type of the resource being configured. This can
  be one of:

        ioport          Module parameter configures an I/O port
        iomem           Module parameter configures an I/O mem address
        ioport_or_iomem Module parameter could be either (runtime set)
        irq             Module parameter configures an I/O port
        dma             Module parameter configures a DMA channel
        dma_addr        Module parameter configures a DMA buffer address
        other           Module parameter configures some other value

  Note that the hwtype is compile checked, but not currently stored (the
  lockdown code probably won't require it). It is, however, there for
  future use.

  A bonus is that the hwtype can also be used for grepping.

  The intention is for the kernel to ignore or reject attempts to set
  annotated module parameters if lockdown is enabled. This applies to
  options passed on the boot command line, passed to insmod/modprobe or
  direct twiddling in /sys/module/ parameter files.

  The module initialisation then needs to handle the parameter not being
  set, by (1) giving an error, (2) probing for a value or (3) using a
  reasonable default.

  What I can't do is just reject a module out of hand because it may
  take a hardware setting in the module parameters. Some important
  modules, some ipmi stuff for instance, both probe for hardware and
  allow hardware to be manually specified; if the driver is aborts with
  any error, you don't get any ipmi hardware.

  Further, trying to do this entirely in the module initialisation code
  doesn't protect against sysfs twiddling.

  [!] Note that in and of itself, this series of patches should have no
      effect on the the size of the kernel or code execution - that is
      left to a patch in the next series to effect. It does mark
      annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
      an already existing field"

* tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
  Annotate hardware config module parameters in sound/pci/
  Annotate hardware config module parameters in sound/oss/
  Annotate hardware config module parameters in sound/isa/
  Annotate hardware config module parameters in sound/drivers/
  Annotate hardware config module parameters in fs/pstore/
  Annotate hardware config module parameters in drivers/watchdog/
  Annotate hardware config module parameters in drivers/video/
  Annotate hardware config module parameters in drivers/tty/
  Annotate hardware config module parameters in drivers/staging/vme/
  Annotate hardware config module parameters in drivers/staging/speakup/
  Annotate hardware config module parameters in drivers/staging/media/
  Annotate hardware config module parameters in drivers/scsi/
  Annotate hardware config module parameters in drivers/pcmcia/
  Annotate hardware config module parameters in drivers/pci/hotplug/
  Annotate hardware config module parameters in drivers/parport/
  Annotate hardware config module parameters in drivers/net/wireless/
  Annotate hardware config module parameters in drivers/net/wan/
  Annotate hardware config module parameters in drivers/net/irda/
  Annotate hardware config module parameters in drivers/net/hamradio/
  Annotate hardware config module parameters in drivers/net/ethernet/
  ...

mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a

2017-04-28T12:53:13+00:00

The ls1046a datasheet specified that the max SD clock frequency
for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet
specified it's 125MHz for ls1012a. So this patch is to add the
limitation.

Signed-off-by: Yangbo Lu 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: sdhci-of-esdhc: poll ESDHC_CLOCK_STABLE bit with udelay

2017-04-28T10:35:27+00:00

The loop to poll ESDHC_CLOCK_STABLE bit with mdelay would waste time
because the time to stabilize is much less than 1 ms. This patch is
to use udelay instead to avoid time wasting.

Signed-off-by: Yangbo Lu 
Acked-by: Adrian Hunter 
Signed-off-by: Ulf Hansson