* Re: [PATCH] USB: misc: iowarrior: fix use-after-free in release
From: Sam Sun @ 2026-06-23 12:28 UTC (permalink / raw)
To: Johan Hovold; +Cc: Greg Kroah-Hartman, Oliver Neukum, linux-usb, linux-kernel
In-Reply-To: <ajlZby4OXzCKECmJ@hovoldconsulting.com>
On Mon, Jun 22, 2026 at 11:49 PM Johan Hovold <johan@kernel.org> wrote:
>
> On Fri, Jun 19, 2026 at 11:03:37PM +0800, Yue Sun wrote:
> > From: Sam Sun <samsun1006219@gmail.com>
> >
> > iowarrior_release() clears dev->opened while holding dev->mutex and then
> > unlocks the mutex before freeing the device when it has already been
> > disconnected. If iowarrior_disconnect() is waiting for the same mutex, it
> > can acquire it while mutex_unlock() in release is still in progress,
> > observe dev->opened == 0, and free the same object.
>
> The above description is not correct as it seems to suggests that there
> is a double-free here, which there is not.
>
> Either release() or disconnect() will free the driver data, but the
> other one may still be executing mutex_unlock() when that happens.
>
> > This violates the
> > mutex_unlock() lifetime rule because the mutex storage can be freed before
> > mutex_unlock() has returned.
>
> Indeed. Thanks for catching this.
>
> > Fix this by adding a kref to struct iowarrior and holding one reference
> > for the USB interface, one for each opened file, and one for each
> > in-flight asynchronous write URB. Release, disconnect and write completion
> > now only drop their references after they are done using the object, and
> > the object is freed only after all users have released it.
>
> You only need a reference for each open file (and one while the driver
> is bound). All I/O must cease on disconnect so there is no need to keep
> an additional reference for each outstanding write.
>
> Note that there is another bug here for which the fix has not yet been
> applied though:
>
> https://lore.kernel.org/all/20260523170523.1074563-1-johan@kernel.org/
>
> > Reported-by: Sam Sun <samsun1006219@gmail.com>
>
> You shouldn't add a reported-by tag for issues you fix yourself. A Link
> to the syzbot report is good to have though.
>
> > Closes: https://lore.kernel.org/r/20260618080204.38322-1-samsun1006219@gmail.com
>
> I only saw your report last week and missed that you had posted this fix
> until today when I was about to submit a series fixing this driver and a
> few others that got this wrong:
>
> https://lore.kernel.org/all/20260622152612.116422-1-johan@kernel.org/
>
> With the commit message fixed and the write references dropped they are
> mostly equivalent.
>
Thanks for taking a look and for the detailed explanation!
I agree that the per-write URB references are unnecessary once the
outstanding write URBs are killed unconditionally on disconnect. Your
series is a better and smaller fix.
I'll drop my version in favour of your series.
Best regards,
Yue
> > Signed-off-by: Sam Sun <samsun1006219@gmail.com>
> > ---
>
> > @@ -95,6 +97,10 @@ struct iowarrior {
> > struct usb_anchor submitted;
> > };
> >
> > +#define to_iowarrior_dev(d) container_of(d, struct iowarrior, kref)
>
> I know we have a few of these in the tree already, but it's not really
> needed for a single user and the "d" is a bit misleading as these macros
> are typically used to cast from a struct device (not a kref).
>
> > +
> > +static void iowarrior_delete(struct kref *kref);
> > +
> > /*--------------*/
> > /* globals */
> > /*--------------*/
> > @@ -235,13 +241,16 @@ static void iowarrior_write_callback(struct urb *urb)
> > /* tell a waiting writer the interrupt-out-pipe is available again */
> > atomic_dec(&dev->write_busy);
> > wake_up_interruptible(&dev->write_wait);
> > + kref_put(&dev->kref, iowarrior_delete);
> > }
>
> > @@ -454,12 +463,14 @@ static ssize_t iowarrior_write(struct file *file,
> > goto error;
> > }
> > usb_anchor_urb(int_out_urb, &dev->submitted);
> > + kref_get(&dev->kref);
> > retval = usb_submit_urb(int_out_urb, GFP_KERNEL);
> > if (retval) {
> > dev_dbg(&dev->interface->dev,
> > "submit error %d for urb nr.%d\n",
> > retval, atomic_read(&dev->write_busy));
> > usb_unanchor_urb(int_out_urb);
> > + kref_put(&dev->kref, iowarrior_delete);
> > goto error;
> > }
> > /* submit was ok */
>
> All outstanding writes should be stopped on disconnect (and soon will be
> when the fix I mentioned above is merged), so this is not needed.
>
> > @@ -637,6 +648,7 @@ static int iowarrior_open(struct inode *inode, struct file *file)
> > }
> > /* increment our usage count for the driver */
> > ++dev->opened;
> > + kref_get(&dev->kref);
> > /* save our object in the file's private structure */
> > file->private_data = dev;
> > retval = 0;
> > @@ -657,13 +669,13 @@ static int iowarrior_release(struct inode *inode, struct file *file)
> > dev = file->private_data;
> > if (!dev)
> > return -ENODEV;
> > + file->private_data = NULL;
>
> This looks like an unrelated change.
>
> > /* lock our device */
> > mutex_lock(&dev->mutex);
> >
> > if (dev->opened <= 0) {
> > retval = -ENODEV; /* close called more than once */
> > - mutex_unlock(&dev->mutex);
> > } else {
> > dev->opened = 0; /* we're closing now */
> > retval = 0;
>
> > @@ -918,8 +929,8 @@ static void iowarrior_disconnect(struct usb_interface *interface)
> > } else {
> > /* no process is using the device, cleanup now */
> > mutex_unlock(&dev->mutex);
> > - iowarrior_delete(dev);
> > }
>
> The unlock should now be moved after the conditional.
>
> > + kref_put(&dev->kref, iowarrior_delete);
> > }
> >
> > /* usb specific object needed to register this driver with the usb subsystem */
>
> Johan
^ permalink raw reply
* Re: [PATCH v1 0/3] thunderbold: A few cleanups
From: Mika Westerberg @ 2026-06-23 12:17 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Mika Westerberg, Yehezkel Bernat, Andreas Noever, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel, linux-usb
In-Reply-To: <cover.1781776904.git.u.kleine-koenig@baylibre.com>
Hi,
On Thu, Jun 18, 2026 at 12:14:49PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
>
> I'm currently working on a project that includes looking at all device
> ID structures from <linux/mod_devicetable.h>. While doing that for
> tb_service_id, I spotted these patch opportunities.
>
> These are all non-critical and also my quest doesn't depend on this, so
> there is no urge to apply these patches. My suggestion is to apply them
> via the thunderbold tree during the next merge window with an ack from
> the network guys.
>
> The first patch touches drivers/net and drivers/thunderbold. It could
> theretically be split, but then this results in at least 3 commits which
> seems excessive to handle three drivers, so I kept it as a single patch.
>
> The third patch is a style change and so is subjective. Drop it, if you
> don't like it. Here splitting would be easy, but given that patch #1
> already touches the same files, letting these go in together without
> splitting seems to be sensible.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (The Capable Hub) (3):
> thunderbold: Stop passing matched device ID to .probe()
> thunderbold: Assert that a service driver has a probe callback
> thunderbold: Drop comma after device id array terminator
Fixed the typo "thunderbold" -> "thunderbolt" and applied all to
thunderbolt.git/next. I also took the networking patch, let me know if
that's not okay (I'm the maintainer of that driver too and it looked fine).
Thanks!
^ permalink raw reply
* Re: [PATCH] thunderbolt: fix bandwidth group reservation indexing
From: Mika Westerberg @ 2026-06-23 12:12 UTC (permalink / raw)
To: raoxu; +Cc: andreas.noever, westeri, YehezkelShB, linux-usb, linux-kernel
In-Reply-To: <1ACD3C00B2C83FD0+20260615090348.3058017-1-raoxu@uniontech.com>
Hi,
On Mon, Jun 15, 2026 at 05:03:48PM +0800, raoxu wrote:
> From: Xu Rao <raoxu@uniontech.com>
>
> tb_init_bandwidth_groups() initializes each bandwidth group with
> "group->index = i + 1", so the valid group index range is
> 1..MAX_GROUPS.
That's because group 0 is "reserved".
> tb_consumed_dp_bandwidth() uses group->index directly as an index into
> group_reserved[], which has MAX_GROUPS elements and is zero-based. This
> leaves group_reserved[0] unused and makes group 7 access one element past
> the end of the array.
>
> When Group_ID 7 has reserved bandwidth, the condition reads beyond the
> end of the array and may also write beyond it. The reserved bandwidth
> for Group_ID 7 is not included in the consumed bandwidth sum either.
>
> Convert the Group_ID to a zero-based array index before accessing
> group_reserved[].
Let's keep it like that but can you make a patch that makes MAX_GROUPS =
7+1 instead? Thanks!
^ permalink raw reply
* Re: [PATCH v1] usb: typec: tcpm: Validate SVID index in svdm_consume_modes()
From: Heikki Krogerus @ 2026-06-23 12:12 UTC (permalink / raw)
To: Badhri Jagan Sridharan
Cc: gregkh, amitsd, kyletso, rdbabiera, linux-kernel, linux-usb,
stable
In-Reply-To: <20260622220803.305750-1-badhri@google.com>
On Mon, Jun 22, 2026 at 10:08:03PM +0000, Badhri Jagan Sridharan wrote:
> In svdm_consume_modes(), the SVID value is read from pmdata->svids using
> pmdata->svid_index as an array index without bounds validation:
>
> paltmode->svid = pmdata->svids[pmdata->svid_index];
>
> If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results
> in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data
> is embedded inside struct tcpm_port, indexing past svids reads into
> adjacent fields. In particular:
> - At index 16, it reads the altmodes count.
> - At index 18 and beyond, it reads into altmode_desc[], which contains
> partner-supplied SVDM Discovery Modes VDOs.
>
> By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index
> to 20, the partner can force paltmode->svid to be loaded with an arbitrary,
> partner- chosen SVID, which is then registered via
> typec_partner_register_altmode().
>
> Fix this by validating that pmdata->svid_index is non-negative and strictly
> less than pmdata->nsvids before accessing the pmdata->svids array inside
> svdm_consume_modes().
>
> Assisted-by: Antigravity:gemini-3.5-flash
> Fixes: 4ab8c18d4d67 ("usb: typec: Register a device for every mode")
> Cc: stable <stable@kernel.org>
> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
> Reviewed-by: RD Babiera <rdbabiera@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> drivers/usb/typec/tcpm/tcpm.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 7ef746a90a17..bc531923b1ca 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -2000,6 +2000,11 @@ static void svdm_consume_modes(struct tcpm_port *port, const u32 *p, int cnt,
> return;
> }
>
> + if (pmdata->svid_index < 0 || pmdata->svid_index >= pmdata->nsvids) {
> + tcpm_log(port, "Invalid SVID index %d", pmdata->svid_index);
> + return;
> + }
> +
> for (i = 1; i < cnt; i++) {
> if (pmdata->altmodes >= ALTMODE_DISCOVERY_MAX) {
> /* Already logged in svdm_consume_svids() */
>
> base-commit: 1c2b66a7d7257d2652aa41f9a860ecb96dde27dd
> --
> 2.55.0.rc0.786.g65d90a0328-goog
--
heikki
^ permalink raw reply
* Re: [PATCH v3] usb: serial: option: add multiple VID/PID
From: Lars Melin @ 2026-06-23 12:10 UTC (permalink / raw)
To: yangsizhe, johan, gregkh, linux-usb, linux-kernel, yangsizhe
In-Reply-To: <20260623024108.2400-1-18392868223@163.com>
On 2026-06-23 09:41, yangsizhe wrote:
> { USB_DEVICE(0x2dee, 0x4d57), /* MeiG SLM770A*/
> + .driver_info = RSVD(0) | RSVD(1) },
Hi yangsizhe,
have you compile-tested this patch?
thanks
Lars
^ permalink raw reply
* Re: [PATCH v2] usb: typec: ucsi: gaokun: unwind notifier on UCSI register failure
From: Heikki Krogerus @ 2026-06-23 12:10 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: Pengyu Luo, Greg Kroah-Hartman, linux-usb, linux-kernel
In-Reply-To: <20260622153230.75195-1-pengpeng@iscas.ac.cn>
On Mon, Jun 22, 2026 at 11:32:30PM +0800, Pengpeng Hou wrote:
> gaokun_ucsi_register_worker() registers the EC notifier before calling
> ucsi_register(). If ucsi_register() fails, the worker currently only logs
> the error and leaves the notifier registered. Later EC events can then
> call into an unpublished UCSI instance. The remove path also
> unconditionally unregisters the notifier and UCSI device even if the
> delayed worker failed before both were published.
>
> Unregister the notifier immediately when ucsi_register() fails, and track
> only the fully published state. The remove path then tears down the pair
> only if both publication steps completed.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> ---
> Changes since v1:
> - Drop the two-flag bookkeeping objected to by Greg Kroah-Hartman.
> - Keep the existing registration order, but use a single flag that is set
> only after both the notifier and UCSI device are published.
> - Unregister the EC notifier immediately if ucsi_register() fails.
> - Compile-tested only; no Gaokun hardware was available.
>
> drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> index ca749fde49bd..0dcbbff5f205 100644
> --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> @@ -98,6 +98,7 @@ struct gaokun_ucsi {
> struct device *dev;
> struct delayed_work work;
> struct notifier_block nb;
> + bool registered;
> u16 version;
> u8 num_ports;
> };
> @@ -457,8 +458,12 @@ static void gaokun_ucsi_register_worker(struct work_struct *work)
> }
>
> ret = ucsi_register(ucsi);
> - if (ret)
> + if (ret) {
> dev_err_probe(ucsi->dev, ret, "ucsi register failed\n");
> + gaokun_ec_unregister_notify(uec->ec, &uec->nb);
> + return;
> + }
> + uec->registered = true;
> }
>
> static int gaokun_ucsi_probe(struct auxiliary_device *adev,
> @@ -504,8 +509,10 @@ static void gaokun_ucsi_remove(struct auxiliary_device *adev)
> struct gaokun_ucsi *uec = auxiliary_get_drvdata(adev);
>
> disable_delayed_work_sync(&uec->work);
> - gaokun_ec_unregister_notify(uec->ec, &uec->nb);
> - ucsi_unregister(uec->ucsi);
> + if (uec->registered) {
> + gaokun_ec_unregister_notify(uec->ec, &uec->nb);
> + ucsi_unregister(uec->ucsi);
> + }
> ucsi_destroy(uec->ucsi);
> }
>
> --
> 2.50.1
--
heikki
^ permalink raw reply
* Re: [PATCH tb-next] thunderbolt: stream: unmap buffers with mapped size
From: Mika Westerberg @ 2026-06-23 12:06 UTC (permalink / raw)
To: raoxu; +Cc: andreas.noever, westeri, YehezkelShB, linux-usb, linux-kernel
In-Reply-To: <BCAED571E6DC370E+20260611064530.3495292-1-raoxu@uniontech.com>
Hi,
On Thu, Jun 11, 2026 at 02:45:30PM +0800, raoxu wrote:
> From: Xu Rao <raoxu@uniontech.com>
>
> The size passed to dma_unmap_page() must match the size used for the
> corresponding dma_map_page() call.
>
> Stream RX and TX buffers are mapped with TB_MAX_FRAME_SIZE when the
> buffer pools are allocated. However, tbstream_ring_free() currently uses
> tb_ring_frame_size() as the unmap size.
>
> That helper returns the current frame payload size, not the DMA mapping
> size. On the TX path, tbstream_dev_alloc_tx() stores a shorter payload
> length in frame.size when the payload is smaller than TB_MAX_FRAME_SIZE.
> This happens for a short final DATA frame, and also for the CLOSE frame,
> which is allocated with SZ_256.
>
> In those cases the buffer was mapped with TB_MAX_FRAME_SIZE, but
> tb_ring_frame_size() returns the shorter frame payload length. This makes
> the dma_unmap_page() size differ from the original dma_map_page() size.
>
> Use TB_MAX_FRAME_SIZE when unmapping stream buffers so the unmap size
> matches the DMA mapping size used by the buffer allocation paths.
>
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
Applied to thunderbolt.git/fixes, thanks!
^ permalink raw reply
* Re: [PATCH v4] thunderbolt: Assert downstream port reset on shutdown
From: Mika Westerberg @ 2026-06-23 12:00 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: andreas.noever, westeri, YehezkelShB, linux-usb,
Mario Limonciello, Sanath S
In-Reply-To: <20260611054157.928921-1-Basavaraj.Natikar@amd.com>
Hi,
On Thu, Jun 11, 2026 at 11:11:57AM +0530, Basavaraj Natikar wrote:
> On shutdown the connection manager tears down the router tree without
> signalling connected devices. A Thunderbolt 3 device directly connected
> to a USB4 host never receives a disconnect indication and during shutdown
> this can cause polling the dead link for up to 60 seconds. On some
> platforms this behavior leads to a warm reset instead of a shutdown due
> to this timeout.
>
> Fix this by asserting PORT_CS_19.DPR on each connected downstream port
> before tearing down the router tree. This drives SBTX low (USB4 spec
> section 6.9), causing the device to detect SBRX low and transition to
> Uninitialized Unplugged state immediately.
>
> Always do this on system shutdown/reboot by forcing host_reset in the
> PCI ->shutdown callback. On plain driver unload only do it when the host
> router was actually reset on load (host_reset=1), since in that case the
> tunnels are not preserved across reload anyway; with host_reset=0 the
> tunnels are kept alive across unload/reload so the links are left intact.
> Restrict the reset to Thunderbolt 3 devices.
>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Co-developed-by: Sanath S <Sanath.S@amd.com>
> Signed-off-by: Sanath S <Sanath.S@amd.com>
> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Applied to thunderbolt.git/next, thanks!
^ permalink raw reply
* Re: [PATCH v2] xhci: pci: Disable soft retry for Renesas uPD720201
From: Michal Pecio @ 2026-06-23 11:55 UTC (permalink / raw)
To: Mathias Nyman
Cc: raoxu, gregkh, linux-kernel, linux-usb, mathias.nyman, stable
In-Reply-To: <c4ef0081-fbe9-47a4-b5d5-60665564ca02@linux.intel.com>
Replying a little out of order here.
On Mon, 22 Jun 2026 14:31:58 +0300, Mathias Nyman wrote:
> Cancel the realtek URB we tried to soft retry earlier.
>
> > 2026-06-22T13:23:39.477082+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (000/3) [200cb341b0/200cb341b1/200cb341c0] xhci_urb_dequeue cancel TD at 200cb341b0 stream 0
> > 2026-06-22T13:23:39.477082+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (004/3) [200cb341b0/200cb341b1/200cb341c0] queue_stop_endpoint suspend 0
>
> queue stop endpoint to cancel URB for realtek device.
> Endpoint context still shows endpoint is in "stopped" state.
> Note that we restarted the endpoint 20ms earlier, endpoint context
> might not have updated yet.
This was business as usual on uPD720200, it seems that these chips
don't update EP Context until the first scheduled service opportunity
(though no later than about 30ms - long interval endpoints must have
different rules) and they cannot execute Stop EP until then either.
Some of them complete the command with Context State Error, others
delay completion until the scheduled restart. If we wait longer and
then queue Stop Endpoint, it executes instantly (fraction of a ms).
It seems that 201/202 chips still have the same limitation.
> I think there are some steps we could do to avoid soft retry,
> restart, and stopping an endpoint we know is behind a disconnected
> parent.
Yes, existing logic can be trivially extended to cover children too.
Of course, this does nothing if the device is disconnected from an
external hub or a transaction error occurs without disconnection.
But further experiments indicate that disconnection from the root hub
is actually a necessary condition to trigger this bug.
If another SuperSpeed device (even one without periodic endpoints like
UAS) is connected to another port, the retry causes another Transaction
Error a few ms later, the pipe halts and Stop EP completes normally
with Context State Error, as expected. Then we reset, remove the URB
and never restart this endpoint again.
The same happens if I trigger the bug and then connect either the same
hub or any other device to any SuperSpeed port before command timeout.
[ +0,000009] xhci_hcd 0000:06:00.0: 6/6 (000/2) [ff8f0bd0/ff8f0bd1/ff8f0be0] queue_reset_endpoint tsp 1
[ +0,000009] xhci_hcd 0000:06:00.0: 0/-1 (fff/f) [ffffffff/ffffffff/ffffffff] xhci_ring_cmd_db cmd_ring_state 1
[ +0,000504] xhci_hcd 0000:06:00.0: 6/6 (002/3) [ff8f0bd0/ff8f0bd1/ff8f0be0] handle_cmd_completion cmd_type 14 comp_code 1
[ +0,000025] xhci_hcd 0000:06:00.0: 6/6 (000/3) [ff8f0bd0/ff8f0bd1/ff8f0be0] ring_ep_doorbell stream 0
[ +0,006627] usb 10-1: USB disconnect, device number 22
[ +0,000016] usb 10-1.4: USB disconnect, device number 23
[ +0,000005] r8152-cfgselector 10-1.4.4: USB disconnect, device number 24
[ +0,000190] xhci_hcd 0000:06:00.0: 6/6 (000/3) [ff8f0bd0/ff8f0bd1/ff8f0be0] xhci_urb_dequeue cancel TD at ff8f0bd0 stream 0
[ +0,000011] xhci_hcd 0000:06:00.0: 6/6 (004/3) [ff8f0bd0/ff8f0bd1/ff8f0be0] queue_stop_endpoint suspend 0
[ +0,000009] xhci_hcd 0000:06:00.0: 0/-1 (fff/f) [ffffffff/ffffffff/ffffffff] xhci_ring_cmd_db cmd_ring_state 1
[ +0,000655] xhci_hcd 0000:06:00.0: 6/6 (004/2) [ff8f0bd0/ff8f0bd1/ff8f0be0] handle_tx_event comp_code 4 trb_dma ff8f0bd0
[ +0,000023] xhci_hcd 0000:06:00.0: 6/6 (004/2) [ff8f0bd0/ff8f0bd1/ff8f0be0] handle_tx_event stream_id 0 trb_len 2 missing 2
[ +0,000013] xhci_hcd 0000:06:00.0: 6/6 (004/2) [ff8f0bd0/ff8f0bd1/ff8f0be0] queue_reset_endpoint tsp 1
[ +0,000008] xhci_hcd 0000:06:00.0: 0/-1 (fff/f) [ffffffff/ffffffff/ffffffff] xhci_ring_cmd_db cmd_ring_state 1
[ +0,000012] xhci_hcd 0000:06:00.0: 6/6 (006/2) [ff8f0bd0/ff8f0bd1/ff8f0be0] handle_cmd_completion cmd_type 15 comp_code 19
I would guess that disconnecting all SuperSpeed ports causes the chip
to turn off its SuperSpeed schedule altogether and wait for SW to stop
all endpoints which aren't halted yet, but in case of pending restart,
Stop EP is scheduled to complete at the next service opportunity, which
never happens.
I also found that disconnecting a different affected NIC from the root
hub itself also triggers this bug, but only if I disable protection
from queuing Reset Endpoint (including with TSP) to "inactive" devices.
And the bug doesn't trigger every time - sometimes the unlink happens
while Reset Endpoint is pending and then its handler removes the URB
without Stop Endpoint.
And cable connection isn't actually necessary - I was mistaken due to
the randomness of the bug.
Regards,
Michal
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Daniel Lezcano @ 2026-06-23 11:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Michael Turquette, Stephen Boyd, Brian Masney, Sylwester Nawrocki,
Chanwoo Choi, Sam Protsenko, Rob Clark, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Sean Paul, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
On 6/22/26 12:16, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> ---
> .../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
> .../devicetree/bindings/arm/qcom.yaml | 4 ++--
> .../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
> .../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
> .../display/samsung/samsung,fimd.yaml | 4 ++--
> .../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
> .../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
> .../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
> .../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
> .../bindings/leds/skyworks,aat1290.yaml | 6 +++---
> .../bindings/media/cec/cec-gpio.yaml | 2 +-
> .../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
> .../devicetree/bindings/mux/mux-consumer.yaml | 4 ++--
> .../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
> .../bindings/phy/samsung,usb2-phy.yaml | 2 +-
> .../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
> .../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
> .../bindings/regulator/maxim,max77802.yaml | 4 ++--
> .../bindings/regulator/richtek,rtq2208.yaml | 2 +-
> .../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
> .../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
> .../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
> .../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
> .../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
> .../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
> .../thermal/samsung,exynos-thermal.yaml | 4 ++--
Acked-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> # thermal
^ permalink raw reply
* Re: [PATCH v2] usb: dwc3: imx8mp: make dwc3_imx_glue_ops static and rename to imx8mp
From: Greg Kroah-Hartman @ 2026-06-23 11:41 UTC (permalink / raw)
To: Ben Dooks
Cc: Thinh Nguyen, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-usb, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623101043.748359-1-ben.dooks@codethink.co.uk>
On Tue, Jun 23, 2026 at 11:10:43AM +0100, Ben Dooks wrote:
> The dwc3_imx_glue_ops is not used outside this file, and technically this
> is the dwc3-imx8mp driver so whilst making this static to avoid the
> following warning, rename it dwc3_imx8mp_glue_ops to distinguish it from
> the other driver which also has dwc3_imx_glue_ops.
>
> Fixes:
> drivers/usb/dwc3/dwc3-imx8mp.c:176:22: warning: symbol 'dwc3_imx_glue_ops' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
> drivers/usb/dwc3/dwc3-imx8mp.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
> index 1cf96540b66e..de8c17bc940d 100644
> --- a/drivers/usb/dwc3/dwc3-imx8mp.c
> +++ b/drivers/usb/dwc3/dwc3-imx8mp.c
> @@ -158,7 +158,7 @@ static irqreturn_t dwc3_imx8mp_interrupt(int irq, void *_dwc3_imx)
> return IRQ_HANDLED;
> }
>
> -static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
> +static void dwc3_imx8mp_pre_set_role(struct dwc3 *dwc, enum usb_role role)
> {
> if (role == USB_ROLE_HOST)
> /*
> @@ -173,8 +173,8 @@ static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
> pm_runtime_use_autosuspend(dwc->dev);
> }
>
> -struct dwc3_glue_ops dwc3_imx_glue_ops = {
> - .pre_set_role = dwc3_imx_pre_set_role,
> +static struct dwc3_glue_ops dwc3_imx8mp_glue_ops = {
> + .pre_set_role = dwc3_imx8mp_pre_set_role,
> };
>
> static int dwc3_imx8mp_probe(struct platform_device *pdev)
> @@ -266,7 +266,7 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
> goto put_dwc3;
> }
>
> - dwc3->glue_ops = &dwc3_imx_glue_ops;
> + dwc3->glue_ops = &dwc3_imx8mp_glue_ops;
>
> if (dwc3->dr_mode == USB_DR_MODE_HOST)
> pm_runtime_dont_use_autosuspend(dwc3->dev);
> --
> 2.37.2.352.g3c44437643
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* chipidea: usbmisc_imx: i.MX93 support
From: Stefan Wahren @ 2026-06-23 10:23 UTC (permalink / raw)
To: Xu Yang, Frank Li
Cc: Alexander Stein, Greg Kroah-Hartman, Linux ARM,
linux-usb@vger.kernel.org
Hi,
during debugging USB OTG on our custom i.MX93 board, we noticed
remarkable differences between the implementation of the
chipidea/usbmisc_imx and the official NXP i.MX93 Reference Manual [1].
Is the USB OTG part including PHY of the i.MX93 officially supported in
Linux Mainline?
According to imx91_93_common.dtsi the USB IP of the i.MX93 should be
identical to i.MX8MM [2]
usbmisc1: usbmisc@4c100200 {
compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
"fsl,imx6q-usbmisc";
But looking at the PHY register definition and reset values in the NXP
i.MX93 Reference Manual,
the registers are comparable to the i.MX95 [3] ones.
Could you please clarify which source is correct (Mainline DTS vs
Reference Manual)?
Looking deeper at chipidea/usbmisc_imx shows the usage of the following
register bits
#define MX7D_USB_OTG_PHY_CFG2_CHRG_CHRGSEL BIT(0)
#define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATDETENB0 BIT(1)
#define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATSRCENB0 BIT(2)
#define MX7D_USB_OTG_PHY_CFG2_CHRG_DCDENB BIT(3)
#define MX7D_USB_OTG_PHY_STATUS_LINE_STATE0 BIT(0)
#define MX7D_USB_OTG_PHY_STATUS_LINE_STATE1 BIT(1)
#define MX7D_USB_OTG_PHY_STATUS_CHRGDET BIT(29)
According to NXP i.MX93 & i.MX95 Reference Manual, these are bits reserved.
Is it correct that the chipidea/usbmisc_imx use these bits on i.MX93?
Best regards
[1] - https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf
<https://www.nxp.com/docs/en/reference-manual/IMX93RM.pdf>
[2] - https://www.nxp.com/docs/en/reference-manual/IMX8MMRM.pdf
<https://www.nxp.com/docs/en/reference-manual/IMX8MMRM.pdf>
[3] - https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf
<https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf>
^ permalink raw reply
* Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805
From: Michal Pecio @ 2026-06-23 10:18 UTC (permalink / raw)
To: Xincheng Zhang
Cc: Mathias Nyman, Greg Kroah-Hartman, linux-usb, linux-kernel,
Forest Crossman
In-Reply-To: <20260623-xhci-via-dma-fix-v1-1-3f12c81a1cf8@ultrarisc.com>
On Tue, 23 Jun 2026 15:32:02 +0800, Xincheng Zhang wrote:
> The VIA VL805 XHCI controller (Device ID 0x3483) fails to handle DMA
> addresses correctly when they exceed 0x1000000000 (64GB). On systems
> with large amounts of RAM, this hardware limitation causes device
> failures.
>
> Add the XHCI_NO_64BIT_SUPPORT quirk to restrict DMA addressing to
> 32-bit, preventing the controller from receiving addresses beyond its
> hardware limit.
>
> Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com>
It could make sense to put a fix for this in stable too.
But I don't like this abuse of the quirk. Firstly, it causes
unnecessary bouncing on systems with >4GB RAM and no IOMMU.
I found other drivers that use DMA_BIT_MASK(36) or even weirder
numbers, so it seems that we too could request 64 gigs exactly
with a bit of driver refactoring.
Secondly, it makes the driver pretend that AC64 capability is absent.
Differences go beyond address bits, notably including register width
and whether QWORD or only DWORD writes cane be used. For example, if
we want to improve command abort on AC64 chips using QWORD writes, we
will need to know the true state of this capability, regarless of
whether the chip really implements all 64 address bits or not.
Forest, you have added a number of similar quirks for ASMedia chips.
Do you happen to know what is their real address width? I think it
might prove useful to have this on record.
Regards,
Michal
^ permalink raw reply
* Re: [PATCH] usb: dwc3: qcom: make dwc3_qcom_glue_ops static
From: Konrad Dybcio @ 2026-06-23 10:16 UTC (permalink / raw)
To: Ben Dooks, Thinh Nguyen, Greg Kroah-Hartman, linux-arm-msm,
linux-usb, linux-kernel
In-Reply-To: <20260623100000.718126-1-ben.dooks@codethink.co.uk>
On 6/23/26 12:00 PM, Ben Dooks wrote:
> The dwc3_qcom_glue_ops is not used outside of the file it is declared in
> , so make it static to avoid the following warning:
Odd to begin a line with a comma>
> drivers/usb/dwc3/dwc3-qcom.c:605:22: warning: symbol 'dwc3_qcom_glue_ops' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
for the change:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] usb: dwc3: imx8mp: make dwc3_imx_glue_ops static and rename to imx8mp
From: Ben Dooks @ 2026-06-23 10:11 UTC (permalink / raw)
To: Ahmad Fatoum, Thinh Nguyen, Greg Kroah-Hartman, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-usb,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <39a5d53d-2eb9-4f72-aca9-95def11edf25@pengutronix.de>
On 23/06/2026 11:07, Ahmad Fatoum wrote:
>
>
> On 6/23/26 12:05 PM, Ben Dooks wrote:
>> The dwc3_imx_glue_ops is not used outside this file, and technically this
>> is the dwc3-imx8mp driver so whilst making this static to avoid the
>> following warning, rename it dwc3_imx8mp_glue_ops to distinguish it from
>> the other driver which also has dwc3_imx_glue_ops.
>>
>> Fixes:
>> drivers/usb/dwc3/dwc3-imx8mp.c:176:22: warning: symbol 'dwc3_imx_glue_ops' was not declared. Should it be static?
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>> drivers/usb/dwc3/dwc3-imx8mp.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
>> index 1cf96540b66e..bc61a89b66b1 100644
>> --- a/drivers/usb/dwc3/dwc3-imx8mp.c
>> +++ b/drivers/usb/dwc3/dwc3-imx8mp.c
>> @@ -173,8 +173,8 @@ static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
>> pm_runtime_use_autosuspend(dwc->dev);
>> }
>>
>> -struct dwc3_glue_ops dwc3_imx_glue_ops = {
>> - .pre_set_role = dwc3_imx_pre_set_role,
>> +statc struct dwc3_glue_ops dwc3_imx8mp_glue_ops = {
>
> Typo
Thanks, forgot to re-run check after this. Sent v2
>
>> + .pre_set_role = dwc3_imx8mp_pre_set_role,
>> };
>>
>> static int dwc3_imx8mp_probe(struct platform_device *pdev)
>> @@ -266,7 +266,7 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
>> goto put_dwc3;
>> }
>>
>> - dwc3->glue_ops = &dwc3_imx_glue_ops;
>> + dwc3->glue_ops = &dwc3_imx8mp_glue_ops;
>>
>> if (dwc3->dr_mode == USB_DR_MODE_HOST)
>> pm_runtime_dont_use_autosuspend(dwc3->dev);
>
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
^ permalink raw reply
* [PATCH v2] usb: dwc3: imx8mp: make dwc3_imx_glue_ops static and rename to imx8mp
From: Ben Dooks @ 2026-06-23 10:10 UTC (permalink / raw)
To: Thinh Nguyen, Greg Kroah-Hartman, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
Cc: Ben Dooks
The dwc3_imx_glue_ops is not used outside this file, and technically this
is the dwc3-imx8mp driver so whilst making this static to avoid the
following warning, rename it dwc3_imx8mp_glue_ops to distinguish it from
the other driver which also has dwc3_imx_glue_ops.
Fixes:
drivers/usb/dwc3/dwc3-imx8mp.c:176:22: warning: symbol 'dwc3_imx_glue_ops' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/usb/dwc3/dwc3-imx8mp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
index 1cf96540b66e..de8c17bc940d 100644
--- a/drivers/usb/dwc3/dwc3-imx8mp.c
+++ b/drivers/usb/dwc3/dwc3-imx8mp.c
@@ -158,7 +158,7 @@ static irqreturn_t dwc3_imx8mp_interrupt(int irq, void *_dwc3_imx)
return IRQ_HANDLED;
}
-static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
+static void dwc3_imx8mp_pre_set_role(struct dwc3 *dwc, enum usb_role role)
{
if (role == USB_ROLE_HOST)
/*
@@ -173,8 +173,8 @@ static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
pm_runtime_use_autosuspend(dwc->dev);
}
-struct dwc3_glue_ops dwc3_imx_glue_ops = {
- .pre_set_role = dwc3_imx_pre_set_role,
+static struct dwc3_glue_ops dwc3_imx8mp_glue_ops = {
+ .pre_set_role = dwc3_imx8mp_pre_set_role,
};
static int dwc3_imx8mp_probe(struct platform_device *pdev)
@@ -266,7 +266,7 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
goto put_dwc3;
}
- dwc3->glue_ops = &dwc3_imx_glue_ops;
+ dwc3->glue_ops = &dwc3_imx8mp_glue_ops;
if (dwc3->dr_mode == USB_DR_MODE_HOST)
pm_runtime_dont_use_autosuspend(dwc3->dev);
--
2.37.2.352.g3c44437643
^ permalink raw reply related
* [PATCH v2] usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()
From: Ben Dooks @ 2026-06-23 10:08 UTC (permalink / raw)
To: Thinh Nguyen, Greg Kroah-Hartman, linux-usb, linux-kernel; +Cc: Ben Dooks
The dwc3_ulpi_setup() calls the register read and write calls with
dwc3->regs when both these calls take the dwc3 structure directly.
Chnage these two calls to fix the following sparse warning, and
possibly a nasty bug in the dwc3_ulpi_setup() code:
drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs
drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/usb/dwc3/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 517aa7f1486d..ceb49f2f8004 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -789,9 +789,9 @@ static void dwc3_ulpi_setup(struct dwc3 *dwc)
if (dwc->enable_usb2_transceiver_delay) {
for (index = 0; index < dwc->num_usb2_ports; index++) {
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(index));
+ reg = dwc3_readl(dwc, DWC3_GUSB2PHYCFG(index));
reg |= DWC3_GUSB2PHYCFG_XCVRDLY;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(index), reg);
+ dwc3_writel(dwc, DWC3_GUSB2PHYCFG(index), reg);
}
}
}
--
2.37.2.352.g3c44437643
^ permalink raw reply related
* Re: [PATCH] usb: dwc3: imx8mp: make dwc3_imx_glue_ops static and rename to imx8mp
From: Ahmad Fatoum @ 2026-06-23 10:07 UTC (permalink / raw)
To: Ben Dooks, Thinh Nguyen, Greg Kroah-Hartman, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-usb,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623100554.735080-1-ben.dooks@codethink.co.uk>
On 6/23/26 12:05 PM, Ben Dooks wrote:
> The dwc3_imx_glue_ops is not used outside this file, and technically this
> is the dwc3-imx8mp driver so whilst making this static to avoid the
> following warning, rename it dwc3_imx8mp_glue_ops to distinguish it from
> the other driver which also has dwc3_imx_glue_ops.
>
> Fixes:
> drivers/usb/dwc3/dwc3-imx8mp.c:176:22: warning: symbol 'dwc3_imx_glue_ops' was not declared. Should it be static?
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
> drivers/usb/dwc3/dwc3-imx8mp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
> index 1cf96540b66e..bc61a89b66b1 100644
> --- a/drivers/usb/dwc3/dwc3-imx8mp.c
> +++ b/drivers/usb/dwc3/dwc3-imx8mp.c
> @@ -173,8 +173,8 @@ static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
> pm_runtime_use_autosuspend(dwc->dev);
> }
>
> -struct dwc3_glue_ops dwc3_imx_glue_ops = {
> - .pre_set_role = dwc3_imx_pre_set_role,
> +statc struct dwc3_glue_ops dwc3_imx8mp_glue_ops = {
Typo
> + .pre_set_role = dwc3_imx8mp_pre_set_role,
> };
>
> static int dwc3_imx8mp_probe(struct platform_device *pdev)
> @@ -266,7 +266,7 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
> goto put_dwc3;
> }
>
> - dwc3->glue_ops = &dwc3_imx_glue_ops;
> + dwc3->glue_ops = &dwc3_imx8mp_glue_ops;
>
> if (dwc3->dr_mode == USB_DR_MODE_HOST)
> pm_runtime_dont_use_autosuspend(dwc3->dev);
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] usb: dwc3: imx8mp: make dwc3_imx_glue_ops static and rename to imx8mp
From: Ben Dooks @ 2026-06-23 10:05 UTC (permalink / raw)
To: Thinh Nguyen, Greg Kroah-Hartman, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-usb, imx,
linux-arm-kernel, linux-kernel
Cc: Ben Dooks
The dwc3_imx_glue_ops is not used outside this file, and technically this
is the dwc3-imx8mp driver so whilst making this static to avoid the
following warning, rename it dwc3_imx8mp_glue_ops to distinguish it from
the other driver which also has dwc3_imx_glue_ops.
Fixes:
drivers/usb/dwc3/dwc3-imx8mp.c:176:22: warning: symbol 'dwc3_imx_glue_ops' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/usb/dwc3/dwc3-imx8mp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
index 1cf96540b66e..bc61a89b66b1 100644
--- a/drivers/usb/dwc3/dwc3-imx8mp.c
+++ b/drivers/usb/dwc3/dwc3-imx8mp.c
@@ -173,8 +173,8 @@ static void dwc3_imx_pre_set_role(struct dwc3 *dwc, enum usb_role role)
pm_runtime_use_autosuspend(dwc->dev);
}
-struct dwc3_glue_ops dwc3_imx_glue_ops = {
- .pre_set_role = dwc3_imx_pre_set_role,
+statc struct dwc3_glue_ops dwc3_imx8mp_glue_ops = {
+ .pre_set_role = dwc3_imx8mp_pre_set_role,
};
static int dwc3_imx8mp_probe(struct platform_device *pdev)
@@ -266,7 +266,7 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
goto put_dwc3;
}
- dwc3->glue_ops = &dwc3_imx_glue_ops;
+ dwc3->glue_ops = &dwc3_imx8mp_glue_ops;
if (dwc3->dr_mode == USB_DR_MODE_HOST)
pm_runtime_dont_use_autosuspend(dwc3->dev);
--
2.37.2.352.g3c44437643
^ permalink raw reply related
* Re: [PATCH] usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()
From: Ben Dooks @ 2026-06-23 10:03 UTC (permalink / raw)
To: Thinh Nguyen, Greg Kroah-Hartman, linux-usb, linux-kernel
In-Reply-To: <20260623095147.700020-1-ben.dooks@codethink.co.uk>
On 23/06/2026 10:51, Ben Dooks wrote:
> The dwc3_ulpi_setup() calls the register read and write calls with
> dwc3->regs when both these calls take the dwc3 structure directly.
>
> Chnage these two calls to fix the following sparse warning, and
> possibly a nasty bug in the dwc3_ulpi_setup() code:
>
> drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces)
> drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc
> drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs
> drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces)
> drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc
> drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
> drivers/usb/dwc3/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 517aa7f1486d..f5e60fb1a5cc 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -789,9 +789,9 @@ static void dwc3_ulpi_setup(struct dwc3 *dwc)
>
> if (dwc->enable_usb2_transceiver_delay) {
> for (index = 0; index < dwc->num_usb2_ports; index++) {
> - reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(index));
> + reg = dwc3_readl(dwcs, DWC3_GUSB2PHYCFG(index));
oops, failed to ammend the typo fix for this, will re-send
> reg |= DWC3_GUSB2PHYCFG_XCVRDLY;
> - dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(index), reg);
> + dwc3_writel(dwc, DWC3_GUSB2PHYCFG(index), reg);
> }
> }
> }
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
^ permalink raw reply
* [PATCH] usb: dwc3: qcom: make dwc3_qcom_glue_ops static
From: Ben Dooks @ 2026-06-23 10:00 UTC (permalink / raw)
To: Thinh Nguyen, Greg Kroah-Hartman, linux-arm-msm, linux-usb,
linux-kernel
Cc: Ben Dooks
The dwc3_qcom_glue_ops is not used outside of the file it is declared in
, so make it static to avoid the following warning:
drivers/usb/dwc3/dwc3-qcom.c:605:22: warning: symbol 'dwc3_qcom_glue_ops' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/usb/dwc3/dwc3-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index f43f73ac36ff..ac68b4218b56 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -602,7 +602,7 @@ static void dwc3_qcom_run_stop_notifier(struct dwc3 *dwc, bool is_on)
pm_runtime_mark_last_busy(qcom->dev);
}
-struct dwc3_glue_ops dwc3_qcom_glue_ops = {
+static struct dwc3_glue_ops dwc3_qcom_glue_ops = {
.pre_set_role = dwc3_qcom_set_role_notifier,
.pre_run_stop = dwc3_qcom_run_stop_notifier,
};
--
2.37.2.352.g3c44437643
^ permalink raw reply related
* [PATCH] usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup()
From: Ben Dooks @ 2026-06-23 9:51 UTC (permalink / raw)
To: Thinh Nguyen, Greg Kroah-Hartman, linux-usb, linux-kernel; +Cc: Ben Dooks
The dwc3_ulpi_setup() calls the register read and write calls with
dwc3->regs when both these calls take the dwc3 structure directly.
Chnage these two calls to fix the following sparse warning, and
possibly a nasty bug in the dwc3_ulpi_setup() code:
drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs
drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/usb/dwc3/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 517aa7f1486d..f5e60fb1a5cc 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -789,9 +789,9 @@ static void dwc3_ulpi_setup(struct dwc3 *dwc)
if (dwc->enable_usb2_transceiver_delay) {
for (index = 0; index < dwc->num_usb2_ports; index++) {
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(index));
+ reg = dwc3_readl(dwcs, DWC3_GUSB2PHYCFG(index));
reg |= DWC3_GUSB2PHYCFG_XCVRDLY;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(index), reg);
+ dwc3_writel(dwc, DWC3_GUSB2PHYCFG(index), reg);
}
}
}
--
2.37.2.352.g3c44437643
^ permalink raw reply related
* [PATCH] usb: mtu3: unmap request DMA on queue failure
From: Haoxiang Li @ 2026-06-23 9:33 UTC (permalink / raw)
To: chunfeng.yun, gregkh
Cc: linux-usb, linux-arm-kernel, linux-mediatek, linux-kernel,
Haoxiang Li, stable
mtu3_gadget_queue() maps the request before checking whether
the QMU GPD ring can accept another transfer. the request is
returned with -EAGAIN before it is linked on the endpoint
request list if mtu3_prepare_transfer() fails.
Normal completion and dequeue paths unmap requests from
mtu3_req_complete(), but this error path never reaches that
helper, so the DMA mapping is left active. Unmap the request
before returning from the failed queue path.
Fixes: df2069acb005 ("usb: Add MediaTek USB3 DRD driver")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
drivers/usb/mtu3/mtu3_gadget.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index da29f467943f..f224f2ee379a 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -305,6 +305,7 @@ static int mtu3_gadget_queue(struct usb_ep *ep,
if (mtu3_prepare_transfer(mep)) {
ret = -EAGAIN;
+ usb_gadget_unmap_request(&mtu->g, req, mep->is_in);
goto error;
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] usb: typec: Add helper to check cable altmode support
From: Heikki Krogerus @ 2026-06-23 8:30 UTC (permalink / raw)
To: Andrei Kuchynski
Cc: Benson Leung, Jameson Thies, Greg Kroah-Hartman, linux-usb,
linux-kernel
In-Reply-To: <CAMMMRMf0kLTJeVztQwDsz8Zm4wBXX52agNpvnKttkFqupQX=4w@mail.gmail.com>
On Mon, Jun 22, 2026 at 02:03:48PM +0200, Andrei Kuchynski wrote:
> Hi Heikki,
>
> On Mon, Jun 22, 2026 at 12:18 PM Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
> >
> > Hi Andrei,
> >
> > > +bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
> > > +{
> > > + return unsupported;
> >
> > So if typec_cable_get() doesn't return a cable, this function will now
> > always return false - i.e. the cable is supported? Is that intentional?
> >
>
> Yes, this is intentional.
> The UCSI GET_CABLE_PROPERTY command is optional. typec_register_cable()
> function can also be called without the desc->identity field.
> Failing to provide cable information shouldn't be a reason to reject the
> alternate mode.
> Also, the cable can be registered after the partner's altmodes. We
> encounter this scenario with the cros_ec_typec driver. I'm planning to fix
> it, but for now, this approach will preserve the previous behavior.
>
> Therefore, the idea is to reject the altmode only if we know the cable
> doesn't support it. That's why the function is called "unsupported".
> It returns true if a limitation is detected. Otherwise, the function
> returns false.
One day and I'm completely confused again :). I opened the code for
myself (not compiled) to get the idea again. Please consider that, or
something like it - the important part for me is the enum. The enum
does not cost that many lines, but it does make the idea more clear,
at least for me.
enum typec_cable_altmode_support {
CABLE_SUPPORT_UNKNOWN,
CABLE_SUPPORTED,
CABLE_NOT_SUPPORTED,
};
static enum typec_cable_altmode_support
typec_cable_check_altmode_support(struct typec_cable *cable,
struct typec_altmode *alt)
{
struct typec_altmode *plug;
const u32 speed;
plug = typec_altmode_get_plug(alt);
if (plug) {
typec_altmode_put_plug(plug);
return CABLE_SUPPORTED;
}
/* Maybe UCSI, or the something else, does no supply the identity */
if (!cable->identity)
return ALTMODE_SUPPORT_UNKNOWN;
/* Non-e-marked cable */
if (!cable->identity->id_header)
return CABLE_NOT_SUPPORTED;
speed = VDO_TYPEC_CABLE_SPEED(cable->identity->vdo[0]);
switch (PD_IDH_PTYPE(cable->identity->id_header)) {
case IDH_PTYPE_PCABLE:
if (speed == CABLE_USB2_ONLY)
return CABLE_NOT_SUPPORTED;
break;
case IDH_PTYPE_ACABLE:
/*
* Active cables must establish an SOP' communication
* node. Since that check failed at the beginning of
* this function, this active cable does not support
* this specific altmode.
*/
return CABLE_NOT_SUPPORTED;
default:
break;
}
return CABLE_SUPPORT_UNKNOWN;
}
bool typec_altmode_cable_not_supported(struct typec_altmode *alt)
{
enum typec_cable_altmode_support support = CABLE_SUPPORT_UNKNOWN;
struct typec_cable *cable;
cable = typec_cable_get(typec_altmode2port(alt));
if (cable) {
support = typec_cable_check_altmode_support(cable, alt);
typec_cable_put(cable);
}
return support == CABLE_NOT_SUPPORTED;
}
thanks,
--
heikki
^ permalink raw reply
* Re: [PATCH 0/4] USB: fix use-after-free on disconnect race
From: Johan Hovold @ 2026-06-23 8:29 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Juergen Stuber, Yue Sun, linux-usb, linux-kernel
In-Reply-To: <20260622152612.116422-1-johan@kernel.org>
On Mon, Jun 22, 2026 at 05:26:08PM +0200, Johan Hovold wrote:
> Mutexes cannot be used to manage lifetime of objects directly as the
> mutex structure is accessed by mutex_unlock() after releasing the lock.
> Johan Hovold (4):
> USB: iowarrior: fix use-after-free on disconnect race
> USB: idmouse: fix use-after-free on disconnect race
> USB: ldusb: fix use-after-free on disconnect race
> USB: legousbtower: fix use-after-free on disconnect race
I forgot to mention that these apply on top of:
https://lore.kernel.org/all/20260523170523.1074563-1-johan@kernel.org/
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox