INVALID_TUNING_PHASE is defined to -1 but saved_tuning_phase is defined
as an unsigned integer. This causes the following UBSAN warning:
[ 1.150177] UBSAN: Undefined behaviour in ../../../../../../kernel/xiaomi/sm6250/drivers/mmc/host/sdhci-msm.c:542:2
[ 1.150180] index 255 is out of range for type 'u8 [16]'
[ 1.150185] CPU: 6 PID: 87 Comm: kworker/6:1 Tainted: G S 4.14.190-lineageos-ge44e3bc2e-dirty #17
[ 1.150187] Hardware name: Qualcomm Technologies, Inc. ATOLL-AB PM6150 wcd937x Audio Codec AB IDP CURTANA (DT)
[ 1.150196] Workqueue: events_freezable mmc_rescan
[ 1.150199] Call trace:
[ 1.150204] dump_backtrace+0x0/0x1d0
[ 1.150208] show_stack+0x18/0x24
[ 1.150213] dump_stack+0xd8/0x114
[ 1.150217] __ubsan_handle_out_of_bounds+0xc8/0x104
[ 1.150220] msm_config_cm_dll_phase+0x238/0x248
[ 1.150222] sdhci_msm_execute_tuning+0x2a0/0xb24
[ 1.150225] sdhci_execute_tuning+0xcc/0x6c0
[ 1.150228] mmc_execute_tuning+0x6c/0xc0
[ 1.150230] mmc_sd_init_card+0x62c/0x6e0
[ 1.150233] mmc_attach_sd+0xbc/0x2cc
[ 1.150235] mmc_rescan+0x2ac/0x3a4
[ 1.150239] process_one_work+0x260/0x45c
[ 1.150241] worker_thread+0x258/0x494
[ 1.150244] kthread+0x11c/0x12c
[ 1.150247] ret_from_fork+0x10/0x18
Fix it by changing the saved_tuning_phase definition to a signed integer.
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Change-Id: I9f53d4c7a7a543e77f6538253c485af61c0e7684
Command queue host initializes and points to parent mmc host. This must be
used to avoid redundancy and hold/release mmc clocks to ensure proper
clock handling.
Change-Id: I407fb4b8364f5281638c75224179d705b8720323
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Command queue driver has customized changes to work on msm-4.14 where
pm_runtime_get_sync() enables the host clocks but customized code releases
the clock after 100ms of inactivity to save power.
With new FBE V2 the crypto keys are programmed in submit_bio() context
where pm_runtime_get_sync() is called by KSM driver but crypto clock need
to be kept on before programming the crypto key to ensure crypto registers
are accesible.
So export and call the mmc clock APIs to hold the mmc and crypto clocks
while programming crypto keys.
Test: repeated power on/off test.
Change-Id: I6cae7febdfac053f4477ab34f4265b9f4f24606c
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock
because it waits for the UFS controller to be resumed, but it can itself
be reached while resuming the UFS controller via:
- ufshcd_runtime_resume()
- ufshcd_resume()
- ufshcd_reset_and_restore()
- ufshcd_host_reset_and_restore()
- ufshcd_hba_enable()
- ufshcd_hba_execute_hce()
- ufshcd_hba_start()
- ufshcd_crypto_enable()
- keyslot_manager_reprogram_all_keys()
- ufshcd_crypto_keyslot_program()
- ufshcd_program_key()
But pm_runtime_get_sync() *is* needed when evicting a key. Also, on
pre-4.20 kernels it's needed when programming a keyslot for a bio since
the block layer used to resume the device in a different place.
Thus, it's hard for drivers to know what to do in .keyslot_program() and
.keyslot_evict(). In old kernels it may even be impossible unless we
were to pass more information down from the keyslot_manager.
There's also another possible deadlock: keyslot programming and eviction
take ksm->lock for write and then resume the device, which may result in
ksm->lock being taken again via the above call stack. To fix this, we
should resume the device before taking ksm->lock.
Fix these problems by moving to a better design where the block layer
(namely, the keyslot manager) handles runtime power management instead
of drivers. This is analogous to the block layer's existing runtime
power management support (blk-pm), which handles resuming devices when
bios are submitted to them so that drivers don't need to handle it.
Test: Tested on coral with:
echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl
sleep 30
touch /data && sync # hangs before this fix
Also verified via kvm-xfstests that blk-crypto-fallback continues
to work both with and without CONFIG_PM=y.
Bug: 137270441
Bug: 149368295
Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8
Signed-off-by: Eric Biggers <ebiggers@google.com>
Git-Commit: 8d97219e60
Git-Repo: https://android.googlesource.com/kernel/common
[neersoni@codeaurora.org]: fixed compilation issues.
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
[vagrawa@codeaurora.org]: fix merge conflicts.
Signed-off-by: Vaibhav Agrawal <vagrawa@codeaurora.org>
Command queue driver has customized changes to work on msm-4.14 where
pm_runtime_get_sync() enables the host clocks but customized code releases
the clock after 100ms of inactivity to save power.
With new FBE V2 the crypto keys are programmed in submit_bio() context
where pm_runtime_get_sync() is called by KSM driver but crypto clock need
to be kept on before programming the crypto key to ensure crypto registers
are accesible.
So export and call the mmc clock APIs to hold the mmc and crypto clocks
while programming crypto keys.
Test: repeated power on/off test.
Change-Id: I6cae7febdfac053f4477ab34f4265b9f4f24606c
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
The call to pm_runtime_get_sync() in ufshcd_program_key() can deadlock
because it waits for the UFS controller to be resumed, but it can itself
be reached while resuming the UFS controller via:
- ufshcd_runtime_resume()
- ufshcd_resume()
- ufshcd_reset_and_restore()
- ufshcd_host_reset_and_restore()
- ufshcd_hba_enable()
- ufshcd_hba_execute_hce()
- ufshcd_hba_start()
- ufshcd_crypto_enable()
- keyslot_manager_reprogram_all_keys()
- ufshcd_crypto_keyslot_program()
- ufshcd_program_key()
But pm_runtime_get_sync() *is* needed when evicting a key. Also, on
pre-4.20 kernels it's needed when programming a keyslot for a bio since
the block layer used to resume the device in a different place.
Thus, it's hard for drivers to know what to do in .keyslot_program() and
.keyslot_evict(). In old kernels it may even be impossible unless we
were to pass more information down from the keyslot_manager.
There's also another possible deadlock: keyslot programming and eviction
take ksm->lock for write and then resume the device, which may result in
ksm->lock being taken again via the above call stack. To fix this, we
should resume the device before taking ksm->lock.
Fix these problems by moving to a better design where the block layer
(namely, the keyslot manager) handles runtime power management instead
of drivers. This is analogous to the block layer's existing runtime
power management support (blk-pm), which handles resuming devices when
bios are submitted to them so that drivers don't need to handle it.
Test: Tested on coral with:
echo 5 > /sys/bus/platform/devices/1d84000.ufshc/rpm_lvl
sleep 30
touch /data && sync # hangs before this fix
Also verified via kvm-xfstests that blk-crypto-fallback continues
to work both with and without CONFIG_PM=y.
Bug: 137270441
Bug: 149368295
Change-Id: I6bc9fb81854afe7edf490d71796ee68a61f7cbc8
Signed-off-by: Eric Biggers <ebiggers@google.com>
Git-Commit: 8d97219e60
Git-Repo: https://android.googlesource.com/kernel/common
[neersoni@codeaurora.org]: fixed compilation issues.
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Disable quirk multi block read acmd as this is leading to
crc errors during rpmb operation.
Change-Id: I484376a2eaaa5f2dbe04059fccba4be0db8a1c81
Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
With new encryption framework intermediate vector calculation is changed
so to support the legacy mechanism for ext4 file system use correct
parameter for data encrypt/decrypt.
Change-Id: I7921699c7a213bad7314a789d7f14a359205690f
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Use tasklet_hi_schedule to schedule finishing mrq to avoid latency
increasing in some system scheduling busy situations(RT threads involved).
Change-Id: Ia3b7cfe2c7c175a934c79b003872392b60becb91
CRs-Fixed: 2775935
Signed-off-by: Hangtian Zhu <hangtian@codeaurora.org>
This change adds new API which does cmdq crypto
initialization for targets having legacy ICE(ICE<3.X).
It populates required cmdq fields needed to achieve
Inline File Encryption.
Change-Id: I71a5c64db529daf8c4afc12b3523c48d8948ab30
Signed-off-by: Jiten Patel <jitepate@codeaurora.org>
With new file encryption framework the crypto vops should support
crypto configuration for block disk encryption feature as well.
Change-Id: I1504a023f91376b207d9af19ad097405a3a42c85
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
This is a workaround to cover a corner case where the host controller
crashes with invalid config error as the crypto config in crypto engine
are lost between key programming call and descriptor processing.
Test: fscryptctl test cases.
Change-Id: I83c1f928a52747686a7341f6d80478dc3d683191
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Fixes for kernel encryption vts test need multiple encryption flag support
which needs additional changes to ensure IV is generated and calculated
correctly for all file systems and storage types.
Also fix the memory leak in V1 encryption path while allocating
encryption keys.
Change-Id: Ifb78dc350ffb7976d40b34477b9dff7785714379
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Use secure world to generate and maintain the file name
encryption key.
Test: vts-kernel-encryption test.
Change-Id: I3a2c093a6fdc622b106b22d324cae0519c8de7c0
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Driver need to register the supported data unit number (dun) size
with keyslot manager so that encryption request with unsupported
dun size can fallback to fs or block crypto.
Change-Id: If0b724a80049fb3544a6338345a55bf7d1084127
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Use secure world to generate and maintain the file name
encryption key.
Test: vts-kernel-encryption test.
Change-Id: I3a2c093a6fdc622b106b22d324cae0519c8de7c0
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
If crypto clock details are present the call returns 0 which must
be checked to parse the clock entry in host controller dtsi node.
Test: 1. Clock scalability.
2. Performance number using Andorbench apk.
Change-Id: I10ee3de1c1e02299de6ab390852d367cdb303224
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
ICE address space was added to command queue address
space in eMMC JEDEC v5.2 spec so adapt the offset of
crypto registers accordingly.
Change-Id: I409b031edcf1055289f2868aaaa00adc20eabfec
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
QTI implementation for block keyslot manager and
crypto vops for crypto support in CQHCI.
Change-Id: I9b64f85ca97c269a6ecd6fde2bb693745d4c43d4
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Wire up cqhci.c with the eMMC Crypto API and support for block layer
inline encryption additions and the keyslot manager.
Change-Id: I0fb63a3d7601a8979386ecf1c65bc5c44369429e
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Add functions to use eMMC inline encryption hardware capability
inline with JEDEC eMMC v5.2 specification and to work with
block keyslot manager. Also add crypto variant vops to handle
quirks in individual inline encryption hardware. The vops fallback
to default implementation which is JEDEC eMMC v5.2 compliant.
Change-Id: I72b85d572d7c76b966e34b80e7e8eca83a2bb35f
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Add crypto capability registers and structs defined in v5.2 of
JEDEC eMMC specification in prepration to add support for inline
encryption to eMMC controllers.
Change-Id: I4cd9d73a291033b885a66a209d097c768fbff921
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
To use block crypto based inline encryption mechanism
storage device driver should create a keyslot manager
and register it with device request queue. To achieve this
pass request queue pointer during host controller initialization
where request queue can be updated with keyslot manager.
Change-Id: I71f0005a1ad8867b6210e92878b8c112d436688e
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Remove the Per File Key logic based inline crypto support
for file encryption framework.
Change-Id: I90071562ba5c41b9db470363edac35c9fe5e4efa
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Driver need to register the supported data unit number (dun) size
with keyslot manager so that encryption request with unsupported
dun size can fallback to fs or block crypto.
Change-Id: If0b724a80049fb3544a6338345a55bf7d1084127
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
If crypto clock details are present the call returns 0 which must
be checked to parse the clock entry in host controller dtsi node.
Test: 1. Clock scalability.
2. Performance number using Andorbench apk.
Change-Id: I10ee3de1c1e02299de6ab390852d367cdb303224
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
ICE address space was added to command queue address
space in eMMC JEDEC v5.2 spec so adapt the offset of
crypto registers accordingly.
Change-Id: I409b031edcf1055289f2868aaaa00adc20eabfec
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
QTI implementation for block keyslot manager and
crypto vops for crypto support in CQHCI.
Change-Id: I9b64f85ca97c269a6ecd6fde2bb693745d4c43d4
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Wire up cqhci.c with the eMMC Crypto API and support for block layer
inline encryption additions and the keyslot manager.
Change-Id: I0fb63a3d7601a8979386ecf1c65bc5c44369429e
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Add functions to use eMMC inline encryption hardware capability
inline with JEDEC eMMC v5.2 specification and to work with
block keyslot manager. Also add crypto variant vops to handle
quirks in individual inline encryption hardware. The vops fallback
to default implementation which is JEDEC eMMC v5.2 compliant.
Change-Id: I72b85d572d7c76b966e34b80e7e8eca83a2bb35f
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
Add crypto capability registers and structs defined in v5.2 of
JEDEC eMMC specification in prepration to add support for inline
encryption to eMMC controllers.
Change-Id: I4cd9d73a291033b885a66a209d097c768fbff921
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
To use block crypto based inline encryption mechanism
storage device driver should create a keyslot manager
and register it with device request queue. To achieve this
pass request queue pointer during host controller initialization
where request queue can be updated with keyslot manager.
Change-Id: I71f0005a1ad8867b6210e92878b8c112d436688e
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Remove the Per File Key logic based inline crypto support
for file encryption framework.
Change-Id: I90071562ba5c41b9db470363edac35c9fe5e4efa
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
If this quirk is set, then data timeout interrupt must not be
handled for R1B commands, as those commands may need larger
timeout value (larger than max timeout that controller can handle).
Change-Id: I7453b1914add21b47393b3eb1578d88e72da7406
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Ziqi Chen <ziqichen@codeaurora.org>
[ Upstream commit e65bb38824711559844ba932132f417bc5a355e2 ]
Except SDHCI_QUIRK_BROKEN_CARD_DETECTION and MMC_CAP_NONREMOVABLE,
we also do not need to handle controller native card detect interrupt
for gpio cd type.
If we wrong enabled the card detect interrupt for gpio case, it will
cause a lot of unexpected card detect interrupts during data transfer
which should not happen.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/1582100563-20555-2-git-send-email-haibo.chen@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1194be8c949b8190b2882ad8335a5d98aa50c735 ]
According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is
TUNING_START_TAP, bit[7] of this register is to disable the command
CRC check for standard tuning. So fix it here.
Fixes: d87fc96636 ("mmc: sdhci-esdhc-imx: support setting tuning start point")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://lore.kernel.org/r/1590488522-9292-1-git-send-email-haibo.chen@nxp.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 966244ccd2919e28f25555a77f204cd1c109cad8 ]
Using a fixed 1s timeout for all commands (and data transfers) is a bit
problematic.
For some commands it means waiting longer than needed for the timer to
expire, which may not a big issue, but still. For other commands, like for
an erase (CMD38) that uses a R1B response, may require longer timeouts than
1s. In these cases, we may end up treating the command as it failed, while
it just needed some more time to complete successfully.
Fix the problem by respecting the cmd->busy_timeout, which is provided by
the mmc core.
Cc: Bruce Chang <brucechang@via.com.tw>
Cc: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200414161413.3036-17-ulf.hansson@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9253d71011c349d5f5cc0cebdf68b4a80811b92d upstream.
Clear tuning_done flag while executing tuning to ensure vendor
specific HS400 settings are applied properly when the controller
is re-initialized in HS400 mode.
Without this, re-initialization of the qcom SDHC in HS400 mode fails
while resuming the driver from runtime-suspend or system-suspend.
Fixes: ff06ce4178 ("mmc: sdhci-msm: Add HS400 platform support")
Cc: stable@vger.kernel.org
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/1590678838-18099-1-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To operate eMMC in 8 bit mode, need to route the
DATA LINES 4 to 7 (the GPIO lines from 92 to 95) to eMMC.
To route these data lines to eMMC, need to select the
EMMC_BOOT_SELECT bit in TLMM_EBI2_EMMC_GPIO_CFG
register (along with EBI2_BOOT_SELECT bit). Otherwise,
the eMMC will not work in 8 bit mode. If selected only eMMC
boot bit, then the device will not boot from NAND.
Change-Id: Ia6862a1d30b1e984facc1ef4a791b05c1941513e
Signed-off-by: Srinivas Ganji <sringanj@codeaurora.org>
commit 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a upstream.
BIOS writers have begun the practice of setting 40 ohm eMMC driver strength
even though the eMMC may not support it, on the assumption that the kernel
will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH
[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.
This is done to avoid changing the value for different boards.
Putting aside the merits of this approach, it is clear the eMMC's mask
of supported driver strengths is more reliable than the value provided
by BIOS. Add validation accordingly.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 51ced59cc0 ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb32e1987bc55ce1db400faf47d85891da3c9b9f upstream.
For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.
This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable
When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.
Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.
This patch fixes this particular problem on Turris MOX.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: stable@vger.kernel.org # v4.16+
Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 53dd0a7cd65edc83b0c243d1c08377c8b876b2ee upstream.
SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least
SAMA5D27 doesn't). Fix this by forcing card-detect in the module
if module-controlled CD is not used.
Fixed commit addresses the problem only for non-removable cards. This
amends it to also cover gpio-cd case.
Cc: stable@vger.kernel.org
Fixes: 7a1e3f1431 ("mmc: sdhci-of-at91: force card detect value for non removable devices")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add freeze and thaw callbacks to handle suspend
to disk scenario. Also add logic to restore card
detection IRQ in restore path.
Change-Id: I50c64b0cc12dd89dfb886c8519520d62771114b9
Signed-off-by: Anjana Hari <ahari@codeaurora.org>
[ Upstream commit a04184ce777b46e92c2b3c93c6dcb2754cb005e1 ]
sdhci_alloc_host() does its work not using managed infrastructure, so
needs explicit free on error path. Add it where needed.
Cc: <stable@vger.kernel.org>
Fixes: bb5f8ea4d5 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/b2a44d5be2e06ff075f32477e466598bb0f07b36.1577961679.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit af3ed119329cf9690598c5a562d95dfd128e91d6 upstream.
The code in mmc_spi_initsequence() tries to send a burst with
high chipselect and for this reason hardcodes the device into
SPI_CS_HIGH.
This is not good because the SPI_CS_HIGH flag indicates
logical "asserted" CS not always the physical level. In
some cases the signal is inverted in the GPIO library and
in that case SPI_CS_HIGH is already set, and enforcing
SPI_CS_HIGH again will actually drive it low.
Instead of hard-coding this, toggle the polarity so if the
default is LOW it goes high to assert chipselect but if it
is already high then toggle it low instead.
Cc: Phil Elwell <phil@raspberrypi.org>
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191204152749.12652-1-linus.walleij@linaro.org
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a187d03352086e300daa2044051db00044cd171 upstream.
For SDHCIv3+ with programmable clock mode, minimal clock frequency is
still base clock / max(divider). Minimal programmable clock frequency is
always greater than minimal divided clock frequency. Without this patch,
SDHCI uses out-of-spec initial frequency when multiplier is big enough:
mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz
[for 480 MHz source clock divided by 1024]
The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode.
Fixes: c3ed387762 ("mmc: sdhci: add support for programmable clock mode")
Cc: <stable@vger.kernel.org> # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present
Cc: <stable@vger.kernel.org>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon1511