[GIT PULL] MMC for v.4.6

[GIT PULL] MMC for v.4.6

[Ulf Hansson]

Hi Linus,

Here's the PR for MMC v4.6.

Details about the highlights are as usual found in the signed tag.

Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af:

  Linux 4.5-rc6 (2016-02-28 08:41:20 -0800)

are available in the git repository at:

  git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.6

for you to fetch changes up to 64e5cd723120643a4c8bef0880a03a60161d3ccb:

  mmc: sdhci-of-at91: fix wake-up issue when using runtime pm
(2016-03-18 09:12:32 +0100)

----------------------------------------------------------------
MMC core:
 - Fix ABI regression of MMC BLK ioctl
 - Remove the unused MMC_DATA_STREAM flag
 - Enable asynchronous system PM for the host device
 - Minor fixes and clean-ups

SDHCI host:
Throughout the years, the numbers of SDHCI variants have increased and so
has also the numbers of SDHCI callbacks/quirks. The purpose of these
callbacks/quirks were to enable SDHCI to deal with variant specific
requirements, but unfortunate this method didn't scale. Instead we have
ended up with a mess. Not only did the code become suboptimal but also
highly fragile.

Lately many discussions of how to move forward with SDHCI has taken place
at the MMC mailing list. Step by step, we aim to turn SDHCI's common code
into a set of library functions. This will enable for optimizations and
allow some of the existing callbacks/quirks to be removed, which also
should help to make the code less fragile.

Therefore I am also really pleased to announce that Adrian Hunter (Intel)
has volunteered to step in as the maintainer for SDHCI.

Future wise, I hope the community around SDHCI will continue to grow and
that this release cycle can be the starting point of moving SDHCI into a
better shape. As a matter of fact, already in this cycle the re-factoring
has begun, but of course there are also fixes and new features included.
Some highlights:

 - sdhci-iproc: Add support for Broadcom's BCM2835 eMMC IP
 - sdhci-acpi: Add support for QCOM controllers
 - sdhci-pic32: Add new SDHCI variant for PIC32MZDA

Other hosts:
 - atmel-mci: Fix a NULL pointer dereference
 - mediatek: Add SD write-protect support
 - mmc_spi: Fix card detect in GPIO case
 - tmio/sdhi: Add r8a7795 support
 - tmio/sdhi: Some fixes and clean-ups
 - dw_mmc: Add HW reset support
 - dw_mmc: Some fixes and clean-ups
 - sunxi: Add support for MMC DDR52 mode

----------------------------------------------------------------
Adrian Hunter (1):
      mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout

Al Cooper (1):
      mmc: sdhci: Allow CAPS check for SDHCI_CAN_64BIT to use overridden caps

Alexandre Courbot (3):
      mmc: sdhci: Set DMA mask when adding host
      mmc: sdhci-acpi: Remove enable_dma() hook
      mmc: sdhci-pci: Do not set DMA mask in enable_dma()

Andrei Pistirica (2):
      dt/bindings: mmc: Add bindings for PIC32 SDHCI host controller
      mmc: sdhci-pic32: Add PIC32 SDHCI host controller driver

Arnd Bergmann (1):
      mmc: omap_hsmmc: don't print uninitialized variables

Brent Taylor (1):
      mmc: atmel-mci: Check pdata for NULL before dereferencing it at DMA config

Brian Norris (1):
      mmc: of_mmc_spi: fix unused warning

Chaotian Jing (1):
      mmc: mediatek: add SD write protect support

Chen-Yu Tsai (6):
      mmc: sunxi: Document host init sequence
      mmc: sunxi: Return error on mmc_regulator_set_ocr() fail in .set_ios op
      mmc: sunxi: Support vqmmc regulator
      mmc: sunxi: Support MMC_DDR52 timing modes
      mmc: sunxi: Support 8 bit eMMC DDR transfer modes
      mmc: sunxi: Enable eMMC HS-DDR (MMC_CAP_1_8V_DDR) support

Chuanxiao Dong (1):
      mmc: debugfs: Add a restriction to mmc debugfs clock setting

Fu, Zhonghui (2):
      mmc: core: enable mmc host device to suspend/resume asynchronously
      mmc: sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously

Geliang Tang (2):
      mmc: sh_mmcif: use to_delayed_work
      mmc: usdhi6rol0: use to_delayed_work

Jaehoon Chung (13):
      mmc: core: use the defined function to check whether card is removable
      mmc: atmel-mci: remove the MMC_DATA_STREAM flag
      mmc: bfin_sdh: remove the MMC_DATA_STREAM flag
      mmc: davinci_mmc: remove the MMC_DATA_STREAM flag
      mmc: dw_mmc: remove the MMC_DATA_STREAM flag
      mmc: jz4740_mmc: remove the MMC_DATA_STREAM flag
      mmc: mxcmmc: remove the MMC_DATA_STREAM flag
      mmc: pxamci: remove the MMC_DATA_STREAM flag
      mmc: s3cmci: remove the MMC_DATA_STREAM flag
      mmc: sunxi-mmc: remove the MMC_DATA_STREAM flag
      mmc: core: remove the MMC_DATA_STREAM flag
      mmc: block: don't use the OR operation for flag of data
      mmc: dw_mmc: remove the prepare_command hook

Jisheng Zhang (14):
      mmc: sdhci-iproc: use sdhci_pltfm_unregister directly
      mmc: sdhci-bcm2835: use sdhci_pltfm_init for private allocation
      mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for private allocation
      mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of sdhci_msm_host
      mmc: sdhci-msm: use sdhci_pltfm_init for private allocation
      mmc: sdhci-of-arasan: fix clk issue in sdhci_arasan_remove()
      mmc: sdhci-of-arasan: use sdhci_pltfm_init for private allocation
      mmc: sdhci-of-at91: use sdhci_pltfm_init for private allocation
      mmc: sdhci-of-esdhc: use sdhci_pltfm_init for private allocation
      mmc: sdhci-pxav3: use sdhci_pltfm_init for private allocation
      mmc: sdhci-st: use sdhci_pltfm_init for private allocation
      mmc: sdhci-tegra: use sdhci_pltfm_init for private allocation
      mmc: sdhci-pxav2: remove unnecessary assignment of pltfm_host->priv
      mmc: sdhci-pltfm: remove priv variable from sdhci_pltfm_host

Jon Hunter (1):
      mmc: tegra: Disable UHS-I modes for tegra114

Kishon Vijay Abraham I (1):
      mmc: host: omap_hsmmc: add a verbose print to enable
CONFIG_REGULATOR_PBIAS

Lucas Stach (2):
      mmc: tegra: properly disable card clock
      mmc: tegra: implement memcomp pad calibration

Magnus Damm (1):
      mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case

Markus Elfring (2):
      mmc: sdricoh_cs: Delete unnecessary variable initialisations
      mmc: sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection

Masahiro Yamada (1):
      mmc: remove unnecessary assignment statements before return

Nicolas Boichat (2):
      mmc: mediatek: Change signal voltage error to dev_dbg()
      mmc: mediatek: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch

Peter Chen (1):
      mmc: core: pwrseq_simple: remove unused header file

Philip Elcan (1):
      mmc: sdhci-acpi: add QCOM controllers

Rameshwar Prasad Sahu (1):
      mmc: sdhci-of-arasan: Remove no-hispd and no-cmd23 quirks for
sdhci-arasan4.9a

Russell King (26):
      mmc: core: shut up "voltage-ranges unspecified" pr_info()
      mmc: core: improve mmc_of_parse_voltage() to return better status
      mmc: block: shut up "retrying because a re-tune was needed" message
      mmc: core: report tuning command execution failure reason
      mmc: sdhci: move initialisation of command error member
      mmc: sdhci: clean up command error handling
      mmc: sdhci: fix command response CRC error handling
      mmc: sdhci: avoid unnecessary mapping/unmapping of align buffer
      mmc: sdhci: plug DMA mapping leak on error
      mmc: sdhci-pxav3: fix higher speed mode capabilities
      mmc: sdhci: further fix for DMA unmapping in sdhci_post_req()
      mmc: sdhci: fix data timeout (part 1)
      mmc: sdhci: fix data timeout (part 2)
      mmc: sdhci: allocate alignment and DMA descriptor buffer together
      mmc: sdhci: clean up coding style in sdhci_adma_table_pre()
      mmc: sdhci: avoid walking SG list for writes
      mmc: sdhci: factor out common DMA cleanup in sdhci_finish_data()
      mmc: sdhci: move sdhci_pre_dma_transfer()
      mmc: sdhci: factor out sdhci_pre_dma_transfer() from
sdhci_adma_table_pre()
      mmc: sdhci: pass the cookie into sdhci_pre_dma_transfer()
      mmc: sdhci: always unmap a mapped data transfer in sdhci_post_req()
      mmc: sdhci: clean up host cookie handling
      mmc: sdhci: cleanup DMA un-mapping
      mmc: sdhci: prepare DMA address/size quirk handling consolidation
      mmc: sdhci: consolidate the DMA/ADMA size/address quicks
      mmc: sdhci: further code simplication

Shawn Lin (13):
      mmc: dw_mmc: add hw_reset support
      mmc: dw_mmc: remove struct block_settings
      mmc: dw_mmc: remove DW_MCI_QUIRK_BROKEN_CARD_DETECTION quirk
      mmc: dw_mmc: fix err handle of dw_mci_probe
      mmc: dw_mmc: remove repetitive clear interrupt
      mmc: dw_mmc: fix num_slots setting
      Documentation: bindings: add description of phy for sdhci-of-arasan
      mmc: sdhci-of-arasan: remove disable clk_ahb from sdhci_arasan_resume
      mmc: sdhci-of-arasan: fix missing sdhci_pltfm_free for err handling
      mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
      mmc: core: remove redundant memset of mmc_decode_cid
      mmc: core: remove redundant memset of sdio_read_cccr
      mmc: block: fix ABI regression of mmc_blk_ioctl

Shinobu Uehara (1):
      mmc: sdhi: Add EXT_ACC register busy check

Simon Horman (1):
      mmc: sh_mmcif, tmio: Use ARCH_RENESAS

Stefan Wahren (5):
      mmc: sdhci-iproc: Clean up platform allocations if shdci init fails
      mmc: sdhci-iproc: Actually enable the clock
      mmc: sdhci-iproc: define MMC caps in platform data
      mmc: sdhci-iproc: add bcm2835 support
      mmc: DT: sdhci-iproc: add bcm2835 compatible

Ulf Hansson (1):
      MAINTAINERS: mmc: Add Adrian Hunter as the maintainer for SDHCI

Wang Hongcheng (1):
      mmc: mmci: Remove unnecessary header file

Wolfram Sang (12):
      mmc: make MAN_BKOPS_EN message a debug
      mmc: mmcif: don't depend on MMC_BLOCK
      mmc: mmc_test: mention that '0' runs all tests
      mmc: sanitize 'bus width' in debug output
      mmc: tmio_dma: remove debug messages with little information
      mmc: sdhi: error message on ENOMEM is superfluous
      mmc: tmio: add flag to reduce delay after changing clock status
      mmc: tmio: remove stale comments
      mmc: sdhi: use faster clock handling on RCar Gen2
      mmc: tmio: refactor set_clock a little
      mmc: tmio: disable clock before changing it
      mmc: sdhi: Add r8a7795 support

ludovic.desroches@atmel.com (1):
      mmc: sdhci-of-at91: fix wake-up issue when using runtime pm

 .../devicetree/bindings/mmc/arasan,sdhci.txt       |  20 +-
 .../devicetree/bindings/mmc/brcm,sdhci-iproc.txt   |   5 +-
 .../bindings/mmc/microchip,sdhci-pic32.txt         |  29 ++
 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |   1 +
 MAINTAINERS                                        |   8 +-
 drivers/mmc/card/block.c                           |  34 +-
 drivers/mmc/card/mmc_test.c                        |   1 +
 drivers/mmc/core/core.c                            |  29 +-
 drivers/mmc/core/debugfs.c                         |   2 +-
 drivers/mmc/core/host.c                            |   1 +
 drivers/mmc/core/mmc.c                             |   4 +-
 drivers/mmc/core/mmc_ops.c                         |  19 +-
 drivers/mmc/core/pwrseq_simple.c                   |   1 -
 drivers/mmc/core/sd.c                              |   2 -
 drivers/mmc/core/sd_ops.c                          |   7 +-
 drivers/mmc/core/sdio.c                            |   2 -
 drivers/mmc/core/sdio_ops.c                        |   3 +-
 drivers/mmc/host/Kconfig                           |  25 +-
 drivers/mmc/host/Makefile                          |   1 +
 drivers/mmc/host/atmel-mci.c                       |  11 +-
 drivers/mmc/host/bfin_sdh.c                        |   3 -
 drivers/mmc/host/davinci_mmc.c                     |  15 +-
 drivers/mmc/host/dw_mmc-exynos.c                   |  31 +-
 drivers/mmc/host/dw_mmc-pltfm.c                    |  19 +-
 drivers/mmc/host/dw_mmc-rockchip.c                 |   7 -
 drivers/mmc/host/dw_mmc.c                          | 101 +++--
 drivers/mmc/host/dw_mmc.h                          |   6 +-
 drivers/mmc/host/jz4740_mmc.c                      |   2 -
 drivers/mmc/host/mmc_spi.c                         |   6 +
 drivers/mmc/host/mmci.c                            |   1 -
 drivers/mmc/host/mtk-sd.c                          |  19 +-
 drivers/mmc/host/mxcmmc.c                          |   3 -
 drivers/mmc/host/of_mmc_spi.c                      |   2 -
 drivers/mmc/host/omap_hsmmc.c                      |   9 +-
 drivers/mmc/host/pxamci.c                          |   6 -
 drivers/mmc/host/s3cmci.c                          |   3 +-
 drivers/mmc/host/sdhci-acpi.c                      |  47 +-
 drivers/mmc/host/sdhci-bcm2835.c                   |  14 +-
 drivers/mmc/host/sdhci-esdhc-imx.c                 |  38 +-
 drivers/mmc/host/sdhci-iproc.c                     |  40 +-
 drivers/mmc/host/sdhci-msm.c                       |  25 +-
 drivers/mmc/host/sdhci-of-arasan.c                 | 109 +++--
 drivers/mmc/host/sdhci-of-at91.c                   |  53 ++-
 drivers/mmc/host/sdhci-of-esdhc.c                  |  19 +-
 drivers/mmc/host/sdhci-pci-core.c                  |  15 -
 drivers/mmc/host/sdhci-pic32.c                     | 257 +++++++++++
 drivers/mmc/host/sdhci-pltfm.h                     |   1 -
 drivers/mmc/host/sdhci-pxav2.c                     |   1 -
 drivers/mmc/host/sdhci-pxav3.c                     |  26 +-
 drivers/mmc/host/sdhci-st.c                        |  40 +-
 drivers/mmc/host/sdhci-tegra.c                     |  82 +++-
 drivers/mmc/host/sdhci.c                           | 500 ++++++++++-----------
 drivers/mmc/host/sdhci.h                           |   4 +-
 drivers/mmc/host/sdricoh_cs.c                      |  26 +-
 drivers/mmc/host/sh_mmcif.c                        |   2 +-
 drivers/mmc/host/sh_mobile_sdhi.c                  |  54 ++-
 drivers/mmc/host/sunxi-mmc.c                       |  95 +++-
 drivers/mmc/host/tmio_mmc_dma.c                    |  11 -
 drivers/mmc/host/tmio_mmc_pio.c                    |  27 +-
 drivers/mmc/host/usdhi6rol0.c                      |   2 +-
 include/linux/mfd/tmio.h                           |   4 +
 include/linux/mmc/core.h                           |   1 -
 include/linux/mmc/dw_mmc.h                         |  12 +-
 include/linux/mmc/tmio.h                           |   5 +
 64 files changed, 1171 insertions(+), 777 deletions(-)
 create mode 100644
Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt
 create mode 100644 drivers/mmc/host/sdhci-pic32.c

[bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Peter Hurley]

On 03/21/2016 05:59 AM, Ulf Hansson wrote:
> Hi Linus,
> 
> Here's the PR for MMC v4.6.
> 
> Details about the highlights are as usual found in the signed tag.
> 
> Please pull this in!
> 
> Kind regards
> Ulf Hansson
> 
> 
> The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af:
> 
>   Linux 4.5-rc6 (2016-02-28 08:41:20 -0800)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.6
> 
> for you to fetch changes up to 64e5cd723120643a4c8bef0880a03a60161d3ccb:
> 
>   mmc: sdhci-of-at91: fix wake-up issue when using runtime pm
> (2016-03-18 09:12:32 +0100)

This merge commit e531cdf50a8a0fb7a4d51c06e52097bd01e9bf7c
Merge: 4526b71 64e5cd7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Mar 21 14:35:52 2016 -0700

    Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc
    
    Pull MMC updates from Ulf Hansson:
    ...

is fingered by git bisect as the cause for a mashup of mmc block devices
on a Beaglebone Black:

[    2.916209] mmc1: new high speed MMC card at address 0001
[    2.923755] mmcblk0: mmc1:0001 MMC04G 3.60 GiB
[    2.929479] mmcblk0boot0: mmc1:0001 MMC04G partition 1 2.00 MiB
[    2.936821] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    2.942270] mmcblk0boot1: mmc1:0001 MMC04G partition 2 2.00 MiB
[    2.949388]  mmcblk0: p1 p2
[    2.950031] mmc0: new high speed SDHC card at address e624
[    2.961118] mmcblk1: mmc0:e624 SU08G 7.40 GiB
[    2.967047] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.974190]  mmcblk1: p1 p2

Note how mmc1 => mmcblk0 and mmc0 => mmcblk1.

This produces a failure to boot as the wrong partition is mounted as
root (/dev/mmcblk0p2 is now on the wrong mmc).

The bisect tried all the mmc tree patches which were all good.
I double-checked by cloning the mmc tree and building both mmc-v4.6
and v4.5-rc6, and both tested good.

I interpret that to mean some change in mmc + some new behavior elsewhere
for v4.6 is causing this. Any ideas?

Regards,
Peter Hurley

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Linus Torvalds]

On Sat, Apr 2, 2016 at 9:56 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>
> Note how mmc1 => mmcblk0 and mmc0 => mmcblk1.
>
> This produces a failure to boot as the wrong partition is mounted as
> root (/dev/mmcblk0p2 is now on the wrong mmc).

It *looks* very much like somebody is doing asynchronous probing of
the bus, meaning that the devices get probed in random order.

And that "random order" is admittedly probably usually fairly static
on any particular hardware platform, but then something happens to
change timing, and...

This is why you should never probe the actual *bus* asynchronously,
just do the end-point setup async. For example, you'd enumerate ports
(and assign devices to the ports) synchronously, but then after device
assignment the actual device probing can be async.

> The bisect tried all the mmc tree patches which were all good.
> I double-checked by cloning the mmc tree and building both mmc-v4.6
> and v4.5-rc6, and both tested good.
>
> I interpret that to mean some change in mmc + some new behavior elsewhere
> for v4.6 is causing this. Any ideas?

Hmm. If it really is just timing, it could have been around forever,
and just hidden by the fact that normally mmc0 gets probed before
mmc1, but then some other probing thing slowed down or the exact
details of the async workqueue  scheduling changed, and now mmc1 just
*happens* to get probed first..

The thing that changed scheduling order could easily have come from
some non-mmc change.

NOTE! I have nothing to back this up except that (a) we've had
problems like this before and (b) it does look from your dmesg that
mmcX is simply probed in the "wrong" order. I didn't look at exactly
what mmc does or who does the probing.

Maybe Ulf can explain what it is that is _supposed_ to keep the mmc
probe order stable. Ulf?

             Linus

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Ulf Hansson]

On 3 April 2016 at 13:54, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, Apr 2, 2016 at 9:56 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>>
>> Note how mmc1 => mmcblk0 and mmc0 => mmcblk1.
>>
>> This produces a failure to boot as the wrong partition is mounted as
>> root (/dev/mmcblk0p2 is now on the wrong mmc).
>
> It *looks* very much like somebody is doing asynchronous probing of
> the bus, meaning that the devices get probed in random order.

Correct.

>
> And that "random order" is admittedly probably usually fairly static
> on any particular hardware platform, but then something happens to
> change timing, and...
>
> This is why you should never probe the actual *bus* asynchronously,
> just do the end-point setup async. For example, you'd enumerate ports
> (and assign devices to the ports) synchronously, but then after device
> assignment the actual device probing can be async.

So to do this, we need to tie the mmc/sd/sdio controller to a
dedicated mmcblk id.

There have been some ideas to fix this by using "aliases" in a DT
based configuration.

>
>> The bisect tried all the mmc tree patches which were all good.
>> I double-checked by cloning the mmc tree and building both mmc-v4.6
>> and v4.5-rc6, and both tested good.
>>
>> I interpret that to mean some change in mmc + some new behavior elsewhere
>> for v4.6 is causing this. Any ideas?
>
> Hmm. If it really is just timing, it could have been around forever,
> and just hidden by the fact that normally mmc0 gets probed before
> mmc1, but then some other probing thing slowed down or the exact
> details of the async workqueue  scheduling changed, and now mmc1 just
> *happens* to get probed first..
>
> The thing that changed scheduling order could easily have come from
> some non-mmc change.
>
> NOTE! I have nothing to back this up except that (a) we've had
> problems like this before and (b) it does look from your dmesg that
> mmcX is simply probed in the "wrong" order. I didn't look at exactly
> what mmc does or who does the probing.
>
> Maybe Ulf can explain what it is that is _supposed_ to keep the mmc
> probe order stable. Ulf?
>
>              Linus

The commit that's likely to cause the regression is:
520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
simultaneously").

This commit further enables asynchronous detection of (e)MMC/SD/SDIO
cards, by converting from an *ordered* work-queue to a *non-ordered*
work-queue for card detection.

Although, one should know that there have *never* been any guarantees
to get a fixed mmcblk id for a card. I expect that's what has been
assumed here.

Let me elaborate a bit on the card detection procedure. When the mmc
controller has been successfully probed, its driver schedules a work
to start enumeration of cards. Only cards that gets detected
successfully becomes registered and those gets an mmcblk id assigned
to it. The picked id, is the first available starting from zero. Now,
as cards can be removable and because drivers for mmc controllers may
sometimes returns -EPROBE_DEFER (for whatever reason), there's never
been support for fixed mmcblk ids.

To deal with this, one should use the so called UUID/PARTUUID. Is
there any reasons to why that can't be done in this case?

Kind regards
Uffe

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Peter Hurley]

On 04/04/2016 04:29 AM, Ulf Hansson wrote:
> On 3 April 2016 at 13:54, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Sat, Apr 2, 2016 at 9:56 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>>>
>>> Note how mmc1 => mmcblk0 and mmc0 => mmcblk1.
>>>
>>> This produces a failure to boot as the wrong partition is mounted as
>>> root (/dev/mmcblk0p2 is now on the wrong mmc).
>>
>> It *looks* very much like somebody is doing asynchronous probing of
>> the bus, meaning that the devices get probed in random order.
> 
> Correct.
> 
>>
>> And that "random order" is admittedly probably usually fairly static
>> on any particular hardware platform, but then something happens to
>> change timing, and...
>>
>> This is why you should never probe the actual *bus* asynchronously,
>> just do the end-point setup async. For example, you'd enumerate ports
>> (and assign devices to the ports) synchronously, but then after device
>> assignment the actual device probing can be async.
> 
> So to do this, we need to tie the mmc/sd/sdio controller to a
> dedicated mmcblk id.
> 
> There have been some ideas to fix this by using "aliases" in a DT
> based configuration.
> 
>>
>>> The bisect tried all the mmc tree patches which were all good.
>>> I double-checked by cloning the mmc tree and building both mmc-v4.6
>>> and v4.5-rc6, and both tested good.
>>>
>>> I interpret that to mean some change in mmc + some new behavior elsewhere
>>> for v4.6 is causing this. Any ideas?
>>
>> Hmm. If it really is just timing, it could have been around forever,
>> and just hidden by the fact that normally mmc0 gets probed before
>> mmc1, but then some other probing thing slowed down or the exact
>> details of the async workqueue  scheduling changed, and now mmc1 just
>> *happens* to get probed first..
>>
>> The thing that changed scheduling order could easily have come from
>> some non-mmc change.
>>
>> NOTE! I have nothing to back this up except that (a) we've had
>> problems like this before and (b) it does look from your dmesg that
>> mmcX is simply probed in the "wrong" order. I didn't look at exactly
>> what mmc does or who does the probing.
>>
>> Maybe Ulf can explain what it is that is _supposed_ to keep the mmc
>> probe order stable. Ulf?
>>
>>              Linus
> 
> The commit that's likely to cause the regression is:
> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
> simultaneously").
> 
> This commit further enables asynchronous detection of (e)MMC/SD/SDIO
> cards, by converting from an *ordered* work-queue to a *non-ordered*
> work-queue for card detection.
> 
> Although, one should know that there have *never* been any guarantees
> to get a fixed mmcblk id for a card. I expect that's what has been
> assumed here.

Tell me about it. I'm in the middle of reverting non-blocking read()
behavior since 3.12 because _one_ userspace app relies on *blocking*
non-blocking read() behavior that existed before 3.12.


> Let me elaborate a bit on the card detection procedure. When the mmc
> controller has been successfully probed, its driver schedules a work
> to start enumeration of cards. Only cards that gets detected
> successfully becomes registered and those gets an mmcblk id assigned
> to it. The picked id, is the first available starting from zero. Now,
> as cards can be removable and because drivers for mmc controllers may
> sometimes returns -EPROBE_DEFER (for whatever reason), there's never
> been support for fixed mmcblk ids.
> 
> To deal with this, one should use the so called UUID/PARTUUID. Is
> there any reasons to why that can't be done in this case?

Well, I can.
But I'm not volunteering to update the other 250,000+ bootloader scripts
that do "root=/dev/mmcblk0p2"

Regards,
Peter Hurley

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Linus Torvalds]

On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The commit that's likely to cause the regression is:
> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
> simultaneously").

Peter, mind testing if you can revert that and get the old behavior
back? It seems to still revert cleanly, although I didn't check if the
revert actually then builds..

> This commit further enables asynchronous detection of (e)MMC/SD/SDIO
> cards, by converting from an *ordered* work-queue to a *non-ordered*
> work-queue for card detection.
>
> Although, one should know that there have *never* been any guarantees
> to get a fixed mmcblk id for a card. I expect that's what has been
> assumed here.

So quite frankly, for the whole "no regressions" issue, "documented
behavior" simply isn't an issue. It doesn't matter one whit or not if
something has been documented: if it has worked and people have
depended on it, it's what we in the industry call "reality".

And reality trumps documentation. Every time.

So it sounds like either that just needs to be reverted, or some other
way to get reliable device naming needs to happen.

So the *simple* model is to just scan the devices minimally serially,
and allocate the names at that point (so the names are reliable
between boots for the same hardware configuration). And then do the
more expensive device setup asynchronously (ie querying device
information, spinning up disks, whatever - things that can take
anything from milliseonds to several seconds, because they are doing
actual IO). So you'd do some very basic (and _often_ fairly quick)
operations serially, but then try to do the expensive parts
concurrently.

The SCSI layer actually goes a bit further than that: it has a fairly
asynchronous scanning thing, but it does allocate the actual host
device nodes serially, and then it even has an ordered list of
"scanning_hosts" that is used to complete the scanning in-order, so
that the sysfs devices show up in the right order even if things
actually got scanned out-of-order. So scans that finished early will
wait for other scans that are for "earlier" devices, and you end up
with what *looks* ordered to the outside, even if internally it was
all done out-of-order.

So there are multiple approaches to handling this, while still
allowing fairly asynchronous IO.

                 Linus

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Peter Hurley]

On 04/04/2016 11:59 AM, Linus Torvalds wrote:
> On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> The commit that's likely to cause the regression is:
>> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
>> simultaneously").
> 
> Peter, mind testing if you can revert that and get the old behavior
> back? It seems to still revert cleanly, although I didn't check if the
> revert actually then builds..

Yeah, a straight revert of 520bd7a8b415 resumes normal service:

[    2.710232] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.718437] mmc0: new high speed SDHC card at address e624
[    2.724801] mmcblk0: mmc0:e624 SU08G 7.40 GiB
[    2.730314]  mmcblk0: p1 p2
...
[    2.808938] mmc1: new high speed MMC card at address 0001
[    2.816352] mmcblk1: mmc1:0001 MMC04G 3.60 GiB
[    2.822075] mmcblk1boot0: mmc1:0001 MMC04G partition 1 2.00 MiB
[    2.829014] mmcblk1boot1: mmc1:0001 MMC04G partition 2 2.00 MiB
[    2.842600]  mmcblk1: p1 p2

Should I send a proper revert?


>> This commit further enables asynchronous detection of (e)MMC/SD/SDIO
>> cards, by converting from an *ordered* work-queue to a *non-ordered*
>> work-queue for card detection.
>>
>> Although, one should know that there have *never* been any guarantees
>> to get a fixed mmcblk id for a card. I expect that's what has been
>> assumed here.
> 
> So quite frankly, for the whole "no regressions" issue, "documented
> behavior" simply isn't an issue. It doesn't matter one whit or not if
> something has been documented: if it has worked and people have
> depended on it, it's what we in the industry call "reality".
> 
> And reality trumps documentation. Every time.
> 
> So it sounds like either that just needs to be reverted, or some other
> way to get reliable device naming needs to happen.
> 
> So the *simple* model is to just scan the devices minimally serially,
> and allocate the names at that point (so the names are reliable
> between boots for the same hardware configuration). And then do the
> more expensive device setup asynchronously (ie querying device
> information, spinning up disks, whatever - things that can take
> anything from milliseonds to several seconds, because they are doing
> actual IO). So you'd do some very basic (and _often_ fairly quick)
> operations serially, but then try to do the expensive parts
> concurrently.
> 
> The SCSI layer actually goes a bit further than that: it has a fairly
> asynchronous scanning thing, but it does allocate the actual host
> device nodes serially, and then it even has an ordered list of
> "scanning_hosts" that is used to complete the scanning in-order, so
> that the sysfs devices show up in the right order even if things
> actually got scanned out-of-order. So scans that finished early will
> wait for other scans that are for "earlier" devices, and you end up
> with what *looks* ordered to the outside, even if internally it was
> all done out-of-order.
> 
> So there are multiple approaches to handling this, while still
> allowing fairly asynchronous IO.
> 
>                  Linus
> 

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Linus Torvalds]

On Mon, Apr 4, 2016 at 12:29 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>
> Yeah, a straight revert of 520bd7a8b415 resumes normal service:

Ok, so we have that as an option.

> Should I send a proper revert?

Let's see if somebody can come up with a better serialization model.
We're only at rc2, and we now have a fallback fix, let's wait a week
or two to see if the mmc people can come up with something.

But maybe you can send me a revert patch around rc4 or so if the
problem still remains, ok?

               Linus

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Peter Hurley]

On 04/04/2016 12:49 PM, Linus Torvalds wrote:
> On Mon, Apr 4, 2016 at 12:29 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>>
>> Yeah, a straight revert of 520bd7a8b415 resumes normal service:
> 
> Ok, so we have that as an option.
> 
>> Should I send a proper revert?
> 
> Let's see if somebody can come up with a better serialization model.
> We're only at rc2, and we now have a fallback fix, let's wait a week
> or two to see if the mmc people can come up with something.
> 
> But maybe you can send me a revert patch around rc4 or so if the
> problem still remains, ok?

Will do.

Regards,
Peter Hurley

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Ulf Hansson]

On 4 April 2016 at 20:59, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> The commit that's likely to cause the regression is:
>> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
>> simultaneously").
>
> Peter, mind testing if you can revert that and get the old behavior
> back? It seems to still revert cleanly, although I didn't check if the
> revert actually then builds..

I have checked, the revert should be a safe option. There is nothing
added on top that relies on it.

Moreover, I have no problem dealing with the revert, as it me
personally that screwed this up.

>
>> This commit further enables asynchronous detection of (e)MMC/SD/SDIO
>> cards, by converting from an *ordered* work-queue to a *non-ordered*
>> work-queue for card detection.
>>
>> Although, one should know that there have *never* been any guarantees
>> to get a fixed mmcblk id for a card. I expect that's what has been
>> assumed here.
>
> So quite frankly, for the whole "no regressions" issue, "documented
> behavior" simply isn't an issue. It doesn't matter one whit or not if
> something has been documented: if it has worked and people have
> depended on it, it's what we in the industry call "reality".
>
> And reality trumps documentation. Every time.

I totally agree.

Although, what puzzles me around this particular issue, is how an SoC
configuration can rely on this fragile behaviour.
All you have to do to break the assumption of fixed mmcblk ids, is to
boot with an SD card inserted and then without. Perhaps these SoCs
just doesn't support this use case!?

>
> So it sounds like either that just needs to be reverted, or some other
> way to get reliable device naming needs to happen.
>
> So the *simple* model is to just scan the devices minimally serially,
> and allocate the names at that point (so the names are reliable
> between boots for the same hardware configuration). And then do the
> more expensive device setup asynchronously (ie querying device
> information, spinning up disks, whatever - things that can take
> anything from milliseonds to several seconds, because they are doing
> actual IO). So you'd do some very basic (and _often_ fairly quick)
> operations serially, but then try to do the expensive parts
> concurrently.
>
> The SCSI layer actually goes a bit further than that: it has a fairly
> asynchronous scanning thing, but it does allocate the actual host
> device nodes serially, and then it even has an ordered list of
> "scanning_hosts" that is used to complete the scanning in-order, so
> that the sysfs devices show up in the right order even if things
> actually got scanned out-of-order. So scans that finished early will
> wait for other scans that are for "earlier" devices, and you end up
> with what *looks* ordered to the outside, even if internally it was
> all done out-of-order.
>
> So there are multiple approaches to handling this, while still
> allowing fairly asynchronous IO.

Thanks for sharing this information!

I will give it a try and see if I can come up with something that
restores the behaviour, but without having to do the revert. If it
turns out to be too complicated, I can post the revert in a couple of
rcs.

Kind regards
Uffe

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Peter Hurley]

On 04/05/2016 01:59 AM, Ulf Hansson wrote:
> Although, what puzzles me around this particular issue, is how an SoC
> configuration can rely on this fragile behaviour.
> All you have to do to break the assumption of fixed mmcblk ids, is to
> boot with an SD card inserted and then without. Perhaps these SoCs
> just doesn't support this use case!?

Both configurations boot reliably; without the uSD inserted, the
boot and root partitions on the eMMC are booted instead.

Without a uSD inserted, the only mmc block device is the eMMC which is
/dev/mmcblk0, and the root partition is still /dev/mmcblk0p2.

Note though that this particular bootscript can load add'l bootscripts
from the boot partition; in this particular case, the eMMC root
partition is set as a fixed UUID in the bootscript from the
boot partition.

Regards,
Peter Hurley

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Jisheng Zhang]

Hi Ulf,

On Tue, 5 Apr 2016 10:59:28 +0200 Ulf Hansson wrote:

> On 4 April 2016 at 20:59, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:  
> >>
> >> The commit that's likely to cause the regression is:
> >> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
> >> simultaneously").  
> >
> > Peter, mind testing if you can revert that and get the old behavior
> > back? It seems to still revert cleanly, although I didn't check if the
> > revert actually then builds..  
> 
> I have checked, the revert should be a safe option. There is nothing
> added on top that relies on it.
> 
> Moreover, I have no problem dealing with the revert, as it me
> personally that screwed this up.
> 
> >  
> >> This commit further enables asynchronous detection of (e)MMC/SD/SDIO
> >> cards, by converting from an *ordered* work-queue to a *non-ordered*
> >> work-queue for card detection.
> >>
> >> Although, one should know that there have *never* been any guarantees
> >> to get a fixed mmcblk id for a card. I expect that's what has been
> >> assumed here.  
> >
> > So quite frankly, for the whole "no regressions" issue, "documented
> > behavior" simply isn't an issue. It doesn't matter one whit or not if
> > something has been documented: if it has worked and people have
> > depended on it, it's what we in the industry call "reality".
> >
> > And reality trumps documentation. Every time.  
> 
> I totally agree.
> 
> Although, what puzzles me around this particular issue, is how an SoC
> configuration can rely on this fragile behaviour.
> All you have to do to break the assumption of fixed mmcblk ids, is to
> boot with an SD card inserted and then without. Perhaps these SoCs
> just doesn't support this use case!?

This use case is supported by carefully always letting emmc host be probed
before the sd hosts. For example, this can be done by putting the emmc host
DT node before the SD hosts' ;)

Thanks,
Jisheng

Re: [bisect] Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc (was [GIT PULL] MMC for v.4.6)

[Ulf Hansson]

On 6 April 2016 at 09:47, Jisheng Zhang <jszhang@marvell.com> wrote:
> Hi Ulf,
>
> On Tue, 5 Apr 2016 10:59:28 +0200 Ulf Hansson wrote:
>
>> On 4 April 2016 at 20:59, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> > On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> >>
>> >> The commit that's likely to cause the regression is:
>> >> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
>> >> simultaneously").
>> >
>> > Peter, mind testing if you can revert that and get the old behavior
>> > back? It seems to still revert cleanly, although I didn't check if the
>> > revert actually then builds..
>>
>> I have checked, the revert should be a safe option. There is nothing
>> added on top that relies on it.
>>
>> Moreover, I have no problem dealing with the revert, as it me
>> personally that screwed this up.
>>
>> >
>> >> This commit further enables asynchronous detection of (e)MMC/SD/SDIO
>> >> cards, by converting from an *ordered* work-queue to a *non-ordered*
>> >> work-queue for card detection.
>> >>
>> >> Although, one should know that there have *never* been any guarantees
>> >> to get a fixed mmcblk id for a card. I expect that's what has been
>> >> assumed here.
>> >
>> > So quite frankly, for the whole "no regressions" issue, "documented
>> > behavior" simply isn't an issue. It doesn't matter one whit or not if
>> > something has been documented: if it has worked and people have
>> > depended on it, it's what we in the industry call "reality".
>> >
>> > And reality trumps documentation. Every time.
>>
>> I totally agree.
>>
>> Although, what puzzles me around this particular issue, is how an SoC
>> configuration can rely on this fragile behaviour.
>> All you have to do to break the assumption of fixed mmcblk ids, is to
>> boot with an SD card inserted and then without. Perhaps these SoCs
>> just doesn't support this use case!?
>
> This use case is supported by carefully always letting emmc host be probed
> before the sd hosts. For example, this can be done by putting the emmc host
> DT node before the SD hosts' ;)

This is just a workaround and it's still *really* fragile.

The workaround you describe, relies on a certain behaviour of the DTS
parsing and the driver core, as you need the the first device in the
DTS to probe first. You are also relying on that the mmc driver
doesn't mess up the probe order by returning -EPROBE_DEFER for the
eMMC slot (because some resources wasn't ready yet).

Anyway, I get the point and thanks for you feedback!

>
> Thanks,
> Jisheng

Kind regards
Uffe