| Age | Commit message (Collapse) | Author |
|---|
|
qcom_ipcc_probe() uses a function-static int id incremented with
plain id++ to generate unique IRQ names. Under async or deferred
probe, two instances can probe concurrently and read the same value
before either increments, producing duplicate IRQ names.
The device already has a unique name assigned by the platform bus. Use
dev_name(&pdev->dev) directly as the IRQ name. This eliminates the racy
counter, the name buffer, and the devm_kasprintf() allocation entirely,
while providing a more informative IRQ name in /proc/interrupts.
Signed-off-by: Anup Vishwakarma <anup.vishwakarma@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
qcom_ipcc_mbox_shutdown() clears chan->con_priv with no locking.
qcom_ipcc_mbox_send_data() dereferences the same field without
checking for NULL first, so a send racing a concurrent shutdown can
crash:
mchan = chan->con_priv;
...
hwirq = qcom_ipcc_get_hwirq(mchan->client_id, mchan->signal_id);
Add the same NULL guard mbox_send_message() already uses for
chan->cl, and bail out before dereferencing a cleared con_priv.
To close the remaining race where send_data() reads con_priv a moment
before a concurrent shutdown clears it, acquire the spinlock in
qcom_ipcc_mbox_shutdown() using the modern guard(spinlock_irqsave)
primitive before setting con_priv to NULL.
Fixes: d6fbfdbc1274 ("mailbox: qcom-ipcc: Fix IPCC mbox channel exhaustion")
Cc: stable@vger.kernel.org
Signed-off-by: Anup Vishwakarma <anup.vishwakarma@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
pm_runtime_get_sync() leaves the runtime PM usage counter incremented
even when it fails, but cmdq_mbox_flush() returns the error without
dropping it. The same happens when the GCE thread does not drain in
time and the function bails out with -EFAULT.
Undo the reference on both error paths.
Fixes: b0524f7c9635 ("mailbox: mediatek: implement flush function")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
bcm74110_rx_push_init_msg() allocates a GFP_ATOMIC struct for every
BCM_MSG_SVC_INIT word received from the PMC co-processor and appends it
to rx_svc_init_list with no cap on list length. The only consumers of
this list (bcm74110_rx_pop_init_msg_block / bcm74110_rx_flush_msg) are
called only during probe and at shutdown respectively; after probe
completes, PMC firmware can continuously inject BCM_MSG_SVC_INIT words,
exhausting GFP_ATOMIC reserves and causing a whole-device denial of
service.
Add BCM74110_INIT_MSG_MAX (16 entries) as the maximum list depth.
bcm74110_rx_push_init_msg() now checks the count under the existing
rx_svc_list_lock before allocating; if the cap is reached the message is
dropped and a rate-limited warning is emitted. The new rx_svc_init_count
field is decremented by bcm74110_rx_pop_init_msg() on successful dequeue
and reset to zero by bcm74110_rx_flush_msg() on shutdown.
Fixes: 52436007b862 ("mailbox: Add support for bcm74110")
Cc: stable@vger.kernel.org
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Assisted-by: Anthropic:claude-sonnet-4.6 cursor
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
Acked-by: Justin Chen <justin.chen@broadcom.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
mhuv2_tx_init() waits forever for access_ready. Fail probe
after 1s instead of hanging boot.
Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver")
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
The RX polling callback unconditionally rearms the timer after it
processes mailbox data. altera_mbox_shutdown() uses
timer_delete_sync(), which waits for a running callback but does not
prevent that callback from rearming the timer after the deletion.
Use timer_shutdown_sync() for the final polling teardown so the timer
cannot be queued again while the mailbox channel is being released.
The timer is reinitialized with timer_setup() on a later channel startup,
so polling mode remains reusable.
Fixes: f62092f6d77d ("mailbox: Add Altera mailbox driver")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
ti_msgmgr_send_data() copies the message to the data registers in u32
units. This has been harmless so far because the clients (TI-SCI)
always passed its preallocated message buffer, which is sized to the
maximum message size (60 or 64 bytes, a multiple of 4), so the extra
bytes read were still within the buffer. But, with a later TI-SCI
update, the message size can be varying now and not guaranteed to be a
multiple of 4, which would trigger KASAN out-of-bounds reports.
Therefore, memcpy() only the trailing bytes into a zeroed u32 before
writing it to the register. This is at most 3 bytes, so the overhead
is negligible.
Fixes: aace66b170ce ("mailbox: Introduce TI message manager driver")
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
In polled rx mode, used from system suspend until resume,
ti_msgmgr_send_data() writes the message to the tx queue and then
waits for the response. If no response arrives in time it returns
the poll error.
The mailbox core treats a ->send_data() error as a send failure.
So, it leaves the message queued without making it the active request,
and mbox_send_message() still returns success. The message is then
submitted again on the next tx_tick() or mbox_send_message(), after the
client has probably timed out and moved on. So, the firmware receives
the same message twice, and later requests are sent late and can have
responses matched to the wrong request.
The message has already been transmitted at this point, so return 0
and only log the missing response. The client detects this case with
its own response timeout anyways.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
When MHUv3 is used as the SCMI mailbox transport (arm,scmi-mailbox),
SCMI clock and power-domain operations still need to work in the noirq
phase of system suspend: genpd may power off a device's parent domain
from genpd_suspend_noirq(), which issues scmi_clock_config_set() /
scmi_power_state_set() and waits for the firmware reply via the mailbox
RX IRQ.
However, dpm_suspend_noirq() calls suspend_device_irqs() before running
the suspend_noirq callbacks, so the combined interrupts are already
masked at that point and the SCMI transfer times out while waiting for
the reply.
Both the PBX and MBX combined interrupts are requested as threaded
IRQs with only IRQF_ONESHOT. The MBX combined IRQ must stay enabled so
that firmware replies are delivered, and the PBX combined IRQ, used
for txdone by IRQ when not in polling mode, needs the same treatment.
IRQ threads are not frozen during system suspend, so with
IRQF_NO_SUSPEND the threaded combined-IRQ handlers still run in the
noirq phase.
Add IRQF_NO_SUSPEND to the MHUv3 combined IRQ registrations so that
SCMI remains functional throughout the suspend/resume cycle. Note that
this only keeps the IRQs functional during the suspend/resume cycle and
does not make the mailbox a wakeup source.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
failure
mhu_db_probe() registers the mailbox controller via
devm_mbox_controller_register(), which automatically calls
mbox_controller_unregister() through devres when the device is removed
or probe fails. If devm_request_threaded_irq() subsequently fails in
the channel setup loop, the error path also manually calls
mbox_controller_unregister(), resulting in a double call that corrupts
the global mailbox controller list and causes a kernel panic.
Remove the redundant manual call and rely on devres for cleanup.
Fixes: 7002ca237b21 ("mailbox: arm_mhu: Add ARM MHU doorbell driver")
Signed-off-by: Anup Vishwakarma <anup.vishwakarma@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
failure
qcom_ipcc_probe() registers the mailbox controller via
devm_mbox_controller_register(), which automatically calls
mbox_controller_unregister() through devres when the device is removed
or probe fails. If devm_request_irq() subsequently fails, the
err_req_irq: label also manually calls mbox_controller_unregister(),
resulting in a double call that corrupts the global mailbox controller
list and causes a kernel panic.
Remove the redundant manual call and rely on devres for cleanup.
Fixes: e9d50e4b4d04 ("mailbox: qcom-ipcc: Dynamic alloc for channel arrangement")
Signed-off-by: Anup Vishwakarma <anup.vishwakarma@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
This is more compact in source code and also compiles to smaller code.
Bloat-o-meter reports:
add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-76 (-76)
Function old new delta
rockchip_mbox_probe 1596 1592 -4
_entry_ptr 24 16 -8
__func__ 62 42 -20
_entry 132 88 -44
Total: Before=6693, After=6617, chg -1.14%
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
There is only a single device variant. Let's not use multi-device
abstraction for that but hardcode the information relevant for that
single device type.
Bloat-o-meter reports the following size reduction for an ARCH=arm64
build:
add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-492 (-492)
Function old new delta
rk3368_drv_data 4 - -4
rockchip_mbox_probe 2084 1596 -488
Total: Before=7185, After=6693, chg -6.85%
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
This way the defines don't make the impression to be more generic than
they actually are.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
mbox_free_channel() makes a PCC channel available before the subsequent
shared-memory unmap. Without serialization, a concurrent request can bind a
new client and replace the mapping, which the old release then unmaps.
Serialize PCC channel acquisition and release. Keep the channel unavailable
until the old shared-memory mapping has been removed.
Suggested-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
I am seeing a crash on PCC that is related to a an shared memory being
unmapped before the IRQ is disabled, and the IRQ kicks in and hits the
unmapped (NULL) address. This is a summary of what I see on my box:
scmi_protocol scmi_dev.1: Message for 1 type 0 is not expected!
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
__handle_irq_event_percpu+0x1c4/0x9e0
handle_irq_event+0x98/0x218
handle_fasteoi_irq+0x230/0x750
generic_handle_domain_irq+0xac/0x138
gic_handle_irq+0x344/0x740
call_on_irq_stack+0x30/0x48
The trapping store is iowrite32(SCMI_SHMEM_FLAG_INTR_ENABLED,
&shmem->header.flags), a write of 1 at offset 4 of a NULL base.
But, back to the problem, pcc_mbox_free_channel() unmaps the shared
memory and clears pchan->chan.shmem *before* freeing the IRQ (aka
calling mbox_free_channel()).
The interrupt is still live when the mapping goes away.
Free the channel first, before the memory unmap. mbox_free_channel()
calls pcc_shutdown(), which frees the platform interrupt, and then unmap
shared memory.
Fixes: 7f9e19f207be ("mailbox: pcc: Check before sending MCTP PCC response ACK")
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
Add support for the TDA54 secure proxy mailbox controller integrated in
the MAIN voltage domain. This instance supports up to 444 threads with
60-byte messages per thread. Add the corresponding device data for the
ti,tda54-main-secure-proxy compatible.
While at it, update some internal variable types from u8 to u16 to hold
values up to 444.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
kernel test robot reported a format-truncation warning for the
snprintf() that builds each channel's debugfs entry name:
drivers/mailbox/axiado-mailbox.c:325:39: warning: '-errors'
directive output may be truncated writing 7 bytes into a region
of size between 2 and 11 [-Wformat-truncation=]
AX3005 exposes 16 mailbox channels, so the longest name generated at
runtime is "chan15-errors" and already fits in the original buffer.
However, the compiler cannot infer that bound from
drv_data->num_chans and therefore assumes the unsigned channel index
may require up to 10 decimal digits. Widen the buffer to 32 bytes,
which removes the -Wformat-truncation warning with no functional
change.
Fixes: 14af7a96afa3 ("mailbox: add Axiado AX3005 mailbox driver")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608250447.gGkRwNAl-lkp@intel.com/
Signed-off-by: Swark Yang <syang@axiado.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
Two RX-path bugs found during bring-up:
1. axiado_rx_thread() previously consumed only one frame per
invocation. Multiple frames can accumulate in the FIFO while the
threaded handler is running. Split the single-frame handling into
axiado_mbox_receive_one_frame() and drain all currently queued
frames before returning from the handler. A cond_resched() in the
drain loop prevents a continuously-fed channel from monopolizing
the CPU.
2. readl_poll_timeout() waiting for the remainder of a frame can
return success either because the required FIFO level was reached
or because a FIFO error appeared -- it does not distinguish the
two. The old code did not check for that case and could therefore
enter the read loop without enough words actually being present.
Explicitly inspect the error status after the poll: if an error
occurs while waiting for the remainder of an already-started
frame, treat that frame as unusable and flush the FIFO to
resynchronize, rather than risk delivering incomplete or garbage
data to the client.
While here:
- Track whether the handler actually serviced a hardware condition,
such as clearing a FIFO error or consuming frame data. Return
IRQ_HANDLED whenever something was serviced, even if the FIFO is
empty afterward, instead of reporting IRQ_NONE after handling a
hardware condition.
- Use readsl() for the RX FIFO payload. The destination is the
driver-owned rx_buffer allocated by devm_kzalloc(), so it has
suitable alignment for the stream accessor. readsl() is
appropriate for copying a sequence of words from the FIFO into
that buffer. The TX path intentionally stays on
get_unaligned_le32()/writel(): its buffer is supplied by an
external mailbox client, the mailbox API gives no guarantee that
buffer is naturally aligned, and the TX path also explicitly
handles a partial final word.
mbox_free_channel() invokes ->shutdown() before chan->cl is cleared,
and axiado_mbox_shutdown() calls disable_irq(), which waits for the
in-flight threaded handler to complete, so no functional change is
needed for that path.
Verified: builds clean with the aarch64 cross-compiler, passes
checkpatch.pl, and was regression-tested with live mailbox traffic on
AX3005.
Fixes: 14af7a96afa3 ("mailbox: add Axiado AX3005 mailbox driver")
Signed-off-by: Swark Yang <syang@axiado.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
|
|
https://gitlab.freedesktop.org/drm/msm into drm-next
Changes for v7.4
CI:
- Dropped sc7180 trogdor lazor from the CI
Core:
- Fixed msm_ioremap for resources without a name
- Changed msm.separate_gpu_kms to default to auto selection
GPU:
- Enable CLX (Current Limit eXtension) for gen8 to avoid
exceeding limits on CX/GX rails
- New GPUs: a830 (Pakala), a845 (Maili), a850 (Hawi),
x2-85 (Mahua)
- Fix VBIF halt mask on a306, which was preventing runpm
suspend
- Enable THP support for GEM buffers
- Add modparam to disable waiting on fences in shrinker
- Drop use of drm_prime_sg_to_page_array()
- a5xx: don't read the GPMU registers on GPUs without a GPMU
- a2xx/a3xx/a5xx: hangcheck progress detection
- a6xx: gmuwrapper runpm fix
- Calculate reported GMEM size based on active slices
- Split a6xx/a7xx/a8xx catalog
DP:
- Picked up some preparation patches for the MST support
- Fixed reported status of the link training
DPU:
- Fixed CRTC bandwidth computation
- Fixed DSC programming
- Fixed encoder disablement path
DSI:
- Fixed VM leak in error path
- Indention fix
MDP5:
- Added MSM8952 configuration
- Dropped incorrect cursor pipe on MSM8976/56
HDMI:
- Small fixes
Notes:
- Merged qcom-drivers-for-7.4 to pick up UBWC_7_0 support
(needed for Hawi/Maili) which in turn depended on
qcom-arm64-for-7.4
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <rob.clark@oss.qualcomm.com>
Link: https://patch.msgid.link/CACSVV02V-FOzGj71G0ZL7khkYEKWFW4q4biOZR8B8vyWy20PdQ@mail.gmail.com
|
|
Replace direct dma_chan::device::dev access with the proper
dmaengine_get_dma_device() for consumer API.
chan->device->dev is not always the device used for DMA mapping. Some DMA
engines support per-channel IOMMU mappings, so different channels may use
different DMA devices. dmaengine_get_dma_device() returns the correct
device for each channel.
This also prepares for making the DMA engine provider data structures
private. DMA consumers should not access DMA engine internals directly.
Link: https://lore.kernel.org/20260917205016.1293317-1-Frank.Li@oss.nxp.com
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Assisted-by: LLM
Cc: Alexandre Bounine <alex.bou9@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Vinod Koul <vkoul@kernel.org>
|
|
The cursor blending mode was added twice because the same change was
applied by accident from different patches. Revert the second patch.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/dri-devel/ce84d3d2-e78b-4939-aecf-9ef7267bd42a@samsung.com/
Fixes: 6947b78df4d2 ("drm/virtio: Add pixel blend mode property to cursor plane")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20261007222244.295186-1-dmitry.osipenko@collabora.com
|
|
The LCPA area is mapped with devm_ioremap(), but lcpa_base and the
per-channel lcpa pointer lack __iomem annotations. This loses the I/O
address space and makes sparse warn when d40_current_addr() assigns
LCPA register addresses to its __iomem pointers.
Annotate both pointers and the LCPA argument of d40_log_lli_lcpa_write()
to preserve the I/O address space from the mapping to the register
accessors. This also fixes the existing LCPA read and write warnings
without changing the generated code.
Fixes: c80edceff29e ("dmaengine: ste_dma40: Fix cyclic transfer residue")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202610090216.pjMRxhRL-lkp@intel.com/
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20261010-dma40-smatch-fix-v1-1-26ca10043957@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of driver specific fixes, plus a new device ID in
the DesignWare device tree binding.
One of the sg2044 fixes which enforces clock limits properly is more
critical than average since getting them wrong might lead to data
corruption"
* tag 'spi-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: dt-bindings: snps,dw-apb-ssi: Add Synaptics sl2610 spi
spi: sg2044-nor: Honor SPI clock limits
spi: sg2044-nor: Return transfer errors
spi: cadence-qspi: Fix status polling with octal DTR chips
spi: spi-nxp-fspi: exit stop mode before waiting for DLL lock
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"There's a couple of core fixes here: there were a couple of issues
with of_regulator_bulk_get_all() not behaving consistently with the
other bulk regulator APIs which caused memory leaks and error handling
issues in users.
We also have a couple of fairly standard driver specific fixes"
* tag 'regulator-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: ltc3676: don't read the write-only HRST and CLIRQ registers
regulator: of: state who owns the array from of_regulator_bulk_get_all()
regulator: of: fill in supply names in of_regulator_bulk_get_all()
regulator: tps6594-regulator: Fix n_linear_ranges for TPS65224 BUCK2-4
|
|
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
|
|
When an MHI endpoint device runs Linux, there is no firmware to implement
the LOOPBACK channel echo that real modem firmware provides. Without an
endpoint-side driver, the host loopback test has no software echo partner
and cannot exercise the full end-to-end MHI data path.
Add an endpoint-side loopback driver that binds to the LOOPBACK channel and
echoes received data back to the host. An ordered workqueue is used for
asynchronous processing to preserve packet ordering. Together with the
host-side loopback driver, this enables complete MHI data path validation
for Linux-based endpoint devices.
Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261005-lb-v7-3-36a268b6386f@oss.qualcomm.com
[mani: fixed checkpatch warnings]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
Some MHI endpoint clients do not use socket buffers and need a way to queue
raw buffers for DL transfers. Add mhi_ep_queue_buf() to support this use
case.
Refactor mhi_ep_queue_skb() to delegate to a new internal mhi_ep_queue()
helper shared by both APIs, and rename mhi_ep_skb_completion() to
mhi_ep_buf_completion() to reflect its broader use.
Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261005-lb-v7-2-36a268b6386f@oss.qualcomm.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
The MHI specification defines a LOOPBACK channel. The endpoint firmware
echoes back whatever the host sends on this channel. Without a host-side
driver, there is no way to exercise this channel to validate MHI data path
integrity between host and endpoint.
Add a host-side loopback driver that binds to the LOOPBACK channel and
expose a sysfs interface for data path testing. The sysfs interface allows
users to configure TRE buffer size and count, trigger a loopback test, and
read the result.
The new sysfs ABI is documented under Documentation/ABI/testing/, not
stable/, since this is a new interface without established API
guarantees yet. It is unrelated to the existing stable MHI sysfs ABI
documented in Documentation/ABI/stable/sysfs-bus-mhi, despite both
being covered by the same MAINTAINERS entry.
Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261005-lb-v7-1-36a268b6386f@oss.qualcomm.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
The Quectel RM500Q-AE (SDX55) enumerates with the Qualcomm SDX55 ID
17cb:0306 and subsystem ID 17cb:5002, so it binds to the generic
qcom-sdx55m entry. That configuration expects QMI on channels 14/15,
which this module's firmware does not answer: the modem probes, but
every QMI request over the control channel times out and no data
session can be set up. Users of this module have had to fall back to
Quectel's out-of-tree driver.
Like the other Quectel modules, the RM500Q-AE provides MBIM control on
channels 12/13 and data on IP_HW0_MBIM. Add an entry for its subsystem
ID, which no other entry in the table uses, that reuses the Quectel
em1xx channel configuration. The EDL image name is the one the generic
SDX55 entry already uses.
Tested on a Xunison Exigo D50 5G (IPQ5018) with modem firmware
RM500QAEAAR13A03M4G: the modem probes as quectel-rm500q and exposes
wwan0mbim0, wwan0at0 and an MBIM network device. A data session set up
with mbimcli and with OpenWrt's umbim reached 160-180 Mbps, the
limit of the cell.
Assisted-by: LLM
Signed-off-by: Steve Meek <stevemeek82@gmail.com>
Link: https://patch.msgid.link/20261011-mhi-next-v1-1-13a738637ff0@gmail.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- NVMe fixes via Keith:
- Fix swapped ZRASF zone state values for full and read only
- nvme-multipath revalidate head zones after unfreezing the head
queue
- Revert "nvme: do not reset controllers in NVME_CTRL_NEW state",
which broke things
- nvmet fixes for invalid NSIDs on feature 82h and using the local
P2P device on metadata allocation failure
- zloop: zero out only the unread tail of a short read
* tag 'block-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
Revert "nvme: do not reset controllers in NVME_CTRL_NEW state"
zloop: zero out only the unread tail of short reads
nvmet: use the local P2P device on metadata allocation failure
nvme-multipath: revalidate head zones after unfreezing the head queue
nvme: fix swapped ZRASF zone state values for full and read only
nvmet: return Invalid Field for invalid NSIDs feature 82h
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
- A fix for the ati_remote2 sysfs attributes handling, resolving type
confusion after conversion to dev_groups
- Updates to the xpad joystick driver adding support for the Corsair
Novablade Pro controller (wired and 2.4 GHz wireless) and a newer
hardware revision of the 8BitDo Pro 2 Wired Controller for Xbox.
* tag 'input-for-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: xpad - add support for 8BitDo Pro 2 Wired Controller for Xbox
Input: xpad - add support for Corsair Novablade Pro
Input: ati_remote2 - fix type confusion in device attribute handlers
|
|
CCG4 firmware occasionally fails to respond to I2C read requests,
especially when reading cci and intr_reg from the ISR path. In these
cases, i2c_transfer() returns -EREMOTEIO.
The CCG4 is EOL, and Infineon no longer supports firmware updates, so
a software workaround is necessary.
Attempt the read up to CCG_READ_MAX_RETRIES (4) times in total when
-EREMOTEIO is returned, sleeping ~1 ms via fsleep() between attempts.
This allows recovery from transient I2C failures without affecting
other error paths.
The sleep is safe because ccg_read() is called both from process
context and from ccg_irq_handler(), which runs in threaded IRQ
context (registered via request_threaded_irq() with a NULL hard-IRQ
handler), so sleeping is allowed in both cases.
Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx")
Cc: stable <stable@kernel.org>
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260916061858.1471606-1-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This change adds Tegra264 XUSB host mode controller support.
The host controller is very similar to the existing Tegra234 XHCI,
except the number of max_num_wakes.
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260903074539.613220-4-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Tegra264 XUSB does not use the firmware mailbox handshake to enable
controller messages (MBOX_CMD_MSG_ENABLED). Add a per-SoC flag and
short-circuit __tegra_xusb_enable_firmware_messages() so both probe
and resume avoid sending the command.
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260903074539.613220-3-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Instead of hard-coding the TUSB73X0 PCI ID, USB_CTRL register address
and the PWRON_POLARITY, introduce definitions for them to make the code
easier to read.
No functional change.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h
Link: https://patch.msgid.link/20261009125154.266435-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
It seems the xhci-pci-prom21 module only has IDs for the 800 series
chipsets. However, the 600 series chipsets also have Promontory 21
chips, so we should add their IDs to the list as well.
I have tested this on my X670 board featuring DID `0x43f7`.
`1022:43f7` also appears on the PCI ID database
(https://pci-ids.ucw.cz/read/PC/1022/43f7).
Device IDs `0x43f9` (B665) & `0x43fa` (A620) were suggested by Shyam.
Also list the new IDs in Documentation/hwmon/prom21-xhci.rst.
Cc: stable@vger.kernel.org # 7.2.x
Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Jihong Min <hurryman2212@gmail.com>
Signed-off-by: Stephen Horvath <linux@stevetech.au>
Tested-by: Mirko Jechow <mirko.jechow@gmx.de>
[mirko.jechow@gmx.de: add new IDs to prom21-xhci.rst]
Signed-off-by: Mirko Jechow <mirko.jechow@gmx.de>
Link: https://patch.msgid.link/20261004002731.49927-1-mirko.jechow@gmx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Offloaded USB audio devices using the xhci-sideband API store a pointer to
the xhci virtual device (vdev) in the sideband structure when registering.
This pointer typically remains valid throughout the lifetime of the USB
device. If a configured offloaded device requires a reset, the USB core
usually unbinds or notifies the audio driver beforehand, ensuring that the
sideband is unregistered before the vdev is freed.
An exception occurs when the USB core resets a device to recover from a
failed resume, but a subsequent 'address device' request also fails. To
recover in this specific scenario, the xHCI driver disables and re-enables
the slot, which frees and re-allocates the vdev.
xhci_sideband_unregister() later dereferences the stale, previously freed
vdev pointer during disconnect, triggering a kernel oops:
Unable to handle kernel paging request at virtual address dead000000000122
Call trace:
xhci_get_ep_ctx+0x0/0x38
xhci_sideband_unregister+0x68/0xf0
uaudio_disconnect+0x70/0x144
usb_audio_disconnect+0x7c/0x268
usb_unbind_interface+0x13c/0x340
device_release_driver_internal+0x1c4/0x2bc
usb_disable_device+0x84/0x190
usb_disconnect+0xe8/0x338
hub_event+0xbd8/0x19ac
Fix this by preventing the reallocation of the vdev in this specific error
path if the device is registered for sideband use.
Just propagate the error directly to the USB core. It should either retry
enumeration or detect the disconnected device, and handle it accordingly.
Debugging this issue to the dangling vdev pointer, reporting it, testing,
and initial patch with different solution by Lianqin Hu
Reported-by: Lianqin Hu <hulianqin@vivo.com>
Closes: https://lore.kernel.org/linux-usb/TYUPR06MB6217000B59003EDF233D7246D2B22@TYUPR06MB6217.apcprd06.prod.outlook.com/
Tested-by: Lianqin Hu <hulianqin@vivo.com>
Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity")
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-12-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
High-speed devices with out of spec 1024 byte bulk endpoints exist and
are allowed by USB core, but xhci-hcd always sets packet size to 512.
The exact nature of these devices isn't documented, commit fb5ee84ea72c
("USB: Accept bulk endpoints with 1024-byte maxpacket") only states
that they "don't work with xHCI host controllers", whatever it means.
But somebody (or a malicious device) can try, and then the driver will
allocate a 512 byte bounce buffer for this endpoint and may write up to
1024 bytes into it if particular scatter-gather URBs are used, because
xhci_align_td() obtains packet size from the descriptor. Fix this.
As a side effect, TRBs will be aligned to the packet size chosen by the
driver on all endpoints of all speeds. Alignment serves the xHC, not
device, so this is fine. Only out of spec devices are affected anyway.
Reported-by: co+fd80bc5967eb22c3@bugs.sh
Link: https://lore.kernel.org/linux-usb/D4tcSGerkYkIV1DmaUo1t8TaR5qQElDLkidn@bugs.sh/
Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Cc: stable@vger.kernel.org
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-11-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Matching events with TDs and giving back missed TDs is carried out
by a complicated loop. Replace it with a simpler linear logic:
0. Having verified that 'td_list' isn't empty,
1. Scan it to find the matching TD and count missed TDs,
2. Perform necessary adjustments for corner cases,
3. Give back missed TDs, if applicable, using a short and tidy loop,
4. Check if the event refers to the expected TD and proceed as usual.
Besides cleaning up the code, this provides a few improvements:
- when the skip flag is set, no TD is given back unless we found a match
or otherwise know how many TDs should be given back
- when the skip flag is clear, we know if the event refers to a "future"
TD so we can log this in the Scary Error Message to aid debugging.
While altering the error message, drop a pointless goto.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-10-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Half of this loop is code which only executes once to deal with cases
where no TD matches the event and then it returns. This code needs not
to be in any kind of loop, so get it out.
Optimize conditionals remaining in the loop body.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-9-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
These events are unique to isochronous endpoints, ignore them otherwise.
Update debug messages to reflect new policies. We could also log invalid
events as errors, but it seems nobody has ever had problems with that,
so don't bother.
This allows dropping the isoc check when skipping TDs.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-8-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In this case we know that the xHC has released ownership of all missed
TDs, we only don't know which were missed and which were queued later.
URBs are queued atomically, so we can safely give back all TDs of the
currently executing URB. Unlike the previous policy, this does actually
ensure that the class driver will learn about the error and won't see
all of its URBs still in progress when all TDs are missed on xHCI 1.0.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-7-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
dbc_tty_minors is protected by dbc_tty_minors_lock when entries are
allocated and during normal device removal. The registration error path
removes an entry without taking that lock. Different DbC instances have
separate event work items, so this removal can race with an IDR update
for another instance.
Take the same mutex around the error-path removal.
Fixes: e1ec140f273e ("xhci: dbgtty: use IDR to support several dbc instances.")
Reported-by: Changyul Lee <lcy8047@gmail.com>
Assisted-by: LLM
Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The xHCI driver programs the Device Notification Control register to
only enable the Function Wake device notification (N1), so any Device
Notification Event TRB received is expected to be a function wake
notification. handle_device_notification() does however not check the
Notification Type field of the event (xHCI 1.2 section 6.4.2.7, DW0
bits 7:4), and forwards every device notification event as a function
wake.
A host controller that delivers an unexpected notification type (e.g.
due to broken firmware or emulation) would trigger a spurious wake
notification on the parent hub.
Parse the notification type and drop events other than Function Wake
with a warning, mirroring the slot ID validation in the same function.
DEV_NOTE_FWAKE is the DNCTRL register bit for notification type 1
(N1), while the event TRB carries the notification type value itself,
so add a separate DEV_NOTE_TYPE_FWAKE constant for the comparison.
[mn:] reduce warning to a debug message
Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Fix various spelling mistakes in comments found by codespell.
Assisted-by: Claude:claude-opus-5-5 codespell
Signed-off-by: Zain Aboobacker <zainaboobacker33@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
xhci_abort_cmd_ring() requests abort, waits for the CRR bit to clear,
drops xhci->lock and waits for the Command Ring Stopped event.
The CRR wait timeout is 5 seconds as suggested by xHCI 4.6.1.2, which
means that if the xHC fails to complete the operation at all, we poll
with the lock held and IRQs disabled for several seconds. If any other
CPU tries to acquire the lock, it will spin likewise. IRQs get delays,
drivers log errors, tasks freeze, it's a mess.
So drop the lock earlier, before waiting for the CRR bit. It should be
safe - the sole caller sets cmd_ring_state to CMD_RING_STATE_ABORTED
before calling us, which will prevent others from ringing the command
doorbell and interfering with the abort. Queuing new commands during
this time poses no danger, and if the command we try to abort actually
completes concurrently, existing code already needs to deal with this.
And in my testing it does - it's trivial to trigger this on ASM1042,
where Address Device can't be aborted, but it completes as soon as the
offending device is unplugged, including during abort attempt.
Note that the lock still covers reinit_completion(), so it won't race
with complete() being called by the event handler. And works are not
reentrant, so another timeout can't expire while the lock is dropped.
We will configure timeout anew when restarting the ring.
One other difference is that now we also drop the lock if abort fails.
This too should be harmless. Commands queued during this time will be
released like any other pending commands. If the aborted command does
complete before we regain the lock, it's a waste, but not regression.
Reported-by: Pedro Fonseca <pedro@fonseca.com.pt>
Link: https://lore.kernel.org/linux-usb/16f65081-5a3c-4c30-9811-9017796a3373@fonseca.com.pt/
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
xhci_reset() returns 0 when the host is not halted, without ever writing
CMD_RESET. Every other path that fails to reset the host returns an
error, so callers that check the return value are told the reset
succeeded on the one path where it did not happen.
Return -EBUSY when the reset is aborted because the host is not halted.
Signed-off-by: Henry Tseng <henrytseng@qnap.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When the PPM reports more than one DisplayPort alternate mode for a
connector, ucsi_ccg_update_altmodes() merges them into a single entry
in uc->updated[] and sets uc->has_multiple_dp. In that case,
ucsi_ccg_update_get_current_cam_cmd() rewrites the response of the
GET_CURRENT_CAM command. The response is a single byte holding the
index of the currently active alternate mode, and it is provided by
the PPM firmware.
The function uses this byte directly as an index into uc->orig[], and
then uses the linked_idx read from that entry as the translated index
into uc->updated[]. Both arrays have UCSI_MAX_ALTMODES entries, but
neither index is checked against that size.
If a malicious or buggy PPM reports a value of UCSI_MAX_ALTMODES or
larger, e.g. 0xFF, uc->orig[cam].linked_idx reads over the end of
uc->orig[]. The byte read from there is then used as the index for
writing cam into uc->updated[new_cam].active_idx, so the out-of-bounds
read is followed by an out-of-bounds write. This happens without any
userspace action, since the UCSI core issues GET_CURRENT_CAM on its own
when handling connector changes.
Fix this by rejecting responses whose index is out of range, printing an
error and returning -EPROTO, so that the caller cannot accept this.
Also check linked_idx before using it as an index, so that the write into
uc->updated[] is always within bounds.
The response is now only processed when the command completed without
an error. ucsi_sync_control_common() only reads the response when the
CCI reports command completion, so otherwise the buffer is not filled
and must not be mistaken for an invalid index.
This bug was found with a Python script that traces where firmware input
is used.
Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices")
Cc: stable <stable@kernel.org>
Reported-by: Nathan Rebello <nathan.c.rebello.27@dartmouth.edu>
Assisted-by: LLM
Signed-off-by: Seungjin Bae <eeodqql09@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20261003215520.611083-2-eeodqql09@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since Thunderbolt alternate mode support was added,
`ucsi_altmode_update_active()` is called on every Connector Partner
Changed event. This made the driver send `UCSI_GET_CURRENT_CAM` to
PPMs even when the partner had no alternate modes registered. Firmware
that does not support the optional alternate mode details answered Not
Supported, which produced a spurious error on every partner change:
```
ucsi_acpi USBC000:00: GET_CURRENT_CAM command failed
```
Fixed by skipping the command when there is nothing to update.
Fixes: da87d45b1951 ("usb: typec: ucsi: Add Thunderbolt alternate mode support")
Assisted-by: Codex:deepseek-v4.1-flash
Cc: stable <stable@kernel.org>
Signed-off-by: Gris Ge <cnfourt@gmail.com>
Reviewed-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260930234611.468765-2-cnfourt@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
