linux-stable.git/drivers/mmc/core, branch v5.18.2

mmc: core: Fix busy polling for MMC_SEND_OP_COND again

2022-05-19T13:46:46+00:00

It turned out that polling period for MMC_SEND_OP_COND, that currently is
set to 1ms, still isn't sufficient. In particular a Micron eMMC on a
Beaglebone platform, is reported to sometimes fail to initialize.

Additional test, shows that extending the period to 4ms is working fine, so
let's make that change.

Reported-by: Jean Rene Dawin 
Tested-by: Jean Rene Dawin 
Fixes: 1760fdb6fe9f (mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND")
Fixes: 76bfc7ccc2fa ("mmc: core: adjust polling interval for CMD1")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson 
Link: https://lore.kernel.org/r/20220517101046.27512-1-ulf.hansson@linaro.org

mmc: core: Set HS clock speed before sending HS CMD13

2022-04-26T11:55:50+00:00

Way back in commit 4f25580fb84d ("mmc: core: changes frequency to
hs_max_dtr when selecting hs400es"), Rockchip engineers noticed that
some eMMC don't respond to SEND_STATUS commands very reliably if they're
still running at a low initial frequency. As mentioned in that commit,
JESD84-B51 P49 suggests a sequence in which the host:
1. sets HS_TIMING
2. bumps the clock ("<= 52 MHz")
3. sends further commands

It doesn't exactly require that we don't use a lower-than-52MHz
frequency, but in practice, these eMMC don't like it.

The aforementioned commit tried to get that right for HS400ES, although
it's unclear whether this ever truly worked as committed into mainline,
as other changes/refactoring adjusted the sequence in conflicting ways:

08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode
switch")

53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode
for mmc")

In any case, today we do step 3 before step 2. Let's fix that, and also
apply the same logic to HS200/400, where this eMMC has problems too.

Resolves errors like this seen when booting some RK3399 Gru/Scarlet
systems:

[    2.058881] mmc1: CQHCI version 5.10
[    2.097545] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA
[    2.209804] mmc1: mmc_select_hs400es failed, error -84
[    2.215597] mmc1: error -84 whilst initialising MMC card
[    2.417514] mmc1: mmc_select_hs400es failed, error -110
[    2.423373] mmc1: error -110 whilst initialising MMC card
[    2.605052] mmc1: mmc_select_hs400es failed, error -110
[    2.617944] mmc1: error -110 whilst initialising MMC card
[    2.835884] mmc1: mmc_select_hs400es failed, error -110
[    2.841751] mmc1: error -110 whilst initialising MMC card

Ealier versions of this patch bumped to 200MHz/HS200 speeds too early,
which caused issues on, e.g., qcom-msm8974-fairphone-fp2. (Thanks for
the report Luca!) After a second look, it appears that aligns with
JESD84 / page 45 / table 28, so we need to keep to lower (HS / 52 MHz)
rates first.

Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch")
Fixes: 53e60650f74e ("mmc: core: Allow CMD13 polling when switching to HS mode for mmc")
Fixes: 4f25580fb84d ("mmc: core: changes frequency to hs_max_dtr when selecting hs400es")
Cc: Shawn Lin 
Link: https://lore.kernel.org/linux-mmc/11962455.O9o76ZdvQC@g550jk/
Reported-by: Luca Weiss 
Signed-off-by: Brian Norris 
Tested-by: Luca Weiss 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220422100824.v4.1.I484f4ee35609f78b932bd50feed639c29e64997e@changeid
Signed-off-by: Ulf Hansson

mmc: core: improve API to make clear mmc_hw_reset is for cards

2022-04-08T09:00:08+00:00

To make it unambiguous that mmc_hw_reset() is for cards and not for
controllers, we make the function argument mmc_card instead of mmc_host.
Also, all users are converted.

Suggested-by: Ulf Hansson 
Signed-off-by: Wolfram Sang 
Acked-by: Kalle Valo 
Link: https://lore.kernel.org/r/20220408080045.6497-2-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson

mmc: core: Fixup support for writeback-cache for eMMC and SD

2022-04-04T11:27:58+00:00

During the card initialization process, the mmc core checks whether the
eMMC/SD card supports an internal writeback-cache and then enables it
inside the card.

Unfortunately, this isn't according to what the mmc core reports to the
upper block layer. Instead, the writeback-cache support with REQ_FLUSH and
REQ_FUA, are being enabled depending on whether the host supports the CMD23
(MMC_CAP_CMD23) and whether an eMMC supports the reliable-write command.

This is wrong and it may also sound awkward. In fact, it's a remnant
from when both eMMC/SD cards didn't have dedicated commands/support to
control the internal writeback-cache. In other words, it was the best we
could do at that point in time.

To fix the problem, but also without breaking backwards compatibility,
let's align the REQ_FLUSH support with whether the writeback-cache became
successfully enabled - for both eMMC and SD cards.

Cc: stable@kernel.org
Fixes: 881d1c25f765 ("mmc: core: Add cache control for eMMC4.5 device")
Fixes: 130206a615a9 ("mmc: core: Add support for cache ctrl for SD cards")
Depends-on: 97fce126e279 ("mmc: block: Issue a cache flush only when it's enabled")
Reviewed-by: Avri Altman 
Signed-off-by: Michael Wu 
Link: https://lore.kernel.org/r/20220331073223.106415-1-michael@allwinnertech.com
[Ulf: Re-wrote the commit message]
Signed-off-by: Ulf Hansson

mmc: block: Check for errors after write on SPI

2022-04-04T10:17:46+00:00

Introduce a SEND_STATUS check for writes through SPI to not mark
an unsuccessful write as successful.

Since SPI SD/MMC does not have states, after a write, the card will
just hold the line LOW until it is ready again. The driver marks the
write therefore as completed as soon as it reads something other than
all zeroes.
The driver does not distinguish from a card no longer signalling busy
and it being disconnected (and the line being pulled-up by the host).
This lead to writes being marked as successful when disconnecting
a busy card.
Now the card is ensured to be still connected by an additional CMD13,
just like non-SPI is ensured to go back to TRAN state.

While at it and since we already poll for the post-write status anyway,
we might as well check for SPIs error bits (any of them).

The disconnecting card problem is reproducable for me after continuous
write activity and randomly disconnecting, around every 20-50 tries
on SPI DS for some card.

Fixes: 7213d175e3b6f ("MMC/SD card driver learns SPI")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Loehle 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/76f6f5d2b35543bab3dfe438f268609c@hyperstone.com
Signed-off-by: Ulf Hansson

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

2022-03-28T20:00:51+00:00

Pull tty/serial driver updates from Greg KH:
 "Here are the big set of tty and serial driver changes for 5.18-rc1.

  Nothing major, some more good cleanups from Jiri and 2 new serial
  drivers. Highlights include:

   - termbits cleanups

   - export symbol cleanups and other core cleanups from Jiri Slaby

   - new sunplus and mvebu uart drivers (amazing that people are still
     creating new uarts...)

   - samsung serial driver cleanups

   - ldisc 29 is now "reserved" for experimental/development line
     disciplines

   - lots of other tiny fixes and cleanups to serial drivers and
     bindings

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'tty-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (104 commits)
  vt_ioctl: fix potential spectre v1 in VT_DISALLOCATE
  serial: 8250: fix XOFF/XON sending when DMA is used
  tty: serial: samsung: Add ARTPEC-8 support
  dt-bindings: serial: samsung: Add ARTPEC-8 UART
  serial: sc16is7xx: Clear RS485 bits in the shutdown
  tty: serial: samsung: simplify getting OF match data
  tty: serial: samsung: constify variables and pointers
  tty: serial: samsung: constify s3c24xx_serial_drv_data members
  tty: serial: samsung: constify UART name
  tty: serial: samsung: constify s3c24xx_serial_drv_data
  tty: serial: samsung: reduce number of casts
  tty: serial: samsung: embed s3c2410_uartcfg in parent structure
  tty: serial: samsung: embed s3c24xx_uart_info in parent structure
  serial: 8250_tegra: mark acpi_device_id as unused with !ACPI
  tty: serial: bcm63xx: use more precise Kconfig symbol
  serial: SERIAL_SUNPLUS should depend on ARCH_SUNPLUS
  tty: serial: jsm: fix two assignments in if conditions
  tty: serial: jsm: remove redundant assignments to variable linestatus
  serial: 8250_mtk: make two read-only arrays static const
  serial: samsung_tty: do not unlock port->lock for uart_write_wakeup()
  ...

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

2022-03-28T19:50:50+00:00

Pull staging driver updates from Greg KH:
 "Here is the big set of staging driver updates for 5.18-rc1.

  Loads of tiny cleanups for almost all staging drivers in here, nothing
  major at all. Highlights include:

   - remove the ashmem Android driver. It is long-dead and if there are
     any legacy userspace applications still using it, the Android
     kernel images will maintain it, the community shouldn't care about
     it anymore

   - wfx wifi driver major cleanups. Should be ready to merge out of
     staging soon, and will coordinate with the wifi maintainers after
     -rc1 is out

   - major cleanups and unwinding of the layers of the r8188eu driver.
     It's amazing just how many unneeded layers of abstraction is in
     there, just when we think it's done, another is found...

   - lots of tiny coding style cleanups in many other staging drivers.

  All have been in linux-next for a while with no reported problems"

* tag 'staging-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (455 commits)
  staging: r8188eu: remove unnecessary memset in r8188eu
  staging: greybus: introduce pwm_ops::apply
  staging: rts5208: Resolve checkpatch.pl issues.
  staging: sm750fb: fix naming style
  staging: fbtft: Consider type of init sequence values in fbtft_init_display()
  staging: fbtft: Constify buf parameter in fbtft_dbg_hex()
  staging: mmal-vchiq: clear redundant item named bulk_scratch
  mips: dts: ralink: add MT7621 SoC
  staging: r8188eu: remove some unused local ieee80211 macros
  staging: r8188eu: make rtl8188e_process_phy_info static
  staging: r8188eu: remove unused function prototype
  staging: r8188eu: remove three unused receive defines
  staging: r8188eu: remove unnecessary initializations
  staging: rtl8192e: Fix spelling mistake "RESQUEST" -> "REQUEST"
  MAINTAINERS: remove the obsolete file entry for staging in ANDROID DRIVERS
  staging: r8188eu: proper error handling in rtw_init_drv_sw
  staging: r8188eu: call _cancel_timer_ex from _rtw_free_recv_priv
  staging: vt6656: Removed unused variable vt3342_vnt_threshold
  staging: vt6656: Removed unused variable bb_vga_0
  staging: remove ashmem
  ...

mmc: core: Drop HS400 caps unless 8-bit bus is supported too

2022-03-15T09:25:21+00:00

When mmc_select_hs400es() tries to switch to the HS400 ES mode, it may bail
out early if the host doesn't support an 8-bit buswidth, as it's required
for the HS400 mode.

To improve the situation, let's instead drop the HS400 bits from the
capability field if the 8-bit bus isn't supported. In this way, we allow
the mmc initialization to continue by trying a lower speed mode.

Signed-off-by: Ulf Hansson 
Link: https://lore.kernel.org/r/20220303165151.129806-1-ulf.hansson@linaro.org

mmc: host: Return an error when ->enable_sdio_irq() ops is missing

2022-03-15T09:25:21+00:00

Even if the current WARN() notifies the user that something is severely
wrong, we can still end up in a PANIC() when trying to invoke the missing
->enable_sdio_irq() ops. Therefore, let's also return an error code and
prevent the host from being added.

While at it, move the code into a separate function to prepare for
subsequent changes and for further host caps validations.

Signed-off-by: Ulf Hansson 
Link: https://lore.kernel.org/r/20220303165142.129745-1-ulf.hansson@linaro.org

mmc: core: Improve fallback to speed modes if eMMC HS200 fails

2022-03-15T09:24:55+00:00

In the error path of mmc_select_hs200() we are trying our best to restore
the card/host into a valid state. This makes sense, especially if we
encounter a simple switch error (-EBADMSG). However, rather than then
continue with using the legacy speed mode, let's try the other better speed
modes first. Additionally, let's update the card->mmc_avail_type to avoid
us from trying a broken HS200 mode again.

In an Amlogic S905W based TV box where the switch to HS200 mode fails for
the eMMC, this allows us to use the eMMC in DDR mode in favor of the legacy
mode, which greatly improves the performance.

Suggested-by: Heiner Kallweit 
Signed-off-by: Ulf Hansson 
Tested-by: Heiner Kallweit 
Link: https://lore.kernel.org/r/20220303164522.129583-1-ulf.hansson@linaro.org