linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Mathias Nyman <mathias.nyman@intel.com>,
	<linux-usb@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Lokesh Vutla <lokeshvutla@ti.com>
Subject: [QUERY] Cold plugged USB device to Inateck PCIE USB card is not detected
Date: Thu, 19 Aug 2021 13:24:08 +0530	[thread overview]
Message-ID: <772e4001-178e-4918-032c-6e625bdded24@ti.com> (raw)

Hi All,

I was trying to test PCIe USB card (Inateck) connected to AM64 EVM and
J7200 EVM. Inateck uses Renesas uPD720201 USB3 host controller.

So if I connect USB pendrive and then boot the board (cold plug), I
don't see the pendrive getting detected. But if I remove and plug it
again, it gets detected.

For the cold plug case, I see this message
	"usb usb1-port3: couldn't allocate usb_device"

It actually fails in
xhci_alloc_dev()->xhci_queue_slot_control()->queue_command()->XHCI_STATE_HALTED

I'm not familiar with xhci but it looks like port event is invoked
before the controller is fully initialized (?).

I tried the following hack which kind of changes the sequence where
xhci_start() and xhci_run_finished() is invoked before port_event() and
with that I could see the pendrive enumerate successfully in cold plug case.

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 228e3d4e1a9f..d19f27c46c6f 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1077,7 +1077,7 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
                        INIT_DELAYED_WORK(&hub->init_work, hub_init_func2);
                        queue_delayed_work(system_power_efficient_wq,
                                        &hub->init_work,
-                                       msecs_to_jiffies(delay));
+                                       msecs_to_jiffies(150));

                        /* Suppress autosuspend until init is done */
                        usb_autopm_get_interface_no_resume(

Irrespective of the delay the port status looks correct and the modified
delay only helps to change the flow.

Adding other prints and delays also change the sequence and seems to
detect the connected pendrive.

Can someone provide hints on how to fix this properly?

Thanks in advance!

Regards
Kishon


             reply	other threads:[~2021-08-19  7:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19  7:54 Kishon Vijay Abraham I [this message]
2021-08-19 13:18 ` [QUERY] Cold plugged USB device to Inateck PCIE USB card is not detected Mathias Nyman
2021-08-19 15:09   ` Alan Stern
2021-08-20  8:26     ` Mathias Nyman
2021-08-20 12:18   ` Kishon Vijay Abraham I

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=772e4001-178e-4918-032c-6e625bdded24@ti.com \
    --to=kishon@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=mathias.nyman@intel.com \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).