Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

On Thu, 20 Oct 2016, Lukas Wunner wrote:

> On Tue, Oct 11, 2016 at 11:18:28AM -0400, Alan Stern wrote:
> > On Sat, 8 Oct 2016, Lukas Wunner wrote:
> > > The PCI core already calls pm_runtime_get_sync() before invoking the
> > > ->probe hook of a driver (see local_pci_probe()).  Drivers need to
> > > explicitly release a runtime ref to allow their device to suspend.
> > > For xhci-pci, this seems to happen in usb_hcd_pci_probe():
> > > 
> > >   if (pci_dev_run_wake(dev))
> > >   pm_runtime_put_noidle(>dev);
> > > 
> > > So you could either modify the if-condition if you want to change the
> > > behaviour for XHCI devices only, or if you want to change it in general,
> > > add something like this to pci_dev_run_wake():
> > > 
> > >   /* PME capable in principle, but not from the intended sleep state */
> > >   if (dev->pme_support && !pci_pme_capable(dev, pci_target_state(dev)))
> > >   return false;
> > > 
> > > I've briefly looked over the callers of pci_dev_run_wake() and the above
> > > seems safe but you should double-check them.
> > 
> > That seems like a good suggestion.  The patch is below; Pierre, can you 
> > test it?  This should remove the need to set the USB autosuspend module 
> > parameter to -1.
> 
> Alan, how do we proceed with this?  Are you going to submit a patch
> (with commit message, tags and all) to linux-pci@ or would you prefer
> me to do that?  I just went over the callers of pci_dev_run_wake()
> once more and the patch still looks safe to me.

Thanks for checking.  I intend to submit it soon; there just hasn't 
been enough free time this week.  :-(

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Lukas Wunner]

On Tue, Oct 11, 2016 at 11:18:28AM -0400, Alan Stern wrote:
> On Sat, 8 Oct 2016, Lukas Wunner wrote:
> > The PCI core already calls pm_runtime_get_sync() before invoking the
> > ->probe hook of a driver (see local_pci_probe()).  Drivers need to
> > explicitly release a runtime ref to allow their device to suspend.
> > For xhci-pci, this seems to happen in usb_hcd_pci_probe():
> > 
> > if (pci_dev_run_wake(dev))
> > pm_runtime_put_noidle(>dev);
> > 
> > So you could either modify the if-condition if you want to change the
> > behaviour for XHCI devices only, or if you want to change it in general,
> > add something like this to pci_dev_run_wake():
> > 
> > /* PME capable in principle, but not from the intended sleep state */
> > if (dev->pme_support && !pci_pme_capable(dev, pci_target_state(dev)))
> > return false;
> > 
> > I've briefly looked over the callers of pci_dev_run_wake() and the above
> > seems safe but you should double-check them.
> 
> That seems like a good suggestion.  The patch is below; Pierre, can you 
> test it?  This should remove the need to set the USB autosuspend module 
> parameter to -1.

Alan, how do we proceed with this?  Are you going to submit a patch
(with commit message, tags and all) to linux-pci@ or would you prefer
me to do that?  I just went over the callers of pci_dev_run_wake()
once more and the patch still looks safe to me.

Thanks,

Lukas

> 
> Index: usb-4.x/drivers/pci/pci.c
> ===
> --- usb-4.x.orig/drivers/pci/pci.c
> +++ usb-4.x/drivers/pci/pci.c
> @@ -2064,6 +2064,10 @@ bool pci_dev_run_wake(struct pci_dev *de
>   if (!dev->pme_support)
>   return false;
>  
> + /* PME-capable in principle, but not from the intended sleep state */
> + if (!pci_pme_capable(dev, pci_target_state(dev)))
> + return false;
> +
>   while (bus->parent) {
>   struct pci_dev *bridge = bus->self;
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi!

I've managed to build the patched kernel on OBS, install the package 
and boot! \o/

And I can confirm that the patch indeed fix the issue!

The kernel was booted without the usb.autosuspend=-1 option, of 
course.

Thank you guys!

Cheers,
Pierre.

Le jeudi 13 octobre 2016, 17:11:46 NZDT Alan Stern a écrit :
> On Fri, 14 Oct 2016, Pierre de Villemereuil wrote:
> > Hi!
> > 
> > I've branched the kernel package on the OpenSUSE Build Server, 
I'll
> > try to apply the patch there (this ought to be cleanest method).
> > 
> > Starting from the root of the kernel tarball, the patch should 
be
> > applied to drivers/pci/pci.c, am I right?
> 
> You just cd to the top directory of the kernel source, and do
> 
>   patch -p1  
> where "filename" is the contents of the email message containing 
the
> patch.  Or if you want, since the patch is so small, you can 
simply
> edit the file by hand to add in the new lines.
> 
> Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi!

I've branched the kernel package on the OpenSUSE Build Server, I'll 
try to apply the patch there (this ought to be cleanest method).

Starting from the root of the kernel tarball, the patch should be 
applied to drivers/pci/pci.c, am I right?

Cheers,
Pierre.


Le mercredi 12 octobre 2016, 14:23:35 NZDT Alan Stern a écrit :
> On Wed, 12 Oct 2016, Pierre de Villemereuil wrote:
> > Hi!
> > 
> > I'm sorry, I'm not savvy enough to know what to do with this (I 
know
> > basics on how to code and compile, but I'm no dev). Could 
someone
> > guide me through it?
> > 
> > I gather this patch needs to be applied to some kernel module 
code
> > which needs to be compiled and reloaded into my current kernel,
> > right?
> 
> More likely you'll have to rebuild an entire new kernel, not just 
a
> single module.
> 
> Search the support site for the distribution you are using.  It 
ought
> to contain reasonably thorough instructions on how to build and 
install
> your own version of their kernel.
> 
> Once you know how to do all that, I can tell you how the patch 
should
> be applied -- that's the easy part.
> 
> Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

On Fri, 14 Oct 2016, Pierre de Villemereuil wrote:

> Hi!
> 
> I've branched the kernel package on the OpenSUSE Build Server, I'll 
> try to apply the patch there (this ought to be cleanest method).
> 
> Starting from the root of the kernel tarball, the patch should be 
> applied to drivers/pci/pci.c, am I right?

You just cd to the top directory of the kernel source, and do

patch -p1 http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

On Wed, 12 Oct 2016, Pierre de Villemereuil wrote:

> Hi!
> 
> I'm sorry, I'm not savvy enough to know what to do with this (I know 
> basics on how to code and compile, but I'm no dev). Could someone 
> guide me through it?
> 
> I gather this patch needs to be applied to some kernel module code 
> which needs to be compiled and reloaded into my current kernel, 
> right?

More likely you'll have to rebuild an entire new kernel, not just a 
single module.

Search the support site for the distribution you are using.  It ought
to contain reasonably thorough instructions on how to build and install
your own version of their kernel.

Once you know how to do all that, I can tell you how the patch should
be applied -- that's the easy part.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi!

I'm sorry, I'm not savvy enough to know what to do with this (I know 
basics on how to code and compile, but I'm no dev). Could someone 
guide me through it?

I gather this patch needs to be applied to some kernel module code 
which needs to be compiled and reloaded into my current kernel, 
right?

Sorry to let you down...

Cheers,
Pierre.

Le mardi 11 octobre 2016, 11:18:28 NZDT Alan Stern a écrit :
> On Sat, 8 Oct 2016, Lukas Wunner wrote:
> > The PCI core already calls pm_runtime_get_sync() before invoking 
the
> > ->probe hook of a driver (see local_pci_probe()).  Drivers need 
to
> > explicitly release a runtime ref to allow their device to 
suspend.
> > 
> > For xhci-pci, this seems to happen in usb_hcd_pci_probe():
> > if (pci_dev_run_wake(dev))
> > 
> > pm_runtime_put_noidle(>dev);
> > 
> > So you could either modify the if-condition if you want to 
change the
> > behaviour for XHCI devices only, or if you want to change it in 
general,
> > 
> > add something like this to pci_dev_run_wake():
> > /* PME capable in principle, but not from the intended sleep 
state */
> > if (dev->pme_support && !pci_pme_capable(dev, 
pci_target_state(dev)))
> > 
> > return false;
> > 
> > I've briefly looked over the callers of pci_dev_run_wake() and 
the above
> > seems safe but you should double-check them.
> 
> That seems like a good suggestion.  The patch is below; Pierre, 
can you
> test it?  This should remove the need to set the USB autosuspend 
module
> parameter to -1.
> 
> Alan Stern
> 
> 
> 
> Index: usb-4.x/drivers/pci/pci.c
> 
===
> --- usb-4.x.orig/drivers/pci/pci.c
> +++ usb-4.x/drivers/pci/pci.c
> @@ -2064,6 +2064,10 @@ bool pci_dev_run_wake(struct pci_dev *de
>   if (!dev->pme_support)
>   return false;
> 
> + /* PME-capable in principle, but not from the intended sleep 
state */
> + if (!pci_pme_capable(dev, pci_target_state(dev)))
> + return false;
> +
>   while (bus->parent) {
>   struct pci_dev *bridge = bus->self;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

On Sat, 8 Oct 2016, Lukas Wunner wrote:

> The PCI core already calls pm_runtime_get_sync() before invoking the
> ->probe hook of a driver (see local_pci_probe()).  Drivers need to
> explicitly release a runtime ref to allow their device to suspend.
> For xhci-pci, this seems to happen in usb_hcd_pci_probe():
> 
>   if (pci_dev_run_wake(dev))
>   pm_runtime_put_noidle(>dev);
> 
> So you could either modify the if-condition if you want to change the
> behaviour for XHCI devices only, or if you want to change it in general,
> add something like this to pci_dev_run_wake():
> 
>   /* PME capable in principle, but not from the intended sleep state */
>   if (dev->pme_support && !pci_pme_capable(dev, pci_target_state(dev)))
>   return false;
> 
> I've briefly looked over the callers of pci_dev_run_wake() and the above
> seems safe but you should double-check them.

That seems like a good suggestion.  The patch is below; Pierre, can you 
test it?  This should remove the need to set the USB autosuspend module 
parameter to -1.

Alan Stern



Index: usb-4.x/drivers/pci/pci.c
===
--- usb-4.x.orig/drivers/pci/pci.c
+++ usb-4.x/drivers/pci/pci.c
@@ -2064,6 +2064,10 @@ bool pci_dev_run_wake(struct pci_dev *de
if (!dev->pme_support)
return false;
 
+   /* PME-capable in principle, but not from the intended sleep state */
+   if (!pci_pme_capable(dev, pci_target_state(dev)))
+   return false;
+
while (bus->parent) {
struct pci_dev *bridge = bus->self;
 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi guys!

Thanks for your efforts for fixing this bug! (The workaround of 
loading the kernel with "usbcore.autosuspend=-1" works very fine for 
me now).

Meanwhile, Asus gave me the expected response:

"Hello Mr. De Villemereuil,

Thank you for having solicited the ASUS Technical Support.

A reading your email I understand that your PC has a problem with 
the firmware bios from linux report.

Unfortunately, Linux is not part of our areas and we are not trained 
on.

So we have no confirmation on the Linux of the report.

Thank you for your understanding and wish you a good day."

I attached the explanation from Mathias about what is going on, but 
apparently if a bug of THEIR firmware is discovered on Linux, they 
simply freak out and say they don't do Linux (kinda expected...). 

So, I guess they won't release a fix for that... Makes your effort 
even more relevant since they sell quite a lot of computers and 
motherboards.

Cheers,
Pierre.


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Lukas Wunner]

On Thu, Oct 06, 2016 at 10:42:14AM -0400, Alan Stern wrote:
> On Wed, 5 Oct 2016, Lukas Wunner wrote:
> > On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> > > On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > > > In short, Pierre's USB host controller doesn't send wakeup signals from
> > > > runtime suspend, because the firmware limits the runtime-suspend state
> > > > to D0 and the controller can't issue PME# from the D0 state.  In this
> > > > situation we would prefer to avoid suspending the controller at all,
> > > > rather than have it go into runtime suspend and then stop working.
> > 
> > As Alan has correctly pointed out below, there are PCI devices which
> > do not support PME but should still be runtime suspended, e.g. because
> > they have some non-standard mechanism to sideband signal wakeup or
> > because they can detect when they need to resume even if they're in
> > a low-power state.
> > 
> > AFAIUI, this device should not be runtime suspended at all because it
> > doesn't generate a PME interrupt and thus stays suspended forever.
> 
> No, as Oliver said, the device can generate a PME# signal.  It just 
> can't do so from D0, and the firmware doesn't allow it to go into a 
> deeper power-savings state.

Okay.

> 
> > The PCI core doesn't allow runtime PM by default.  Rather it calls
> > pm_runtime_forbid() when the device is added (see pci_pm_init(), called
> > indirectly from pci_device_add()).  PCI drivers need to explicitly call
> > pm_runtime_allow(), typically from their ->probe hook.
> 
> No, pm_runtime_allow() is generally called by userspace, via writing 
> to the .../power/control file in sysfs.  Most drivers do not use it; it 
> is a policy mechanism.  And drivers can't use it to _enforce_ anything, 
> since the user can always override the setting.

Okay, I stand corrected.

> 
> > If this xHC cannot signal wakeup, it shouldn't allow runtime PM in the
> > first place.  Simple as that.
> > 
> I still think this belongs in the PCI core -- except for the difficulty
> of determining whether a device can use a non-PME method for wakeup
> signalling.  If that issue has a good solution then the PCI core could 
> call pm_runtime_get_noresume() for devices that are capable of 
> generating wakeup signals but not in any D-state that the firmware will 
> allow for runtime suspend.

The PCI core already calls pm_runtime_get_sync() before invoking the
->probe hook of a driver (see local_pci_probe()).  Drivers need to
explicitly release a runtime ref to allow their device to suspend.
For xhci-pci, this seems to happen in usb_hcd_pci_probe():

if (pci_dev_run_wake(dev))
pm_runtime_put_noidle(>dev);

So you could either modify the if-condition if you want to change the
behaviour for XHCI devices only, or if you want to change it in general,
add something like this to pci_dev_run_wake():

/* PME capable in principle, but not from the intended sleep state */
if (dev->pme_support && !pci_pme_capable(dev, pci_target_state(dev)))
return false;

I've briefly looked over the callers of pci_dev_run_wake() and the above
seems safe but you should double-check them.

Best regards,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

On Wed, 5 Oct 2016, Lukas Wunner wrote:

> On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> > On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > > In short, Pierre's USB host controller doesn't send wakeup signals from
> > > runtime suspend, because the firmware limits the runtime-suspend state
> > > to D0 and the controller can't issue PME# from the D0 state.  In this
> > > situation we would prefer to avoid suspending the controller at all,
> > > rather than have it go into runtime suspend and then stop working.
> 
> As Alan has correctly pointed out below, there are PCI devices which
> do not support PME but should still be runtime suspended, e.g. because
> they have some non-standard mechanism to sideband signal wakeup or
> because they can detect when they need to resume even if they're in
> a low-power state.
> 
> AFAIUI, this device should not be runtime suspended at all because it
> doesn't generate a PME interrupt and thus stays suspended forever.

No, as Oliver said, the device can generate a PME# signal.  It just 
can't do so from D0, and the firmware doesn't allow it to go into a 
deeper power-savings state.

> The PCI core doesn't allow runtime PM by default.  Rather it calls
> pm_runtime_forbid() when the device is added (see pci_pm_init(), called
> indirectly from pci_device_add()).  PCI drivers need to explicitly call
> pm_runtime_allow(), typically from their ->probe hook.

No, pm_runtime_allow() is generally called by userspace, via writing 
to the .../power/control file in sysfs.  Most drivers do not use it; it 
is a policy mechanism.  And drivers can't use it to _enforce_ anything, 
since the user can always override the setting.

> If this xHC cannot signal wakeup, it shouldn't allow runtime PM in the
> first place.  Simple as that.
> 
> The USB core has a function usb_enable_autosuspend() which does nothing
> else but call pm_runtime_allow().  This is called in a couple of places,
> I guess the relevant caller here is drivers/usb/core/hub.c:hub_probe().
> I'd suggest to amend that function so that runtime PM isn't allowed
> if the host controller can't signal plug events from pci_target_state().

usb_enable_autosuspend() is intended mainly for use with USB hubs.  
There is a policy decision in the USB stack that runtime PM will by 
default be allowed for hubs but not for other devices.

In any case, usb_enable_autosuspend() can't be used for host
controllers.  A host controller is not a USB device -- in this case it
is a PCI device.

> This approach is better than returning -EBUSY from the ->runtime_suspend
> hook because the PM core doesn't waste CPU cycles by repeatedly calling
> ->runtime_suspend in vain, always getting -EBUSY back.

I still think this belongs in the PCI core -- except for the difficulty
of determining whether a device can use a non-PME method for wakeup
signalling.  If that issue has a good solution then the PCI core could 
call pm_runtime_get_noresume() for devices that are capable of 
generating wakeup signals but not in any D-state that the firmware will 
allow for runtime suspend.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Oliver Neukum]

On Wed, 2016-10-05 at 22:41 +0200, Lukas Wunner wrote:
> The PCI core doesn't allow runtime PM by default.  Rather it calls
> pm_runtime_forbid() when the device is added (see pci_pm_init(),
> called
> indirectly from pci_device_add()).  PCI drivers need to explicitly
> call
> pm_runtime_allow(), typically from their ->probe hook.
> 
> If this xHC cannot signal wakeup, it shouldn't allow runtime PM in the
> first place.  Simple as that.

Presumably it can generate PME, just not in D0. The XHCI driver
could, albeit with a slight layering violation, check
that specific combination. But why put the code for a potentially
common problem into xhci?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Lukas Wunner]

On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > In short, Pierre's USB host controller doesn't send wakeup signals from
> > runtime suspend, because the firmware limits the runtime-suspend state
> > to D0 and the controller can't issue PME# from the D0 state.  In this
> > situation we would prefer to avoid suspending the controller at all,
> > rather than have it go into runtime suspend and then stop working.

As Alan has correctly pointed out below, there are PCI devices which
do not support PME but should still be runtime suspended, e.g. because
they have some non-standard mechanism to sideband signal wakeup or
because they can detect when they need to resume even if they're in
a low-power state.

AFAIUI, this device should not be runtime suspended at all because it
doesn't generate a PME interrupt and thus stays suspended forever.

The PCI core doesn't allow runtime PM by default.  Rather it calls
pm_runtime_forbid() when the device is added (see pci_pm_init(), called
indirectly from pci_device_add()).  PCI drivers need to explicitly call
pm_runtime_allow(), typically from their ->probe hook.

If this xHC cannot signal wakeup, it shouldn't allow runtime PM in the
first place.  Simple as that.

The USB core has a function usb_enable_autosuspend() which does nothing
else but call pm_runtime_allow().  This is called in a couple of places,
I guess the relevant caller here is drivers/usb/core/hub.c:hub_probe().
I'd suggest to amend that function so that runtime PM isn't allowed
if the host controller can't signal plug events from pci_target_state().

This approach is better than returning -EBUSY from the ->runtime_suspend
hook because the PM core doesn't waste CPU cycles by repeatedly calling
->runtime_suspend in vain, always getting -EBUSY back.

HTH,

Lukas

> > 
> > On Wed, 5 Oct 2016, Mathias Nyman wrote:
> > 
> > > On 04.10.2016 17:11, Alan Stern wrote:
> > > > On Tue, 4 Oct 2016, Mathias Nyman wrote:
> > > >
> > > >> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> > > >>> Hi Mathias,
> > > >>>
> > > >>> Just to know: does that mean the firmware from Asus is faulty in 
> > > >>> here? Do you
> > > >>> think I should contact Asus about this?
> > > >>>
> > > >>
> > > >> Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI 
> > > >> DSDT firmware version.
> > > >>
> > > >> But we still want the driver to handle cases like this.
> > > >> Just wrote the patch.
> > > >> Adding Alan Stern to CC for PM sanity feedback on it:
> > > >>
> > > >> ---
> > > >>
> > > >> Author: Mathias Nyman 
> > > >> Date:   Tue Oct 4 13:07:59 2016 +0300
> > > >>
> > > >>   xhci: Prevent a non-responsive xhci suspend state.
> > > >>
> > > >>   ACPI may limit the lowest possible runtime suspend PCI D-state 
> > > >> to D0.
> > > >>   If xHC is not capable of generating PME# events in D0 we end
> > > >>   up with a non-responsive runtime suspended host without PME# 
> > > >> capability
> > > >>   and with interrupts disabled, unable to detect or wake up when a
> > > >>   new usb device is connected.
> > > >>
> > > >>   This was triggered on a ASUS TP301UA machine.
> > > >>
> > > >>   Reported-by: Pierre de Villemereuil 
> > > >>   Signed-off-by: Mathias Nyman 
> > > >>
> > > >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > > >> index d7b0f97..08b021c 100644
> > > >> --- a/drivers/usb/host/xhci-pci.c
> > > >> +++ b/drivers/usb/host/xhci-pci.c
> > > >> @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, 
> > > >> bool do_wakeup)
> > > >>   if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
> > > >>   xhci_ssic_port_unused_quirk(hcd, true);
> > > >>
> > > >> +   /* Prevent a non-responsive PCI D0 state without PME# wake 
> > > >> capability */
> > > >> +   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
> > > >> +   if (!pci_pme_capable(pdev, PCI_D0))
> > > >> +   return -EBUSY;
> > > >> +
> > > >>   ret = xhci_suspend(xhci, do_wakeup);
> > > >>   if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
> > > >>   xhci_ssic_port_unused_quirk(hcd, false);
> > > >
> > > > I've got three comments about this proposal.
> > > >
> > > > First, this logic should not apply during system suspend, only during
> > > > runtime suspend.  You don't want to abort putting a laptop to sleep
> > > > just because the xHCI controller can't generate wakeup signals.
> > > 
> > > Yes, I assume it would be ok change usb core to pass down something like
> > > pm_message_t to suspend_common() so that we could do this.
> > > hcd_pci_runetime_suspend()  -> suspend_common()  -> 
> > > hcd->driver->pci_suspend()
> > > 
> > > Assuming this workaround should stay in xhci-pci.c
> > 
> > If necessary, it could be moved 

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Bjorn Helgaas]

[+cc Rafael, Lukas]

On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> [Adding Bjorn and linux-pci to the CC: list]
> 
> In short, Pierre's USB host controller doesn't send wakeup signals from
> runtime suspend, because the firmware limits the runtime-suspend state
> to D0 and the controller can't issue PME# from the D0 state.  In this
> situation we would prefer to avoid suspending the controller at all,
> rather than have it go into runtime suspend and then stop working.
> 
> On Wed, 5 Oct 2016, Mathias Nyman wrote:
> 
> > On 04.10.2016 17:11, Alan Stern wrote:
> > > On Tue, 4 Oct 2016, Mathias Nyman wrote:
> > >
> > >> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> > >>> Hi Mathias,
> > >>>
> > >>> Just to know: does that mean the firmware from Asus is faulty in here? 
> > >>> Do you
> > >>> think I should contact Asus about this?
> > >>>
> > >>
> > >> Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI 
> > >> DSDT firmware version.
> > >>
> > >> But we still want the driver to handle cases like this.
> > >> Just wrote the patch.
> > >> Adding Alan Stern to CC for PM sanity feedback on it:
> > >>
> > >> ---
> > >>
> > >> Author: Mathias Nyman 
> > >> Date:   Tue Oct 4 13:07:59 2016 +0300
> > >>
> > >>   xhci: Prevent a non-responsive xhci suspend state.
> > >>
> > >>   ACPI may limit the lowest possible runtime suspend PCI D-state to 
> > >> D0.
> > >>   If xHC is not capable of generating PME# events in D0 we end
> > >>   up with a non-responsive runtime suspended host without PME# 
> > >> capability
> > >>   and with interrupts disabled, unable to detect or wake up when a
> > >>   new usb device is connected.
> > >>
> > >>   This was triggered on a ASUS TP301UA machine.
> > >>
> > >>   Reported-by: Pierre de Villemereuil 
> > >>   Signed-off-by: Mathias Nyman 
> > >>
> > >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > >> index d7b0f97..08b021c 100644
> > >> --- a/drivers/usb/host/xhci-pci.c
> > >> +++ b/drivers/usb/host/xhci-pci.c
> > >> @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, 
> > >> bool do_wakeup)
> > >>   if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
> > >>   xhci_ssic_port_unused_quirk(hcd, true);
> > >>
> > >> +   /* Prevent a non-responsive PCI D0 state without PME# wake 
> > >> capability */
> > >> +   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
> > >> +   if (!pci_pme_capable(pdev, PCI_D0))
> > >> +   return -EBUSY;
> > >> +
> > >>   ret = xhci_suspend(xhci, do_wakeup);
> > >>   if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
> > >>   xhci_ssic_port_unused_quirk(hcd, false);
> > >
> > > I've got three comments about this proposal.
> > >
> > > First, this logic should not apply during system suspend, only during
> > > runtime suspend.  You don't want to abort putting a laptop to sleep
> > > just because the xHCI controller can't generate wakeup signals.
> > 
> > Yes, I assume it would be ok change usb core to pass down something like
> > pm_message_t to suspend_common() so that we could do this.
> > hcd_pci_runetime_suspend()  -> suspend_common()  -> 
> > hcd->driver->pci_suspend()
> > 
> > Assuming this workaround should stay in xhci-pci.c
> 
> If necessary, it could be moved into hcd_pci_runtime_suspend().  But I 
> would prefer to put it in the PCI core.
> 
> > > Second, this really has nothing to do with the D0 state.  The same
> > > logic should apply to whatever state is chosen for runtime suspend: If
> > > the controller can't generate PME# wakeup signals in that state then
> > > the suspend should be aborted.
> > 
> > PCI code actually does this for us, it will walk down the D-states until
> > it finds one that support PME#, but stop at D0 end return D0 even if D0
> > does not support PME#.
> 
> That sounds like a bug.  Or rather, accepting D0 as the target state
> when it doesn't support PME# is the bug.
> 
> > Unfortunately that is done in a static function in pci/pci.c.
> > 
> > static pci_power_t pci_target_state(struct pci_dev *dev)
> > {
> >  pci_power_t target_state = PCI_D3hot;
> > 
> > if (platform_pci_power_manageable(dev)) {
> >  /*
> >   * Call the platform to choose the target state of the 
> > device
> >   * and enable wake-up from this state if supported.
> >   */
> >  pci_power_t state = platform_pci_choose_state(dev);
> > 
> > switch (state) {
> > case PCI_POWER_ERROR:
> >  case PCI_UNKNOWN:
> >  break;
> >  case PCI_D1:
> >  case PCI_D2:
> >  if (pci_no_d1d2(dev))
> > break;
> >  default:
> >  

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

[Adding Bjorn and linux-pci to the CC: list]

In short, Pierre's USB host controller doesn't send wakeup signals from
runtime suspend, because the firmware limits the runtime-suspend state
to D0 and the controller can't issue PME# from the D0 state.  In this
situation we would prefer to avoid suspending the controller at all,
rather than have it go into runtime suspend and then stop working.

On Wed, 5 Oct 2016, Mathias Nyman wrote:

> On 04.10.2016 17:11, Alan Stern wrote:
> > On Tue, 4 Oct 2016, Mathias Nyman wrote:
> >
> >> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> >>> Hi Mathias,
> >>>
> >>> Just to know: does that mean the firmware from Asus is faulty in here? Do 
> >>> you
> >>> think I should contact Asus about this?
> >>>
> >>
> >> Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI DSDT 
> >> firmware version.
> >>
> >> But we still want the driver to handle cases like this.
> >> Just wrote the patch.
> >> Adding Alan Stern to CC for PM sanity feedback on it:
> >>
> >> ---
> >>
> >> Author: Mathias Nyman 
> >> Date:   Tue Oct 4 13:07:59 2016 +0300
> >>
> >>   xhci: Prevent a non-responsive xhci suspend state.
> >>
> >>   ACPI may limit the lowest possible runtime suspend PCI D-state to D0.
> >>   If xHC is not capable of generating PME# events in D0 we end
> >>   up with a non-responsive runtime suspended host without PME# 
> >> capability
> >>   and with interrupts disabled, unable to detect or wake up when a
> >>   new usb device is connected.
> >>
> >>   This was triggered on a ASUS TP301UA machine.
> >>
> >>   Reported-by: Pierre de Villemereuil 
> >>   Signed-off-by: Mathias Nyman 
> >>
> >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> >> index d7b0f97..08b021c 100644
> >> --- a/drivers/usb/host/xhci-pci.c
> >> +++ b/drivers/usb/host/xhci-pci.c
> >> @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
> >> do_wakeup)
> >>   if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
> >>   xhci_ssic_port_unused_quirk(hcd, true);
> >>
> >> +   /* Prevent a non-responsive PCI D0 state without PME# wake 
> >> capability */
> >> +   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
> >> +   if (!pci_pme_capable(pdev, PCI_D0))
> >> +   return -EBUSY;
> >> +
> >>   ret = xhci_suspend(xhci, do_wakeup);
> >>   if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
> >>   xhci_ssic_port_unused_quirk(hcd, false);
> >
> > I've got three comments about this proposal.
> >
> > First, this logic should not apply during system suspend, only during
> > runtime suspend.  You don't want to abort putting a laptop to sleep
> > just because the xHCI controller can't generate wakeup signals.
> 
> Yes, I assume it would be ok change usb core to pass down something like
> pm_message_t to suspend_common() so that we could do this.
> hcd_pci_runetime_suspend()  -> suspend_common()  -> hcd->driver->pci_suspend()
> 
> Assuming this workaround should stay in xhci-pci.c

If necessary, it could be moved into hcd_pci_runtime_suspend().  But I 
would prefer to put it in the PCI core.

> > Second, this really has nothing to do with the D0 state.  The same
> > logic should apply to whatever state is chosen for runtime suspend: If
> > the controller can't generate PME# wakeup signals in that state then
> > the suspend should be aborted.
> 
> PCI code actually does this for us, it will walk down the D-states until
> it finds one that support PME#, but stop at D0 end return D0 even if D0
> does not support PME#.

That sounds like a bug.  Or rather, accepting D0 as the target state
when it doesn't support PME# is the bug.

> Unfortunately that is done in a static function in pci/pci.c.
> 
> static pci_power_t pci_target_state(struct pci_dev *dev)
> {
>  pci_power_t target_state = PCI_D3hot;
> 
>   if (platform_pci_power_manageable(dev)) {
>  /*
>   * Call the platform to choose the target state of the device
>   * and enable wake-up from this state if supported.
>   */
>  pci_power_t state = platform_pci_choose_state(dev);
> 
>   switch (state) {
>   case PCI_POWER_ERROR:
>  case PCI_UNKNOWN:
>  break;
>  case PCI_D1:
>  case PCI_D2:
>  if (pci_no_d1d2(dev))
>   break;
>  default:
>   target_state = state;
>  }
>  } else if (!dev->pm_cap) {
>  target_state = PCI_D0;
>  } else if (device_may_wakeup(>dev)) {
>  /*
>   * Find the deepest state from which the device can generate
>   * wake-up 

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 04.10.2016 17:11, Alan Stern wrote:

On Tue, 4 Oct 2016, Mathias Nyman wrote:


On 03.10.2016 23:54, Pierre de Villemereuil wrote:

Hi Mathias,

Just to know: does that mean the firmware from Asus is faulty in here? Do you
think I should contact Asus about this?



Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI DSDT 
firmware version.

But we still want the driver to handle cases like this.
Just wrote the patch.
Adding Alan Stern to CC for PM sanity feedback on it:

---

Author: Mathias Nyman 
Date:   Tue Oct 4 13:07:59 2016 +0300

  xhci: Prevent a non-responsive xhci suspend state.

  ACPI may limit the lowest possible runtime suspend PCI D-state to D0.
  If xHC is not capable of generating PME# events in D0 we end
  up with a non-responsive runtime suspended host without PME# capability
  and with interrupts disabled, unable to detect or wake up when a
  new usb device is connected.

  This was triggered on a ASUS TP301UA machine.

  Reported-by: Pierre de Villemereuil 
  Signed-off-by: Mathias Nyman 

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index d7b0f97..08b021c 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
do_wakeup)
  if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
  xhci_ssic_port_unused_quirk(hcd, true);

+   /* Prevent a non-responsive PCI D0 state without PME# wake capability */
+   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
+   if (!pci_pme_capable(pdev, PCI_D0))
+   return -EBUSY;
+
  ret = xhci_suspend(xhci, do_wakeup);
  if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
  xhci_ssic_port_unused_quirk(hcd, false);


I've got three comments about this proposal.

First, this logic should not apply during system suspend, only during
runtime suspend.  You don't want to abort putting a laptop to sleep
just because the xHCI controller can't generate wakeup signals.


Yes, I assume it would be ok change usb core to pass down something like
pm_message_t to suspend_common() so that we could do this.
hcd_pci_runetime_suspend()  -> suspend_common()  -> hcd->driver->pci_suspend()

Assuming this workaround should stay in xhci-pci.c



Second, this really has nothing to do with the D0 state.  The same
logic should apply to whatever state is chosen for runtime suspend: If
the controller can't generate PME# wakeup signals in that state then
the suspend should be aborted.


PCI code actually does this for us, it will walk down the D-states until
it finds one that support PME#, but stop at D0 end return D0 even if D0
does not support PME#.

Unfortunately that is done in a static function in pci/pci.c.

static pci_power_t pci_target_state(struct pci_dev *dev)
{
pci_power_t target_state = PCI_D3hot;

if (platform_pci_power_manageable(dev)) {
/*
 * Call the platform to choose the target state of the device
 * and enable wake-up from this state if supported.
 */
pci_power_t state = platform_pci_choose_state(dev);

switch (state) {
case PCI_POWER_ERROR:
case PCI_UNKNOWN:
break;
case PCI_D1:
case PCI_D2:
if (pci_no_d1d2(dev))
break;
default:
target_state = state;
}
} else if (!dev->pm_cap) {
target_state = PCI_D0;
} else if (device_may_wakeup(>dev)) {
/*
 * Find the deepest state from which the device can generate
 * wake-up events, make it the target state and enable device
 * to generate PME#.
 */
if (dev->pme_support) {
while (target_state
  && !(dev->pme_support & (1 << target_state)))
target_state--;
}
}

return target_state;
}

The best I can do from xhci is call pci_choose_state() which will call
platform_pci_choose_state(), but won't do the PME# checking and
D-state decrement to D0 .

If pci_choose_state() returns D0 from a runtime suspend callback
(and yes, should make sure its runtime suspend, not system suspend)
I can pretty much assume pci_target_state will do the same.



Third, the same reasoning applies to every PCI device that relies on
PME#, not just to xHCI controllers.  Therefore the new code should be
added to drivers/pci/pci-driver.c:pci_pm_runtime_suspend(), not to
xhci-pci.c.


Yes, that would be the preferred solution.
I was not sure we can do that. pci-driver.c 

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

On Tue, 4 Oct 2016, Mathias Nyman wrote:

> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> > Hi Mathias,
> >
> > Just to know: does that mean the firmware from Asus is faulty in here? Do 
> > you
> > think I should contact Asus about this?
> >
> 
> Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI DSDT 
> firmware version.
> 
> But we still want the driver to handle cases like this.
> Just wrote the patch.
> Adding Alan Stern to CC for PM sanity feedback on it:
> 
> ---
> 
> Author: Mathias Nyman 
> Date:   Tue Oct 4 13:07:59 2016 +0300
> 
>  xhci: Prevent a non-responsive xhci suspend state.
>  
>  ACPI may limit the lowest possible runtime suspend PCI D-state to D0.
>  If xHC is not capable of generating PME# events in D0 we end
>  up with a non-responsive runtime suspended host without PME# capability
>  and with interrupts disabled, unable to detect or wake up when a
>  new usb device is connected.
> 
>  This was triggered on a ASUS TP301UA machine.
> 
>  Reported-by: Pierre de Villemereuil 
>  Signed-off-by: Mathias Nyman 
> 
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index d7b0f97..08b021c 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
> do_wakeup)
>  if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
>  xhci_ssic_port_unused_quirk(hcd, true);
> 
> +   /* Prevent a non-responsive PCI D0 state without PME# wake capability 
> */
> +   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
> +   if (!pci_pme_capable(pdev, PCI_D0))
> +   return -EBUSY;
> +
>  ret = xhci_suspend(xhci, do_wakeup);
>  if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
>  xhci_ssic_port_unused_quirk(hcd, false);

I've got three comments about this proposal.

First, this logic should not apply during system suspend, only during 
runtime suspend.  You don't want to abort putting a laptop to sleep 
just because the xHCI controller can't generate wakeup signals.

Second, this really has nothing to do with the D0 state.  The same
logic should apply to whatever state is chosen for runtime suspend: If
the controller can't generate PME# wakeup signals in that state then
the suspend should be aborted.

Third, the same reasoning applies to every PCI device that relies on
PME#, not just to xHCI controllers.  Therefore the new code should be
added to drivers/pci/pci-driver.c:pci_pm_runtime_suspend(), not to
xhci-pci.c.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 03.10.2016 23:54, Pierre de Villemereuil wrote:

Hi Mathias,

Just to know: does that mean the firmware from Asus is faulty in here? Do you
think I should contact Asus about this?



Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI DSDT 
firmware version.

But we still want the driver to handle cases like this.
Just wrote the patch.
Adding Alan Stern to CC for PM sanity feedback on it:

---

Author: Mathias Nyman 
Date:   Tue Oct 4 13:07:59 2016 +0300

xhci: Prevent a non-responsive xhci suspend state.

ACPI may limit the lowest possible runtime suspend PCI D-state to D0.

If xHC is not capable of generating PME# events in D0 we end
up with a non-responsive runtime suspended host without PME# capability
and with interrupts disabled, unable to detect or wake up when a
new usb device is connected.

This was triggered on a ASUS TP301UA machine.

Reported-by: Pierre de Villemereuil 
Signed-off-by: Mathias Nyman 

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index d7b0f97..08b021c 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
do_wakeup)
if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
xhci_ssic_port_unused_quirk(hcd, true);

+   /* Prevent a non-responsive PCI D0 state without PME# wake capability */
+   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
+   if (!pci_pme_capable(pdev, PCI_D0))
+   return -EBUSY;
+
ret = xhci_suspend(xhci, do_wakeup);
if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
xhci_ssic_port_unused_quirk(hcd, false);

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi Mathias,

Just to know: does that mean the firmware from Asus is faulty in here? Do you 
think I should contact Asus about this?

Cheers,
Pierre.

Le lundi 3 octobre 2016, 15:09:03 NZDT Mathias Nyman a écrit :
> On 03.10.2016 13:09, Mathias Nyman wrote:
> > I'm writing a workaround that will disable runtime PM for the xhci
> > controller In case we are about to put (keep) it in D0 without PME# wake
> > support.
> > 
> > I also learned the lspci -vv might wake up the controller from D3cold so
> > it's also possible that PME# is failing in D3Cold.
> > 
> > Could you do two more things to verify the D state so that I fix the right
> > issue:
> > 
> > 1. check the D state from sysfs, on-battery, in state where usb devices
> > are not detected: cat
> > /sys/bus/pci/devices/\:00\:14.0/firmware_node/power_state
> > 
> > 2. send the DSDT table of your machine, it includes the ACPI methods that
> > dictate the possible D states copy /sys/firmware/acpi/tables/DSDT to a
> > file and send it (a link to it, or attachment) to me, It's binary.
> Thanks, I got the info off-list, and device is really in D0 and ACPI DSDT
> (provided by firmware) is the one enforcing it:
> 
>  From DSDT:
> 
> Scope (_SB.PCI0)
>  {
>  Device (XHC)
>  {
>   ...
>   Method (_S0W, 0, NotSerialized)  // _S0W: S0 Device Wake State
>  {
>  If (LEqual (XFLT, Zero))
>  {
>  Return (Zero)
>  }
>  Else
>  {
>  Return (Zero)
>  }
>  }
> 
> 
> _S0W will return the deepest allowed runtime suspend D state, always zero in
> this case.
> 
> Normally if driver has all the needed quirks in place then XFLT == 3 (As
> linux xhci-hcd does) then _S0W usually returns "3". But with this firmware
> _S0W always returns zero. checking XFLT is useless.
> 
> Anyways, I'll write a workaround for this case in xhci, disabling runtime PM
> if lowest runtime sleep state (highest D state) is D0 and PME# is disabled
> in D0.
> 
> -Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 03.10.2016 13:09, Mathias Nyman wrote:

I'm writing a workaround that will disable runtime PM for the xhci controller
In case we are about to put (keep) it in D0 without PME# wake support.

I also learned the lspci -vv might wake up the controller from D3cold so it's 
also
possible that PME# is failing in D3Cold.

Could you do two more things to verify the D state so that I fix the right 
issue:

1. check the D state from sysfs, on-battery, in state where usb devices are not 
detected:
cat /sys/bus/pci/devices/\:00\:14.0/firmware_node/power_state

2. send the DSDT table of your machine, it includes the ACPI methods that 
dictate the possible D states
copy /sys/firmware/acpi/tables/DSDT to a file and send it (a link to it, or 
attachment) to me, It's binary.



Thanks, I got the info off-list, and device is really in D0 and ACPI DSDT 
(provided by firmware) is
the one enforcing it:

From DSDT:

Scope (_SB.PCI0)
{
Device (XHC)
{
...
Method (_S0W, 0, NotSerialized)  // _S0W: S0 Device Wake State
{
If (LEqual (XFLT, Zero))
{
Return (Zero)
}
Else
{
Return (Zero)
}
}


_S0W will return the deepest allowed runtime suspend D state, always zero in 
this case.

Normally if driver has all the needed quirks in place then XFLT == 3 (As linux 
xhci-hcd does)
then _S0W usually returns "3". But with this firmware _S0W always returns zero.
checking XFLT is useless.

Anyways, I'll write a workaround for this case in xhci, disabling runtime PM if
lowest runtime sleep state (highest D state) is D0 and PME# is disabled in D0.

-Mathias  
--

To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 01.10.2016 11:34, Pierre de Villemereuil wrote:

Hi Mathias,

FYI, turned out to be pretty easy. I got the tip from deano_ferrari without
even asking:
https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected?
p=2794434#post2794434

Simply adding this to GRUB options while launching kernel:
usbcore.autosuspend=-1
disables USB suspends and fixes the problem (well, "workarounds" it).

Weirdly enough, I still get "auto" on battery with:
cat /sys/bus/pci/devices/\:00\:14.0/power/control

Though I get "-1" from this:
cat /sys/module/usbcore/parameters/autosuspend

Not sure any of this is relevant, but I guess sharing information can't hurt.



It's probably laptop-mode-tools (or equivalent) that keeps writing over that 
value.

I'm writing a workaround that will disable runtime PM for the xhci controller
In case we are about to put (keep) it in D0 without PME# wake support.

I also learned the lspci -vv might wake up the controller from D3cold so it's 
also
possible that PME# is failing in D3Cold.

Could you do two more things to verify the D state so that I fix the right 
issue:

1. check the D state from sysfs, on-battery, in state where usb devices are not 
detected:
cat /sys/bus/pci/devices/\:00\:14.0/firmware_node/power_state

2. send the DSDT table of your machine, it includes the ACPI methods that 
dictate the possible D states
copy /sys/firmware/acpi/tables/DSDT to a file and send it (a link to it, or 
attachment) to me, It's binary.

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi Mathias,

FYI, turned out to be pretty easy. I got the tip from deano_ferrari without 
even asking:
https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected?
p=2794434#post2794434

Simply adding this to GRUB options while launching kernel:
usbcore.autosuspend=-1
disables USB suspends and fixes the problem (well, "workarounds" it).

Weirdly enough, I still get "auto" on battery with:
cat /sys/bus/pci/devices/\:00\:14.0/power/control

Though I get "-1" from this:
cat /sys/module/usbcore/parameters/autosuspend

Not sure any of this is relevant, but I guess sharing information can't hurt.

Cheers,
Pierre.

Le vendredi 30 septembre 2016, 11:32:46 NZDT Mathias Nyman a écrit :
> On 29.09.2016 23:36, Pierre de Villemereuil wrote:
> > Hi Mathias,
> > 
> > It seems you are right: entering
> > echo on > /sys/bus/pci/devices/\:00\:14.0/power/control
> > does tame USB to behave properly.
> > 
> > However, every time the AC is plugged/unplugged, this value gets
> > overridden. Any way to make this permanent? (I realise this would harm a
> > tiny bit of my battery life, but I guess not enough for me to realise
> > it).
> There's probably something like laptop-mode-tools that sets these, I'm not
> really familiar, or using it myself but I'd start looking in
> 
> /etc/laptop-mode/laptop-mode.conf
> /etc/laptop-mode/conf.d/*
> 
> and try to find the configuration that enables runtime power management for
> usb host while on battery.
> 
> -Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 29.09.2016 23:36, Pierre de Villemereuil wrote:

Hi Mathias,

It seems you are right: entering
echo on > /sys/bus/pci/devices/\:00\:14.0/power/control
does tame USB to behave properly.

However, every time the AC is plugged/unplugged, this value gets overridden. 
Any way to make this permanent? (I realise this would harm a tiny bit of my 
battery life, but I guess not enough for me to realise it).



There's probably something like laptop-mode-tools that sets these, I'm not 
really familiar, or using it myself but
I'd start looking in

/etc/laptop-mode/laptop-mode.conf
/etc/laptop-mode/conf.d/*

and try to find the configuration that enables runtime power management for usb 
host while on battery.

-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi Mathias,

It seems you are right: entering 
echo on > /sys/bus/pci/devices/\:00\:14.0/power/control 
does tame USB to behave properly.

However, every time the AC is plugged/unplugged, this value gets overridden. 
Any way to make this permanent? (I realise this would harm a tiny bit of my 
battery life, but I guess not enough for me to realise it).

If you need any info to find a proper fix and help to test it, don't hesitate. 

Cheers,
Pierre.


Le jeudi 29 septembre 2016, 15:50:34 NZDT Mathias Nyman a écrit :
> On 28.09.2016 22:08, Pierre de Villemereuil wrote:
> > Hi!
> > 
> > When entering "cat
> > /sys/bus/pci/devices/\:00\:14.0/power/runtime_status", I got:
> > - on battery: suspended
> > - on AC: active
> 
> Ok thanks, So current guess is that xhci-hcd driver suspend was called,
> it stopped the xhci controller, and expects PCI code to put it to D3.
> xhci-hcd driver assumes it will be woken up later by a PCI PME# event at
> device connect, which will call the resume function for the xhci-hcd driver.
> 
> But PCI never puts the controller to D3, and lspci shows xhci controller is
> not capable of generating PME# events in D0 (PME(D0 shows "-")
> 
> Capabilities: [70] Power Management version 2
>  Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable+ DSel=0
> DScale=0 PME-
> 
> So we get stuck in D0, incapable of generating PME#, with a stopped xhci
> controller waiting for PME# to wake us up.
> 
> I'll see if I can create a similar situation.
> 
> Keeping the host on should help as a temporary workaround for you:
> echo on > /sys/bus/pci/devices/\:00\:14.0/power/control
> 
> There might be something in ACPI DSDT tables (provided by firmware) that
> prevents PCI from putting xhci to D3.
> 
> -Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 28.09.2016 22:08, Pierre de Villemereuil wrote:

Hi!

When entering "cat /sys/bus/pci/devices/\:00\:14.0/power/runtime_status",
I got:
- on battery: suspended
- on AC: active



Ok thanks, So current guess is that xhci-hcd driver suspend was called,
it stopped the xhci controller, and expects PCI code to put it to D3.
xhci-hcd driver assumes it will be woken up later by a PCI PME# event at
device connect, which will call the resume function for the xhci-hcd driver.

But PCI never puts the controller to D3, and lspci shows xhci controller is
not capable of generating PME# events in D0 (PME(D0 shows "-")

Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-

So we get stuck in D0, incapable of generating PME#, with a stopped xhci 
controller
waiting for PME# to wake us up.

I'll see if I can create a similar situation.

Keeping the host on should help as a temporary workaround for you:
echo on > /sys/bus/pci/devices/\:00\:14.0/power/control

There might be something in ACPI DSDT tables (provided by firmware) that
prevents PCI from putting xhci to D3.

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi!

When entering "cat /sys/bus/pci/devices/\:00\:14.0/power/runtime_status", 
I got:
- on battery: suspended
- on AC: active

Cheers,
Pierre

Le mercredi 28 septembre 2016, 16:59:25 NZDT Mathias Nyman a écrit :
> On 28.09.2016 11:43, Pierre de Villemereuil wrote:
> > Hi!
> > 
> > Here you are.
> 
> Thanks
> 
> > - On battery:
> > 
> > 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
> > Controller (rev 21) (prog-if 30 [XHCI])> 
> >  Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
> 
> I was expecting it to be in D3, and thinking there could be an issue with
> PME waking it up. The previous dmesg logs showed that the suspend routines
> for xhci-hcd were called, so everything should be ready for xhci to go to
> D3, unless some ACPI/PCI parts prevent it
> 
> And a bit odd that PME-Enable+ is set. PME-Enable is usually set when we
> enter D3 to enable PCI waking up the xhci controller
> 
> > - on AC:
> > 
> > 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
> > Controller (rev 21) (prog-if 30 [XHCI])> 
> >  Subsystem: ASUSTeK Computer Inc. Device 201f
> >  
> >  Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> 
> Here PME-Enable- is not set in D0, as it should.
> 
> does xhci show its status as suspended on battery?
> (we know the xhci controller in PCI in D0, but xhci might still show
> suspended)
> 
> what does
> cat /sys/bus/pci/devices/\:00\:14.0/power/runtime_status
> show?
> 
> -Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 28.09.2016 11:43, Pierre de Villemereuil wrote:

Hi!

Here you are.



Thanks


- On battery:

00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller (rev 21) (prog-if 30 [XHCI])
 Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-


I was expecting it to be in D3, and thinking there could be an issue with PME 
waking it up.
The previous dmesg logs showed that the suspend routines for xhci-hcd were 
called, so everything should be ready
for xhci to go to D3, unless some ACPI/PCI parts prevent it

And a bit odd that PME-Enable+ is set. PME-Enable is usually set when we enter 
D3 to enable PCI waking up the
xhci controller




- on AC:

00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller (rev 21) (prog-if 30 [XHCI])
 Subsystem: ASUSTeK Computer Inc. Device 201f
 Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-


Here PME-Enable- is not set in D0, as it should.

does xhci show its status as suspended on battery?
(we know the xhci controller in PCI in D0, but xhci might still show suspended)

what does
cat /sys/bus/pci/devices/\:00\:14.0/power/runtime_status
show?

-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi!

Here you are.

- On battery:

00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller (rev 21) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Device 201f
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR-  On 27.09.2016 22:28, Pierre de Villemereuil wrote:
> > Hi !
> > 
> >> run:
> >> sudo lspci -d :8c31 -vv
> > 
> > The command yields nothing, either on AC or battery, with a USB device
> > plugged or not.
> > 
> > FYI, here's a 'blank' lspci:
> > > 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
> 
> Right, -d :8c31 was Lynx Point xhci specific, you got a Sunris Point LP one.
> 
> sudo lspci -s 14.0 -vv
> 
> should do it
> Sorry about that, the "-vv" are also needed for showing D state and
> PME-enable and PME status
> 
> -Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 27.09.2016 22:28, Pierre de Villemereuil wrote:

Hi !


run:
sudo lspci -d :8c31 -vv


The command yields nothing, either on AC or battery, with a USB device plugged
or not.

FYI, here's a 'blank' lspci:

> 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI



Right, -d :8c31 was Lynx Point xhci specific, you got a Sunris Point LP one.

sudo lspci -s 14.0 -vv

should do it
Sorry about that, the "-vv" are also needed for showing D state and PME-enable 
and PME status

-Mathias


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi !

> run:
> sudo lspci -d :8c31 -vv

The command yields nothing, either on AC or battery, with a USB device plugged 
or not.

FYI, here's a 'blank' lspci:

00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 
08)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor 
Thermal Subsystem (rev 08)
00:13.0 Non-VGA unclassified device: Intel Corporation Device 9d35 (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP 
Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP 
Serial IO I2C Controller #0 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI 
#1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller 
[AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port 
#6 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

> Did I understand correctly that there was nothing in dmesg if AC is
> unplugged when connecting a usb device? Not even with enhanced xhci
> debugging enabled?

Yes, that is correct.

> 
> Is there anything that looks suspicious in BIOS?
> An option that disables wake up events for usb ports? or disables
> usb ports, Energy saver support EuP/ErP?

No, the only thing in the BIOS regarding USB is a security feature allowing to 
disable it entirely and another one regarding "legacy USB" (which, as far as I 
understand concerns very old USB1 devices?).

Hope this helps,
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 27.09.2016 03:03, Pierre de Villemereuil wrote:

Hi guys,

Any news on this front? Anything I can do to help find the issue?



A couple more logs just to clarify a few things.

run:
sudo lspci -d :8c31 -vv

both when AC is connected (the state where it detects usb devices)
and when not connected (state when usb devive detection fails)

It should show the pci state of the controller (D0 is up and running, D3 is 
suspended)
if in D3 it should show that PME is enabled.
A usb connect event should generate a PME that then wakes up the xHC host from 
D3.

Did I understand correctly that there was nothing in dmesg if AC is unplugged
when connecting a usb device? Not even with enhanced xhci debugging enabled?

Is there anything that looks suspicious in BIOS?
An option that disables wake up events for usb ports? or disables
usb ports, Energy saver support EuP/ErP?

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi guys,

Any news on this front? Anything I can do to help find the issue?

Cheers,
Pierre.

Le mardi 20 septembre 2016, 11:05:13 NZDT Oliver Neukum a écrit :
> On Tue, 2016-09-20 at 20:58 +1200, Pierre de Villemereuil wrote:
> > Hi Oliver!
> > 
> > Here you are.
> > 
> > dmesg signals when plugging AC in:
> > http://paste.opensuse.org/57485b34
> > 
> > dmesg signals when unplugging AC:
> > http://paste.opensuse.org/5a8e9910
> > 
> > And just in case, dmesg signals when plugging a USB device when AC is
> > plugged in:
> > http://paste.opensuse.org/45faee84
> > 
> > Hope this helps!
> 
> This looks like your XHCI is suspended when you unplug AC but remote
> wakeup is not operational. The problem looks specific to XHCI not
> USB in general. Time to add the XHCI maintainer.
> 
> Mathias,
> 
> hotplug on battery fails. The XHCI seems to fail to wake up if something
> is plugged into the root hub.
> 
>   Regards
>   Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Oliver Neukum]

On Tue, 2016-09-20 at 20:58 +1200, Pierre de Villemereuil wrote:
> Hi Oliver!
> 
> Here you are.
> 
> dmesg signals when plugging AC in:
> http://paste.opensuse.org/57485b34
> 
> dmesg signals when unplugging AC:
> http://paste.opensuse.org/5a8e9910
> 
> And just in case, dmesg signals when plugging a USB device when AC is plugged 
> in:
> http://paste.opensuse.org/45faee84
> 
> Hope this helps!

This looks like your XHCI is suspended when you unplug AC but remote
wakeup is not operational. The problem looks specific to XHCI not
USB in general. Time to add the XHCI maintainer.

Mathias,

hotplug on battery fails. The XHCI seems to fail to wake up if something
is plugged into the root hub.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi Oliver!

Here you are.

dmesg signals when plugging AC in:
http://paste.opensuse.org/57485b34

dmesg signals when unplugging AC:
http://paste.opensuse.org/5a8e9910

And just in case, dmesg signals when plugging a USB device when AC is plugged 
in:
http://paste.opensuse.org/45faee84

Hope this helps!

Cheers,
Pierre.

Le mardi 20 septembre 2016, 10:38:09 NZST Oliver Neukum a écrit :
> On Tue, 2016-09-20 at 11:11 +1200, Pierre de Villemereuil wrote:
> > Dear Oliver,
> > 
> > Sorry about my last message, the bug is actually still going on. I found
> > something interesting though: when AC is plugged, USB is working totally
> > OK, but when on battery, then here comes trouble... Could this be power
> > management?
> 
> Yes, absolutely.
> 
> > Below is my TLP config (mostly default) if it's any help:
> > http://paste.opensuse.org/8168b819
> > 
> > I tried to disable USB-suspend: doesn't change anything.
> > 
> > I cannot unload xhci_hcd module:
> > # modprobe -r xhci_hcd
> > modprobe: FATAL: Module xhci_hcd is in use.
> > 
> > Something specific I should use?
> > 
> > Also, after entering your command below to enhance debug, dmesg is still
> > not showing anything when USB is plugged. Still, below is the output of
> > dmesg when "udevadm trigger" is entered with a USB mouse plugged:
> > http://paste.opensuse.org/325663de
> > 
> > Hope this helps and sorry for the confusion with my last e-mail.
> 
> OK, please make logs of connecting and disconnecting your system
> from AC with XHCI debugging enabled and post them to this list.
> 
>   Regards
>   Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Oliver Neukum]

On Tue, 2016-09-20 at 11:11 +1200, Pierre de Villemereuil wrote:
> Dear Oliver,
> 
> Sorry about my last message, the bug is actually still going on. I found 
> something interesting though: when AC is plugged, USB is working totally OK, 
> but when on battery, then here comes trouble... Could this be power 
> management? 

Yes, absolutely.

> Below is my TLP config (mostly default) if it's any help:
> http://paste.opensuse.org/8168b819
> 
> I tried to disable USB-suspend: doesn't change anything.
> 
> I cannot unload xhci_hcd module:
> # modprobe -r xhci_hcd
> modprobe: FATAL: Module xhci_hcd is in use.
> 
> Something specific I should use?
> 
> Also, after entering your command below to enhance debug, dmesg is still not 
> showing anything when USB is plugged. Still, below is the output of dmesg 
> when 
> "udevadm trigger" is entered with a USB mouse plugged:
> http://paste.opensuse.org/325663de
> 
> Hope this helps and sorry for the confusion with my last e-mail.

OK, please make logs of connecting and disconnecting your system
from AC with XHCI debugging enabled and post them to this list.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Dear Oliver,

Sorry about my last message, the bug is actually still going on. I found 
something interesting though: when AC is plugged, USB is working totally OK, 
but when on battery, then here comes trouble... Could this be power 
management? 

Below is my TLP config (mostly default) if it's any help:
http://paste.opensuse.org/8168b819

I tried to disable USB-suspend: doesn't change anything.

I cannot unload xhci_hcd module:
# modprobe -r xhci_hcd
modprobe: FATAL: Module xhci_hcd is in use.

Something specific I should use?

Also, after entering your command below to enhance debug, dmesg is still not 
showing anything when USB is plugged. Still, below is the output of dmesg when 
"udevadm trigger" is entered with a USB mouse plugged:
http://paste.opensuse.org/325663de

Hope this helps and sorry for the confusion with my last e-mail.

Cheers,
Pierre.

Le mardi 20 septembre 2016, 09:43:57 NZST Pierre de Villemereuil a écrit :
> Dear Oliver,
> 
> I'm not really sure what happened, but now USB appears to be working
> perfectly well... In the meantime, since my last checks, I simply updated
> Tumbleweed and entered the command below as root (I rebooted twice since
> then: USB still working!).
> 
> I didn't find anything relevant in the Tumbleweed updates, only this one is
> related to USB, but the only commit doesn't seem to be fixing anything at
> runtime:
> 
>  usb_modeswitch 
> Subpackages: usb_modeswitch-data
> 
> - Avoid a race in make install, which lead to packaging a truncated
>   usb_modeswitch_dispatcher script. Fixes boo#998641
> 
> But I dont think the command below is still active after a reboot (is it?)
> and it seems just to activate some more debugging, so I really don't
> understand how this happened!
> 
> Sorry, this must be a quite frustrating report...
> 
> Cheers,
> Pierre.
> 
> Le lundi 19 septembre 2016, 11:22:52 NZST Oliver Neukum a écrit :
> > On Sun, 2016-09-18 at 19:48 +1200, Pierre de Villemereuil wrote:
> > > Dear kernel devs,
> > > 
> > > I'm using openSUSE Tumbleweed (kernel 4.7.2-2-default) on an ASUS
> > > Vivobook
> > > Flip TP301UA-C4028T, see here for specs:
> > > https://www.asus.com/Notebooks/ASUS-VivoBook-Flip-TP301UA/specifications
> > > /
> > > 
> > > Since my install in July, USB hot-plug (a.k.a. plug'n'play) is not
> > > working. To make any USB device working (I tested many USB keys, a
> > > slideshow remote control and a mouse), it has to be plugged on boot up
> > > or
> > > wake up from suspend. Using the following command also make the system
> > > aware that USB is connected: udevadm trigger
> > > 
> > > More information can be found on the following thread on the openSUSE
> > > forums:
> > > https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected
> > 
> > Basically dmesg should show a hotplug. What happens if you unload and
> > reload the xhci_hcd modules?
> > 
> > And please do
> > 
> > echo "module xhci_hcd +mpf" > /sys/kernel/debug/dynamic_debug/control
> > 
> > (as root) and check dmesg again.
> > 
> > Regards
> > 
> > Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Dear Oliver,

I'm not really sure what happened, but now USB appears to be working perfectly 
well... In the meantime, since my last checks, I simply updated Tumbleweed and 
entered the command below as root (I rebooted twice since then: USB still 
working!).

I didn't find anything relevant in the Tumbleweed updates, only this one is 
related to USB, but the only commit doesn't seem to be fixing anything at 
runtime:

 usb_modeswitch 
Subpackages: usb_modeswitch-data

- Avoid a race in make install, which lead to packaging a truncated
  usb_modeswitch_dispatcher script. Fixes boo#998641

But I dont think the command below is still active after a reboot (is it?) and 
it seems just to activate some more debugging, so I really don't understand 
how this happened!

Sorry, this must be a quite frustrating report...

Cheers,
Pierre.

Le lundi 19 septembre 2016, 11:22:52 NZST Oliver Neukum a écrit :
> On Sun, 2016-09-18 at 19:48 +1200, Pierre de Villemereuil wrote:
> > Dear kernel devs,
> > 
> > I'm using openSUSE Tumbleweed (kernel 4.7.2-2-default) on an ASUS Vivobook
> > Flip TP301UA-C4028T, see here for specs:
> > https://www.asus.com/Notebooks/ASUS-VivoBook-Flip-TP301UA/specifications/
> > 
> > Since my install in July, USB hot-plug (a.k.a. plug'n'play) is not
> > working. To make any USB device working (I tested many USB keys, a
> > slideshow remote control and a mouse), it has to be plugged on boot up or
> > wake up from suspend. Using the following command also make the system
> > aware that USB is connected: udevadm trigger
> > 
> > More information can be found on the following thread on the openSUSE
> > forums:
> > https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected
> Basically dmesg should show a hotplug. What happens if you unload and
> reload the xhci_hcd modules?
> 
> And please do
> 
> echo "module xhci_hcd +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> (as root) and check dmesg again.
> 
>   Regards
>   Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Oliver Neukum]

On Sun, 2016-09-18 at 19:48 +1200, Pierre de Villemereuil wrote:
> Dear kernel devs,
> 
> I'm using openSUSE Tumbleweed (kernel 4.7.2-2-default) on an ASUS Vivobook 
> Flip TP301UA-C4028T, see here for specs:
> https://www.asus.com/Notebooks/ASUS-VivoBook-Flip-TP301UA/specifications/
> 
> Since my install in July, USB hot-plug (a.k.a. plug'n'play) is not working. 
> To 
> make any USB device working (I tested many USB keys, a slideshow remote 
> control and a mouse), it has to be plugged on boot up or wake up from 
> suspend. 
> Using the following command also make the system aware that USB is connected:
> udevadm trigger
> 
> More information can be found on the following thread on the openSUSE forums:
> https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected

Basically dmesg should show a hotplug. What happens if you unload and
reload the xhci_hcd modules?

And please do

echo "module xhci_hcd +mpf" > /sys/kernel/debug/dynamic_debug/control

(as root) and check dmesg again.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Dear kernel devs,

I'm using openSUSE Tumbleweed (kernel 4.7.2-2-default) on an ASUS Vivobook 
Flip TP301UA-C4028T, see here for specs:
https://www.asus.com/Notebooks/ASUS-VivoBook-Flip-TP301UA/specifications/

Since my install in July, USB hot-plug (a.k.a. plug'n'play) is not working. To 
make any USB device working (I tested many USB keys, a slideshow remote 
control and a mouse), it has to be plugged on boot up or wake up from suspend. 
Using the following command also make the system aware that USB is connected:
udevadm trigger

More information can be found on the following thread on the openSUSE forums:
https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected

Since, from what I shared on that thread didn't lead anywhere suspicious, the 
guy that helped me there found my problem much curious and encouraged me to 
report this bug to this mailing list.

I'm no IT guys, but I'll happily type any command that could give you more 
input (much of the input is already available in the forum thread).

Hope this will be of any help!

Cheers,
Pierre.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html