| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For commands that doesn't involve to prepare a data transfer, owl-mmc is
using a fixed 30s response timeout. This is a bit problematic.
For some commands it means waiting longer than needed for the completion 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
30s. 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: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Some commands uses R1B responses, which means the card may assert the DAT0
line to signal busy for a period of time, after it has received the
command. The mmc core normally specifies the busy period for the command in
the cmd->busy_timeout. Ideally the driver should respect it, but that
requires quite some update of the code, so let's defer that to someone with
the HW at hand.
Instead, let's inform the mmc core about the maximum supported busy timeout
in ->max_busy_timeout during ->probe(). This value corresponds to the fixed
5s timeout used by jz4740. In this way, we let the mmc core validate the
needed timeout, which may lead to that it converts from a R1B into a R1
response and then use CMD13 to poll for busy completion.
In other words, this change enables support for commands with longer busy
periods than 5s, like erase (CMD38) for example.
Cc: Paul Cercueil <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Fix the following sparse warning:
drivers/mmc/host/sdhci-pci-o2micro.c:497:6: warning: symbol
'sdhci_pci_o2_set_clock' was not declared. Should it be static?
drivers/mmc/host/sdhci-pci-o2micro.c:512:5: warning: symbol
'sdhci_pci_o2_probe_slot' was not declared. Should it be static?
drivers/mmc/host/sdhci-pci-o2micro.c:581:5: warning: symbol
'sdhci_pci_o2_probe' was not declared. Should it be static?
drivers/mmc/host/sdhci-pci-o2micro.c:786:5: warning: symbol
'sdhci_pci_o2_resume' was not declared. Should it be static?
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zou Wei <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Fixes coccicheck warning:
drivers/mmc/core/debugfs.c:222:0-23: WARNING: mmc_clock_fops should be
defined with DEFINE_DEBUGFS_ATTRIBUTE
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
for debugfs files
Fixes: 703aae3d09a4b ("mmc: add a file to debugfs for changing host clock at runtime")
Fixes: a04c50aaa916f ("mmc: core: no need to check return value of debugfs_create functions")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zou Wei <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
If sdhci-of-at91.c is compiled without CONFIG_HAVE_CLK, the line
caps1 |= FIELD_PREP(SDHCI_CLOCK_MUL_MASK, clk_mul);
... emits "FIELD_PREP: value too large for the field" warning.
The compiler seems to decide clk_mul is constant (unsigned int)-1,
because clk_get_rate() returns 0 when CONFIG_HAVE_CLK is disabled.
Add HAVE_CLK to the depenency since this driver does not work without
the clock APIs anyway.
Reported-by: Randy Dunlap <[email protected]>
Suggested-by: Adrian Hunter <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Randy Dunlap <[email protected]> # build-tested
|
|
After TAP refactorization, we can use 'unsigned int' for two more
variables because all the calculations work on this type now.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
This patch fix a power-on issue, and avoid to retry the power sequence.
In power off sequence: sdmmc must set pwr_reg in "power-cycle" state
(value 0x2), to prevent the card from being supplied through the signal
lines (all the lines are driven low).
In power on sequence: when the power is stable, sdmmc must set pwr_reg
in "power-off" state (value 0x0) to drive all signal to high before to
set "power-on".
To avoid writing the same value to the power register several times, this
register is cached by the pwr_reg variable. At probe pwr_reg is initialized
to 0 by kzalloc of mmc_alloc_host.
Like pwr_reg value is 0 at probing, the power on sequence fail because
the "power-off" state is not writes (value 0x0) and the lines
remain drive to low.
This patch initializes "pwr_reg" variable with power register value.
This it done in sdmmc variant init to not disturb default mmci behavior.
Signed-off-by: Ludovic Barre <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
On some qualcomm SoCs we need to vote on a performance state of a power
domain depending on the clock rates. Hence move to using OPP api to set
the clock rate and performance state specified in the OPP table.
On platforms without an OPP table, dev_pm_opp_set_rate() is eqvivalent to
clk_set_rate()
Signed-off-by: Rajendra Nayak <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Some commands uses R1B responses, which means the card may assert the DAT0
line to signal busy for a period of time, after it has received the
command. The mmc core normally specifies the busy period for the command in
the cmd->busy_timeout. Ideally the driver should respect it, but that
requires quite some update of the code, so let's defer that to someone with
the HW at hand.
Instead, let's inform the mmc core about the maximum supported busy timeout
in ->max_busy_timeout during ->probe(). This value corresponds to the fixed
4s timeout used by usdhi6rol0. In this way, we let the mmc core validate
the needed timeout, which may lead to that it converts from a R1B into a R1
response and then use CMD13 to poll for busy completion.
In other words, this change enables support for commands with longer busy
periods than 4s, like erase (CMD38) for example.
Cc: Jesper Nilsson <[email protected]>
Cc: Lars Persson <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Jesper Nilsson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Using a fixed 2s timeout for all commands 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
2s. 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: Ludovic Desroches <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Ludovic Desroches <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Setting the timer on a per request basis, is rather limiting as the timer
really depends on what commands that is to be sent as part of the request.
Therefore improve the behaviour by programming the timer per command basis
instead.
Cc: Ludovic Desroches <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Ludovic Desroches <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
When atmci_request_end() is about to finish a request for one slot, there
is a possibility that there is new request queued for another slot. If this
turns out to be the case, the new request is started and the timer is
re-programmed for it.
Although, a few lines below in atmci_request_end(), this timer becomes
deleted, likely corresponding to the other recently completed request. This
looks wrong, so let's fix it.
Cc: Ludovic Desroches <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Ludovic Desroches <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
ADMA_ERR_SIZE_EN bit of VENDOR_SPECIFIC_FUNC register controls
ADMA length mismatch error interrupt. Enable it by default.
And update all bit shift defines with BIT macro.
Signed-off-by: Veerabhadrarao Badiganti <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
sdhci-msm can support auto cmd12.
So enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk.
Signed-off-by: Veerabhadrarao Badiganti <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
When use one SDIO wifi which enable the runtime PM feature on i.MX6SX,
we meet system hang. This hang happened during the usdhc runtime resume,
in sdhci_init(), when call the sdhci_set_default_irqs. One interrupt
(SDHCI_INT_CARD_INT) triggered just after the host->ier update and before
the write of register SDHCI_SIGNAL_ENABLE. So in sdhci_irq, it will skip
the call of sdio_signal_irq() because current host->ier do not set the
SDHCI_INT_CARD_INT. So this SDIO wifi interrupt always keep triggered,
let the system stuck in irq handle, can't response any other thread.
This patch add spin lock for the sdhci_set_default_irqs to fix this issue.
Signed-off-by: Haibo Chen <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Implement the request_atomic() API for nonremovable cards, that means
we can submit next request in the irq hard handler context to reduce
latency.
Moreover factor out the AUTO CMD23 checking into a separate function
to reduce duplicate code.
Signed-off-by: Baolin Wang <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/60142fe6c6c1dbba2696e775564ae2166786f0bc.1586744073.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Implement the request_atomic() ops for the sdhci driver to process
one request in the atomic context if the card is nonremovable.
Moreover, we should return BUSY flag if controller has not released
the inhibit bits to allow HSQ trying to send request again in non-atomic
context.
Suggested-by: Adrian Hunter <[email protected]>
Signed-off-by: Baolin Wang <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/9ed34afa9fb42e0c234065cac5401d7826942b55.1586744073.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <[email protected]>
|
|
The SD host controller can process one request in the atomic context if
the card is nonremovable, which means we can submit next request in the
irq hard handler when using the MMC host software queue to reduce the
latency. Thus this patch adds a new API request_atomic() for the host
controller, as well as adding support for host software queue to submit
a request by the new request_atomic() API.
Moreover there is an unusual case that the card is busy when trying to
send a command, and we can not polling the card status in interrupt
context by using request_atomic() to dispatch requests. Thus we should
queue a work to try again in the non-atomic context in case the host
releases the busy signal later.
Suggested-by: Adrian Hunter <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Signed-off-by: Baolin Wang <[email protected]>
Link: https://lore.kernel.org/r/a344e27e506cb2329073cbd5cf65e15cc3cbeba9.1586744073.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Spending time under spinlock increases IRQ latencies and also
response times because preemption is disabled.
sdhci_send_command() waits up to 10 ms under spinlock for inhibit bits
to clear. In general inhibit bits will not be set, but there may be
corner cases, especially in the face of errors, where waiting helps.
There might also be dysfunctional hardware that needs the waiting. So
retain the legacy behaviour but do not wait for inhibit bits while under
spinlock. Instead adjust the logic to enable waiting while not under
spinlock. That is mostly straight forward, but in the interrupt handler
it requires deferring an "inhibited" command to the IRQ thread where
sleeping is allowed.
Signed-off-by: Adrian Hunter <[email protected]>
Tested-by: Baolin Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
In preparation for further changes, tidy sdhci_request() a bit.
Signed-off-by: Adrian Hunter <[email protected]>
Tested-by: Baolin Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
sdhci_finish_data() is defined before it is referenced, so forward
declaration is not necessary.
Signed-off-by: Adrian Hunter <[email protected]>
Tested-by: Baolin Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
sdhci_send_command() has not been used outside of sdhci.c for many
years. Stop exporting it.
Signed-off-by: Adrian Hunter <[email protected]>
Tested-by: Baolin Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Add 2 helper functions to make the use of the auto-CMD23 flag more
readable.
Signed-off-by: Adrian Hunter <[email protected]>
Tested-by: Baolin Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Use the well defined HIGH_SPEED_BUS_SPEED macro in mmc_sd_switch_hs()
to make code more readable.
Signed-off-by: Jisheng Zhang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Instead of reimplementing the logic in mmc_regulator_set_vqmmc(), use the
mmc code function directly.
This also allows us to fix a related issue on STM32MP1, when a voltage
switch of 1.8V is done for the eMMC, but the current level is already set
to 1.8V. More precisely, in this scenario the call to the
->post_sig_volt_switch() hangs, indefinitely waiting for the voltage switch
to complete. Fix this problem by checking if mmc_regulator_set_vqmmc()
returned 1 and then skip invoking the callback.
Signed-off-by: Marek Vasut <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[Ulf: Updated the commit message]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Adjust mmc_regulator_set_vqmmc() to return 1 if the voltage switch was
skipped because the regulator voltage was already correct. This allows
drivers to detect such condition and possibly skip various voltage
switching extras.
Signed-off-by: Marek Vasut <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Patch all drivers which use mmc_regulator_set_vqmmc() and prepare them for
the fact that mmc_regulator_set_vqmmc() can return a value > 0, which would
happen if the signal voltage switch did NOT happen, because the voltage was
already set correctly.
Signed-off-by: Marek Vasut <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[Ulf: Re-worked/simplified the code a bit]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Clang warns:
drivers/mmc/host/sdhci-of-arasan.c:784:9: warning: variable 'ret' is
uninitialized when used here [-Wuninitialized]
return ret;
^~~
drivers/mmc/host/sdhci-of-arasan.c:738:9: note: initialize the variable
'ret' to silence this warning
int ret;
^
= 0
drivers/mmc/host/sdhci-of-arasan.c:860:9: warning: variable 'ret' is
uninitialized when used here [-Wuninitialized]
return ret;
^~~
drivers/mmc/host/sdhci-of-arasan.c:810:9: note: initialize the variable
'ret' to silence this warning
int ret;
^
= 0
2 warnings generated.
This looks like a copy paste error. Neither function has handling that
needs ret so just remove it and return 0 directly.
Link: https://github.com/ClangBuiltLinux/linux/issues/996
Reported-by: kernelci.org bot <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
No need to call platform_get_resource twice when we still have the
pointer from before. Also, use '%pa' for a resource_size_t pointer.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
|
|
When tuning HS400, if all TAPS are good, we can utilize the SMPCMP
register to select the optimal TAP. For that, we populate a second
bitmap with SMPCMP results and query it in case the regular bitmap is
full (= all good).
Signed-off-by: Masaharu Hayakawa <[email protected]>
Signed-off-by: Takeshi Saito <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Yoshihiro Shimoda <[email protected]>
Tested-by: Yoshihiro Shimoda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
The comment and the define about how TAPs are selected were confusing to
me because the good TAP was only valid if it was bigger than a *_MAX_*
value. Rename the define and adapt the comment to what really happens.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Yoshihiro Shimoda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
To select the best TAP, we need to find the longest stream of set bits
in a bit field. There is now a helper function for bitmaps which
iterates over all region of set bits. Using it makes the code much more
concise and easier to understand. Double so, because we need to handle
two bitmaps in the near future. Remove a superfluous comment while here.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Yoshihiro Shimoda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Use FIELD_GET and FIELD_PREP to get access to the register fields. Delete
the shift macros and use GENMASK() for the touched macros.
Note that, this has the side-effect of changing the constants to 64-bit on
64-bit platforms.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
In the SDHCI specification, the Capabilities Register (Offset 0x40h)
is the 64-bit width register, but in Linux, it is represented as two
registers, SDHCI_CAPABILITIES and SDHCI_CAPABILITIES_1 so that drivers
can use 32-bit register accessors.
The upper 32-bit field is associated with SDHCI_CAPABILITIES_1.
Move the definition of SDHCI_CAPABILITIES_1 to the correct place.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Modify code to fix the warnings reported by kernel-doc for better
documentation.
Signed-off-by: Manish Narani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
The SDHCI clock operations are platform specific. So it better to define
them separately for particular platform. This will prevent multiple
if..else conditions and will make it easy for user to add their own
clock operations handlers.
Signed-off-by: Manish Narani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Existing driver code has the platform specific structures scattered
throughout the driver code. Rearrange the platform specific data
structures for more modularity and readability. This will help in adding
new static functions with more ease.
Signed-off-by: Manish Narani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
There is 'struct sdhci_arasan_data' but also
'struct sdhci_arasan_of_data sdhci_arasan_data'. Rename the latter to
avoid confusion with the name of the struct.
Reported-by: Adrian Hunter <[email protected]>
Signed-off-by: Manish Narani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Add support to set tap delays for Xilinx Versal SD controller. The tap
delay registers have moved to SD controller space in Versal. Make the
changes accordingly.
Signed-off-by: Manish Narani <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The in-parameter struct mmc_data *data is never NULL, because the caller
always provides a valid pointer. Hence drop the corresponding redundant
code.
Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The in-parameter "wait" is always set to 0 by the caller, hence just drop
it and its corresponding code.
Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Manuel Lauss <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The MMC_CAP_ERASE and MMC_CAP_CMD23 flags are already being set in the
common sdhci_setup_host(). This makes it redundant to set them for
sdhci-sprd, so let's drop them.
Signed-off-by: Ulf Hansson <[email protected]>
Reviewed-by: Baolin Wang <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Instead of explicitly checking for SDIO specific requests and then
returning an error code, let's set MMC_CAP2_NO_SDIO to tell the mmc core to
prevent them altogether.
Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The data structure member “rpmb->md” was passed to a call of the function
“mmc_blk_put” after a call of the function “put_device”. Reorder these
function calls to keep the data accesses consistent.
Fixes: 1c87f7357849 ("mmc: block: Fix bug when removing RPMB chardev ")
Signed-off-by: Peng Hao <[email protected]>
Cc: [email protected]
[Uffe: Fixed up mangled patch and updated commit message]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Previous to commit 511ce378e16f07 ("mmc: Add MMC host software queue
support"), removing MMC_CAP2_CQE was enough to disable command queuing, but
now the cqe_ops must also be NULL otherwise ->cqe_enable() will be
called. Fix SDHCI_QUIRK_BROKEN_CQE to do that.
Signed-off-by: Adrian Hunter <[email protected]>
Fixes: 511ce378e16f07 ("mmc: Add MMC host software queue support")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
The AMD eMMC 5.0 controller does not support 64 bit DMA.
Fixes: 34597a3f60b1 ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400")
Signed-off-by: Raul E Rangel <[email protected]>
Link: https://marc.info/?l=linux-mmc&m=158879884514552&w=2
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/20200508165344.1.Id5bb8b1ae7ea576f26f9d91c761df7ccffbf58c5@changeid
Signed-off-by: Ulf Hansson <[email protected]>
|
|
We want the char-misc fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
First, it should be noted that the CQE timeout (60 seconds) is substantial
so a CQE request that times out is really stuck, and the race between
timeout and completion is extremely unlikely. Nevertheless this patch
fixes an issue with it.
Commit ad73d6feadbd7b ("mmc: complete requests from ->timeout")
preserved the existing functionality, to complete the request.
However that had only been necessary because the block layer
timeout handler had been marking the request to prevent it from being
completed normally. That restriction was removed at the same time, the
result being that a request that has gone will have been completed anyway.
That is, the completion was unnecessary.
At the time, the unnecessary completion was harmless because the block
layer would ignore it, although that changed in kernel v5.0.
Note for stable, this patch will not apply cleanly without patch "mmc:
core: Fix recursive locking issue in CQE recovery path"
Signed-off-by: Adrian Hunter <[email protected]>
Fixes: ad73d6feadbd7b ("mmc: complete requests from ->timeout")
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Consider the following stack trace
-001|raw_spin_lock_irqsave
-002|mmc_blk_cqe_complete_rq
-003|__blk_mq_complete_request(inline)
-003|blk_mq_complete_request(rq)
-004|mmc_cqe_timed_out(inline)
-004|mmc_mq_timed_out
mmc_mq_timed_out acquires the queue_lock for the first
time. The mmc_blk_cqe_complete_rq function also tries to acquire
the same queue lock resulting in recursive locking where the task
is spinning for the same lock which it has already acquired leading
to watchdog bark.
Fix this issue with the lock only for the required critical section.
Cc: <[email protected]>
Fixes: 1e8e55b67030 ("mmc: block: Add CQE support")
Suggested-by: Sahitya Tummala <[email protected]>
Signed-off-by: Sarthak Garg <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
|