| Age | Commit message (Collapse) | Author |
|---|
|
Instead of creating and removing the device sysfs attributes directly
during probe and remove of the driver, respectively, use dev_groups in
struct device_driver to point to the attribute definitions and let the
core take care of creating and removing them.
No intentional functional impact.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260731113632.158440-8-clamor95@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The lm3533_set_boost_freq() and lm3533_set_boost_ovp() functions are used
only in lm3533_device_setup(), which in turn is only called by
lm3533_device_init(). Incorporate their code directly into
lm3533_device_init() to simplify driver readability.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20260731113632.158440-7-clamor95@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The lm3533_als_set_input_mode() and lm3533_als_set_resistor() functions
are used only in lm3533_als_setup(). Incorporate their code into
lm3533_als_setup() directly to simplify driver readability.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Link: https://patch.msgid.link/20260731113632.158440-6-clamor95@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Instead of passing the entire lm3533 core data structure, only pass the
regmap and the light sensor presence flag to child devices.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Acked-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> #for-iio
Link: https://patch.msgid.link/20260731113632.158440-5-clamor95@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Using 'extern' is not required, drop them.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20260731113632.158440-4-clamor95@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Remove driver-specific regmap wrappers in favor of using regmap helpers
directly.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Link: https://patch.msgid.link/20260731113632.158440-3-clamor95@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Document the LM3533 - a complete power source for backlight, keypad and
indicator LEDs in smartphone handsets. The high-voltage inductive boost
converter provides the power for two series LED strings display backlight
and keypad functions.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Jonathan Cameron <jic23@kernel.org> #for light sensor
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org> #for backlight
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260731113632.158440-2-clamor95@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
bcom_ata_init() declared and assigned a struct bcom_ata_inc *inc that
was never read, tripping clang -Wunused-but-set-variable:
drivers/dma/bestcomm/ata.c:58:23: error: variable 'inc' set but not
used [-Werror,-Wunused-but-set-variable]
58 | struct bcom_ata_inc *inc;
| ^
Drop the declaration and the bcom_task_inc() call that fed it.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260908213334.593584-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Replace the devm_clk_get() + clk_prepare_enable() pair with
devm_clk_get_enabled(), which handles enable/disable and the
unprepare on driver detach automatically. This lets us drop the
err_irq cleanup label and the clk_disable_unprepare() calls in
probe error paths and at_dma_remove().
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260908212607.590224-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The driver open-codes several channel configuration and descriptor
control bitfield writes with left shifts. Define masks for those fields
and use FIELD_PREP() when programming the registers.
Valid field values keep the same encoding. FIELD_PREP() confines values
to their respective fields, but does not validate handshake numbers
supplied through DMA specifiers.
Suggested-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260902-dma-fix-v3-4-414c6449fbcc@ultrarisc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The CH_CFG2 channel priority field occupies bits 51:47 of the 64-bit
channel configuration register, corresponding to bits 19:15 of CH_CFG2_H.
The driver currently shifts the priority value by 20, programming the
wrong bits. Use bit 15 as the field position.
Fixes: 824351668a41 ("dmaengine: dw-axi-dmac: support DMAX_NUM_CHANNELS > 8")
Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260902-dma-fix-v3-3-414c6449fbcc@ultrarisc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
axi_chan_list_dump_lli() uses the channel-wide descs_allocated count to
walk the hw_desc[] array of a single transaction. If multiple
transactions have allocated LLIs, the channel count can exceed the
transaction-local nr_hw_descs and make the DMA error path read past the
end of hw_desc[].
Use the descriptor-local nr_hw_descs count when dumping LLIs.
Fixes: ef6fb2d6f1ab ("dmaengine: dw-axi-dmac: simplify descriptor management")
Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260902-dma-fix-v3-2-414c6449fbcc@ultrarisc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The snps,axi-max-burst-len property describes the number of beats in an
AXI burst, while the ARLEN and AWLEN fields encode that value minus one.
The driver keeps axi_rw_burst_len as the actual burst length so that
dma_device.max_burst reports the correct value. However, it also programs
that unencoded value directly into the hardware fields. A value of 256
therefore overflows the 8-bit fields and can cause AXI decode errors.
Subtract one only when constructing hardware descriptors, while keeping
the actual value for dma_device.max_burst.
Fixes: c454d16a7d5a ("dmaengine: dw-axi-dmac: Burst length settings")
Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260902-dma-fix-v3-1-414c6449fbcc@ultrarisc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The compound frame descriptors and embedded CDBs are allocated from the
cf_desc_pool with dma_pool_alloc(), which does not zero the memory. Only
cdb32, the gfm coefficients and the frame address/length fields are
programmed; the dpi_dest_spec/dpi_src_spec fields in the CDBs and the
rbro32 field of each frame are left uninitialized. The hardware reads
the whole block (frame 0 length is sizeof(struct fsl_re_xor_cdb) or
sizeof(struct fsl_re_pq_cdb)), so uninitialized heap contents are
exposed to the device on each new descriptor.
Use dma_pool_zalloc() in both fsl_re_chan_alloc_desc() and
fsl_re_alloc_chan_resources() so the descriptor and CDB memory is
zeroed before it is handed to the RAID engine.
Fixes: ad80da658bbc ("dmaengine: Driver support for FSL RaidEngine device.")
Assisted-by: opencode:deepseek-v4-flash-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260820031654.28450-1-rosenp@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Sysfb drivers currently use the given display mode for looking up the
panel orientation. But the look-up table stores the native geometry of
the panels, so the lookup fails if the current mode sizes differs.
Get the panel's native geometry with drm_edid_detect_panel_size() from
the EDID and use it for looking up the panel orientation.
v2:
- ofdrm: validate EDID header before using it (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-4-tzimmermann@suse.de
|
|
Add drm_edid_detect_panel_size() to extract the panel's preferred
display resolution from a given EDID. Required for setting up DRM's
panel orientation quirks in sysfb drivers.
v4:
- fix test for EDID PTD (Jani)
v3:
- mention use case in documentation (Jani)
- use is_detailed_timing_descriptor() (Jani)
- rename helper to drm_edid_detect_panel_size()
v2:
- handle EDID without pixel timing descriptor (Sashiko)
- fix checks for width and height pointers
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-3-tzimmermann@suse.de
|
|
The Lenovo D330 is a notebook with detachable display. The display
is installed in landscape orientation, but the display mode is in
portrait orientation. By default, the display output is rotated to
the left by 90°.
The sysfb quirk breaks the display by swapping display width and
height; and thus mixing up the display geometry. Fix this by keeping
the display as-is. The sysfb DRM drivers, usually efidrm, will pick
the correct panel orientation for the display.
The exact behavior might depend on the version of the BIOS release,
but the exact version numbers of broken and good releases are unknown.
Users are advised to update to the latest firmware.
Tested on a Lenovo D330-10IGM IdeaPad with firmware 8NCN43WW.
v3:
- mention possible dependency on BIOS release in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-2-tzimmermann@suse.de
|
|
ene_ub6250_probe() sets us->transport but never sets
us->transport_reset. get_transport() only fills in transport_reset
for the standard USB_PR_CB/CBI/BULK protocols; since this driver
matches on VID/PID alone, a device can report any bInterfaceProtocol
value and still bind, leaving transport_reset NULL.
When the transport then reports an error, usb_stor_invoke_transport()
calls us->transport_reset(us) in its Handle_Errors path, dereferencing
a NULL function pointer:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:0x0
Call Trace:
usb_stor_invoke_transport+0x55a/0x1a40 drivers/usb/storage/transport.c:926
usb_stor_control_thread+0x44c/0x8f0 drivers/usb/storage/usb.c:462
kthread+0x38b/0x480 kernel/kthread.c:436
Set transport_reset to usb_stor_Bulk_reset: ene_send_scsi_cmd()
already frames its command/status packets with the shared
struct bulk_cb_wrap/bulk_cs_wrap from include/linux/usb/storage.h
and only ever transfers over us->send_bulk_pipe/recv_bulk_pipe, i.e.
this device speaks the Bulk-Only Transport wire protocol underneath
its own SCSI translation layer, so the Bulk-Only reset is the correct
recovery action for it, matching the pattern already used by the
other subdrivers with a custom transport function (alauda, datafab,
jumpshot, karma).
Also harden usb_stor_probe2()'s existing sanity check to require
transport_reset alongside transport and proto_handler, so a future
subdriver making the same mistake fails to probe instead of crashing
on the first error recovery.
Reported-by: syzbot+356ae236154297f0d60d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=356ae236154297f0d60d
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260909171926.54111-1-ngocthang2710.1999@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
SET_CONFIGURATION is handled asynchronously by the mass-storage thread.
A class request can arrive after the composite core selects the function
but before the thread installs common->fsg, or while the function is being
disabled.
fsg_setup() already rejects this state with -EOPNOTSUPP, but checking it
through fsg_is_set() also emits a warning. Check the active function
directly so normal requests during a configuration transition are rejected
without hiding fsg_is_set() warnings from other internal paths.
Fixes: 8876f5e7d3b2 ("USB: gadget: f_mass_storage: added eject callback")
Reported-by: syzbot+d31109047baed8f3b590@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d31109047baed8f3b590
Signed-off-by: Keisuke Tsukuda <tkdkei@outlook.jp>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260908203348.95825-3-tkdkei@outlook.jp
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
A SET_CONFIGURATION request that disables the current configuration, or a
disconnect, can abort a control transfer whose status stage was delayed by
a function driver. The asynchronous function work can nevertheless finish
later and call usb_composite_setup_continue() after reset_config() has
cleared delayed_status.
This is an expected consequence of aborting the old control transfer, and
does not require a kernel warning. Keep the diagnostic available under
dynamic debug and ignore the obsolete completion as before.
Fixes: 2bac51a1827a ("usb: gadget: composite: reset delayed_status on reset_config")
Reported-by: syzbot+a83a5a1ba9ff57935171@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a83a5a1ba9ff57935171
Signed-off-by: Keisuke Tsukuda <tkdkei@outlook.jp>
Link: https://patch.msgid.link/20260908203348.95825-2-tkdkei@outlook.jp
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
hsotg->regset is allocated in dwc2_debugfs_init() using devm_kzalloc(),
which ties its lifetime to the device (struct dwc2_hsotg) rather than
to the debugfs entries it serves. dwc2_debugfs_exit() removes the
debugfs directory but leaves hsotg->regset allocated until the device
itself is removed, so the pointer dangles for the remainder of the
device lifetime.
Switch to kzalloc() and free it explicitly in dwc2_debugfs_exit() so
the regset lifetime matches the debugfs lifetime. Set the pointer to
NULL after freeing to avoid a stale dangling pointer.
Reported-by: kakapapa2 <kakapapa2@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219977
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Huang Wei <huangwei@kylinos.cn>
Link: https://patch.msgid.link/20260909021014.906548-1-huangwei@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
dwc2_hsotg_rx_data() reads the OUT packet length from the RX FIFO status
(GRXSTS.BYTECNT, host-controlled) and, when it exceeds the remaining
space of the active gadget request (max_req = req.length - req.actual),
merely fires WARN_ON_ONCE(1) and then stores the whole packet into
hs_req->req.buf + req->req.actual via dwc2_readl_rep():
req.actual += size;
dwc2_readl_rep(hsotg, EPFIFO(ep_idx), req.buf + actual,
DIV_ROUND_UP(size, 4));
A packet larger than the request buffer therefore over-writes up to
maxpacket bytes past it. The rounded-up word read additionally emits up
to 3 bytes past the logical end even when the size does not exceed the
remaining space (short-request boundary).
Attack chain (USB peripheral/gadget mode, PIO only; the attacker is the
USB host):
malicious host -> OUT packet on epN -> RX FIFO interrupt
-> dwc2_hsotg_handle_rx() (GRXSTS_PKTSTS_OUTRX / SETUPRX)
-> dwc2_hsotg_rx_data(hsotg, epnum, BYTECNT=64) with the queued
request having req.length=8, req.actual=7 (1 byte left)
-> "to_read(64) > max_req(1)" -> WARN_ON_ONCE(1) only
-> dwc2_readl_rep() writes 16 words at req.buf+7
-> 63 bytes past the 8-byte request buffer
Reproduced (kernel 7.2.0+, KASAN/SLUB debug): calling the real
dwc2_hsotg_rx_data() with the above state (request buffer 8 bytes,
actual 7, size 64) triggers the WARN and leaves req.actual = 71 (the
64 bytes are accrued regardless), and the SLUB redzone immediately
after the 8-byte object plus neighbouring slab objects are overwritten
with FIFO content (byte 7 changes from a marker to FIFO data) - the
out-of-bounds write is visible byte-for-byte. The FIFO read is done by
raw 32-bit I/O words, which generic KASAN does not instrument, so the
redzone/neighbour clobber is the forensic evidence.
Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn>
Assisted-by: opencode:deepseek-v4-flash-free
Link: https://patch.msgid.link/20260826133401.3796639-1-lihaofeng@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Without handling for b_hnp_enable, a_hnp_support, and a_alt_hnp_support,
HNP cannot be enabled when two OTG controllers are connected.
Handle SetFeature for these OTG selectors, gated on otg_caps.hnp_support.
The OTG specification only defines SetFeature for them, so reject
ClearFeature with -EINVAL instead of silently accepting it. Use dev_dbg
for status updates to avoid noisy logs.
Advertise the core's HNP/SRP capability during gadget init by restoring
GUSBCFG_HNPCAP/SRPCAP from otg_caps, mirroring dwc2_gusbcfg_init() on the
host side, instead of clearing them unconditionally.
Clear the HNP flags and GOTGCTL_DEVHNPEN on disconnect/reset so OTG state
does not leak across sessions.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
Link: https://patch.msgid.link/e1f4718cadf28c4348bcf6ebb025f71732416538.1786950594.git.tze.yee.ng@altera.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
ttm_tt_swapout() returns the number of pages swapped out on success and
a negative error code on failure; for a populated ttm it never returns
zero. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU
walk on swapout failure") moved the bulk_move bookkeeping in
ttm_bo_swapout_cb() under "if (!ret)", so the
ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail()
pair is now skipped on every successful swapout. The equivalent change
for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink()
infinite LRU walk on backup failure") tests "lret > 0", which is what
was intended here as well.
Before b2ed01e7ad3d the resource was taken off the bulk_move before the
swapout; since then a swapped-out resource stays inside its BO's
bulk_move range (and on the manager LRU) although it is unevictable.
When it is later freed or the BO leaves the bulk_move
(ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()),
ttm_resource_del_bulk_move() skips it because of its
!ttm_resource_unevictable() guard, so a range endpoint in pos->first /
pos->last is left pointing at freed memory. The next
ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor
is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(),
"list_del corruption" in ttm_resource_move_to_lru_tail() or a NULL
dereference in ttm_resource_manager_next() -- minutes to hours after a
hibernation, or at process exit / reboot following one. Samuel
Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the
dangling cursor; the missing removal at swapout time is the reason it
dangles.
Testing the condition for success restores the removal. On an AMD
Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on
a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug
crashed 5 of 18 hibernation cycles; a function profile of one
hibernation showed 336 ttm_tt_swapout() calls and zero
ttm_resource_del_bulk_move_unevictable() calls. With this change the
removal happens for every swapped-out resource and 12 further cycles
were clean.
Fixes: b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure")
Cc: stable@vger.kernel.org # v7.1+
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5387
Link: https://lore.kernel.org/dri-devel/CAHYiNPa6aVacJoLOje-qZ1GyYx-9p0tN4NuP8D_eSL+UJeevXw@mail.gmail.com/
Signed-off-by: Vadim Nikitushkin <bub4z0r@gmail.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260909205028.13799-1-bub4z0r@gmail.com
|
|
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no IRQ is available, while other errors should be propagated.
Propagate errors such as -EPROBE_DEFER and -EINVAL instead of continuing
probe without the IRQ.
Acked-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260810093112.47807-1-phucduc.bui@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Some UDC drivers propagate the controller OF node to the gadget device
but there are no (and has never been any) users of this as the
devicetree binding and composite driver support was never merged. [1]
Drop the unused and incomplete support for OF node propagation which if
ever needed should be handled by UDC core.
Note that this also avoids probe failures when reusing an OF node that
describe resources like pinctrl that are managed by driver core (cf.
commit 48ed32482c41 ("usb: gadget: aspeed: Fix probe regression")).
Link: https://lore.kernel.org/all/1340720833-781-1-git-send-email-aletes.xgr@gmail.com/ [1]
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260702145350.109509-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was
registered before that state was initialized, while teardown released the
buffer before free_irq() synchronized the handler.
Initialize the EQ without arming it, register the IRQ, and then arm it.
Reverse the resource order during teardown by freeing the IRQ before
destroying the EQ.
Fixes: 2a152512a155 ("RDMA/efa: CQ notifications")
Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-2-dd9d9267fbf4@nvidia.com
Reviewed-by: Michael Margolin <mrgolin@amazon.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
|
The management IRQ handler accesses both the admin completion queue and the
async event queue. The driver registered the IRQ before constructing these
queues and destroyed them before freeing the IRQ, so the handler's lifetime
was not contained by the resources it accesses.
Initialize the queues with interrupts masked, request the IRQ, and then
switch to interrupt mode. On removal, reset the device and free the IRQ
before destroying the queues. Also reset the device before destroying the
queues if IRQ registration fails, because the device already has their DMA
addresses.
Fixes: b7f5e880f377 ("RDMA/efa: Add the efa module")
Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-1-dd9d9267fbf4@nvidia.com
Reviewed-by: Michael Margolin <mrgolin@amazon.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
|
|
Correct "binded" to "bound", reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Peter Chen <peter.chen@kernel.org>
Link: https://patch.msgid.link/20260907061652.38637-1-hemanth.selam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The dma_fence abstractions added by commit 3282d5916019 ("rust: Add
dma_fence abstractions") are compiled unconditionally, but the C
`dma_fence_*` symbols they reference live in
drivers/dma-buf/dma-fence.c, which is only built when
CONFIG_DMA_SHARED_BUFFER=y. Kernels with CONFIG_RUST=y and
CONFIG_RUST_KERNEL_DOCTESTS=y but CONFIG_DMA_SHARED_BUFFER=n fail
to link:
ld.lld: error: undefined symbol: dma_fence_release
>>> referenced by usercopy_64.c
>>> vmlinux.o:(rust_helper_dma_fence_put)
... dma_fence_signal{,_locked}, dma_fence_context_alloc,
dma_fence_init, dma_fence_{add,remove}_callback ...
Wrap the dma_fence.c helper include in the same
`pub mod dma_buf;` in rust/kernel/lib.rs with a matching #[cfg].
Fixes: 3282d5916019 ("rust: Add dma_fence abstractions")
Signed-off-by: Edwin Peer <epeer@nvidia.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260909202327.33285-1-epeer@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
This is a sibling fix of commit
b84c5632c7b3 ("net: net_failover: Fix the deadlock in slave register").
There is netdev_lock_ops() in the upper callers, so using netif_open()
instead of dev_open().
Call Trace:
__schedule+0x2bb/0x650
schedule+0x27/0xb0
schedule_preempt_disabled+0x15/0x30
__mutex_lock.constprop.0+0x550/0xaf0
__mutex_lock_slowpath+0x13/0x20
mutex_lock+0x3b/0x50
dev_open+0x3b/0xe0
net_failover_slave_name_change+0x22/0x40
failover_event+0xd4/0x1e0
notifier_call_chain+0x62/0xf0
raw_notifier_call_chain+0x16/0x30
call_netdevice_notifiers_info+0x50/0x80
netif_change_name+0x200/0x330
do_setlink.isra.0+0xb12/0xdf0
? security_capable+0x9a/0x1e0
? ns_capable+0x31/0x60
rtnl_setlink+0x302/0x670
? netlink_recvmsg+0x296/0x340
? security_capable+0x9a/0x1e0
? __pfx_rtnl_setlink+0x10/0x10
rtnetlink_rcv_msg+0x384/0x460
? __pfx_rtnetlink_rcv_msg+0x10/0x10
netlink_rcv_skb+0x61/0x120
rtnetlink_rcv+0x15/0x30
netlink_unicast+0x28f/0x3c0
netlink_sendmsg+0x216/0x450
__sys_sendto+0x222/0x230
__x64_sys_sendto+0x24/0x40
x64_sys_call+0x1d5d/0x2390
do_syscall_64+0x105/0x5a0
? do_syscall_64+0x140/0x5a0
? exc_page_fault+0x94/0x1e0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations")
Signed-off-by: Faicker Mo <faicker.mo@gmail.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260908040708.3972058-1-faicker.mo@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The AN8811HB comes in two package variants, AN8811HBCN and AN8811HBN,
which use different GPIO pins to drive LED outputs. AN8811HBCN uses
GPIOs 0, 1, and 15, while AN8811HBN uses GPIOs 3, 4, and 5. Using a
fixed GPIO assignment causes incorrect LED behavior on one of the
variants.
Read the package variant from the read-only silicon identification bits
in AN8811HB_HWTRAP2 at probe time and store it in priv->is_an8811hbcn.
Add an8811hb_led_gpio_setup() to configure the correct GPIO output pins
and select lines based on the detected variant, and call it from
config_init.
Signed-off-by: Weiting Lee <weiting.lee@airoha.com>
Link: https://patch.msgid.link/20260907015638.2875763-1-weiting.lee@airoha.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Use #address-cells = <1> and #size-cells = <1> because we don't need
64-bit register addressing for this hardware. While at it, also adjust
the ranges property to encompass the entire AHUB range as per the TRM.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The refactoring is going to alter the default behavior of
alloc_workqueue() to be unbound by default.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU. For more details see the Link tag below.
This is also enforced by:
commit 21c05ca88a548 ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present")
In order to keep alloc_workqueue() behavior identical, explicitly request
WQ_PERCPU.
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20260907094822.121457-1-marco.crivellari@suse.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
When the is_transport_polling_capable() check fails in scmi_raw_message_send(),
it returns -EINVAL without doing scmi_xfer_raw_put(), which will leak a
struct scmi_xfer.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260909-scmi-async-done-race-v2-0-cc5dec25c6be%40rivian.com
Fixes: 07cb8c324b63 ("firmware: arm_scmi: Add polling support to raw mode")
Signed-off-by: Roland Dreier <rolanddreier@rivian.com>
Link: https://patch.msgid.link/20260909-scmi-raw-v1-1-de3fa75d2c6f@rivian.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
In SCMI raw mode, scmi_xfer_raw_worker() releases the xfer before
releasing the waiter that disarms xfer->async_done, and scmi_xfer_get()
does not clear async_done when it hands out a recycled xfer. A concurrent
transaction can therefore pick up the xfer while it still points at the
old waiter's completion, so:
- a delayed response arriving for the new transaction can be signalled
on the old waiter's completion, which may already be re-armed for yet
another unrelated transaction, making that transaction's wait return
early; and
- the old waiter's disarm, which still runs after the xfer has been
released, clobbers the arming just installed by the new transaction,
so the new waiter times out even if its delayed response arrives.
Release the waiter first, while the worker still holds a reference on
the xfer, so that an xfer can never reach the free list still
armed. Track whether a delayed response is expected in the waiter
itself instead of peeking at xfer->async_done outside xfer->lock, and
wait on the waiter's own embedded completion. (The new async flag is
not strictly needed but it makes the logic easier to reason about)
Finally, harden scmi_xfer_get() to clear async_done when handing out
an xfer, so that no future release-ordering change can leak a stale
arming into a new transaction.
Fixes: 3c3d818a9317 ("firmware: arm_scmi: Add core raw transmission support")
Signed-off-by: Roland Dreier <rolanddreier@rivian.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://patch.msgid.link/20260909-scmi-async-done-race-v2-2-cc5dec25c6be@rivian.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Asynchronous SCMI commands are completed by a delayed response. The RX
path signals the response with complete(xfer->async_done). Unlike
xfer->done, xfer->async_done is a pointer to a completion owned by
whoever is waiting for the delayed response, and it stays valid only for
as long as that waiter is still waiting. In do_xfer_with_response() it
is a DECLARE_COMPLETION_ONSTACK() in the caller's stack frame.
Nothing serialises the RX path against a waiter that gives up on a
timeout. scmi_msg_response_validate() does read xfer->async_done
under xfer->lock, and documents that as a requirement, but the lock is
dropped again before scmi_handle_response() dereferences the pointer,
and neither the arming nor the disarming side takes it at all. So a
delayed response arriving just as the wait times out can be signalled
on a completion that is already gone:
waiter RX path (IRQ context)
------ ---------------------
do_xfer_with_response():
xfer->async_done = &async_response
do_xfer(xfer)
wait_for_completion_timeout(xfer->async_done, tmo)
/* returns 0, gives up */
/* response receive interrupt */
scmi_handle_response():
scmi_xfer_command_acquire()
lock xfer->lock
validate: async_done != NULL
unlock xfer->lock
xfer->async_done = NULL
return -ETIMEDOUT
/* async_response goes out of scope */
complete(xfer->async_done)
That last complete() has two possible bad outcomes: it either dereferences
the NULL just stored by the waiter or - if that store is not yet visible
on the RX CPU - it takes a lock and writes to a stack frame that the
waiter may already have returned from.
Fix this by making xfer->lock cover xfer->async_done end-to-end. Add
helpers to arm and disarm it under the lock, use them on both the regular
and the raw paths, and have the RX path read and signal the completion
under that same lock. A waiter that is timing out then either completes
its disarm before the RX path looks, in which case the delayed response is
dropped, or blocks in the disarm until the RX path is done with the
completion, in which case the completion is still alive.
Log the dropped case, so every path where a delayed response that was
matched to a pending xfer and then discarded produces an error. (This is
the same treatment scmi_msg_response_validate() already gives a
delayed response that arrives after the waiter has disarmed the xfer)
Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response")
Signed-off-by: Roland Dreier <rolanddreier@rivian.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://patch.msgid.link/20260909-scmi-async-done-race-v2-1-cc5dec25c6be@rivian.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
Use proper available ftrace macros to handle tag strings of variable size,
to avoid wasting space using statically oversized arrays while risking to
expose stale stack data when such array is not properly padded when filled.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://patch.msgid.link/20260808191234.402312-1-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
The gpi_ch_init() error handling paths do not fully clean up resources
when channel initialization fails.
The unwind paths iterate over the original channel pointer instead of
the channels stored in gpii->gchan[], preventing previously initialized
sibling channels from being properly reset and deallocated.
In addition, gpi_alloc_chan_resources() allocates ch_ring before calling
gpi_ch_init(), but does not release it when initialization fails,
resulting in a memory leak.
The event ring cleanup path also leaves the PM state unchanged after
freeing the ring. As a result, subsequent cleanup may incorrectly assume
that the ring is still allocated, leading to a redundant EV_CMD_DEALLOC
command and an attempt to deallocate an already released ring.
Fix the unwind paths to operate on the correct channels, release
ch_ring when channel initialization fails, and restore the event ring
PM state after freeing the ring.
Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
Reviewed-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Link: https://patch.msgid.link/20260810-gpi_bug_fix-v2-1-60555394cbf9@oss.qualcomm.com
Link: https://patch.msgid.link/20260819-gpi_bug_fix-v3-1-4c97333e6f5b@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
sprd_dma_enable() enabled sdev->clk and then the optional ashb_clk. If
enabling ashb_clk failed, sdev->clk was left enabled: both callers
(probe and resume) treat a non-zero return as "nothing was enabled" and
bail out, leaking sdev->clk.
Convert the driver to the clk_bulk API. clk_bulk_prepare_enable()
enables all clocks and unwinds them on failure, and
clk_bulk_disable_unprepare() disables them, which fixes the imbalance
and simplifies the enable/disable paths. Both clocks are fetched with
devm_clk_bulk_get_optional(); the optional ashb_eb clock simply becomes
a NULL entry that the bulk helpers treat as a no-op, while the mandatory
enable clock is still checked explicitly.
Fixes: 9b3b8171f7f4 ("dmaengine: sprd: Add Spreadtrum DMA driver")
Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260819053518.2825514-1-nagachaithanya9911@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
da8xx_probe() creates the CPPI child devices before registering the MUSB
platform device. If population partially succeeds or the later MUSB
registration fails, the probe path unregisters the generic PHY but leaves
the OF children registered under a parent whose probe failed.
Depopulate the OF children before unregistering the PHY on both failure
paths. Use one cleanup label so each resource is unwound in reverse
publication order without introducing an unused label.
Fixes: d6299b6efbf6 ("usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx")
Assisted-by: Codex:gpt-5
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260813153230.40421-1-pengpeng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
da8xx_probe() creates CPPI platform devices with of_platform_populate(),
but da8xx_remove() unregisters only the separately created MUSB device and
the generic PHY. The OF children therefore remain registered after the
glue driver is unbound.
Pair the successful population with of_platform_depopulate() during remove.
Unregister the MUSB device first because it reuses the parent DT node but
was not created by of_platform_populate().
Fixes: d6299b6efbf6 ("usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx")
Assisted-by: Codex:gpt-5
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260813153353.42817-1-pengpeng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use the matching DMA direction when unmapping requests, reset the
endpoint sequence before clearing its number, and update rather than
accumulate endpoint configuration fields. Only dequeue requests that
are actually queued and reject interrupts not owned by the UDC.
Keep peripheral mode from sourcing VBUS, avoid sleeping under the UDC
spinlock, and unwind the IRQ, notifier, PHY, MMIO, and gadget resources
in ownership order.
Suggested-by: Daniel Palmer <daniel@thingy.jp>
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-6-dd92ecf5675b@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Replace the private EHCI fork with an hc_driver built from the common
EHCI implementation. Configure the FOTG210 register, root-hub TT,
speed-reporting, port-reset, and Gemini timing quirks through the new
hooks.
Keep role selection fixed at probe time, while cleaning up clock/reset
handling, interrupt masks, Gemini syscon setup, VBUS sequencing, probe
failures, shutdown, and system sleep. Device trees without dr_mode
retain their historical host default.
Suggested-by: Daniel Palmer <daniel@thingy.jp>
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-5-dd92ecf5675b@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Some EHCI implementations omit CONFIGFLAG and USBMODE, or have an
integrated transaction translator that cannot schedule siTDs.
Add quirks to skip CONFIGFLAG and TDI mode accesses and to reject
full- and low-speed isochronous transfers. Standard controllers retain
their current behavior.
Suggested-by: Daniel Palmer <daniel@thingy.jp>
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-4-dd92ecf5675b@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Some EHCI implementations report device speed in
implementation-defined registers.
Add an optional hook for port speed reporting. Move the common
integrated-TT speed decoding into the hub code, preserving the PORTSC
and HOSTPC paths when no hook is supplied.
Gate the callback behind the hidden USB_EHCI_PORT_SPEED_HOOK option so
controllers using standard speed reporting incur no extra state or
runtime checks.
The hook is only meaningful for controllers with an integrated root
hub transaction translator, so make the option depend on
USB_EHCI_ROOT_HUB_TT.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: Daniel Palmer <daniel@thingy.jp>
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-3-dd92ecf5675b@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Some EHCI implementations need controller-specific sequencing around
port reset.
Add optional hooks for reset preparation and completion. Controllers
without the hooks retain the existing behavior.
Gate the callbacks behind the hidden USB_EHCI_PORT_RESET_HOOKS option
so controllers using standard reset sequencing incur no extra state or
runtime checks.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: Daniel Palmer <daniel@thingy.jp>
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-2-dd92ecf5675b@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Some EHCI implementations place the port status registers outside the
standard operational register layout.
Add a per-controller port status base and use a helper for all PORTSC
accesses, while preserving the standard location by default.
Gate the alternate member and lookup behind the hidden
USB_EHCI_DEVIANT_PORT_STATUS_REG option. This avoids growing struct
ehci_hcd or adding a runtime branch on systems using the standard port
status register location.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: Daniel Palmer <daniel@thingy.jp>
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260903-gemini-usb-fotg2-v3-1-dd92ecf5675b@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit be7b1c68cd3e4fc0f5a4e1b85696de1052f21f2f.
Commit be7b1c68cd3e ("usb: dwc3: qcom: Add support to skip phy management by USB core")
is causing a regression on qualcomm platforms.
During role switch it tends to cause the following crash:
[ 5.620951] refcount_t: underflow; use-after-free.
[ 5.621114] Call trace:
[ 5.621115] refcount_warn_saturate+0xd8/0x140 (P)
[ 5.621117] kobject_put+0x11c/0x230
[ 5.621121] software_node_notify_remove+0xdc/0xf8
[ 5.621124] device_del+0x1dc/0x328
[ 5.621126] usb_disconnect+0x1d8/0x348
[ 5.621129] usb_remove_hcd+0x100/0x2a8
[ 5.621131] xhci_plat_remove+0x8c/0x170
[ 5.621134] platform_remove+0x28/0x40
[ 5.621135] device_release_driver_internal+0x174/0x290
[ 5.621138] device_release_driver+0x20/0x38
[ 5.621140] bus_remove_device+0x19c/0x1f8
[ 5.621142] device_del+0x1c4/0x328
[ 5.621143] platform_device_unregister+0x34/0xc0
[ 5.621145] dwc3_host_exit+0x50/0x70
[ 5.621146] __dwc3_set_mode+0xa4/0x378
[ 5.644535] Unable to handle kernel paging request at virtual address
[ 5.644657] Workqueue: events_freezable __dwc3_set_mode
[ 5.644664] pc : __pi_strcmp+0x9c/0x140
[ 5.644668] lr : software_node_property_present+0x60/0x98
[ 5.644697] Call trace:
[ 5.644698] __pi_strcmp+0x9c/0x140 (P)
[ 5.644700] device_property_present+0x9c/0xc0
[ 5.644703] dwc3_gadget_init+0x230/0x7b0
[ 5.644704] __dwc3_set_mode+0x314/0x378
[ 5.644707] process_scheduled_works+0x1b8/0x538
[ 5.644710] worker_thread+0x1fc/0x2f8
[ 5.644711] kthread+0x114/0x148
[ 5.644713] ret_from_fork+0x10/0x20
Revert skipping of usb core phy management for Qualcomm platforms to avoid
the above issues.
Reported-by: Val Packett <val@packett.cool>
Closes: https://lore.kernel.org/all/f9926203-ee69-4e18-b6c7-95261ba10807@packett.cool/
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260909-xhci-fixes-revert-v1-1-7cc97fa0f307@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
