| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
# net/ceph/osd_client.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git
|
|
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
|
|
bsg-lib allocates a 96-byte (SCSI_SENSE_BUFFERSIZE) reply buffer per
job, but struct ufs_rpmb_reply is 104 bytes: a 40-byte struct
ufs_bsg_reply followed by a 64-byte EHS. When an Advanced RPMB command
returns an EHS, ufshcd_advanced_rpmb_req_handler() copies it right after
the 40-byte header and writes 8 bytes past the end of the buffer.
Let each BSG transport pass its reply buffer size to bsg_setup_queue()
and have ufs_bsg request sizeof(struct ufs_rpmb_reply), so the full
reply reaches user space. Other transports keep SCSI_SENSE_BUFFERSIZE.
Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg")
Cc: stable@vger.kernel.org
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20261013132708.1669415-1-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
|
|
While the C11 allows us to define variables in the code, we do not do
this style (see more at [1]). Move the declaration to the top of the
function.
Link: https://lore.kernel.org/lkml/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/ [1]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20261013095924.959455-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Driver (and tape media changer) only fixes. Three of the fixes are
about the same size, (ch, ufs decouble CQ and ufs avoid unsafe MMIO)
but the unsafe MMIO is the least obvious logic change"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: core: Decouple CQ sweep from request iterator in MCQ
scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()
scsi: ch: Do not keep references to data transfer element devices
scsi: ufs: mediatek: Handle mPHY power-on failures
scsi: qedi: Initialize callback state before registration
scsi: ufs: core: Hold a clock reference across the probe
|
|
|
|
A merge conflict resolution dropped SCMD_FAILURE_ASCQ_ANY from the retry
added by commit a8a34238e5e6 ("scsi: ufs: rpmb: Retry power-on UNIT
ATTENTION on the RPMB WLUN"), so only 29h/00h is retried, not the other 29h
ASCQs.
Link: https://lore.kernel.org/linux-scsi/yq1jyo4onqe.fsf@mail.kernel.org/
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://patch.msgid.link/20260929140806.2859367-1-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
In MCQ mode, ufshcd_mcq_compl_pending_transfer() uses
blk_mq_tagset_busy_iter() to iterate over busy requests during error
recovery and host reset. However, both iterator callbacks perform
whole-queue operations redundantly for each visited request:
- force_compl == true: ufshcd_mcq_force_compl_one() calls
ufshcd_mcq_compl_all_cqes_lock() on every busy request, sweeping the
entire completion ring (hwq->max_entries slots) once per active request
under spin_lock_irqsave even though the first sweep already cleared all
completion entries.
- force_compl == false: ufshcd_mcq_compl_one() acquires cq_lock and polls
CQTPy over MMIO via ufshcd_mcq_poll_cqe_lock() for every busy request
without doing any per-request work.
Sweep or poll each hardware queue (hba->uhq[i]) once at the start of
ufshcd_mcq_compl_pending_transfer(). When force_compl is true, run
blk_mq_tagset_busy_iter() afterward to complete residual in-flight
requests with DID_REQUEUE, and remove the now-unused
ufshcd_mcq_compl_one() callback.
Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode")
Cc: stable@vger.kernel.org
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/20260928035816.1294326-3-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
During MCQ host reset, ufshcd_host_reset_and_restore() stops the host
controller via ufshcd_hba_stop() (HCE = 0) before calling
ufshcd_complete_requests(hba, true) ->
ufshcd_mcq_compl_pending_transfer(hba, true) ->
ufshcd_mcq_force_compl_one() -> ufshcd_mcq_compl_all_cqes_lock(). Because
ufshcd_mcq_force_compl_one() is its sole caller,
ufshcd_mcq_compl_all_cqes_lock() always runs with HCE = 0.
Despite the comment above ufshcd_mcq_compl_all_cqes_lock() stating that
reading CQTPy may not be safe with the controller disabled, the function
still calls ufshcd_mcq_update_cq_tail_slot() at the end of its sweep:
1. Unsafe CQTPy MMIO read:
Calling ufshcd_mcq_update_cq_tail_slot() at the end of the sweep reads
CQTPy over MMIO while HCE = 0, directly contradicting the function's
documented contract (commit 1373df88d535 ("scsi: ufs: core: Add a
comment block above ufshcd_mcq_compl_all_cqes_lock()")) that reading
CQTPy may not be safe with the controller disabled.
2. Spurious error logs on empty slots:
Sweeping all max_entries slots visits empty entries where
command_desc_base_addr is 0, causing ufshcd_mcq_process_cqe() to log
unguarded dev_err(hba->dev, "Abnormal CQ entry!\n") messages.
Fix both issues in ufshcd_mcq_compl_all_cqes_lock():
- Remove the ufshcd_mcq_update_cq_tail_slot() call and the redundant
hwq->cq_head_slot = hwq->cq_tail_slot assignment without replacement.
The two indices are already equal after the sweep: they are equal when
the sweep starts, since ufshcd_mcq_poll_cqe_lock() consumes entries
until cq_head_slot reaches cq_tail_slot, and the sweep advances
cq_head_slot by exactly one full ring. Both indices are also
reinitialized before the queue is reused.
- Extract ufshcd_mcq_compl_cqe() and invoke it only on non-empty slots
during full-ring sweeps, keeping "Abnormal CQ entry!" logging strictly
for unexpected empty entries in ufshcd_mcq_poll_cqe_lock().
Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode")
Cc: stable@vger.kernel.org
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260928035816.1294326-2-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The MediaTek helper enables VA09 before powering on the mPHY, but ignores
the PHY result. A failure can leave VA09 enabled and publish
mphy_powered_on as true, so a later power-on attempt is skipped.
Check phy_power_on(), attempt to unwind VA09 on failure, and leave the
state flag unchanged. Propagate the helper result from host initialization
as well as its existing resume caller. Keep the original PHY error if the
supply rollback also fails, and report that rollback separately.
The issue was found by our static-analysis tool.
Fixes: 561e3a8726b2 ("scsi: ufs-mediatek: Fix unbalanced clock on/off")
Fixes: cf137b3ea49a ("scsi: ufs-mediatek: Support VA09 regulator operations")
Assisted-by: gpt 5
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20260920034953.19535-1-hppiscas@163.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The sa8255p vops (fw-managed variant) was missing the MCQ hooks, causing
the driver to silently fall back to SDB mode even when MCQ resource is
available. Wire up the same MCQ ops used by the standard qcom vops, so that
MCQ mode works on sa8255p.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260728051104.675088-1-shengchao.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
A race exists between ufshcd_auto_hibern8_update() and
ufs_mtk_pwr_change_notify() when both paths concurrently access
REG_AUTO_HIBERNATE_IDLE_TIMER. Additionally, the static local variable used
to save/restore AHIT in the power change path is not re-entrant and may
hold a stale value if a sysfs write races with a gear change.
Introduce ahit_mutex and ahit_disable_depth in struct ufs_hba to
serialize AHIT register access. The depth counter tracks how many
host-driver paths have forced AHIT off; sysfs writes are suppressed
while it is non-zero and the register is restored from hba->ahit
only when the last disabler drops it to zero.
Fixes: f5ca8d0c7a63 ("scsi: ufs: host: mediatek: Disable auto-hibern8 during power mode changes")
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Link: https://patch.msgid.link/20260914085148.136429-3-peter.wang@mediatek.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Previously, POST_CHANGE was only notified on a successful gear switch.
This could leave the host in an inconsistent state if resources were
acquired in PRE_CHANGE (e.g. disabling auto-hibern8) but never released due
to a missing POST_CHANGE.
Fix this by always calling POST_CHANGE regardless of the gear switch
result. On failure, pass dev_req_params = NULL to signal that there is
nothing to apply; hosts that receive NULL simply skip their post work.
Update the affected drivers (ufs-exynos and ufshcd-pci) to guard their
POST_CHANGE logic with a NULL check so they correctly handle the failure
case.
Fixes: f5ca8d0c7a63 ("scsi: ufs: host: mediatek: Disable auto-hibern8 during power mode changes")
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Link: https://patch.msgid.link/20260914085148.136429-2-peter.wang@mediatek.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
JEDEC JESD220F specifies that the Timestamp attribute (qTimestamp) is an
optional feature for UFS devices. Some compliant UFS 4.0 devices do not
implement it and return QUERY_RESULT_INVALID_IDN (0xFD).
ufshcd_set_timestamp_attr() gates the write on wspecversion >= 0x400 and
the absence of UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT. Neither covers a
device that advertises UFS 4.0 but declines the attribute, so the write is
reissued on every boot and every resume.
Record the capability in struct ufs_dev_info and clear it when the device
answers -EOPNOTSUPP, so the write is not retried. -ETIMEDOUT and -EIO still
reach dev_err(); they are transient and must not disable the attribute.
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Tested-by: Xilin Wu <sophon@radxa.com>
Link: https://patch.msgid.link/20260911024319.1346706-3-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
JEDEC JESD220F specifies that devices not supporting an optional Query IDN
return QUERY_RESULT_INVALID_IDN (0xFD) in the Query Response UPIU.
ufshcd_dev_cmd_completion() maps all non-zero Query responses to -EINVAL
and logs dev_err(). A device declining an optional IDN is spec-compliant,
so this reports an error that did not occur and leaves the retry loops
resending a request the device will never accept.
Decode 0xFD as -EOPNOTSUPP, terminate the query retry loops on it, and drop
the dev_err() in the query wrappers and descriptor readers for that
case. Other errors are logged and retried as before.
The suppressed dev_err() calls carried the opcode and IDN; log them with
dev_dbg() where the response is decoded.
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Tested-by: Xilin Wu <sophon@radxa.com>
Link: https://patch.msgid.link/20260911024319.1346706-2-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Clock gating becomes possible as soon as ufshcd_init_clk_gating() has run,
and from that point on the probe keeps accessing host registers without
ever taking a clock reference. This has been safe only because of the state
check in __ufshcd_release(): gate_work is not queued unless
hba->ufshcd_state is UFSHCD_STATE_OPERATIONAL, and the promotion to that
state used to happen after the last register access of the probe, at the
end of ufshcd_probe_hba().
That is fragile: it only works while the promotion happens after the
register accesses. Commit a390e6677f41 ("scsi: ufs: core: Expand the
ufshcd_device_init(hba, true) call") changed that ordering by moving the
promotion into ufshcd_init(), which schedules ufshcd_async_scan()
afterwards. ufshcd_probe_hba() therefore now runs with the state already
promoted, and it accesses host registers without holding a clock reference:
- On hosts with UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH it calls
ufshcd_hba_stop() and ufshcd_hba_enable() before ufshcd_device_init()
sets the state back to UFSHCD_STATE_RESET, and both read
REG_CONTROLLER_ENABLE, so gated clocks stall there instead of just
losing a write.
- It ends with an ufshcd_configure_auto_hibern8() write, which its other
callers do take a clock reference for.
Take a clock reference as soon as clock gating has been initialised and
keep it until the probe is over. It then does not matter who drops a clock
reference while the probe is running, and the register accesses of the
probe no longer depend on hba->ufshcd_state. The reference is dropped by
ufshcd_async_scan() once the scan has finished, or by the new out_release
label if the probe fails after it was taken.
Fixes: a390e6677f41 ("scsi: ufs: core: Expand the ufshcd_device_init(hba, true) call")
Signed-off-by: Naomi Chu <naomi.chu@mediatek.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/20260909091045.1134956-1-naomi.chu@mediatek.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Mostly small driver fixes. The biggest fix is the one to the block
zone handling which might trip for real or virtual hardware if the
number of zones is > 2^32"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: megaraid_sas: Protect megasas_get_ctrl_info() in megasas_resume()
scsi: sd_zbc: Reject disks with too many zones
scsi: block: Fix zones_cond out-of-bounds write on zone report
scsi: leapraid: Avoid -Wformat-security warning
scsi: devinfo: Add BLIST_SKIP_IO_HINTS for EMC Symmetrix
scsi: libiscsi_tcp: Check the data direction of a Data-In PDU
scsi: ufs: pltfrm: Add quirk for R-Car S4 lacking lanes-per-direction
scsi: ufs: core: Keep internal commands dispatchable during error handling
|
|
The Versal Gen 2 UFS driver polls the firmware for M-PHY TX/RX
configuration readiness and SRAM initialisation completion with two
open-coded do/while loops. Each iteration is a full firmware round-trip
(PM_IOCTL/IOCTL_READ_REG of a protected PMC_IOU_SLCR register), so the
loop can issue up to a million EEMI calls, and it hard-codes the wait
policy inside the controller driver.
Introduce coarse blocking helpers, zynqmp_pm_wait_mphy_tx_rx_config_ready()
and zynqmp_pm_wait_sram_init_done(), that take a caller-supplied timeout
budget and contain the poll loop. The loop is EEMI-specific (legacy
firmware only exposes the per-read status primitive) so it lives in the
firmware driver, keeping the UFS driver backend-agnostic: a future
backend can offload the wait to the platform in a single call without
touching the controller driver again. The existing per-read primitives stay
exported, so the current EEMI interface is unchanged.
The timeout budget remains owned by the UFS driver (the consumer that
knows the hardware) and is passed down, so EEMI and any future backend
stay consistent.
Reviewed-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
Link: https://patch.msgid.link/eaeaaea8ed76069943e0706a0917139ff6569929.1785855749.git.michal.simek@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Merge Linux 7.3-rc2 to resolve libata and mpi3mr merge conflicts.
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Conflicts:
drivers/ata/libata-scsi.c
drivers/scsi/mpi3mr/mpi3mr_transport.c
|
|
Damien Le Moal <dlemoal@kernel.org> says:
This patch series defines as macros all ASC/ASCQ combinations present in
https://www.t10.org/lists/asc-num.txt and converts the SCSI core code and
SCSI low level drivers to use these macros instead of hard-coded
ASC/ASCQs. To do this, struct scsi_sense_hdr and struct scsi_failure are
modified to replace the asc and ascq 8-bits fields with a 16-bits
sense_code field.
This cleans up the code in many places and makes it easier, and self
documented, to test sense codes in the case of errors.
Overall, there should be no functional chnages here.
Note: this series currently applies cleanly only to the scsi-staging tree.
It does not apply to Linus tree as commit 6d81700ad7c4 ("ata: libata-scsi:
do not raise UA for storage element depopulation and restoration") creates
a conflict with patch 37. The conflict is trivial to resolve, but this
will create a conflict in linux-next. Could you maybe rebase scsi-staging
on rc2 ?
Also please note that sashiko did comment about several pre-existing
issues for different drivers, but I am not addressing these issues in
this series.
[mkp: fixed ufs conflict]
Link: https://patch.msgid.link/20260908090308.1085097-1-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Since commit e72323f3b09f ("scsi: ufs: core: Configure only active lanes
during link"), the following error is observed on R-Car S4:
ufshcd-renesas e6860000.ufs: Tx lane mismatch [config,reported] [2,1]
ufshcd-renesas e6860000.ufs: link startup failed -67
ufshcd-renesas e6860000.ufs: error -ENOLINK: Initialization failed with error -67
ufshcd-renesas e6860000.ufs: probe with driver ufshcd-renesas failed with error -67
R-Car S4 has one UFS lane per direction, as described in section 152.1 of
its hardware manual. Without lanes-per-direction, the UFS platform driver
defaults to two lanes.
Previously, the core used PA_CONNECTEDRXDATALANES and
PA_CONNECTEDTXDATALANES to configure the link without checking them against
lanes-per-direction, so the missing property did not prevent
initialization.
While fixing the R-Car S4 DTS is the proper solution, doing only that would
still break backwards compatibility with existing DTBs. Hence add a quirk
to let lanes-per-direction default to one on R-Car S4.
Fixes: e72323f3b09f9c89 ("scsi: ufs: core: Configure only active lanes during link")
Reported-by: Koichiro Den <den@valinux.co.jp>
Closes: https://lore.kernel.org/20260911073058.253000-1-den@valinux.co.jp
Cc: stable@vger.kernel.org # 7.2+
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/ae0cc2bd764e6dfffce99db3d8b44a55887c508c.1789394185.git.geert+renesas@glider.be
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Commit 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()")
switched UFS internal commands to allocate requests on
hba->host->pseudo_sdev->request_queue, which shares the host tagset with
regular LUNs.
During error recovery, ufshcd_err_handling_prepare() calls
blk_mq_quiesce_tagset(&hba->host->tag_set), marking all queues in the
tagset as quiesced, including pseudo_sdev->request_queue. When
ufshcd_verify_dev_init() subsequently issues internal commands (e.g. NOP
OUT UPIU) via blk_execute_rq(), blk_mq_run_hw_queue() skips running the
quiesced queue, resulting in an unrecoverable circular wait deadlock.
Keep quiescing the tagset and unquiesce the pseudo SCSI device on top of
that, so internal commands stay dispatchable while the logical units remain
quiesced. Re-quiesce the pseudo device before unquiescing the tagset so
that quiesce_depth stays balanced.
Clock scaling and ufshcd_pause_command_processing() are unaffected: they
keep quiescing the whole tagset, internal commands included.
Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/6f78c4bd-a70b-402d-abfd-599091b67674@acm.org/
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260912131625.2301486-1-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
ufs_qcom_enable_lane_clks() and ufs_qcom_disable_lane_clks() currently
use clk_bulk_prepare_enable()/clk_bulk_disable_unprepare() on the entire
host->clks array obtained from devm_clk_bulk_get_all(). This array
contains all device clocks, not just lane symbol clocks.
Since the UFS core framework already manages the non-lane clocks via the
setup_clocks callback, the bulk enable/disable in the lane clock APIs
resulted in duplicate reference count increments on those shared
clocks. The extra enable counts were never balanced by a corresponding
disable from the framework's clock gating path, preventing the clock
reference counts from reaching zero and ultimately blocking CXO shutdown
during low-power states.
Fix this by restricting the lane clock APIs to only prepare/enable and
disable/unprepare the three lane symbol clocks (tx_lane0_sync_clk,
rx_lane0_sync_clk, rx_lane1_sync_clk), leaving the handling of all other
clocks to the UFS core framework. The lane clocks are now acquired
individually via devm_clk_get() instead of being looked up in the bulk
clock array.
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260909053944.2827968-1-nitin.rawat@oss.qualcomm.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
it in ufshcd"
Bean Huo <beanhuo@iokpp.de> says:
The devfreq core has three users of the optional ->get_cur_freq()
callback. Two of them check the return value, the third one does not
and passes an uninitialized frequency to the transition notifiers when
the callback fails. Patch 1 fixes that.
Patch 2 writes down what a driver is expected to return from the
callback. Today this has to be found by reading the devfreq core.
Patch 3 records the frequency the controller starts at.
ufshcd_init_clocks() puts the controller at its highest frequency, but
nothing writes that down, so clk_scaling.target_freq stays 0 and
devfreq starts with previous_freq at 0 as well. With use_pm_opp this
makes ufshcd_devfreq_get_dev_status() report 0 Hz, the ondemand
governor then asks for the maximum frequency, and
ufshcd_devfreq_target() runs a full ufshcd_devfreq_scale() that holds
up the queue for up to a second only to set the same OPP and the same
gear again.
Patch 4 adds the ->get_cur_freq() callback to ufshcd. Without it the
cur_freq attribute shows the last frequency the governor selected,
which is wrong whenever the controller is scaled outside the governor,
for example after writing 0 to clkscale_enable.
The patches touch two subsystems. Patches 1 and 2 are for the devfreq
tree, patches 3 and 4 are for the SCSI tree. The two halves are
independent, at build time and at run time, and can be applied in
either order.
Patch was tested on a Radxa Dragon Q6A (1d84000.ufshc):
before "echo 0 > clkscale_enable": cur_freq 75000000, target_freq 75000000
after "echo 0 > clkscale_enable": cur_freq 300000000, target_freq 75000000
Without it both files report 75000000 and keep doing so for as long as
clock scaling stays disabled. A 4 GiB direct read after enabling clock
scaling again counted the transitions in trans_stat and attributed
time to the 300000000 state, so the frequency the callback returns is
one that devfreq recognises.
One thing to be aware of: devfreq_monitor_resume() copies
previous_freq from the callback, but it does not call
devfreq_update_status(). A frequency change made while the governor
was suspended therefore does not show up as a transition. That is how
devfreq behaves today and this series does not change it.
Link: https://patch.msgid.link/20260907192140.2701755-1-beanhuo@iokpp.de
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
When a driver does not provide a ->get_cur_freq() callback, the cur_freq
sysfs attribute shows devfreq->previous_freq, which only tracks the scaling
that the governor itself did.
The UFS controller is also scaled outside the governor. The clearest
example is writing 0 to clkscale_enable: ufshcd_clkscale_enable_store()
sets the clocks to max_freq through ufshcd_devfreq_scale() and suspends the
governor, so devfreq_set_target() is never called. After that, cur_freq
keeps showing the last frequency the governor chose instead of the one the
controller runs at, and it does so as long as clock scaling stays disabled.
Add ufshcd_devfreq_get_cur_freq(). It reports clk_scaling.target_freq when
OPPs are used and the first clock's curr_freq otherwise, the same values
that ufshcd_devfreq_get_dev_status() reports.
Signed-off-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@sandisk.com>
Reviewed-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20260907192140.2701755-5-beanhuo@iokpp.de
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
ufshcd_init_clocks() puts the controller at its highest frequency, but
nothing writes that down. clk_scaling.target_freq stays 0, and
devfreq_dev_profile.initial_freq is never set, so devfreq->previous_freq is
0 as well.
With use_pm_opp this shows up in a few places. The target_freq attribute
reads 0 until the governor scales for the first time.
ufshcd_devfreq_get_dev_status() reports 0 Hz, which makes the ondemand
governor ask for the maximum frequency. ufshcd_devfreq_target() then
sees 0 != max and runs a full ufshcd_devfreq_scale(), which holds up the
queue for up to a second only to set the same OPP and the same gear
again. Without OPPs the frequency is not reported as 0, but
previous_freq is, and devfreq_update_status() then drops the first
time_in_state update.
Record the maximum frequency in ufshcd_devfreq_init() instead.
ufshcd_add_lus() runs after ufshcd_probe_hba() has geared up to
hba->max_pwr_info.info, so the clocks and the gear are both at their
maximum by the time we get here. The only difference is that the first
governor poll no longer redoes work that is already done. From the second
poll on nothing changes, because target_freq held the maximum frequency
there anyway.
That first scale also re-applied the gear that
ufshcd_vops_freq_to_gear_speed() maps the maximum frequency to, so it
quietly corrected the link if the OPP table and the gear negotiated at
probe disagreed. That does not happen any more. On ufs-qcom the two cannot
disagree, because ufs_qcom_negotiate_pwr_mode() clamps the gear through
ufshcd_negotiate_pwr_params() against the same controller capability the
OPP table is written from.
clki->max_freq is the right value in both modes.
ufshcd_parse_clock_min_max_freq() fills it from the highest OPP, and
ufshcd_clkscale_enable_store() already uses it the same way.
Suggested-by: Stanley Jhu <stanleyjhu@google.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20260907192140.2701755-4-beanhuo@iokpp.de
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> says:
This series makes UFS RPMB work out of the box with an OP-TEE that
implements the standard eMMC RPMB key-derivation flow, without requiring
any fundamental changes on the OP-TEE side.
RPMB provides an authenticated, replay-protected storage area whose
security relies on a secret authentication key. In our setup that key is
never exposed to the kernel: OP-TEE derives it in the secure world from its
hardware-unique key and a device identifier (dev_id) that the RPMB core
hands down. OP-TEE's implementation targets eMMC, where dev_id is the
16-byte eMMC CID, and both the fixed length and the raw-CID layout are
baked into its key derivation.
Two things stand in the way of reusing that same, unmodified OP-TEE flow
for UFS RPMB:
1. On a cold boot the very first frame sent to the RPMB well-known LU
comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI
core reports rather than retries. RPMB has no earlier guaranteed
access that could clear the condition first, so RPMB fails on every
power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT
ATTENTION on the RPMB WLUN.
2. The UFS RPMB id is "<device_id>-R<region>", which is variable length
and longer than 16 bytes. Passing it verbatim would tie the derived
key to a length OP-TEE does not expect and diverge from the fixed eMMC
CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with blake2b,
keeping the key stable and unique per region while matching the eMMC
CID layout OP-TEE relies on. The hash algorithm and input string are
thus part of the key-derivation ABI and must stay stable.
With both patches, UFS RPMB is functional from the first access after a
cold boot and derives keys through the existing eMMC-style OP-TEE flow,
(requires minimal OP-TEE changes pending on the CID proposal done here).
Tested on IQ-9075 with Open Firmware [1], pending OP-TEE changes
[1]https://ldts.github.io/qcom-buildroot
Dependencies:
U-boot:
https://lore.kernel.org/u-boot/20260720085202.537019-1-jorge.ramirez@oss.qualcomm.com/T/#mc423eb4dcf8a15849077029e4f7c1913bb7d8873
OP-TEE:
https://github.com/OP-TEE/optee_os/pull/7881
Link: https://patch.msgid.link/20260831154804.719528-1-jorge.ramirez@oss.qualcomm.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The RPMB authentication key is derived from the dev_id handed to the RPMB
subsystem. OP-TEE implements the eMMC RPMB flow, where the dev_id is the
eMMC CID: a fixed 16-byte value the key derivation depends on.
The UFS RPMB id is "<device_id>-R<region>", which is variable length and
longer than 16 bytes. Handing it to the RPMB subsystem as-is would tie the
derived key to a length OP-TEE does not expect and diverge from the
fixed-CID eMMC ABI, forcing OP-TEE to be taught about variable-length UFS
ids.
A fixed 16-byte dev_id is needed so the derived key stays stable and unique
per region while matching the eMMC CID layout OP-TEE relies on, keeping the
key-derivation ABI identical with no OP-TEE change. The reduction to a
fixed 16 bytes must also be reproducible by the bootloaders (such as
U-Boot) that derive the same dev_id.
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20260831154804.719528-3-jorge.ramirez@oss.qualcomm.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
After a power cycle, the first command sent to any UFS logical unit
completes with CHECK CONDITION reporting a power-on UNIT ATTENTION. The
SCSI core surfaces this condition to the caller rather than retrying it.
For the RPMB well-known LU the first command after boot is the first RPMB
frame, and RPMB has no earlier, guaranteed access that could clear the
condition beforehand. The power-on UNIT ATTENTION therefore reaches RPMB
and fails that first frame, breaking RPMB on every cold boot.
The RPMB WLUN needs the power-on UNIT ATTENTION to be retried so that RPMB
works from the very first access after a power cycle.
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20260831154804.719528-2-jorge.ramirez@oss.qualcomm.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull kmalloc_obj conversions from Kees Cook:
"Another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules
in scripts/coccinelle/api/kmalloc_objs.cocci"
* tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
treewide: refresh kmalloc_obj() conversions
drm/amd/display: Fix harmless type mismatch in allocation
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
Back in the 2.6.xx days, it was possible to for low-level drivers to set
the shost lock pointer. That is why there is a default lock and a
pointer to the shost lock.
However, support for this has long been removed, so drop
Scsi_Host.default_lock and make Scsi_Host.host_lock as the actual lock.
Getting the address of embedded host_lock structure just requires adding
a fixed offset value to the shost pointer. However, getting the value of
the host_lock pointer requires loading from a fixed offset to the shost
pointer. The latter should be very slightly slower, which is relevant as
this lock is used a lot throughout the core code and drivers.
Signed-off-by: John Garry <john.garry@linux.dev>
Acked-by: Damien Le Moal <dlemoal@kernel.org> # ata parts
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260831095821.3486994-1-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Pull in outstanding fixes queued for 7.3.
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Pull more SCSI updates from Martin Petersen:
"Remaining updates for the 7.3 merge window. The only core change is
enabling context analysis for the SCSI layer and UFS.
The remaining changes are either bug fixes or hardening"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi: (26 commits)
scsi: snic: Fix SCSI host leak on workqueue allocation failure
scsi: MAINTAINERS: Update my email address
scsi: MAINTAINERS: Leave the cumana_1 and oak drivers to the RISCPC maintainers
scsi: leapraid: Standardize NCQ priority sysfs attributes
scsi: leapraid: Serialize firmware log mmap with teardown
scsi: leapraid: Balance host references for firmware log VMAs
scsi: lpfc: Remove unnnecessary NULL check
scsi: qla2xxx: Fix an loop timeout test
scsi: qla2xxx: Fix an error code in qla_get_tmf()
scsi: ibmvfc: Fix use of uninitialized rport in ibmvfc_do_work()
scsi: core: Enable context analysis for hosts.o
scsi: lpfc: Replace strlcat() with sysfs_emit_at() in the sysfs show functions
scsi: lpfc: Replace strlcat() with seq_buf in the debugfs dump helpers
scsi: lpfc: Replace strlcat() with seq_buf in lpfc_rx_monitor_report()
scsi: lpfc: Replace strlcat() with scnprintf() in lpfc_vport_symbolic_node_name()
scsi: lpfc: Replace strlcat() with seq_buf in lpfc_info()
scsi: core: Enable context analysis
scsi: core: Protect host state changes with the host lock
scsi: core: Add lock context annotations
scsi: core: Pass the SCSI host pointer directly to scanning functions
...
|
|
The Intel UFS 4.0 PCI variant (PCI ID 8086:D335) advertises MCQ support
in its capability register. However, ufshcd_alloc_mcq() also requires an
.op_runtime_config hook to locate the per-queue operation and runtime
(OPR) register blocks, which was not provided by this variant operations
table.
As a result, MCQ initialization fails and ufshcd_add_scsi_host() prints
"MCQ mode is disabled, err=%d\n" before falling back to legacy
single-doorbell (SDB) mode.
Add ufs_intel_mcq_config_resource() to initialize the MCQ configuration
base and add ufs_intel_op_runtime_config() to set up the OPR register
offsets and stride.
Wire both hooks into the variant operations table so MCQ is enabled when
supported by the hardware.
Fixes: 096cd6b7adf2 ("scsi: ufs: ufs-pci: Add support for Intel Nova Lake")
Signed-off-by: sangram kumar yerra <sangram.k.y@intel.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260818112830.453402-3-sangram.k.y@intel.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Reliable HS-Gear5 operation on Intel UFS 4.0 controllers requires
configuring PA_INITIAL_ADAPT before changing the power mode. Without
this setting, the link fails to train reliably at Gear5.
Add a pwr_change_notify() hook to configure the adaptation mode before
the power mode transition. Enable this only for UFS 4.0 and later
controllers by checking hba->ufs_version.
Wire the hook into the existing Meteor Lake family variant operations
table (ufs_intel_mtl_hba_vops) instead of introducing a separate table,
since the Intel UFS 4.0 PCI variant (PCI ID 8086:D335) already uses this
vops table and the hook is internally gated on UFS version >= 4.0.
Use PA_INITIAL_ADAPT when the negotiated TX power mode is FAST_MODE or
FASTAUTO_MODE. Otherwise, reset the adaptation mode to PA_NO_ADAPT,
which is the default setting.
Fixes: 096cd6b7adf2 ("scsi: ufs: ufs-pci: Add support for Intel Nova Lake")
Signed-off-by: sangram kumar yerra <sangram.k.y@intel.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260818112830.453402-2-sangram.k.y@intel.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The current devfreq downdifferential threshold of 5% causes overly
aggressive frequency downscaling, leading to performance degradation
sometimes during sequential read workloads.
Update the UFS devfreq downdifferential threshold to 65. This widens
the hysteresis window and prevents overly aggressive downscaling,
ensuring that frequency is maintained for loads above 5% and scaling
down occurs only when utilization falls below this level, while scale-up
still triggers above the 70% threshold.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Link: https://patch.msgid.link/20260825145203.265579-3-nitin.rawat@oss.qualcomm.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
controller v6.2+
The link startup mode (HS LSS - high-speed link startup, or LS LSS -
low-speed link startup) is decided in the boot stage based on the
bootconfig GPIO. This selection is carried forward through the secondary
stage bootloaders and finally to HLOS via the spare configuration
register (REG_UFS_DEBUG_SPARE_CFG).
On Qualcomm UFS controller v6.2 and later, bit 31 in the spare
configuration register indicates the high-speed link startup mode
selection, as per the Hardware Programming Guide (HPG).
The spare register value is read during host driver initialization but
gets cleared after UFS reset. Preserve the spare register value during
initialization and restore it during link startup to maintain the
bootloader-configured link startup mode.
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://patch.msgid.link/20260825145203.265579-2-nitin.rawat@oss.qualcomm.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Nothing in suspend.h needs swap.h. However, many files indirectly
depend on some of swap.h's dependencies, so this is a large
cross-subsystem patch. Stats:
42 are missing includes of interrupt.h (the question of why swap.h
brings in interrupt.h remains unanswered).
10 missing includes of seq_file.h
5 missing includes of swap.h (obviously all files could have just added
swap.h, but I preferred to bring in a more minimal inclusion set)
3 missing includes of highmem.h
2 missing includes of device.h
2 missing includes of string_choices.h
1 missing include of cacheflush.h
1 missing include of dma-direction.h
1 missing include of kthread.h
1 missing include of pagemap.h
1 missing include of string_helpers.h
1 missing include of writeback.h
I tried to follow whatever conventions appeared to be in use for the
various subsystems I touched; for example I added string_choices.h to
drm_print.h instead of individually to each driver which used the
functions declared there.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
|
|
Pull SCSI updates from James Bottomley:
"One new driver: leapraid (similar to mpi3mr but OK'd by Broadcom). The
usual suspects for driver updates (ufs, qla2xxx, smartpqi, zfcp, fnic,
ibmvfc) plus a few small core updates: a fix for an uninitialized sg
list pad bytes plus the removal of the dma mask check for max sectors.
The big update in the sd driver is mostly code refactoring for obscure
error leg handling"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (195 commits)
scsi: fnic: Fix built-in NVMe/FC build
scsi: fnic: Fix invalid comparison for error
scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()
scsi: zfcp: Enable CONTEXT_ANALYSIS
scsi: zfcp: Add __must_hold() attribute to zfcp_qdio_sbal_get()
scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock
scsi: storvsc: Support manual scans for all Hyper-V targets
scsi: sd: Fix sd_done() sense handling condition
scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails
scsi: sd: Fix error handling in sd_probe() after large pool creation failure
scsi: leapraid: Add driver documentation
scsi: leapraid: Add new SCSI driver
scsi: ufs: Add support for the aggregated read query opcode
scsi: ufs: Use unsigned types for the BSG query
scsi: ibmvfc: Fix spelling mistake "Deleteing" -> "Deleting"
scsi: qla2xxx: Update version to 12.00.00.2607b2
scsi: qla2xxx: Bound i2c->length in I2C bsg handlers
scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers
scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[]
scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak
...
|
|
Annotate functions that modify the state of a synchronization object.
Remove the struct semaphore annotations because lock context annotations
are not supported for semaphores.
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/3c975386a5bcb939f8a2a0d47fd621f234321a9e.1786142946.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Set the task state to TASK_UNINTERRUPTIBLE before calling
io_schedule_timeout() in ufshcd_wait_for_pending_cmds(). Without
setting the task state, io_schedule_timeout() returns immediately
because the task state remains TASK_RUNNING. This results in a busy loop
that wastes CPU cycles.
Fixes: 2000bc309703 ("scsi: ufs: core: Reduce the clock scaling latency")
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/8fe4526ce272811b28e99048b42358dd8f7c48af.1786142946.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Hyeoncheol Jeong <hyenc.jeong@samsung.com> says:
UFS 5.0 / JEDEC 220H introduces the AGGREGATED READ query opcode
(0x9), which retrieves an aggregated data packet bundling multiple
Descriptors, Attributes and Flags in a single QUERY RESPONSE
UPIU. Such a packet can be far larger than a single descriptor, so the
reserved (device management) tag gets a dedicated UCD with an enlarged
response area.
Patch 1 is a preparatory cleanup that switches the BSG query
descriptor length to unsigned types. Patch 2 adds the aggregated read
support.
v3: https://lore.kernel.org/linux-scsi/20260724030812epcms2p4eb2c77cb4dcd5fd51ca9c3eaa5ea4bfa@epcms2p4/
v2: https://lore.kernel.org/linux-scsi/20260722084819epcms2p49c27fce999e821385f7b5d7ea5a02868@epcms2p4/
Link: https://patch.msgid.link/20260728092208epcms2p881b17276fb41c006a4229c1d073b4ad0@epcms2p8
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
UFS 5.0 / JEDEC 220H introduces the AGGREGATED READ query opcode (0x9),
which retrieves an aggregated data packet in a single query request. The
packet may bundle multiple Descriptors, Attributes and Flags as
group-headed groups, returned in the Data Segment of the QUERY RESPONSE
UPIU.
Such a packet can be far larger than a single descriptor (up to a few
KiB vs the 255-byte descriptor limit), so its response UPIU buffer must
be enlarged. Enlarging the shared utp_transfer_cmd_desc would waste that
extra space per tag, so add a dedicated utp_devman_cmd_desc with a 4 KiB
response area (ALIGNED_DEVMAN_RSP_SIZE), allocated once for the reserved
(device management) tag that aggregated read uses. Regular tags keep the
512-byte descriptor in a pool of (nutrs - UFSHCD_NUM_RESERVED) entries,
leaving normal I/O unchanged.
ufshcd_init_lrb() and ufshcd_host_memory_configure() pick the devman
descriptor for the reserved tag and index the pool at (tag -
UFSHCD_NUM_RESERVED) otherwise. The pre-4.1 MCQ tag recovery adds one
compare against the devman UCD address and returns the reserved tag
(UFSHCI 4.1+ carries the tag in the CQE), and the BSG raw-UPIU and
device management paths learn the new opcode, sizing descriptors by
QUERY_AGGREGATED_MAX_SIZE.
Signed-off-by: Hyeoncheol Jeong <hyenc.jeong@samsung.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260728092741epcms2p8c53432ef3c2f0d6a63dd980ad5ef9f00@epcms2p8
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The UPIU query length field is an unsigned 16-bit value per the UFS
standard, but ufs_bsg carried it around in signed int. Switch the
descriptor length and buffer pointer to u16/u8, fold the trivial
ufs_bsg_get_query_desc_size() helper into its only caller, and replace
min_t(int, ...) with min(). No functional change intended.
Signed-off-by: Hyeoncheol Jeong <hyenc.jeong@samsung.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260728092434epcms2p56b013ab7a2df90d3df9186322de54340@epcms2p5
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
shost->eh_noresume is currently consulted twice in one error handling
iteration: once before scsi_autopm_get_host() and once again before
scsi_autopm_put_host().
That is racy when a PM-triggered error path flips shost->eh_noresume
while the SCSI EH thread is still running.
The problem flow looks like this:
PM path
ufshcd_set_dev_pwr_mode()
shost->eh_noresume = 1
ufshcd_execute_start_stop <-- trigger EH
...
shost->eh_noresume = 0
EH path
scsi_error_handler()
if (!shost->eh_noresume)
scsi_autopm_get_host() <-- skipped
...
if (!shost->eh_noresume)
scsi_autopm_put_host() <-- executed later
In that case one EH iteration can skip autoresume on entry and still
drop a runtime PM reference on exit. That leaves an unmatched runtime PM
put and can trigger a runtime PM usage count underflow.
Fix this by making eh_noresume a regular bool so it can be accessed with
READ_ONCE() and WRITE_ONCE(). Snapshot it once per EH iteration and use
that snapshot for both runtime PM get and put decisions.
Fixes: ae0751ffc77e ("[SCSI] add flag to skip the runtime PM calls on the host")
Signed-off-by: Hongjie Fang <hongjiefang@asrmicro.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/20260729111614.2407559-1-hongjiefang@asrmicro.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
