| Age | Commit message (Collapse) | Author |
|---|
|
In case any probe error occurs (usually, a probe deferral) the
power domains shall be cleaned up while respecting their child
to parent relationship, or the system may freeze.
In order to do that without any memory footprint impacts after
the fact, allocate a temporary array in the probe function and
use it to store the indices of the added power domains in the
correct order.
This will be used in the error cleanup path and will be freed
at the end regardless of the probe status as, when the probing
succeeds, the genpd API takes care of unregistering all PDs in
the correct order anyway.
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Merge the pmdomain fixes for v7.2-rc[n] into the next branch, to allow
them to get tested together with the pmdomain changes that are targeted
for the next release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Should probe fail for HW_VOTER type power domains, this driver was
unconditionally trying to perform cleanup for DIRECT_CTL domains,
but only after checking if the target domain is powered on... with
the DIRECT_CTL scpsys_domain_is_on() code again.
And there's more: the scpsys_domain_is_on() function is also being
unconditionally used in the probe path, for any power domain that
has flag MTK_SCPD_KEEP_DEFAULT_OFF!
This bug was never experienced by anyone because the HWV domains
never failed probe, and because none of those is declared with the
aforementioned flag - but it's still something critical.
In order to fix this, add a check for MTCMOS Type and, based on
that, call the correct functions for an "is on" check, and also
do the same for the cleanup path, calling the correct functions
for the "power off" action.
For the latter, since there's a call to pm_genpd_remove() right
before calling power_off, be cautious and add a variation of the
power off functions (with a _internal suffix) for those to get a
pointer to scpsys_domain instead of one to generic_pm_domain as,
even if that's still working, this is way too much fragile and
would break at some point.
Fixes: 88914db077b6 ("pmdomain: mediatek: Add support for Hardware Voter power domains")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
* for-next/scmi/fixes:
firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context
firmware: arm_scmi: Use 64-bit division for clock rate rounding
firmware: arm_scmi: Grammar s/may needed/may be needed/
* for-next/ffa/fixes:
firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()
firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Retention is very rarely an operational corner. In the majority of
cases, HW cannot operate properly at Retention levels and so the minimum
operational level when enabling a rail is the first corner above
Retention. A small subset of always-on use cases can operate at
Retention, but those aren't controlled from HLOS.
Currently, we allow Retention by default and only disallow it special
cases. But this leaves us open to various failures when the PD is
enabled without first being voted to an OPP above Retention. Such as
when a child GDSC PD requests to enable its parent RPMh PD. In this
case, the GDSC would get stuck powering on.
Newer chips have started supporting Retention on rails that didn't
previously (such as for MMCX). Instead of adding more special cases to
skip Retention on MMCX, start skipping Retention by default since it's
almost never desired from an HLOS perspective.
Signed-off-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
bcm2835_power_probe() initializes all power domains and then registers
the onecell genpd provider, but ignores of_genpd_add_provider_onecell()
failures. Probe can therefore return success even though no provider was
published.
Check the provider registration return value and jump to the existing
cleanup path on failure.
Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under a new binding.")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Fix grammar in the help text for the ARM_SCMI_POWER_DOMAIN symbol.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260704122123.73004-1-pengpeng@iscas.ac.cn
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The Commubox FXA291 by Endress+Hauser AG is a USB serial converter
based on FT232B which is used to communicate with field devices.
It enumerates using the FTDI vendor ID and a custom PID.
usb 1-9: New USB device found, idVendor=0403, idProduct=e510, bcdDevice= 4.00
usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-9: Product: FXA291
usb 1-9: Manufacturer: Endress+Hauser
usb 1-9: SerialNumber: 00000000
ftdi_sio 1-9:1.0: FTDI USB Serial Device converter detected
usb 1-9: Detected FT232B
usb 1-9: FTDI USB Serial Device converter now attached to ttyUSB0
Signed-off-by: Tim Pambor <timpambor@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Killing the interrupt-in urb when the line disciple requests throttling
may lead to data loss if an ongoing transfer is cancelled.
Instead set a flag to prevent the completion handler from resubmitting
the urb until the port is unthrottled.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Forward from rc1 to rc3 to track upstream closer again.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
The driver data usb-serial pointer is unused since commit 66c32e483355
("USB: serial: keyspan_pda: drop redundant usb-serial pointer"), which
apparently failed to remove the pointer as intended.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Three functions are initialising their return value variables at
declaration only to later assign them unconditionally.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
If the completion handler races with unthrottle() both functions may try
to resubmit the same interrupt-in urb, but at most one will succeed.
Fix the unthrottle logic using a throttle-requested flag so that only
one attempt to resubmit the urb is made to avoid logging an error.
Fixes: 43d186fe992d ("USB: serial: add metro-usb driver to the tree")
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The unthrottle callback is allowed to sleep so pass the correct GFP flag
to usb_submit_urb() to avoid unnecessary atomic allocations.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The OOB port is not registered with driver core and does not have a
name.
Use the USB interface with dev_printk() that may involve the OOB port to
avoid log entries with no driver and a "null" device name.
Fixes: f9dfbebb8b39 ("USB: serial: digi_acceleport.c: remove dbg() usage")
Fixes: 194343d9364e ("USB: remove use of err() in drivers/usb/serial")
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The mlx4 CM paravirtualization layer rewrites a VF's local
communication ID to a PF-visible ID when CM MADs are sent from the VF.
For messages that start or advance a connection from the VF side, such
as REQ, REP, MRA and SIDR_REQ, mlx4_ib_multiplex_cm_handler() allocates
an id_map_entry when no existing mapping is found.
A REJ is different because it is a terminal response to an already known
exchange. It should either find an existing id_map_entry, rewrite the
local communication ID, and schedule that entry for deletion, or it
should pass through unchanged when no mapping exists.
Some REJ messages, such as rejects for an inbound REQ before an MRA or
REP was sent, do not have an id_map_entry because their local_comm_id is
zero. Timeout REJ messages are handled in the initial lookup branch, but
a lookup miss there must not fall through to id_map_alloc(); such a miss
means there is no existing mapping to translate or delete for the REJ.
Commit 227a0e142e37 ("IB/mlx4: Add support for REJ due to timeout")
added the timeout REJ case to the initial branch so an outgoing timeout
REJ could reuse the id_map_entry that was created when the VF's REQ was
multiplexed. Reusing that entry is the useful part: it rewrites the
timeout REJ local_comm_id to the same PF-visible ID that was sent in the
REQ. If the lookup misses, allocating a new id_map_entry does not help
because the peer has never seen that new PF-visible ID, and REJ is not
starting a new exchange.
Keep timeout REJ handling in the initial lookup branch, but return before
allocation if no mapping is found. Handle the other REJ cases with the
same lookup-only behavior. When a mapping is found, translate the local
communication ID and schedule delayed deletion, as is already done for
DREQ and for received REJ in the demux path. When no mapping is found,
keep the existing pass-through behavior.
Signed-off-by: Praveen Kumar Kannoju <praveen.kannoju@oracle.com>
Link: https://patch.msgid.link/20260615171759.557425-1-praveen.kannoju@oracle.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
diagnose_failure_lnl() read VPU_HW_BTRS_MTL_INTERRUPT_STAT instead of
VPU_HW_BTRS_LNL_INTERRUPT_STAT, which on LNL and newer parts is a
different register with a different bit layout, so failure diagnostics
decoded the wrong register and reported a bogus error cause.
Read the LNL interrupt status register instead.
Fixes: 8a27ad81f7d3 ("accel/ivpu: Split IP and buttress code")
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260710101331.1899505-1-karol.wachowski@linux.intel.com
|
|
Clean up the inb command handling a bit by removing an unnecessary line
break and moving the assignment operator before breaking another long
expression.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Clean up the write completion handler by adding a temporary variable for
the transfer buffer and using the pre-existing urb pointer while
dropping some redundant casts.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add the missing space around operators in transfer-buffer length
expressions to make the code more readable.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Drop the in-buf size define which has not been used since the port
buffers were removed by commit 5fea2a4dabdf ("USB: digi_acceleport
further buffer clean up").
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The driver submits the OOB read urb on first open of a port and does not
stop it until the device is disconnected.
Add an open counter and submit the urb on first open and stop it on last
close to avoid wasting resources (e.g. power) when the device is not in
use.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The urb context pointer does not change while an urb is in flight so
there is never a need to check for NULL on completion.
The port driver data is not freed until the port is unbound at which
point all I/O for that port has been stopped (and I/O is no longer
started for a port that has not yet been probed).
The device driver data is not freed until after the driver has been
unbound and at which point all I/O has also ceased.
Drop the redundant, overly defensive (and still incomplete) sanity
checks from the completion callbacks.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Clean up the driver by moving some declarations to approximate reverse
xmas style and removing some stray newlines (and adding a few for
readability).
While at it, also replace two spaces before tabs in the driver structs.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add a helper function for retrieving the OOB port to replace two
convoluted expressions.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Explicitly stop the write urb on close() also if the device is being
unbound instead of relying on core to do it after returning.
Note that the dp_write_urb_in_use flag is cleared by the completion
handler.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Drop the close wait queue which has not been used since commit
335f8514f200 ("tty: Bring the usb tty port structure into more use").
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The driver submits the read urbs for all ports when the first port is
opened, which could happen before the other ports have been probed and
their private data set up.
If such an urb completes before the port has been probed, the completion
handler will not resubmit it, thus preventing any further reads.
Fix the ordering issue by not submitting the port read urbs until the
port is opened.
This also avoids wasting resources (e.g. power) when ports are not in
use.
Note that the port write urbs are already stopped on close (unless
unbinding, but they are also stopped by core on disconnect).
Fixes: fb44ff854e14 ("USB: digi_acceleport: fix port-data memory leak")
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Stopping an urb is not an error and should not be logged as such.
Demote the dev_err() in the read bulk completion handler to dev_dbg()
when an urb is being unlinked on disconnect.
Note that this will become more of an issue when the urbs are stopped
every time a port is closed.
This issue was flagged by Sashiko when reviewing the upcoming change.
Link: https://sashiko.dev/#/patchset/20260623150826.314727-1-johan%40kernel.org?part=2
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
dma_iova_destroy() frees the IOVA space through __iommu_dma_iova_unlink()
using a "free_iova" boolean, which duplicates the IOVA free logic in
dma_iova_free(). And it frees using the unmapped @mapped_len, which for a
partially linked reservation is smaller than the reserved size. This
results in a benign waste as pointed out by Robin, not a leak. So this is
a cleanup, not a fix.
Drop the duplicated free path. Fold __iommu_dma_iova_unlink into
dma_iova_unlink and remove the free_iova parameter so it only unmaps.
dma_iova_destroy then unlinks the mapped range if mapped_len is set and
unconditionally calls dma_iova_free, which frees the whole reservation
via dma_iova_size. The freed size now always matches the reserved size,
and destroy reads as unlink then free.
Note that dma_iova_destroy() no longer routes the free through the flush
queue; teardown now unmaps synchronously and frees directly, matching
dma_iova_free().
No functional change intended for callers.
Suggested-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Honglei Huang <honghuan@amd.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260703033729.455358-1-honghuan@amd.com
|
|
|
|
Wrap the dequeue_xmitframes_to_sleeping_queue() function declaration to
fix line exceeding 100 characters.
This fixes the following checkpatch.pl check:
- CHECK: line length of 126 exceeds 100 columns.
Signed-off-by: Pablo Vallespín Aranguren <pablopva014@gmail.com>
Link: https://patch.msgid.link/alPVQEAdoUFjHiJo@ThinkPad-P15
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add pinctrl configuration for Exynos8855. The bank type
macros are reused from EXYNOS850 and GS101 SoC.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://patch.msgid.link/20260627171228.2687857-4-alim.akhtar@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Correct eight PERIS gate clock parents to match the hardware clock
tree and reorder the GIC mux parents so mout_peris_bus_user is the
default source.
Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://patch.msgid.link/20260613-exynos990-peris-fix-v3-v3-3-2b230db78ae4@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Add the missing CLK_GOUT_PERIS_TMU_SUB_PCLK gate clock for the Thermal
Management Unit sub-block and update CLKS_NR_PERIS accordingly.
Signed-off-by: Denzeel Oliva <wachiturroxd150@gmail.com>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://patch.msgid.link/20260613-exynos990-peris-fix-v3-v3-2-2b230db78ae4@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The hand-rolled bit-scanning loop in the NCQ completion path has an
infinite loop bug. When tag_mask has only high bits set (e.g.
0x80000000), the inner while loop left-shifts tag_mask until it
overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1
stays 0, causing an infinite loop in hardirq context with a spinlock
held.
Replace the open-coded bit-scanning with __ffs() which correctly
finds the least significant set bit and is bounded by the width of
the argument.
Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
clear_interrupt_bit() ignores the bit argument and performs a
read-write-back of the entire INTPR register. If INTPR uses standard
Write-1-to-Clear semantics, this clears every pending interrupt bit,
not just the intended one. Coalesced interrupts (e.g. DMAT + NEWFP)
would be cleared together, silently losing the second event.
Write only the specific bit to clear so that other pending interrupts
are preserved.
Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
Replace irq_of_parse_and_map() with platform_get_irq() in both
sata_dwc_dma_init_old() and sata_dwc_probe(). This is the preferred
way to obtain IRQs for platform devices and provides better error
reporting. Remove the now-unnecessary #include <linux/of_irq.h>.
irq_of_parse_and_map() requires irq_dispose_mapping(), which is missing.
Also fix unused variable when CONFIG_SATA_DWC_OLD_DMA is disabled.
Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
sata_dwc_enable_interrupts() is called before platform_get_irq() and
ata_host_activate(), leaving the SATA controller's interrupt mask
enabled without a registered handler. If a later step fails (irq
request, phy init, etc.) or if the controller asserts an interrupt
during probe, the irq line may fire with no handler, causing a
spurious interrupt storm.
Move sata_dwc_enable_interrupts() after ata_host_activate() so that
interrupts are only unmasked once the handler is registered and the
core is fully initialized.
Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
|
|
We need the tty/serial fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
printer_read() uses the same variable for the requested copy size and
the number of bytes actually copied to user space. copy_to_user()
returns the number of bytes not copied, so when it fails to copy
anything, the computed copied length becomes zero.
In that case len, buf, current_rx_bytes and current_rx_buf are left
unchanged. If RX data is available and the user buffer remains
unwritable, the read loop can repeat indefinitely.
Track the copied length separately and return -EFAULT, or the number of
bytes already copied, if an iteration makes no progress.
Fixes: b185f01a9ab7 ("usb: gadget: printer: factor out f_printer")
Cc: stable <stable@kernel.org>
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com>
Link: https://patch.msgid.link/20260709205622.55700-1-mlbnkm1@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The f_midi driver embeds a work item (midi->work) whose handler,
f_midi_in_work(), dereferences the enclosing struct f_midi through
container_of(). This work is armed from two sites: f_midi_complete(),
on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA
rawmidi output-stream start.
Neither f_midi_disable() nor f_midi_unbind() cancels midi->work.
f_midi_disable() only disables the endpoints and drains the in_req_fifo;
it does not synchronize the work item, and the sound card is released
asynchronously to the final free of the midi object.
The midi object is reference-counted (midi->free_ref) and is freed in
f_midi_free() only once both the usb_function reference and the rawmidi
private_data reference have been dropped. In f_midi_unbind(),
f_midi_disable() runs before the sound card is released, so while the
USB endpoints are already disabled the rawmidi device is still usable by
an open substream. A concurrent userspace write on such a substream can
reach f_midi_in_trigger() and queue midi->work again after
f_midi_disable() has returned. A work item armed this way may still be
pending when the last reference drops and f_midi_free() proceeds to
kfree(midi), letting f_midi_in_work() dereference the struct after it
has been freed, a use-after-free.
For this reason cancelling midi->work in f_midi_disable() would not be
sufficient: the ALSA trigger path can rearm the work after disable()
returns. Cancelling at the refcount-zero free site is the boundary
after which neither arming source can survive, because by then both
references that keep the midi object alive have been dropped: the USB
endpoints are already disabled and the rawmidi device has been released.
Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero
block of f_midi_free(), before the embedded work_struct is freed along
with the rest of the structure. opts->lock is a sleeping mutex, so
calling cancel_work_sync() under it is permitted, and the handler takes
midi->transmit_lock rather than opts->lock, so no self-deadlock can
occur while it waits for a running instance of the work to finish.
This issue was found by an in-house static analysis tool.
Fixes: 8653d71ce3763 ("usb/gadget: f_midi: Replace tasklet with work")
Cc: stable <stable@kernel.org>
Assisted-by: Codex:gpt-5.5
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Link: https://patch.msgid.link/20260709150717.399083-1-fanwu01@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Broadcom BDC UDC driver registers its IRQ handler with
devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm
only after bdc_remove() returns. devm releases resources in reverse
LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() ->
bdc_mem_free() manually before returning: bdc_udc_exit() tears down
individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() ->
bdc_mem_free() frees and NULLs the DMA-coherent status-report ring
(bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while
the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED)
remains deliverable in the window up to the post-remove devm
free_irq().
On receipt of a shared interrupt in that window, bdc_udc_interrupt()
dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA)
and dispatches sr_handler callbacks that index into bdc_ep_array,
causing a NULL-deref or use-after-free.
The same window affects the delayed_work bdc->func_wake_notify, which is
armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change()
-> schedule_delayed_work() and may self-rearm from its own callback
bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a
queued work item that fires after bdc_remove() returns and the bdc
structure is devm-freed dereferences freed memory.
Replace devm_request_irq() with request_irq() and add an explicit
free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before
free_irq() to stop the device from asserting interrupts, then
free_irq() drains any in-flight handler, then cancel_delayed_work_sync()
drains the func_wake_notify delayed work. This ordering ensures the
IRQ handler and delayed work cannot interfere with the subsequent
endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the
matching free_irq() into the bdc_udc_init() error path so the IRQ is
released on probe failure, and route the bdc_init_ep() failure through
err0 instead of returning directly.
This issue was found by an in-house static analysis tool.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Cc: stable <stable@kernel.org>
Assisted-by: Codex:gpt-5.5
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Link: https://patch.msgid.link/20260709020904.502611-1-fanwu01@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
A synchronization issue exists during port unregistration where pending
partner work items can race against workqueue destruction, leading to
use-after-free conditions:
cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:__queue_work+0x83/0x4a0
Call Trace:
<IRQ>
__cfi_delayed_work_timer_fn+0x10/0x10
run_timer_softirq+0x3b6/0xbd0
sched_clock_cpu+0xc/0x110
irq_exit_rcu+0x18d/0x330
fred_sysvec_apic_timer_interrupt+0x5e/0x80
Fix this by ensuring strict ordering and proper serialization during
teardown:
1. Move ucsi_unregister_partner() to the beginning of the teardown
sequence and protect it under the connector mutex lock.
2. Ensure all pending partner tasks are explicitly flushed and finished
before the workqueue is destroyed.
3. Switch from mod_delayed_work() to a cancel_delayed_work() and
queue_delayed_work() sequence. This guarantees that items currently marked
as pending won't be scheduled an additional time, preventing a double
release of resources which leads to the following crash:
Oops: general protection fault, probably for non-canonical address
0xdead000000000122: 0000 [#1] SMP NOPTI
Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker
RIP: 0010:ucsi_poll_worker+0x65/0x1e0
Call Trace:
<TASK>
process_scheduled_works+0x218/0x6d0
worker_thread+0x188/0x3f0
__cfi_worker_thread+0x10/0x10
kthread+0x226/0x2a0
To ensure these rules are applied identically across both the normal
teardown and the ucsi_init() error paths, consolidate the cleanup logic
into a new helper, ucsi_unregister_port().
Cc: stable <stable@kernel.org>
Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking")
Fixes: b13abcb7ddd8 ("usb: typec: ucsi: Fix NULL pointer access")
Fixes: fac4b8633fd6 ("usb: ucsi: Ensure connector delayed work items are flushed")
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Link: https://patch.msgid.link/20260707141736.1635698-1-akuchynski@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length
against frame_max but does not verify that the datagram fits within the
declared block length. Additionally, when decoding multiple NTBs from a
single socket buffer, subsequent block lengths are not checked against the
actual remaining buffer data.
With these checks missing, a malicious USB host can specify datagram
offsets and lengths that point beyond the block, or supply secondary NTB
headers declaring lengths larger than the buffer. skb_put_data() then
copies adjacent kernel memory from skb_shared_info into the network skb.
Fix this by verifying that sufficient buffer space remains for the NTB
header before parsing, handling zero-length block declarations, ensuring
that block lengths never exceed the remaining buffer space, and verifying
that each datagram payload stays strictly within the block boundary.
Fixes: 427694cfaafa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call")
Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()")
Cc: stable <stable@kernel.org>
Assisted-by: Jetski:Gemini-2.5-Pro
Signed-off-by: Sonali Pradhan <sonalipradhan@google.com>
Link: https://patch.msgid.link/20260703083725.1903850-1-sonalipradhan@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The UDC pointer is set on successful probe and will never be NULL when
the driver is later unbound so drop the misleading sanity check (and
confused error message).
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260702141536.90887-5-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
A change replacing custom printk() macros with dev_printk() incorrectly
used the gadget struct device instead of the controller struct device
(including for messages printed before the gadget device name has been
initialised).
Switch to using the controller platform device with dev_printk() so that
the controller device and driver names are included in log messages as
expected.
Fixes: 6025f20f16c2 ("usb: gadget: fsl-udc: Replace custom log wrappers by dev_{err,warn,dbg,vdbg}")
Cc: stable <stable@kernel.org>
Cc: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20260702141536.90887-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
