All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ladislav Michl <oss-lists@triops.cz>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: xHCI host dies on device unplug
Date: Tue, 20 Dec 2022 08:58:58 +0100	[thread overview]
Message-ID: <Y6FrQm5mYrwAnbFt@lenoch> (raw)
In-Reply-To: <Y6Dbh1xJucfNvwXq@lenoch>

On Mon, Dec 19, 2022 at 10:45:43PM +0100, Ladislav Michl wrote:
> On Mon, Dec 19, 2022 at 07:31:02PM +0100, Ladislav Michl wrote:
> > On Mon, Dec 19, 2022 at 02:25:46PM +0200, Mathias Nyman wrote:
> > > Looks like controller didn't complete the stop endpoint command.
> > > 
> > > Event for last completed command (before cycle bit change "c" -> "C") was:
> > >   0x00000000028f55a0: TRB 00000000035e81a0 status 'Success' len 0 slot 1 ep 0 type 'Command Completion Event' flags e:c,
> > > 
> > > This was for command at 35e81a0, which in the command ring was:
> > >   0x00000000035e81a0: Reset Endpoint Command: ctx 0000000000000000 slot 1 ep 3 flags T:c
> > > 
> > > The stop endpoint command was the next command queued, at 35e81b0:
> > >   0x00000000035e81b0: Stop Ring Command: slot 1 sp 0 ep 3 flags c
> > > 
> > > There were a lot of URBs queued for this device, and they are cancelled one by one after disconnect.
> > > 
> > > Was this the only device connected? If so does connecting another usb device to another root port help?
> > > Just to test if the host for some reason partially stops a while after last device disconnect?
> > 
> > Device is connected directly into SoC. Once connected into HUB, host doesn't die
> > (as noted in other email, sorry for not replying to my own message, so it got lost)
> > It seems as intentional (power management?) optimization. If another device is
> > plugged in before 5 sec timeout expires, host completes stop endpoint command.
> > 
> > Unfortunately I cannot find anything describing this behavior in
> > documentation, so I'll ask manufacturer support.
> 
> As support is usually slow I asked search engine first and this sounds
> familiar:
> "Synopsis Designware USB3 IP earlier than v3.00a which is configured in silicon
> with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to prevent
> xhci host controller from dying when device is disconnected."
> 
> usb: dwc3: Add quirk for Synopsis device disconnection errata
> https://patchwork.kernel.org/project/linux-omap/patch/1424151697-2084-5-git-send-email-Sneeker.Yeh@tw.fujitsu.com/
> 
> Any clue what happened with that? I haven't found any meaningfull traces...

Just for completeness, this turned into:
41135de1e7fd ("usb: xhci: add quirk flag for broken PED bits")
and it is enabled:
cc params 0x0220f065 hci version 0x100 quirks 0x0000000002010010

However I do not see original logic there, clearing PORT_CSC before
stopping endpoint.

> > Both solutions, do nothing or reset controller once last device is unpluged
> > works, but I doubt they are suitable for mainline kernel without further
> > investigation.
> > 
> > > Another thing is that the stop endpoint command fails after three soft reset tries,
> > > does disabling soft reset help?
> > 
> > No, this does not cause any change.
> > 
> > 	ladis

  reply	other threads:[~2022-12-20  7:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 21:27 xHCI host dies on device unplug Ladislav Michl
2022-12-06 13:17 ` Ladislav Michl
2022-12-15 16:12   ` Ladislav Michl
2022-12-16 10:13     ` Mathias Nyman
2022-12-16 21:32       ` Ladislav Michl
2022-12-19 12:25         ` Mathias Nyman
2022-12-19 18:31           ` Ladislav Michl
2022-12-19 21:45             ` Ladislav Michl
2022-12-20  7:58               ` Ladislav Michl [this message]
2022-12-21  9:46                 ` Mathias Nyman
2022-12-21  7:14               ` Ladislav Michl
2022-12-21  9:58                 ` Mathias Nyman
2022-12-21 10:11                   ` Ladislav Michl
2022-12-21 12:05                     ` Ladislav Michl
2022-12-21 12:12                     ` Mathias Nyman
2022-12-21 12:21                       ` Ladislav Michl
2022-12-19  7:11       ` Ladislav Michl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y6FrQm5mYrwAnbFt@lenoch \
    --to=oss-lists@triops.cz \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.