kernel/git/next/linux-next.git/drivers/ufs, branch master

Merge branch 'headers' of git://git.infradead.org/users/willy/pagecache.git

2026-09-11T15:17:01+00:00

# Conflicts: # net/ceph/osd_client.c

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git

2026-09-11T15:00:53+00:00

scsi: ufs: ufs-qcom: Enable only lane clocks in lane clock APIs

2026-09-10T02:30:27+00:00

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 Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260909053944.2827968-1-nitin.rawat@oss.qualcomm.com Signed-off-by: Martin K. Petersen (Oracle)

Merge patch series "devfreq: check the get_cur_freq() return value and use it in ufshcd"

2026-09-10T02:28:06+00:00

Bean Huo 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)

scsi: ufs: core: Report the current clock frequency to devfreq

2026-09-10T02:26:51+00:00

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 Reviewed-by: Avri Altman Reviewed-by: Stanley Jhu Link: https://patch.msgid.link/20260907192140.2701755-5-beanhuo@iokpp.de Signed-off-by: Martin K. Petersen (Oracle)

scsi: ufs: core: Record the frequency the controller starts at

2026-09-10T02:26:51+00:00

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 Signed-off-by: Bean Huo Reviewed-by: Stanley Jhu Link: https://patch.msgid.link/20260907192140.2701755-4-beanhuo@iokpp.de Signed-off-by: Martin K. Petersen (Oracle)

Merge patch series "ufs: rpmb: make RPMB usable with OP-TEE key derivation"

2026-09-10T01:54:19+00:00

Jorge Ramirez-Ortiz 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 "-R", 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)

scsi: ufs: rpmb: Use a fixed-length RPMB dev_id

2026-09-10T01:53:11+00:00

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 "-R", 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 Reviewed-by: Bean Huo Reviewed-by: Stanley Jhu Link: https://patch.msgid.link/20260831154804.719528-3-jorge.ramirez@oss.qualcomm.com Signed-off-by: Martin K. Petersen (Oracle)

scsi: ufs: rpmb: Retry power-on UNIT ATTENTION on the RPMB WLUN

2026-09-10T01:53:11+00:00

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 Reviewed-by: Bean Huo Reviewed-by: Stanley Jhu Link: https://patch.msgid.link/20260831154804.719528-2-jorge.ramirez@oss.qualcomm.com Signed-off-by: Martin K. Petersen (Oracle)

Merge tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2026-09-06T03:45:18+00:00

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