| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
# net/ceph/osd_client.c
|
|
dw_mmc-rockchip's execute_tuning() scans the tuning window phase by phase
through mmc_send_tuning(), which applied the whole-sequence 150 ms
bound as the data timeout of every single CMD19/CMD21. With HS200
eMMC the TMOUT register saturates at ~112 ms for the requested
150 ms, so every phase that misses the window stalls that long, and
multi-second boot slowdowns have been reported[1].
Use 5 ms per tuning command via mmc_send_tuning_timeout() instead:
~1.3x the spec-implied per-execution device budget (150 ms / 40 =
3.75 ms, excluding host overhead), 30x below the 150 ms ceiling, and
the reporter verified that tuning keeps passing with it. A wrong
sampling phase normally fails fast with a CRC error anyway, so the
timeout only catches devices which never return the tuning block at
all. This also bounds the cost of runtime re-tuning.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221781 [1]
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
In CMDQ mode an I/O error in one task (data_crc_err, data_end_bit_err,
etc.) makes the controller raise a halt request. While the halt request
is pending, the controller rejects doorbell writes with a slave response
error, which hangs the CPU (or raises SError on ARM) on Rockchip
platforms.
A software workaround[1] clears CQHCI_CTL right before ringing the
doorbell to narrow down the window, but a race remains: an I/O error can
still happen in another slot between the CQHCI_CTL write and the
doorbell kick, so the hang is not fully solved.
To fix this once and for all, newer silicon introduces
SW_ERR_HALR_REQ_DISABLE (CQHCI_CTL[1]) which stops the controller from
raising a halt request on I/O errors. Set the bit when the CQE is
enabled, which is the last CQHCI_CTL write before any doorbell write.
Older SoCs keep this bit reserved, so writing it is a no-op and nothing
changes in the wild, thus no fixes tag is needed.
[1] https://github.com/rockchip-linux/kernel/commit/4b7ea0500a1a5c186807b737fecfc6bb4d4e06f8
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Convert open-coded if/else with set_bit/clear_bit and their
non-atomic __set_bit/__clear_bit variants to the assign_bit/__assign_bit
API.
Done with Coccinelle semantic patch and manual fixups.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Aubin Constans <aubin.constans@microchip.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
pcim_iomap_regions() and pcim_iomap_table() have been deprecated.
Replace them with pcim_iomap_region(), which requests and maps a single
BAR and returns the mapping directly.
pcim_iomap_region() returns an IOMEM_ERR_PTR() on failure, so check the
result with IS_ERR() and propagate the error with ERR_CAST().
Signed-off-by: Alper Ak <alperyasinak1@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
After spmmc_controller_init() resets the controller, all timing
fields are zero. The hs_en path initialises the write timing
delays (wr_cmd_dly, wr_dat_dly) but leaves the read side at zero.
In DDR52 mode, rd_crc_dly=0 causes the first write to fail with
CRC_TOKEN_CHECK_ERROR, triggering the auto-tuning retry loop and
causing a multi-second delay on the first cold-boot write.
Set rd_crc_dly=1 when enabling DDR mode to avoid this.
Tested on a LTPP3G2, booting via eMMC in DDR52 mode,
on linux-next-20260915.
Signed-off-by: Andrew Gaylard <ag@ffroot.co.za>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
thunder_mmc_probe() creates host->slot_pdev[i] with
of_platform_device_create(), while thunder_mmc_remove() does not destroy
the child platform devices.
The probe failure path removes each MMC slot and destroys its associated
platform device, but the normal remove path only removes the MMC slot.
As a result, the child platform devices remain registered after the
ThunderX MMC controller is removed.
Destroy each slot platform device during removal after cleaning up the
corresponding MMC slot, matching the probe failure cleanup path. Keep an
extra device reference around of_platform_device_destroy() as done in
the existing error path.
This issue was found by manual code inspection.
Fixes: 166bac38c3c56 ("mmc: cavium: Add MMC PCI driver for ThunderX SOCs")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
octeon_mmc_probe() creates host->slot_pdev[i] with
of_platform_device_create(), while octeon_mmc_remove() does not destroy
the child platform devices.
The probe failure path removes each MMC slot and destroys its associated
platform device, but the normal remove path only removes the MMC slot.
As a result, the child platform devices remain registered after the
Octeon MMC controller is removed.
Destroy each slot platform device during removal after cleaning up the
corresponding MMC slot, matching the probe failure cleanup path.
This issue was found by manual code inspection.
Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Since commit 522811e944ed ("of: platform: stop accessing invalid dev in
of_platform_device_destroy"), there is no need to take a reference for the
device before calling of_platform_device_destroy(), hence let's drop this.
Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
sdhci_sprd_probe() enables runtime PM, while sdhci_sprd_remove() does
not perform the corresponding runtime PM cleanup.
The probe failure path disables runtime PM before disabling the clocks,
but the normal remove path directly disables clocks that are also
managed by the runtime PM callbacks. If the device is runtime
suspended, those clocks may already be disabled.
Resume the device before removal, disable runtime PM and drop the
temporary runtime PM reference before disabling the clocks.
This issue was found by manual code inspection.
Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The driver queues req_timeout while a request is active.
msdc_request_done() uses cancel_delayed_work(), which does not wait for
a timeout callback that has already started.
The timeout callback calls mmc_request_done(), which wakes the request
waiter, and then continues to use host->dev_comp and check the SDIO IRQ.
During unbind, msdc_drv_remove() can return and the managed mmc_host can
be freed before the callback finishes.
KASAN reported use-after-free accesses in msdc_request_done() and
msdc_recheck_sdio_irq() in each of three unbind tests. The same tests
completed without a kernel diagnostic after this change.
Call cancel_delayed_work_sync() after mmc_remove_host() has stopped new
requests and before the driver releases the host resources.
Fixes: 208489032bdd ("mmc: mediatek: Add Mediatek MMC driver")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The Elan Digital Systems controller has been obsolete for many years. In
fact, its corresponding driver that was introduced in 2011 only received
one initial commit, but has since then never been actively maintained.
In this regards, we have lately started to receive a lot of AI generated
bug fixes as the driver is a real mess. Rather than continue this path
instead of making a proper rework of the driver, which is what would be
needed, let's just remove the driver altogether.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
struct dw_mci_slot does not exist anymore and nothing ever references
host->slot; the member is a leftover from the multi-slot design this
driver was upstreamed with, where the slot struct lived in the same
header.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Probe failure and removal leave SDHCI child devices registered after the
parent clock and managed resources are released.
Unregister the OF children in reverse order before disabling the parent
clock on both paths. Use of_platform_device_destroy() because manual
child creation does not set the flag required by of_platform_depopulate().
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Assisted-by: OpenAI:GPT-5.6
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Use device handlers instead of of_node ones for simplicity.
As this driver is effectively OF only, it ends up behaving the same.
Change is_bool to present as no-1-8-v is not specified as a bool in dts,
but as either present or not.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
On the T7 SoC, the bus path between the SD/eMMC controllers and the
NIC_MATRIX fabric goes through a pipeline stage inserted by the hardware
design to help timing closure. The stage has its own gate clock and,
when that clock is disabled, a controller that starts a DMA transfer can
never complete it, hanging the storage devices and, from there, the
whole system.
Add a dedicated match data for the amlogic,t7-mmc compatible that makes
the driver claim and enable the "pipeline" clock for as long as the
device is bound.
The clock is deliberately not optional: the hardware cannot do DMA
without it, and failing the probe with a clear error is preferable to
booting and hitting an undiagnosable DMA hang later.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Lucas Tanure <tanure@linux.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The threaded IRQ handler can run before devm_request_threaded_irq()
returns, but thread_lock was initialized afterwards. Initialize it before
requesting either interrupt.
Fixes: 8047310ee984 ("mmc: sh_mmcif: fix a race, causing an Oops on SMP")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The Altera Agilex5 SoC integrates a Cadence SD6HC controller that needs
platform-specific configuration to operate correctly.
The SoC requires three named resets: "sdhc-reset", "combophy", and
"sdmmc-ocp". All three are exclusive and must be asserted together before
being released, so the SDHCI, SoftPHY, and OCP/AXI clock domains cross the
reset boundary simultaneously. SoftPHY is shared with NAND at the SoC
level, but only one of SDMMC or NAND is enabled on a given board.
The IOMMU maps DMA addresses within a 40-bit physical address space, so
the DMA mask is capped at 40 bits to prevent allocation beyond the
controller's reach.
The silicon requires the MULTIBLOCK_READ_ACMD12, CAP_CLOCK_BASE_BROKEN,
PRESET_VALUE_BROKEN, and ACMD23_BROKEN quirks. Since
CAP_CLOCK_BASE_BROKEN prevents reading the base clock from the
capabilities register, the maximum clock is supplied from the platform
clock instead.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The Cadence SD6HC is a sixth-generation SD/SDIO/eMMC host controller
with an integrated combo-PHY. PHY timing depends on the active speed
mode, the SD clock period, and board-level IO-cell and DLL delay-
element characteristics.
SD6HC provides separate card-interface (CIU) and bus-interface (BIU)
clocks, and asserts eMMC hardware reset through an internal controller
register rather than an external RST_n line. The "cdns,sd6hc" compatible
string identifies this IP in device tree.
Split the existing driver into sdhci-cadence-core.c and
sdhci-cadence-phy-v6.c, and add sdhci-cadence.h for shared private
state.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Refactor the sdhci-cadence driver in preparation for adding SD6HC (V6
controller) support. Separate PHY parameter handling into a dedicated
sdhci_cdns4_phy structure and move PHY initialization logic into a
dedicated sdhci_cdns4_phy_probe() function. This allows different
controller versions to manage their PHY configurations independently
while keeping shared logic in the main driver.
Each compatible entry now carries its own driver data, so drop the
silent fallback to sdhci_cdns4_drv_data and return an error if platform
data is missing.
No functional change.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
SD4HC PHY helpers and the default ops/drv_data are not marked as
version-specific, so it is unclear what is shared versus SD4HC-only
ahead of SD6HC support.
Rename those symbols with a cdns4 prefix to separate the SD4HC paths
from the shared driver core and avoid clashes when SD6HC is added.
No functional change.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The SDIO3 Configuration register branch of pxav3_set_uhs_signaling()
only clears the clock-inversion and feedback-clock bits for
MMC_TIMING_MMC_HS. As a result, MMC_TIMING_SD_HS (ordinary SD High
Speed) falls through to the default case, which sets SDIO3_CONF_CLK_INV
and leaves the feedback clock cleared.
According to erratum FE-2946959, clock inversion is only needed for
slow frequencies when the card hold-time requirement is high and is not
required nor desirable for high-speed modes. SD High Speed runs at 50
MHz, so the same timing argument that applies to MMC High Speed holds.
Treat MMC_TIMING_SD_HS the same as MMC_TIMING_MMC_HS and clear the
clock-inversion and feedback-clock bits for both.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Debugging hangs on the request legs now means asking 'what was the
watchdog guarding and until when?' Expose the awaited events, the
valid states, and the absolute deadline of the current watch next to
the existing pending_events/completed_events nodes; all three zero out
once a leg is settled or the watch fired.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The voltage switch (CMD11) keeps its dedicated 500ms deadline, but it
is now just another arm of the central watchdog; cmd11_timer is
deleted. The synthesized payload is identical to what the command leg
watchdog produces (cmd_status = RTO plus EVENT_CMD_COMPLETE), so the
request state machine cannot tell the difference.
Behavior notes for review:
* The extra jiffy in the legacy '500ms + 1' arming was pure jiffies
rollover paranoia and disappears together with the jiffies math.
* Since patch 1 arms the regular command watch on every RESP_EXP
command -- including voltage switches -- the subsequent arm here
replaces it, as documented there. For a genuinely stuck CMD11 the
abort latency therefore becomes exactly 500ms instead of racing
min(cto_ms, 500ms) between two timers as before; the reported
error (-ETIMEDOUT either way) is unchanged.
* dw_mci_cmd_interrupt() already delivers the watched events under
irq_lock on any completion path, so the former out-of-lock
timer_delete() next to the VOLT_SWITCH branch simply goes away.
No functional change intended.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The data timeout joins the command timeout on the central watchdog;
dto_timer is deleted.
dw_mci_set_drto() arms DW_MCI_WD_DATA_EVENTS with EVENT_DATA_COMPLETE
as its precheck mask: a DATA_ERROR that arrived while still waiting
for the paired completion must not prevent the watch -- the legacy
mod_timer() guard tested exactly that one bit, and the fault-injection
machinery relies on this by injecting DATA_ERROR early.
The EXTENDED_TMOUT quirk semantics fall out naturally now:
* On quirk hosts the data-error branch delivers the whole watched
set, stopping the watch since no further data events will come --
this mirrors the former conditional timer_delete() plus the manual
EVENT_DATA_COMPLETE side-post.
* Without the quirk nothing is delivered there and the outstanding
watch keeps guarding until a genuine DATA_OVER arrives, exactly
like leaving dto_timer running did.
The DATA_OVER branch delivers unconditionally, superseding its
unconditional timer_delete(). The stale-timer WARN_ON +
timer_delete_sync() dance in dw_mci_clear_pending_data_complete() goes
away for the same reason as on the command leg: a callback racing past
its checks is idempotent under irq_lock.
No functional change intended.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The driver keeps three independent fallback timers (cmd11, cto, dto)
whose callbacks all re-implement the same race handling: peek MINTSTS
in case the interrupt is in flight, check whether the event was
delivered meanwhile, verify host->state matches the leg being guarded,
and finally synthesize the missed event. This series replaces them
with a single hrtimer watchdog.
This first step introduces the watchdog and moves the command timeout
onto it; cto_timer is deleted. Later steps convert the data timeout
and the voltage-switch timer onto the same watch.
The new protocol relies on two simple facts which hold for all current
event producers:
* every site posting EVENT_CMD_COMPLETE (dw_mci_cmd_interrupt() and
the command-error branch of dw_mci_interrupt()) runs under
irq_lock,
* every site arming a watch does so under irq_lock as well.
Consequently a watchdog callback holding irq_lock can neither miss nor
race an already-delivered event: the bookkeeping part of the former
're-read MINTSTS' paranoia is subsumed by checking the awaited mask
against pending_events under the same lock the producers use. The
hardware-latency part of that paranoia is kept verbatim, see below.
A callback that raced past every check nonetheless degrades to at most
one idempotent extra state machine run instead of completing a foreign
leg.
The callback classifies what expired by comparing the awaited set
against the named DW_MCI_WD_{CMD,DATA}_EVENTS masks so that subsequent
conversions only add call sites. dw_mci_wd_arm() takes a separate
'already delivered' precheck mask because guarding the data legs must
tolerate a DATA_ERROR that arrived while still waiting for the paired
completion -- exactly like mod_timer() paths did before.
Behavioral notes for review:
* dw_mci_wd_arm() replaces any previously armed watch. During a
voltage switch (CMD11) both cto_timer and cmd11_timer were armed
concurrently before, racing each other with duplicated warnings;
now only the last arm on that path survives.
* The stale-timer defensiveness of dw_mci_clear_pending_cmd_complete()
(WARN_ON + timer_delete_sync) is dropped because the callback is now
idempotent by construction; timer_delete_sync from the BH would also
be wrong-context sleeping on hrtimers.
* Before declaring a timeout the callback re-reads MINTSTS: when the
completion interrupt is already latched in hardware and only its
handler has not been scheduled yet, the firing grants further
DW_MCI_WD_INFLIGHT_GRACE_MS rounds instead of failing an about-to-
complete transfer. This replicates the interrupt-latency paranoia
of the retired cto_timer()/dto_timer() callbacks; unlike them it
keeps re-watching rather than going passive, so if that latched
interrupt is ultimately lost the request still unwedges with a
timeout error instead of hanging forever.
No functional change intended beyond the deduplication described above.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Inline Crypto Engine (ICE) keys are lost after hibernation entry and this
needs to be restored when hibernation exits. ICE keys are re-programmed
during sdhci_msm_ice_init() but it may not cover cases where the
hibernation image is already restored.
Unwrap the pm ops and use directly in driver to add the call to restore
Inline Crypto Engine (ICE) keys. This ensures that ICE is brought into
same state as before hibernation. If hibernation image creation itself
fails then device boots through normal flow where there is no need to
reprogram the keys.
Also set MMC_CAP2_CRYPTO_NO_REPROG to indicate that re-programming of ICE
keys is not needed during MMC runtime suspend/resume or suspend-to-RAM
since the rail powering the ICE will not be turned off.
During CQE recovery, key would be lost only when BCR reset is performed
which do not happen right now and will be taken up once it is fixed as part
of recovery flow.
Signed-off-by: Ram Prakash Gupta <ram.gupta@oss.qualcomm.com>
Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@quicinc.com>
Co-developed-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
Co-developed-by: Sarthak Garg <quic_sartgarg@quicinc.com>
Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
Signed-off-by: Debraj Mukhopadhyay <quic_dmukhopa@quicinc.com>
Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
A UHS session can leave the SD pads and SD18 regulator configured for
1.8V. The power-off path disables card power and suspends the regulator,
but does not restore their voltage selection.
On the next power-up, this stale state remains until after the MMC core
requests its initial signal voltage. Restore the SD pads and SD18 regulator
to 3.3V before enabling card power, as the old rts5139 driver did.
Tested: StarLite ADL with an RTS5129 tray reader; repeated 1.8V UHS
sessions, power cycles, and tray removal/reinsertion.
Tested: StarFighter MTL with an RTS5129 trayless reader; repeated 1.8V
UHS sessions, power cycles, and card removal/reinsertion.
Tested: Both systems re-enumerated the card after every cycle.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The Realtek RTS522A card reader in the Lenovo ThinkPad X260
(subsystem 17aa:504a) incorrectly reports inserted SD cards as
write-protected.
This causes the MMC core to expose the card as read-only:
mmcblk0: mmc0:aaaa SN256 238 GiB (ro)
and /sys/block/mmcblk0/ro reports 1.
Setting MMC_CAP2_NO_WRITE_PROTECT makes the card writable again.
Limit the quirk to the affected Lenovo subsystem.
Assisted-by: ChatGPT:GPT-5.6 Sol
Signed-off-by: Florian Maillard <florian.maillard@mailoo.org>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
mmc_spi_data_do() updates data->bytes_xfered after each block has been
transferred successfully. If a later block in the same data request
fails with a CRC error, data->bytes_xfered may therefore contain the
number of bytes completed before the failing block.
mmc_spi_request() has a private recovery path for such CRC failures. It
sends STOP_TRANSMISSION, clears data->error and jumps back to
crc_recover to issue the same command and data request again. However,
it does not clear data->bytes_xfered before the retry.
If the retry succeeds, the request is completed with the bytes from the
failed attempt still included in data->bytes_xfered. For a multi-block
request this can make the completed request report more bytes than were
transferred by the successful retry, and can even exceed the request size
when most blocks completed before the CRC error.
This is most likely to be observed on MMC-over-SPI systems where long
multi-block transfers occasionally hit a data CRC error but the
mmc_spi-internal retry succeeds. The data itself is retried, but the
completion accounting is not.
Clear data->bytes_xfered together with data->error before repeating the
request so the final completion reports only the bytes transferred by the
successful attempt.
Fixes: 061c6c847eeb ("mmc_spi: Recover from CRC errors for r/w operation over SPI.")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
host->sdio_irq is assigned from platform_get_irq_optional(), which
returns a positive IRQ number on success or a negative error code on
failure. Therefore, 0 is not a possible return value from this API.
Check for a positive IRQ number before requesting the SDIO IRQ instead
of treating zero as a valid IRQ.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available. Other errors, such as -EPROBE_DEFER
and -EINVAL, should be propagated so that the caller can handle them
appropriately.
However, the driver currently stores the return value directly in
host->sdio_irq and continues probing.
Propagate negative errors other than -ENXIO.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available. Other errors, such as -EPROBE_DEFER
and -EINVAL, should be propagated so that the caller can handle them
appropriately.
However, the driver currently stores the return value directly in
cd_irq and continues probing.
Propagate negative errors other than -ENXIO, and only assign the IRQ to
cd_irq when a valid IRQ number is returned.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
DDR50 mode is not required to support the tuning command CMD19, meaning
that calibration may fail on cards that do not implement it, in which
case a known-good itap delay value should be programmed into the host
controller.
Do this by reading the (already defined) itap delay DT property for DDR50
and, if tuning fails for this mode, fall back to the DT-provided itap delay
value. If the DT does not provide a value for DDR50 fallback then this
simply disables using itapdly.
Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning")
Cc: stable@vger.kernel.org
Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
When tuning fails, stale ITAPDLY values can persist and interfere with
subsequent I/O accesses, for example in DDR50 mode in cards with no tuning
support. Move the ITAPDLY enable setting out of the tuning loop to after
successful tuning, and explicitly clear ITAPDLY (delay and enable) when
tuning fails so that we are sure only working values are actually left in
hardware.
Fixes: 901d16e46296 ("mmc: sdhci_am654: Add retry tuning")
Cc: stable@vger.kernel.org
Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The CMD/DATA reset after tuning should be performed regardless of
whether tuning succeeded or failed, since tuning data may remain in
the buffer in either case. Move the error return after the reset so
that the controller is always cleaned up.
Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning")
Cc: stable@vger.kernel.org
Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The tuning_loop field in struct sdhci_am654_data is only used within
sdhci_am654_platform_execute_tuning() as a loop counter that is
initialized to 0 in sdhci_am654_init(). Since it shouldn't persist across
function calls, otherwise every failure expends its "budget", move it to a
local variable and remove the struct field along with the now-unnecessary
initialization.
Signed-off-by: Diogo Ivo (Schneider Electric) <diogo.ivo@bootlin.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: de31f6ab68a3 ("mmc: sdhci_am654: Reset Command and Data line after tuning")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
mmc_hsq_pump_requests() queues retry_work when request_atomic() returns
-EBUSY; today sdhci-sprd is the only consumer that implements
request_atomic(). The work is embedded in a devm-allocated mmc_hsq, but
is never cancelled during driver removal. Work still pending at unbind
can therefore run after the devm allocation has been released and
dereference hsq->mmc and hsq->mrq.
Use devm_work_autocancel() to cancel and drain retry_work before the devm
allocation is released. By the time devres cleanup begins,
mmc_remove_host() has already stopped the host, so no new requests can
arm the work.
This issue was found by an in-house static analysis tool.
Fixes: 6db96e5810e0 ("mmc: host: Introduce the request_atomic() for the host")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
mxcmci_remove() frees the host through the devm tail, but neither it nor
mmc_remove_host() drains the driver's own asynchronous state.
host->watchdog, a 10 s timer armed on the DMA path in mxcmci_setup_data(),
is deleted only by the DMA- and IRQ-complete paths, which the remove path
does not explicitly drain; it can therefore fire after the host is freed
and dereference it in mxcmci_watchdog(). host->datawork, armed from the
IRQ handler on the PIO path, is not cancelled by the remove path either.
Free the devm-registered IRQ, then cancel datawork and delete the watchdog
in mxcmci_remove(), before dma_release_channel(). Freeing the IRQ first
keeps a trailing handler from re-arming datawork between the cancel and
the host free. Both callbacks are non-self-rearming.
This issue was found by an in-house static analysis tool.
Fixes: f6ad0a481342 ("mmc: mxcmmc: fix bug that may block a data transfer forever")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
ux500_busy_complete() can queue ux500_busy_timeout_work for an R1b
command, but mmci_remove() never cancels it. The work can subsequently
dereference the devm-allocated mmci_host after it has been released.
Mask the controller interrupts and disable the delayed work during
removal. This drains any queued instance and stops an IRQ handler that
is still in progress from queueing the work again once it has been
disabled.
This issue was found by an in-house static analysis tool.
Fixes: b1a665932dc2 ("mmc: mmci: Add support for SW busy-end timeouts")
Cc: stable@vger.kernel.org # v6.10+
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
None of these files actually needs pagemap.h. After this patch, no
files in drivers/mmc depend on pagemap.h any more.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
|
|
Merge the mmc fixes for v7.2-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
