| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The firmware ID is treated as a NUL-terminated string even though the
TLV length is its only boundary. If the value does not contain a NUL
terminator, snprintf() can read beyond the received response.
Limit the conversion to the advertised TLV value length.
Fixes: 164c62f958f8 ("Bluetooth: btintel: Add firmware ID to firmware name")
Reviewed-by: Ali Ahmet Memis <ali@iusegentoo.com>
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
Tested-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btintel_parse_version_tlv() verifies that a complete TLV is present in
the response, but it does not ensure that the value is long enough for
the specific TLV type. A short value can therefore cause an
out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(),
or memcpy().
Reject values shorter than the minimum required by each known TLV type.
Also reject responses that do not contain the Command Complete Status
field.
Fixes: 57375beef71a ("Bluetooth: btintel: Add infrastructure to read controller information")
Reviewed-by: Ali Ahmet Memis <ali@iusegentoo.com>
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
Tested-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
On spurious interrupt where the TX and RX causes are not set, driver was
not clearing the auto mask which can block all the interrupts. Driver
needs to clear the automask even if no causes are set.
Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport")
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
In qcom_pas_stop function, return value of qcom_pas_shutdown for pas_id
is overwritten by the return value of qcom_pas_shutdown for dtb_pas_id.
This causes errors seen on qcom_pas_shutdown failures for pas_id to be
masked to the caller. This might lead to issues where the memory regions
locked by PAS, as part of qcom_pas_auth_and_reset, are not released for
access by linux and rproc_coredump flow will end up accessing the locked
memory, leading to an access violation.
Fix this by using a separate variable for the dtb_pas_id shutdown call
and only overriding the main return value if the pas_id shutdown succeeded
but dtb_pas_id shutdown failed.
Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading")
Signed-off-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260819-rproc_dtb_fix-v1-1-cb6be7f93bc9@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
When a sink detach occurs while waiting for TX send status, the old
TCPM_SOURCING_VBUS event along with TCPM_VBUS_EVENT and TCPM_CC_EVENT
can be queued in port->pd_events. Because TCPM_SOURCING_VBUS is
evaluated after TCPM_VBUS_EVENT and TCPM_CC_EVENT in
tcpm_pd_event_handler(), a stale TCPM_SOURCING_VBUS event can override
the detach handling and incorrectly set port->vbus_source and
port->vbus_present to true.
Add a state guard to check that the port is either operating as a
Source (tcpm_port_is_source(port)) or in a Fast Role Swap (FRS) state
up to FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED before processing
TCPM_SOURCING_VBUS. Otherwise, discard and log the event.
Log snippet for error condition before fix:
[72792.204955] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS]
[72792.204960] sourcing vbus
[72792.204962] VBUS on
[72792.204970] AMS POWER_NEGOTIATION start
[72792.204974] cc:=4
[72792.205319] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION]
[72792.205325] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION]
[72792.205332] PD TX, header: 0x11a1
[72792.216911] PD TX complete, status: 2
[72792.216957] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION]
[72792.218005] VBUS off
[72792.218013] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION]
[72792.218020] VBUS VSAFE0V
[72792.218024] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [rev3 POWER_NEGOTIATION]
[72792.218458] CC1: 2 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected]
[72792.218467] VBUS on --> VBUS left on
[72792.218980] disable vbus discharge ret:0
[72792.235193] Start toggling
After fix:
[ 1195.291691] state change SRC_ATTACHED -> SRC_STARTUP [rev3 NONE_AMS]
[ 1195.291698] sourcing vbus
[ 1195.291700] VBUS on
[ 1195.291707] AMS POWER_NEGOTIATION start
[ 1195.291710] cc:=4
[ 1195.291758] state change SRC_STARTUP -> AMS_START [rev3 POWER_NEGOTIATION]
[ 1195.291794] state change AMS_START -> SRC_SEND_CAPABILITIES [rev3 POWER_NEGOTIATION]
[ 1195.291798] PD TX, header: 0x11a1
[ 1195.297056] PD TX complete, status: 2
[ 1195.297092] pending state change SRC_SEND_CAPABILITIES -> SRC_SEND_CAPABILITIES @ 150 ms [rev3 POWER_NEGOTIATION]
[ 1195.297177] VBUS off
[ 1195.297184] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION]
[ 1195.297227] CC1: 2 -> 0, CC2: 0 -> 0 [state SRC_SEND_CAPABILITIES, polarity 0, disconnected]
[ 1195.307469] cc:=2
[ 1195.307544] pending state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED @ 650 ms [rev3 POWER_NEGOTIATION]
[ 1195.307555] Discarding sourcing vbus! Invalid state SRC_SEND_CAPABILITIES
[ 1195.957636] state change SRC_SEND_CAPABILITIES -> SNK_UNATTACHED [delayed 650 ms]
[ 1195.957732] disable vbus discharge ret:0
[ 1195.970196] Start toggling
[ 1195.970468] VBUS off
[ 1196.051637] VBUS off
[ 1196.051642] VBUS VSAFE0V
Fixes: 8dc4bd073663 ("usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)")
Cc: stable <stable@kernel.org>
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260827-sourcing-vbus-v1-1-9be1aca991a0@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
During adsp_map_carveout, the IOVA is computed by combining the
physical address and the SID:
iova = adsp->mem_phys | (sid << 32);
However, adsp_unmap_carveout() uses the physical address and not
the IOVA in iommu_unmap(), causing the unmap to fail or leak
mappings because the address doesn't match the original IOVA.
Cache the constructed IOVA within the qcom_adsp device struct
during mapping and use it during unmapping.
Fixes: f22eedff28af ("remoteproc: qcom: Add support for memory sandbox")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Link: https://lore.kernel.org/r/20260827203055.640116-1-smostafa@google.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Commit f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS
TZ APIs") changed the probe-time gate for need_mem_protection platforms
from qcom_scm_is_available() to qcom_pas_is_available(). Memory
protection in this driver is implemented with qcom_scm_assign_mem(),
which is a TZ service distinct from PAS. The only PAS call in the driver
is qcom_pas_mem_setup(), and it is already guarded by need_pas_mem_setup.
No descriptor sets both flags: sc7180, sc7280, sdm660, sdm845, msm8996
and msm8998 set need_mem_protection only, while msm8937, msm8940 and
msm8953 set need_pas_mem_setup only. On TrustZone firmware that does not
implement PAS - for example SC7180 Chromebooks, where call-availability
queries report every QCOM_SCM_SVC_PIL command as unavailable - the modem
consequently never probes:
platform 4080000.remoteproc: deferred probe pending: (reason unknown)
On those machines the modem is also what loads the WLAN firmware, so
ath10k never receives QMI and wifi does not come up either.
Gate memory protection on SCM availability as it was before, and require
PAS only where a PAS call is actually issued. Keeping the SCM check
matters: qcom_scm_assign_mem() passes __scm->mempool to
qcom_tzmem_alloc() without testing __scm, so dropping the gate entirely
would allow a NULL dereference when qcom_scm has not yet probed.
Fixes: f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs")
Link: https://lore.kernel.org/r/20260808034716.58888-1-phollinsky@holtechnik.com
Signed-off-by: Paul Hollinsky <phollinsky@holtechnik.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260821081540.89137-1-phollinsky@holtechnik.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
qcom_pas_attach() unmasks the handover IRQ and marks handover_issued
even though this driver instance never runs qcom_q6v5_prepare() for
the boot it is attaching to. This was believed necessary to flush a
stale interrupt latched at the interrupt controller while masked, but
the handover IRQ is a Qualcomm SMP2P soft IRQ, not a real edge-latched
hardware interrupt. The Linux SMP2P driver updates its cached value
unconditionally on every notification and only delivers the nested IRQ
for bits currently enabled in its own software bitmap, so a transition
that happens while masked is simply dropped, never replayed on a later
unmask.
Since there is nothing to flush, and this driver instance never takes
the proxy power-domain/clock/regulator votes that the handover
callback would tear down, there is no need to unmask the IRQ in
attach() at all. Drop the enable_irq()/disable_irq() pair; setting
handover_issued = true is sufficient to keep the flag consistent for
the eventual qcom_q6v5_unprepare()/qcom_q6v5_prepare() cycle.
It fixes the following unbalanced runtime PM usage and IRQ enable
warnings seen on Nord ADSP (probed as attached), after commit bb7c5d6f5b41
("remoteproc: qcom: q6v5: Make handover IRQ one-shot") comes in place.
root@iq10-rrd:~# cat /sys/class/remoteproc/remoteproc0/state
attached
root@iq10-rrd:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[ 40.004874] genpd genpd:0:4c00000.remoteproc: Runtime PM usage count underflow!
[ 40.012409] genpd genpd:1:4c00000.remoteproc: Runtime PM usage count underflow!
[ 40.050074] remoteproc remoteproc0: stopped remote processor adsp
root@iq10-rrd:~# echo start > /sys/class/remoteproc/remoteproc0/state
[ 44.350298] remoteproc remoteproc0: powering up adsp
[ 44.375769] remoteproc remoteproc0: Booting fw image qcom/nord/adsp.mbn, size 8241816
[ 44.389850] PDM: no support for the platform, userspace daemon might be required.
[ 44.397864] ------------[ cut here ]------------
[ 44.402633] Unbalanced enable for IRQ 363
[ 44.406779] WARNING: kernel/irq/manage.c:775 at __enable_irq+0x4c/0x7c, CPU#9: sh/791
...
Suggested-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260801011731.1084591-1-shengchao.guo@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Pull in outstanding fixes queued for 7.3.
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The length information in the reply is used to copy the key token to
the target buffer. An invalid information in t->len of the reply may
cause an over-read of the target buffer and also a over-write of the
target buffer. To prevent that, check t->len before using it.
As the available space in destination and source buffer is always
larger than the valid length value in the parameter block in the
reply, compare t->len with this (already validated) length
information. As a side effect, this check also prevents buffer
over-read and over-write.
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
Updating drm-misc-fixes to the state of v7.2.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
|
The UCSI displayport driver indexes the connector's port altmode array
with the GET_CURRENT_CAM response after checking it is not 0xff. The
port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM
returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and
not equal to 0xff, the kernel may crash with an array index OOB error.
Update the UCSI displayport driver to verify the current cam is less
than UCSI_MAX_ALTMODES before accessing the port altmode array.
Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Cc: stable@vger.kernel.org
Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Link: https://patch.msgid.link/20260825234545.2076049-1-jthies@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
At the conversion to the faux driver/device we broke the support for probe
deferral. In hindsight, the move to the faux device seems questionable, as
it simply makes the code more complicated and for no good reason.
To fix the support for the probe deferral let's therefore restore the old
code and drop the faux device.
Fixes: af5376a77e87 ("cpuidle: psci: Transition to the faux device interface")
Fixes: 5836ebeb4a2b ("cpuidle: psci: Avoid initializing faux device if no DT idle states are present")
Fixes: 39cdf87a97fd ("cpuidle: psci: Fix uninitialized variable in dt_idle_state_present()")
Cc: stable@vger.kernel.org
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
pci_match_device() can return the dummy pci_device_id_any entry
when a device is force-bound via sysfs driver_override, in which
case ->driver_data is unset (NULL). i915_pci_probe() casts it to
struct intel_device_info * unconditionally and dereferences
intel_info->require_force_probe, causing a NULL-ptr-deref.
Reported-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=db96c5ff032f4292a8dc
Tested-by: syzbot+db96c5ff032f4292a8dc@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Link: https://patch.msgid.link/20260813064902.367504-1-kartikey406@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
dg2_power_well_count() is supposed to return an integer,
not a boolean. Make it so.
Fixes: 9112ce99c1d7 ("drm/i915/cdclk: Extract dg2_power_well_count()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826143100.19401-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit dcf423710d0253d7d729c3992bbae0c6197c9c22)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Apparently PTL+ no longer has the cd2x pipe select field in
CDCLK_CTL. Take that into account during CDCLK sanitization.
This currently triggers a spurious CDCLK sanitization during
driver load on PTL+ which will causes a visible glitch on all
active displays.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8550
Fixes: 2ee8dbd880b1 ("drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260717155107.17801-1-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
(cherry picked from commit 1786d26887817a779641d3a093c66ac91382113b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
icl_plane_disable_sel_fetch_arm() wrote SEL_FETCH_PLANE_CTL = 0 only when
crtc_state->enable_psr2_sel_fetch was set. If a plane was disabled after
selective fetch had been turned off, the guard fired early and left the
register's enable bit set in hardware.
The bit is harmless until selective fetch is re-enabled. When it is, the
hardware resumes fetching for the now-disabled plane and keeps its old DDB
range reserved.
i9xx_cursor_disable_sel_fetch_arm() has the same guard on SEL_FETCH_CUR_CTL
and is fixed the same way.
v2: Add same check for cursor also. [sashiko]
Cc: stable@vger.kernel.org
Fixes: b1f5279b5981 ("drm/i915/psr: Move plane sel fetch configuration into plane source files")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739
Assisted-by: GitHub-Copilot:claude-opus-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260818095149.2172935-1-nemesa.garg@intel.com
(cherry picked from commit 600a7c9d40e5e0c5544f42d1c9592c8d15224dc0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the
symbol clock computed assuming 8b/10b encoding (link_rate / 10). For
DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to
be modified.
DDI_CLK_VALFREQ does not have any functional impact on H/w, it
only records the frequency S/w intends to set.
Use intel_ddi_link_symbol_clock() to write the correct DDI clock in
kHz
Fixes: 5ec58d714935 ("drm/i915/lt_phy: Add .enable_clock hook on DDI")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-4-suraj.kandpal@intel.com
(cherry picked from commit eaed815ca3483c227e4ec80b86d1b3ce5c2508be)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the
symbol clock computed assuming 8b/10b encoding (link_rate / 10). For
DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to
be modfied.
DDI_CLK_VALFREQ does not have any functional impact on H/w, it
only records the frequency S/w intends to set.
Use intel_ddi_link_symbol_clock() to write the correct DDI clock in
kHz.
Fixes: 51390cc0e00a ("drm/i915/mtl: Add Support for C10 PHY message bus and pll programming")
Fixes: 73fc3abcb797 ("drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-3-suraj.kandpal@intel.com
(cherry picked from commit 9ac3ee6c0f92cd09893bd442964fb6b0d6813b5e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add intel_ddi_link_symbol_clock() to return the DDI clock frequency for
a given port clock:
DP 8b/10b : rate
DP 128b/132b (UHBR) : (10 / 32) * rate
HDMI FRL : (10 / 18) * rate
HDMI TMDS : rate
The DP case reuses intel_dp_link_symbol_clock().
This will help in upcoming commits to decide value to be written
in DDI_CLK_VALFREQ.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-2-suraj.kandpal@intel.com
(cherry picked from commit 5abc20e39dd074e8696387ca6871d6e432baf0cd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This reverts commit b48a0a0a76ccecec60f0568e2af4d89994b08bec, which
wrongfully added the MXC and MMCX power domains on Eliza.
Even though they are indeed available in cmd-db, which has been the source
of information for adding these two, at hardware level they are not
actually wired up. Therefore they need to be dropped.
Fixes: b48a0a0a76cc ("pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza")
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
When a TD reaches a link TRB with data that is not aligned to the
endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail
through the bounce buffer of the ring segment holding that link TRB.
xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers,
copies the data back into the URB's buffer.
The enqueue path records the segment that was bounced in td->bounce_seg,
under the assumption that a TD never spans more than two ring segments.
That assumption does not hold: a TD large enough to span three or more
segments crosses several link TRBs and can be bounced at each of them.
Only the last one survives in td->bounce_seg, so every earlier bounce
buffer is neither copied back nor DMA unmapped.
The URB still completes with actual_length equal to the requested length
and no error, so the transfer looks successful while a wMaxPacketSize
sized hole in the destination buffer silently keeps its previous
contents. It also leaks a DMA mapping per dropped bounce.
Any sufficiently large and fragmented bulk transfer can hit this. It was
found with a USB mass storage device behind xHCI backing a dm-verity
target with 512 byte hash blocks, where the stale data is detected rather
than silently consumed. The device enumerates as SuperSpeed, so
wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash
block. verity_prefetch_io() makes the block layer merge hundreds of them
into a single request of up to 512 scatterlist entries of 512 bytes each.
At 256 TRBs per ring segment such a TD spans three segments, and every
segment boundary falls on an odd multiple of 512, i.e. unaligned to
wMaxPacketSize. dm-bufio then caches a hash block holding stale data and
dm-verity declares the metadata block corrupted:
device-mapper: verity: 8:2: metadata block 10850 is corrupted
A reproducer running this under qemu is available at
https://github.com/baloo/xhci-verity
The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs)
already lives on the ring segment, so there is nothing extra to track.
Keep recording the last bounced segment in td->bounce_seg and, on
completion, walk the segments from td->start_seg up to it, unmapping
every segment that still has a pending bounce.
Stopping at td->bounce_seg rather than td->end_seg matters: a bounce
implies the TD continues past that segment's link TRB, so bounce_seg is
always strictly before end_seg, and a later TD may already have started
in end_seg and been bounced there. Walking that far would copy a foreign
bounce buffer into this URB and unmap it twice. It also keeps the walk
correct if a TD ever wraps the whole ring so that end_seg == start_seg.
[mn: Add ring->num_segs check to prevent unlikely infinite for loop.]
Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Cc: stable@vger.kernel.org
Suggested-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Arthur Gautier <baloo@superbaloo.net>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260831090448.95644-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
An isoc URB without URB_ISO_ASAP should be scheduled immediately after
the previous one, unless it's the first submission or prior URBs have
completed without resubmitting and the endpoint became idle.
An HCD_BH driver must consider URBs pending completion in the BH queue
in addition to its own queue. Regrettably, core doesn't provide much
information, we can only know if we are being called by completion now.
This issue is as old as HCD_BH, affects ehci-hcd too and has no known
reproducible impact, as drivers generally resubmit from completion.
A recent patch tried to address it by looking at xHCI HW state instead.
Obviously, HW has no knowledge of the BH giveback queue either, and the
whole solution amounts to testing whether prior URBs have been unlinked
instead of completing normally - then a new stream is assumed.
This leads to false negatives when a driver simply allows the endpoint
to empty out and begins a new stream. New URBs are scheduled into the
past and promptly fail with -EXDEV status, causing data loss and worse,
because drivers get confused by premature completion, particularly when
multiple endpoints are started at once and required to stay in sync.
snd-usb-audio underruns the OUT endpoint when userspace fails to supply
playback data in time. If this is detected in duplex mode, IN URBs are
unlinked and both streams restarted. OUT underruns again before IN even
begins, another recovery is attempted and the cycle repeats.
Fix this by using the best criteria we can muster, taken from ehci-hcd.
This brings false negative rate back to zero and false positive rate to
less than ever before in xhci-hcd. Traditional logic was equivalent to:
if (list_empty(&ep_ring->td_list) ||
GET_EP_CTX_STATE(ep_ctx) != EP_STATE_RUNNING)
// consider this URB a new stream
While free of false negatives, it had easily avoidable false positives:
* no check for completion in progress when the list is empty
* the ep_ctx check doesn't make up for it at all, but it adds a race -
EP state can remain "stopped" for a while after the first submission
[mn: add debug message in possible false positive case where driver might
incorrectly assume new stream starts mid stream just because td list is
empty (URB enqueue is late), and workqueue isn't processing URB
completions for this endpoint at the moment]
Link: https://lore.kernel.org/linux-usb/20260813005635.34750f8c.michal.pecio@gmail.com/
Fixes: add8469b3e00 ("xhci: fix frame id calculation and checks for isoc URBs")
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20260831090448.95644-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This fixes one broken line in commit 6d45e9556d4a ("usb: xhci: standardize
multi bit-field macros") included in 7.3-rc1 kernel
HCS_ERST_MAX holds power of 2 value for maximum number of segments.
In the culprit commit, this was incorrectly converted to "shift up 2".
On hardware where this field is zero, this results in xhci_alloc_erst()
calling dma_alloc_coherent() with size = 0, leading to a horrible splat
and non-usable XHCI.
Revert the shift-up-2 to the BIT() macro.
Fixes: 6d45e9556d4a ("usb: xhci: standardize multi bit-field macros")
Cc: Niklas Neronin <niklas.neronin@linux.intel.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Tested-by: Pierre-David Belanger <pierredavidbelanger@gmail.com>
Link: https://patch.msgid.link/20260831090448.95644-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
mst_stream_compute_config() called intel_pfit_compute_config() twice
in a row.
commit 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config()
for sharpness filter")
was erroneously cherry-picked to the fixes tree while
commit ca97f5546f19 ("drm/i915/mst: Call intel_pfit_compute_config()
for sharpness filter")
was already in there.
Drop the redundant duplicate call.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nemesa Garg <nemesa.garg@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Fixes: 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter")
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/20260806074819.2631970-1-chaitanya.kumar.borah@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo: adjusted commit message]
(cherry picked from commit ea9f3470d33602fb776ea55443467baacf66f23a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
npc_mcam_free_all_entries() disables every MCAM entry mapped to a
port before freeing it. On CN20K, that also disables the default
broadcast, multicast, promiscuous, and unicast rules, which causes
packet drops when all rules are removed per port.
Only disable and free non-default entries. Leave CN20K default rules
enabled when freeing the remaining port entries.
Fixes: 013717353c03 ("octeontx2-af: npc: cn20k: Tear down default MCAM rules explicitly on free")
Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
rppx1_bls_swap_regs() gets the Bayer pattern from the acquisition
module. The PRE1 path uses pre1.acq, but the PRE2 path mistakenly uses
pre2.bls. The BLS module does not store a Bayer pattern, so PRE2 would
read zero (RGGB) and map fixed black levels to the wrong colour
registers.
PRE2 is not started or dispatched yet, so the bug is currently latent.
Read the pattern from pre2.acq, as the PRE1 path does, so that enabling
PRE2 does not start out with the wrong register mapping.
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
rppx1_ext_params_blocks_info[] is indexed by block type and is built
with designated initialisers, so a block type without an entry is left
as a zero-sized hole. RPPX1_PARAMS_BLOCK_TYPE_AWBG_POST is the only
such hole: a block reporting that type and a size of zero passes
v4l2_isp_params_validate_buffer(), which then has nothing to advance
the walk with.
Describe the block, so the array covers all block types the uAPI
defines. The MAIN_POST white balance gains module is probed and started
with the rest of the POST pipe, and RPPX1_PARAMS_MAX_SIZE already
reserves room for all three white balance gains blocks.
The block is not dispatched by rppx1_params(), in line with the other
described blocks that have no users yet.
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Replace PTR_ERR() and %ld with %pe and pass the original pointer directly
to dev_dbg(), dev_warn(), dev_err() or pr_err(). The %pe format specifier
prints a symbolic error name (e.g. -ENOMEM) when CONFIG_SYMBOLIC_ERRNAME
is enabled, otherwise it falls back gracefully and prints the raw integer
value. This makes error messages more readable without any functional
change.
Signed-off-by: Sumeet Pawnikar <sumeet4linux@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
The multiplication be32_to_cpup(val++) * 1000 is performed using 32 bit
unsigned integers and hence uses a 32 bit multiplication; this will
overflow if be32_to_cpup(val++) is greater than 4294967 (which is
very unlikely at present). The result is assigned to an unsigned long
(which is a 64 bit value on 64 bit systems), so fix this potential
overflow by casting the first operand of the multiplication to
an unsigned int.
Fixes: b496dfbc94ab ("PM / OPP: Initialize OPP table from device tree")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Transport drivers (such as rmi_i2c and rmi_spi) invoke
rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev
device during system power management events. However, transport drivers
are fully registered and operational even if the physical RMI driver
failed to bind or probe the rmi_dev device.
When rmi_driver_suspend() or rmi_driver_resume() is called on an unbound
rmi_dev, dev_get_drvdata() returns NULL. Calling rmi_disable_irq() or
rmi_enable_irq() without driver data attached causes a NULL pointer
dereference and General Protection Fault when attempting to lock
data->enabled_mutex.
Fix this by checking if driver data is attached to rmi_dev in
rmi_driver_suspend() and rmi_driver_resume(), exiting early if
no driver data is present.
Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices")
Reported-by: syzbot+09103639e39c989e3ed3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=09103639e39c989e3ed3
Cc: stable@vger.kernel.org
Assisted-by: LLM
Link: https://patch.msgid.link/anQe8UiyUR4x0flD@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
When chunking writes into SMBus blocks in rmi_smb_write_block(), the
loop calculates block_len using the original total length (len) instead
of the remaining length (cur_len).
If len is greater than 32 bytes (SMB_MAX_COUNT), block_len remains 32
for every iteration, even on the final partial chunk where fewer than 32
bytes remain. This causes smb_block_write() to read 32 bytes from the
advanced data buffer pointer, reading past the end of the input buffer.
Fix this by calculating block_len using cur_len and advancing the buffer
and address pointers by block_len.
Fixes: 82264d0cf7ae ("Input: synaptics-rmi4 - add SMBus support")
Cc: stable@vger.kernel.org
Reported-by: sashiko-bot@kernel.org
Assisted-by: LLM
Link: https://patch.msgid.link/anLFSMKSoKyyZ272@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
msc313e_wdt_probe() doesn't set the driver data for the platform device.
As a result, dev_get_drvdata() in msc313e_wdt_suspend() and
msc313e_wdt_resume() will return NULL, leading to a NULL pointer
dereference afterward.
Set the platform device driver data in msc313e_wdt_probe().
Fixes: e9800b799464 ("watchdog: Add Mstar MSC313e WDT driver")
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260827044700.554333-2-tzungbi@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
sunxi_wdt_probe() unconditionally stops the watchdog even when firmware
left it running. This opens an unprotected interval during boot and
prevents CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED from taking over the active
watchdog.
Detect an enabled watchdog and decode its programmed interval. Preserve
representable timeouts, and round the 0.5-second interval up to the
minimum representable one-second timeout. Use the configured timeout for
reserved interval encodings. Set the Linux reset mode and ping the
watchdog without clearing its enable bit, then mark it hardware-running
before registration so the watchdog core services it until userspace
takes control. Leave disabled watchdogs untouched.
Fixes: d00680ed0026 ("watchdog: sunxi: New watchdog driver for Allwinner A10/A13")
Cc: stable@vger.kernel.org
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260827-submit-sunxi-wdt-boot-enabled-v1-v2-1-610d37dccc97@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
syzbot reported the following circular locking dependency:
xs->mutex -> netdev lock -> pnodes_lock -> net->xdp.lock -> xs->mutex
The pnodes_lock -> net->xdp.lock edge is recorded when
ipvlan_device_event(NETDEV_UNREGISTER) calls unregister_netdevice_many()
while holding pnodes_lock. A nested NETDEV_UNREGISTER notification for
an IPvlan device enters xsk_notifier(), which acquires net->xdp.lock.
Keep pnodes_lock only while marking the upper devices as dying, removing
them from port->ipvlans, and queueing them for unregistration. Once the
devices have been detached from the protected list, release pnodes_lock
before unregister_netdevice_many() invokes notifier callbacks.
The port remains alive across unregistration because
ipvlan_device_event() holds the reference acquired by ipvlan_port_get().
The dying flag prevents a concurrent ->dellink() callback from deleting a
queued device again.
Fixes: 35add1093e2f ("ipvlan: Protect ipvl_port.ipvlans with mutex.")
Reported-by: syzbot+aa48b5fe7bfda62d1682@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=aa48b5fe7bfda62d1682
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260828164918.451364-1-maciej.fijalkowski@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
vxlan_mdb_is_valid_source(), which validates MDBE_ATTR_SOURCE and every
MDBE_ATTR_SRC_LIST member, accepts the all-zeros address.
A source list is only accepted on a (*, G) entry, whose source is the
all-zeros address, and for each member of the list an (S, G) entry is
derived from it by substituting the source. Entries are keyed by a plain
memcmp() of struct vxlan_mdb_entry_key, so if MDBE_ATTR_SOURCE is present
and holds the all-zeros address and the source list holds it as well, the
derived (S, G) key is byte-identical to the (*, G) key and resolves to the
same entry. Omitting MDBE_ATTR_SOURCE is not equivalent, as the key is
then left with a zero address family.
vxlan_mdb_remote_src_del() removes the forwarding entry of a source before
freeing the source entry:
vxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr);
vxlan_mdb_remote_src_entry_del(ent);
With the keys aliased, the first call deletes the remote of the entry that
owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second
call then runs on the freed entry, and its hlist_del() reads ->pprev and
->next out of it and writes through them.
Adding the (*, G) entry with NLM_F_REPLACE and no source list marks the
all-zeros source for deletion and reaches this from the sweep at the end
of vxlan_mdb_remote_srcs_replace().
BUG: KASAN: slab-use-after-free in __vxlan_mdb_add+0x1cd/0xd70
Read of size 8 at addr ffff888102852500 by task poc/84
__vxlan_mdb_add+0x1cd/0xd70
vxlan_mdb_add+0xc0/0x140
rtnl_mdb_add+0x157/0x2a0
rtnetlink_rcv_msg+0x207/0x5a0
Allocated by task 84:
__kmalloc_cache_noprof+0x153/0x360
vxlan_mdb_remote_srcs_add+0x2eb/0x440
__vxlan_mdb_add+0x803/0xd70
Freed by task 84:
kfree+0x14c/0x3b0
vxlan_mdb_remote_del+0x129/0x1a0
__vxlan_mdb_del+0x4f/0xe0
vxlan_mdb_remote_src_fwd_del.isra.0+0x162/0x1b0
__vxlan_mdb_add+0x1c5/0xd70
The MDB operations are netns-scoped, so an unprivileged user can perform
them in a new user and network namespace.
Reject the all-zeros address in vxlan_mdb_is_valid_source(), which covers
both call sites. A (*, G) entry is expressed by omitting the source, so
nothing legitimate is refused.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support")
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/20260826173604.90158-1-baul.lee@xbow.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
amd-xgbe driver currently sets the MAC_RCR.DCRCC bit whenever
RX is enabled. This disables hardware FCS validation, causing packets
with bad FCS to be accepted unconditionally.
This change unsets DCRCC so that packets with bad FCS will be dropped,
in-line with typical behaviours of many other network controllers.
Tests:
- Verified that packets with bad FCS are now dropped.
- Verified that receiving packets with bad FCS will increment the
`rx_crc_errors` counter.
Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver")
Signed-off-by: James Nugraha <aslan.jnn@gmail.com>
Link: https://patch.msgid.link/20260827232220.69907-1-aslan.jnn@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Pull i2c fixes from Andi Shyti:
"Fixes mainly for teardown and resource handling, runtime PM and
hardware-specific controller issues:
- fix debugfs use-after-free when removing the adapter
- designware: apply interrupt mask quirk for HJMC3001
- imx-lpi2c: avoid target accesses on master-only controllers
- mux: release channel node when adapter registration fails
- qcom-cci: fix autosuspend and runtime PM cleanup on removal
- qcom-geni: fix timing parameters for 32 MHz clock"
* tag 'i2c-fixes-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux:
i2c: core: fix debugfs UAF on adapter removal
i2c: imx-lpi2c: avoid accessing target registers on master-only controllers
i2c: qcom-cci: fix autosuspend cleanup
i2c: designware: Enable interrupt mask workaround for HJMC3001
i2c: qcom-geni: update frequency table to fix timing parameters
i2c: mux: Fix channel node leak on adapter add failure
|
|
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
...
|
|
When a LUN_RESET aborts a WRITE command that is in the
TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and
waits for the frontend to finish processing.
If the initiator subsequently sends the remaining dataout PDUs,
__iscsit_check_dataout_hdr() catches the payload, stops the dataout
timer if the sequence is final and finally dumps the data. However, the
iSCSI target doesn't trigger the completion process for these aborted
commands. Because of this, the abort path hangs indefinitely in
target_put_cmd_and_wait(), leading to a deadlocked target worker thread.
Fix this by explicitly calling target_complete_cmd() when the final
dataout PDU is received for an aborted WRITE command.
target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes
the command into target_abort_work, allowing the abort completion to
successfully unblock.
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Link: https://patch.msgid.link/20260717143828.76291-2-mlombard@redhat.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
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>
|
|
SG_GET_REQUEST_TABLE reports per-request diagnostic state through
sg_req_info::problem. The field is meant to indicate whether there is an
error to report for a completed request.
sg_fill_request_table() currently combines masked_status, host_status
and driver_status with bitwise AND. This only reports a problem when all
three status fields are non-zero at the same time. A normal target check
condition, for example, has masked_status set while host_status and
driver_status may both be zero, so the request is incorrectly reported
as clean.
Use the same condition as sg_new_read(), which sets SG_INFO_CHECK when
any of the three status fields is non-zero.
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/26BF67F369E2123E+20260706084443.805598-1-raoxu@uniontech.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
mpi3mr_get_tgtdev_by_addr() increments the target device kref when it
returns a device. If a subsequent error triggers a goto out_fail after
the tgtdev reference is acquired, the reference is never released
because the out_fail path does not call mpi3mr_tgtdev_put(). This
prevents the target device structure from ever being freed.
Add a tgtdev put in the out_fail path, guarded by a NULL check since
tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup
path is shared by earlier error cases where tgtdev is still NULL.
Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL")
Signed-off-by: Milan P. Gandhi <mgandhi@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Link: https://patch.msgid.link/20260812103344.174247-3-mgandhi@redhat.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
sas_port_alloc_num() can return NULL on memory allocation failure. The
return value is passed directly to sas_port_add() without a NULL check,
which causes a NULL pointer dereference.
Additionally, if sas_port_add() fails, the allocated port is not freed
before jumping to out_fail, leaking the sas_port structure. Call
sas_port_free() to properly release it.
Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL")
Signed-off-by: Milan P. Gandhi <mgandhi@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Link: https://patch.msgid.link/20260812103344.174247-2-mgandhi@redhat.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>
|
|
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>
|
|
Commit 249313b3f7b5 ("scsi: ibmvfc: allocate targets based on protocol")
added a protocol parameter to ibmvfc_alloc_target() but did not describe
it in the function's kernel-doc comment, so a W=1 build warns:
drivers/scsi/ibmvscsi/ibmvfc-core.c:4996: warning: Function parameter
or struct member 'protocol' not described in 'ibmvfc_alloc_target'
Add the missing parameter description.
Fixes: 249313b3f7b5 ("scsi: ibmvfc: allocate targets based on protocol")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608270829.lHI1FAdO-lkp@intel.com/
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Reviewed-by: Dave Marquardt <davemarq@linux.ibm.com>
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/b073968ae020b6ae0240e91341a92f428587ebd9.1787828961.git.falakreyaz@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Commit e0fca728a89f ("scsi: ibmvfc: delete NVMe/FC targets as well as
SCSI") renamed ibmvfc_relogin() to ibmvfc_scsi_relogin() but left the
kernel-doc comment referring to the old name, so a W=1 build warns:
drivers/scsi/ibmvscsi/ibmvfc-core.c:1901: warning: expecting prototype
for ibmvfc_relogin(). Prototype was for ibmvfc_scsi_relogin() instead
Update the kernel-doc comment to use the current function name.
Fixes: e0fca728a89f ("scsi: ibmvfc: delete NVMe/FC targets as well as SCSI")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608271026.iMLmrwz4-lkp@intel.com/
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Reviewed-by: Dave Marquardt <davemarq@linux.ibm.com>
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://patch.msgid.link/dd866cf2321381694af027fbd726bcbd63ac3751.1787828961.git.falakreyaz@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
pm8001_request_msix() unwinds previously registered handlers with
free_irq() when request_irq() fails. The rollback loop uses the failing
index i for every iteration instead of the already registered vector
index j.
That passes the wrong IRQ/dev_id pair to free_irq() and leaves the
earlier handlers installed. Use j for both pci_irq_vector() and the
matching irq_vector entry in the rollback loop.
Fixes: a76037ff3479 ("scsi: pm8001: switch to pci_irq_alloc_vectors")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Link: https://patch.msgid.link/20260824113618.2239100-1-runyu.xiao@seu.edu.cn
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
Laxman Acharya Padhya
Kiran K
Vignesh Viswanathan
Amit Sunil Dhamne
Mostafa Saleh
Paul Hollinsky
Shawn Guo
Martin K. Petersen (Oracle)
Holger Dengler
Thomas Zimmermann
Jameson Thies
Ulf Hansson
Deepanshu Kartikey
Ville Syrjälä
Nemesa Garg
Suraj Kandpal
Abel Vesa
Arthur Gautier
Michal Pecio
Chen-Yu Tsai
Chaitanya Kumar Borah
Kiran Kumar K
Linmao Li
Sumeet Pawnikar
Colin Ian King
Dmitry Torokhov
Tzung-Bi Shih
James Hilliard
Maciej Fijalkowski
Baul Lee
James Nugraha
Linus Torvalds
Maurizio Lombardi
sangram kumar yerra
Xu Rao
Milan P. Gandhi
Nitin Rawat
Muhammad Falak R Wani
Runyu Xiao