[PATCH 1/3] xhci: Ensure link state is U3 after setting USB_SS_PORT_LS_U3

[PATCH 1/3] xhci: Ensure link state is U3 after setting USB_SS_PORT_LS_U3

[Kai-Heng Feng]

The xHCI spec doesn't specify the upper bound of U3 transition time. For
some devices 20ms is not enough, so we need to make sure the link state
is in U3 before further actions.

I've tried to use U3 Entry Capability by setting U3 Entry Enable in
config register, however the port change event for U3 transition
interrupts the system suspend process.

For now let's use the less ideal method by polling PLS.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
 drivers/usb/host/xhci-hub.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 7a3a29e5e9d2..2b2e9d004dbf 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1228,6 +1228,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
 			break;
 		case USB_PORT_FEAT_LINK_STATE:
 			temp = readl(ports[wIndex]->addr);
+			xhci_dbg(xhci, "before setting link state, actual port %d-%d status = 0x%0x\n", hcd->self.busnum, wIndex + 1, temp);
 			/* Disable port */
 			if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
 				xhci_dbg(xhci, "Disable port %d\n", wIndex);
@@ -1316,9 +1317,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
 			msleep(20); /* wait device to enter */
 			spin_lock_irqsave(&xhci->lock, flags);
 
-			temp = readl(ports[wIndex]->addr);
-			if (link_state == USB_SS_PORT_LS_U3)
+			if (link_state == USB_SS_PORT_LS_U3) {
+				retval = xhci_handshake(ports[wIndex]->addr, PORT_PLS_MASK, XDEV_U3, 80 * 1000);
+				if (retval)
+					xhci_dbg(xhci, "polling XDEV_U3 on port %d-%d timeout\n", hcd->self.busnum, wIndex + 1);
+
 				bus_state->suspended_ports |= 1 << wIndex;
+			}
+
+			temp = readl(ports[wIndex]->addr);
+			xhci_dbg(xhci, "after setting link state, port %d-%d status = 0x%0x\n", hcd->self.busnum, wIndex + 1, temp);
+
 			break;
 		case USB_PORT_FEAT_POWER:
 			/*
-- 
2.17.1

[PATCH 2/3] xhci: Wait until link state trainsits to U0 after setting USB_SS_PORT_LS_U0

[Kai-Heng Feng]

Like U3 case, xHCI spec doesn't specify the upper bound of U0 transition
time. The 20ms is not enough for some devices.

Intead of polling PLS or PLC, we can facilitate the port change event to
know that the link transits to U0 is completed.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
 drivers/usb/host/xhci-hub.c  | 8 +++++++-
 drivers/usb/host/xhci-mem.c  | 1 +
 drivers/usb/host/xhci-ring.c | 1 +
 drivers/usb/host/xhci.h      | 1 +
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 2b2e9d004dbf..07886a1bce62 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1310,11 +1310,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
 					spin_lock_irqsave(&xhci->lock, flags);
 				}
 			}
+			if (link_state == USB_SS_PORT_LS_U0)
+				reinit_completion(&ports[wIndex]->link_state_changed);
 
 			xhci_set_link_state(xhci, ports[wIndex], link_state);
 
 			spin_unlock_irqrestore(&xhci->lock, flags);
-			msleep(20); /* wait device to enter */
+			if (link_state == USB_SS_PORT_LS_U0) {
+				if (!wait_for_completion_timeout(&ports[wIndex]->link_state_changed, msecs_to_jiffies(100)))
+					xhci_dbg(xhci, "missing U0 port change event for port %d-%d\n", hcd->self.busnum, wIndex + 1);
+			} else
+				msleep(20); /* wait device to enter */
 			spin_lock_irqsave(&xhci->lock, flags);
 
 			if (link_state == USB_SS_PORT_LS_U3) {
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 3b1388fa2f36..c760a28e3556 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2268,6 +2268,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)
 		xhci->hw_ports[i].addr = &xhci->op_regs->port_status_base +
 			NUM_PORT_REGS * i;
 		xhci->hw_ports[i].hw_portnum = i;
+		init_completion(&xhci->hw_ports[i].link_state_changed);
 	}
 
 	xhci->rh_bw = kcalloc_node(num_ports, sizeof(*xhci->rh_bw), flags,
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d23f7408c81f..44d91a53bf07 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1677,6 +1677,7 @@ static void handle_port_status(struct xhci_hcd *xhci,
 	     (portsc & PORT_PLS_MASK) == XDEV_U1 ||
 	     (portsc & PORT_PLS_MASK) == XDEV_U2)) {
 		xhci_dbg(xhci, "resume SS port %d finished\n", port_id);
+		complete(&port->link_state_changed);
 		/* We've just brought the device into U0/1/2 through either the
 		 * Resume state after a device remote wakeup, or through the
 		 * U3Exit state after a host-initiated resume.  If it's a device
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 13d8838cd552..b86a664453dc 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1708,6 +1708,7 @@ struct xhci_port {
 	int			hw_portnum;
 	int			hcd_portnum;
 	struct xhci_hub		*rhub;
+	struct completion       link_state_changed;
 };
 
 struct xhci_hub {
-- 
2.17.1

Re: [PATCH 2/3] xhci: Wait until link state trainsits to U0 after setting USB_SS_PORT_LS_U0

[Mathias Nyman]

On 3.1.2020 10.40, Kai-Heng Feng wrote:
> Like U3 case, xHCI spec doesn't specify the upper bound of U0 transition
> time. The 20ms is not enough for some devices.
> 
> Intead of polling PLS or PLC, we can facilitate the port change event to
> know that the link transits to U0 is completed.
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>   drivers/usb/host/xhci-hub.c  | 8 +++++++-
>   drivers/usb/host/xhci-mem.c  | 1 +
>   drivers/usb/host/xhci-ring.c | 1 +
>   drivers/usb/host/xhci.h      | 1 +
>   4 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 2b2e9d004dbf..07886a1bce62 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -1310,11 +1310,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>   					spin_lock_irqsave(&xhci->lock, flags);
>   				}
>   			}
> +			if (link_state == USB_SS_PORT_LS_U0)
> +				reinit_completion(&ports[wIndex]->link_state_changed);

All the other suspend and resume related port flags/completions are
in struct xhci_bus_state. See for example rexit_done[].
Not sure that is a better place but at least it would be consistent.

Could actually make sense to move more of them to the xhci_port structure,
but perhaps in some later suspend/resume rework patch.
>   
>   			xhci_set_link_state(xhci, ports[wIndex], link_state);
>   
>   			spin_unlock_irqrestore(&xhci->lock, flags);
> -			msleep(20); /* wait device to enter */
> +			if (link_state == USB_SS_PORT_LS_U0) {
> +				if (!wait_for_completion_timeout(&ports[wIndex]->link_state_changed, msecs_to_jiffies(100)))
> +					xhci_dbg(xhci, "missing U0 port change event for port %d-%d\n", hcd->self.busnum, wIndex + 1);

We might be waiting for completion here in unnecessary.
No completion is called if port is already in U0, either set by
xhci_bus_resume(), or we race with a device initiated resume.

Maybe read the current port link state first, and don't do anything if it's
already in U0, or fail if it's in a state where we can't resume to U0.

> +			} else
> +				msleep(20); /* wait device to enter */
>   			spin_lock_irqsave(&xhci->lock, flags);

Code might also be cleaner if we have separate if() statements for U0 and U3 link
states, and skip the generic xhci_set_link_state()

USB 3.2 specs only support PORT_LINK_STATE request feature selectors for
U0, U1, U2, U3, SS.Disabled, Rx.Detect and Compliance mode.
Out of these xhci driver already handles the SS.Disabled, Rx.detect and Compliance in
separate if statements, and xHC hardware can't force a U1 or U2 state by writing
the PLS field of the PORTSC register, so the xhci_set_link_state() here
is only useful for U0 and U3.

So maybe something like this:

if (link_state == U0)
   if (active_link_state == U0)
     break
   else if (active_link_state != a proper link state)
     return error	
   xhci_set_link_state(U0)
   wait_for_completion_timeout()
   break;

if (link_state == U3)
   xhci_stop_device(slot_id)
   xhci_set_link_state(U3)
   for (max 10 tries) {
     msleep_range(~10ms)
     if (readl(PORTSC(PLS) == U3)
       break
   }
   break
>   
>   			if (link_state == USB_SS_PORT_LS_U3) {
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 3b1388fa2f36..c760a28e3556 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -2268,6 +2268,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)
>   		xhci->hw_ports[i].addr = &xhci->op_regs->port_status_base +
>   			NUM_PORT_REGS * i;
>   		xhci->hw_ports[i].hw_portnum = i;
> +		init_completion(&xhci->hw_ports[i].link_state_changed);
>   	}
>   
>   	xhci->rh_bw = kcalloc_node(num_ports, sizeof(*xhci->rh_bw), flags,
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index d23f7408c81f..44d91a53bf07 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1677,6 +1677,7 @@ static void handle_port_status(struct xhci_hcd *xhci,
>   	     (portsc & PORT_PLS_MASK) == XDEV_U1 ||
>   	     (portsc & PORT_PLS_MASK) == XDEV_U2)) {
>   		xhci_dbg(xhci, "resume SS port %d finished\n", port_id);
> +		complete(&port->link_state_changed);

Completion will only be called if there was a port link change (PLC bit set)
and link is in U0/U1/U2. Completion will also be called for device
initiated resume even when no one is waiting for it. (probably harmless)

-Mathias

Re: [PATCH 2/3] xhci: Wait until link state trainsits to U0 after setting USB_SS_PORT_LS_U0

[Kai-Heng Feng]

On Fri, Jan 10, 2020 at 11:27 PM Mathias Nyman
<mathias.nyman@linux.intel.com> wrote:
>
> On 3.1.2020 10.40, Kai-Heng Feng wrote:
> > Like U3 case, xHCI spec doesn't specify the upper bound of U0 transition
> > time. The 20ms is not enough for some devices.
> >
> > Intead of polling PLS or PLC, we can facilitate the port change event to
> > know that the link transits to U0 is completed.
> >
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > ---
> >   drivers/usb/host/xhci-hub.c  | 8 +++++++-
> >   drivers/usb/host/xhci-mem.c  | 1 +
> >   drivers/usb/host/xhci-ring.c | 1 +
> >   drivers/usb/host/xhci.h      | 1 +
> >   4 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > index 2b2e9d004dbf..07886a1bce62 100644
> > --- a/drivers/usb/host/xhci-hub.c
> > +++ b/drivers/usb/host/xhci-hub.c
> > @@ -1310,11 +1310,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
> >                                       spin_lock_irqsave(&xhci->lock, flags);
> >                               }
> >                       }
> > +                     if (link_state == USB_SS_PORT_LS_U0)
> > +                             reinit_completion(&ports[wIndex]->link_state_changed);
>
> All the other suspend and resume related port flags/completions are
> in struct xhci_bus_state. See for example rexit_done[].
> Not sure that is a better place but at least it would be consistent.
>
> Could actually make sense to move more of them to the xhci_port structure,
> but perhaps in some later suspend/resume rework patch.

Ok. Should I keep this part of the patch as is? Or move it to
xhci_bus_state and probably move it back to xhci_port in later rework
patch?

> >
> >                       xhci_set_link_state(xhci, ports[wIndex], link_state);
> >
> >                       spin_unlock_irqrestore(&xhci->lock, flags);
> > -                     msleep(20); /* wait device to enter */
> > +                     if (link_state == USB_SS_PORT_LS_U0) {
> > +                             if (!wait_for_completion_timeout(&ports[wIndex]->link_state_changed, msecs_to_jiffies(100)))
> > +                                     xhci_dbg(xhci, "missing U0 port change event for port %d-%d\n", hcd->self.busnum, wIndex + 1);
>
> We might be waiting for completion here in unnecessary.
> No completion is called if port is already in U0, either set by
> xhci_bus_resume(), or we race with a device initiated resume.

Is there a way to know if device initiated resume is inplace?

>
> Maybe read the current port link state first, and don't do anything if it's
> already in U0, or fail if it's in a state where we can't resume to U0.

What happens if device initiated resume happens right after we query the PLS?

>
> > +                     } else
> > +                             msleep(20); /* wait device to enter */
> >                       spin_lock_irqsave(&xhci->lock, flags);
>
> Code might also be cleaner if we have separate if() statements for U0 and U3 link
> states, and skip the generic xhci_set_link_state()
>
> USB 3.2 specs only support PORT_LINK_STATE request feature selectors for
> U0, U1, U2, U3, SS.Disabled, Rx.Detect and Compliance mode.
> Out of these xhci driver already handles the SS.Disabled, Rx.detect and Compliance in
> separate if statements, and xHC hardware can't force a U1 or U2 state by writing
> the PLS field of the PORTSC register, so the xhci_set_link_state() here
> is only useful for U0 and U3.
>
> So maybe something like this:
>
> if (link_state == U0)
>    if (active_link_state == U0)
>      break
>    else if (active_link_state != a proper link state)
>      return error
>    xhci_set_link_state(U0)
>    wait_for_completion_timeout()
>    break;
>
> if (link_state == U3)
>    xhci_stop_device(slot_id)
>    xhci_set_link_state(U3)
>    for (max 10 tries) {
>      msleep_range(~10ms)
>      if (readl(PORTSC(PLS) == U3)
>        break
>    }
>    break

Ok, will rework the next patch in this direction.

Kai-Heng

> >
> >                       if (link_state == USB_SS_PORT_LS_U3) {
> > diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> > index 3b1388fa2f36..c760a28e3556 100644
> > --- a/drivers/usb/host/xhci-mem.c
> > +++ b/drivers/usb/host/xhci-mem.c
> > @@ -2268,6 +2268,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)
> >               xhci->hw_ports[i].addr = &xhci->op_regs->port_status_base +
> >                       NUM_PORT_REGS * i;
> >               xhci->hw_ports[i].hw_portnum = i;
> > +             init_completion(&xhci->hw_ports[i].link_state_changed);
> >       }
> >
> >       xhci->rh_bw = kcalloc_node(num_ports, sizeof(*xhci->rh_bw), flags,
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index d23f7408c81f..44d91a53bf07 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -1677,6 +1677,7 @@ static void handle_port_status(struct xhci_hcd *xhci,
> >            (portsc & PORT_PLS_MASK) == XDEV_U1 ||
> >            (portsc & PORT_PLS_MASK) == XDEV_U2)) {
> >               xhci_dbg(xhci, "resume SS port %d finished\n", port_id);
> > +             complete(&port->link_state_changed);
>
> Completion will only be called if there was a port link change (PLC bit set)
> and link is in U0/U1/U2. Completion will also be called for device
> initiated resume even when no one is waiting for it. (probably harmless)
>
> -Mathias

Re: [PATCH 2/3] xhci: Wait until link state trainsits to U0 after setting USB_SS_PORT_LS_U0

[Mathias Nyman]

On 13.1.2020 11.18, Kai-Heng Feng wrote:
> On Fri, Jan 10, 2020 at 11:27 PM Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
>>
>> On 3.1.2020 10.40, Kai-Heng Feng wrote:
>>> Like U3 case, xHCI spec doesn't specify the upper bound of U0 transition
>>> time. The 20ms is not enough for some devices.
>>>
>>> Intead of polling PLS or PLC, we can facilitate the port change event to
>>> know that the link transits to U0 is completed.
>>>
>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>> ---
>>>    drivers/usb/host/xhci-hub.c  | 8 +++++++-
>>>    drivers/usb/host/xhci-mem.c  | 1 +
>>>    drivers/usb/host/xhci-ring.c | 1 +
>>>    drivers/usb/host/xhci.h      | 1 +
>>>    4 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
>>> index 2b2e9d004dbf..07886a1bce62 100644
>>> --- a/drivers/usb/host/xhci-hub.c
>>> +++ b/drivers/usb/host/xhci-hub.c
>>> @@ -1310,11 +1310,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>>>                                        spin_lock_irqsave(&xhci->lock, flags);
>>>                                }
>>>                        }
>>> +                     if (link_state == USB_SS_PORT_LS_U0)
>>> +                             reinit_completion(&ports[wIndex]->link_state_changed);
>>
>> All the other suspend and resume related port flags/completions are
>> in struct xhci_bus_state. See for example rexit_done[].
>> Not sure that is a better place but at least it would be consistent.
>>
>> Could actually make sense to move more of them to the xhci_port structure,
>> but perhaps in some later suspend/resume rework patch.
> 
> Ok. Should I keep this part of the patch as is? Or move it to
> xhci_bus_state and probably move it back to xhci_port in later rework
> patch?

Maybe move it to xhci_bus_state for now.

> 
>>>
>>>                        xhci_set_link_state(xhci, ports[wIndex], link_state);
>>>
>>>                        spin_unlock_irqrestore(&xhci->lock, flags);
>>> -                     msleep(20); /* wait device to enter */
>>> +                     if (link_state == USB_SS_PORT_LS_U0) {
>>> +                             if (!wait_for_completion_timeout(&ports[wIndex]->link_state_changed, msecs_to_jiffies(100)))
>>> +                                     xhci_dbg(xhci, "missing U0 port change event for port %d-%d\n", hcd->self.busnum, wIndex + 1);
>>
>> We might be waiting for completion here in unnecessary.
>> No completion is called if port is already in U0, either set by
>> xhci_bus_resume(), or we race with a device initiated resume.
> 
> Is there a way to know if device initiated resume is inplace?

Yes, before xhci interrupt handler handles the device initiated resume PLS
is XDEV_RESUME and PLC is set.

After the interrupt handler PLS goes from XDEV_RESUME to XDEV_RECOVERY to XDEV_U0.
A bit is set for bus_state->port_remote_wakeup, and on usb core side
also bus->resuming_ports |= bit is set, (having both may be a bit redundant, we might
be able to get rid of bus_state->port_remote_wakeup, but not right now)

> 
>>
>> Maybe read the current port link state first, and don't do anything if it's
>> already in U0, or fail if it's in a state where we can't resume to U0.
> 
> What happens if device initiated resume happens right after we query the PLS?

Not sure, fortunately the drivers task is to write XDEV_U0 to PLS both when
we want a host initiated resume, or when we want to react on a device initiated
resume. So hopefully that's ok, but this race exists.

Better keep calling completion for both host and device initiated resume cases
when port reaches U0/U1/U2 to avoid waiting for the completion unnecessary,
like you current patch does.
  
-Mathias

[PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Kai-Heng Feng]

Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
bus when bringing underlying ports from U3 to U0.

After some expirements and guessworks, the hub itself needs to be U0
during setting its port's link state back to U0.

So add a new quirk to let the hub disables LPM on setting U0 for its
downstream facing ports.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
 drivers/usb/core/hub.c     | 12 ++++++++++--
 drivers/usb/core/quirks.c  |  7 +++++++
 include/linux/usb/quirks.h |  3 +++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f229ad6952c0..35a035781c5a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
 	}
 
 	/* see 7.1.7.7; affects power usage, but not budgeting */
-	if (hub_is_superspeed(hub->hdev))
+	if (hub_is_superspeed(hub->hdev)) {
+		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
+			usb_lock_device(hub->hdev);
+			usb_unlocked_disable_lpm(hub->hdev);
+		}
 		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
-	else
+		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
+			usb_unlocked_enable_lpm(hub->hdev);
+			usb_unlock_device(hub->hdev);
+		}
+	} else
 		status = usb_clear_port_feature(hub->hdev,
 				port1, USB_PORT_FEAT_SUSPEND);
 	if (status) {
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 6b6413073584..69474d0d2b38 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -131,6 +131,9 @@ static int quirks_param_set(const char *val, const struct kernel_param *kp)
 			case 'o':
 				flags |= USB_QUIRK_HUB_SLOW_RESET;
 				break;
+			case 'p':
+				flags |= USB_QUIRK_DISABLE_LPM_ON_U0;
+				break;
 			/* Ignore unrecognized flag characters */
 			}
 		}
@@ -371,6 +374,10 @@ static const struct usb_device_id usb_quirk_list[] = {
 	{ USB_DEVICE(0x0b05, 0x17e0), .driver_info =
 			USB_QUIRK_IGNORE_REMOTE_WAKEUP },
 
+	/* Realtek hub in Dell WD19 (Type-C) */
+	{ USB_DEVICE(0x0bda, 0x0487), .driver_info =
+			USB_QUIRK_DISABLE_LPM_ON_U0 },
+
 	/* Action Semiconductor flash disk */
 	{ USB_DEVICE(0x10d6, 0x2200), .driver_info =
 			USB_QUIRK_STRING_FETCH_255 },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index a1be64c9940f..1881d650f84c 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -69,4 +69,7 @@
 /* Hub needs extra delay after resetting its port. */
 #define USB_QUIRK_HUB_SLOW_RESET		BIT(14)
 
+/* LPM on hub needs to be disabled during setting port link state. */
+#define USB_QUIRK_DISABLE_LPM_ON_U0		BIT(15)
+
 #endif /* __LINUX_USB_QUIRKS_H */
-- 
2.17.1

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Alan Stern]

On Fri, 3 Jan 2020, Kai-Heng Feng wrote:

> Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> bus when bringing underlying ports from U3 to U0.
> 
> After some expirements and guessworks, the hub itself needs to be U0
> during setting its port's link state back to U0.
> 
> So add a new quirk to let the hub disables LPM on setting U0 for its
> downstream facing ports.
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>  drivers/usb/core/hub.c     | 12 ++++++++++--
>  drivers/usb/core/quirks.c  |  7 +++++++
>  include/linux/usb/quirks.h |  3 +++
>  3 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index f229ad6952c0..35a035781c5a 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>  	}
>  
>  	/* see 7.1.7.7; affects power usage, but not budgeting */
> -	if (hub_is_superspeed(hub->hdev))
> +	if (hub_is_superspeed(hub->hdev)) {
> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> +			usb_lock_device(hub->hdev);
> +			usb_unlocked_disable_lpm(hub->hdev);
> +		}
>  		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
> -	else
> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> +			usb_unlocked_enable_lpm(hub->hdev);
> +			usb_unlock_device(hub->hdev);

The locking here seems questionable.  Doesn't this code sometimes get
called with the hub already locked?  Or with the child device locked
(in which case locking the hub would violate the normal locking order:  
parent first, child second)?

> +		}
> +	} else
>  		status = usb_clear_port_feature(hub->hdev,
>  				port1, USB_PORT_FEAT_SUSPEND);
>  	if (status) {
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index 6b6413073584..69474d0d2b38 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -131,6 +131,9 @@ static int quirks_param_set(const char *val, const struct kernel_param *kp)
>  			case 'o':
>  				flags |= USB_QUIRK_HUB_SLOW_RESET;
>  				break;
> +			case 'p':
> +				flags |= USB_QUIRK_DISABLE_LPM_ON_U0;
> +				break;

The new 'p' flag needs to be documented.

Alan Stern

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Kai-Heng Feng]

Hi Alan,

> On Jan 3, 2020, at 23:21, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> On Fri, 3 Jan 2020, Kai-Heng Feng wrote:
> 
>> Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
>> bus when bringing underlying ports from U3 to U0.
>> 
>> After some expirements and guessworks, the hub itself needs to be U0
>> during setting its port's link state back to U0.
>> 
>> So add a new quirk to let the hub disables LPM on setting U0 for its
>> downstream facing ports.
>> 
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> ---
>> drivers/usb/core/hub.c     | 12 ++++++++++--
>> drivers/usb/core/quirks.c  |  7 +++++++
>> include/linux/usb/quirks.h |  3 +++
>> 3 files changed, 20 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>> index f229ad6952c0..35a035781c5a 100644
>> --- a/drivers/usb/core/hub.c
>> +++ b/drivers/usb/core/hub.c
>> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>> 	}
>> 
>> 	/* see 7.1.7.7; affects power usage, but not budgeting */
>> -	if (hub_is_superspeed(hub->hdev))
>> +	if (hub_is_superspeed(hub->hdev)) {
>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
>> +			usb_lock_device(hub->hdev);
>> +			usb_unlocked_disable_lpm(hub->hdev);
>> +		}
>> 		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
>> -	else
>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
>> +			usb_unlocked_enable_lpm(hub->hdev);
>> +			usb_unlock_device(hub->hdev);
> 
> The locking here seems questionable.  Doesn't this code sometimes get
> called with the hub already locked?  Or with the child device locked
> (in which case locking the hub would violate the normal locking order:  
> parent first, child second)?

Maybe introduce a new lock? The lock however will only be used by this specific hub.
But I still want the LPM can be enabled for this hub.

> 
>> +		}
>> +	} else
>> 		status = usb_clear_port_feature(hub->hdev,
>> 				port1, USB_PORT_FEAT_SUSPEND);
>> 	if (status) {
>> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
>> index 6b6413073584..69474d0d2b38 100644
>> --- a/drivers/usb/core/quirks.c
>> +++ b/drivers/usb/core/quirks.c
>> @@ -131,6 +131,9 @@ static int quirks_param_set(const char *val, const struct kernel_param *kp)
>> 			case 'o':
>> 				flags |= USB_QUIRK_HUB_SLOW_RESET;
>> 				break;
>> +			case 'p':
>> +				flags |= USB_QUIRK_DISABLE_LPM_ON_U0;
>> +				break;
> 
> The new 'p' flag needs to be documented.

Yes I missed that, will add in v2.

Kai-Heng

> 
> Alan Stern

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Alan Stern]

On Sat, 4 Jan 2020, Kai-Heng Feng wrote:

> Hi Alan,
> 
> > On Jan 3, 2020, at 23:21, Alan Stern <stern@rowland.harvard.edu> wrote:
> > 
> > On Fri, 3 Jan 2020, Kai-Heng Feng wrote:
> > 
> >> Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> >> bus when bringing underlying ports from U3 to U0.
> >> 
> >> After some expirements and guessworks, the hub itself needs to be U0
> >> during setting its port's link state back to U0.
> >> 
> >> So add a new quirk to let the hub disables LPM on setting U0 for its
> >> downstream facing ports.
> >> 
> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> >> ---
> >> drivers/usb/core/hub.c     | 12 ++++++++++--
> >> drivers/usb/core/quirks.c  |  7 +++++++
> >> include/linux/usb/quirks.h |  3 +++
> >> 3 files changed, 20 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> >> index f229ad6952c0..35a035781c5a 100644
> >> --- a/drivers/usb/core/hub.c
> >> +++ b/drivers/usb/core/hub.c
> >> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
> >> 	}
> >> 
> >> 	/* see 7.1.7.7; affects power usage, but not budgeting */
> >> -	if (hub_is_superspeed(hub->hdev))
> >> +	if (hub_is_superspeed(hub->hdev)) {
> >> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> >> +			usb_lock_device(hub->hdev);
> >> +			usb_unlocked_disable_lpm(hub->hdev);
> >> +		}
> >> 		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
> >> -	else
> >> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> >> +			usb_unlocked_enable_lpm(hub->hdev);
> >> +			usb_unlock_device(hub->hdev);
> > 
> > The locking here seems questionable.  Doesn't this code sometimes get
> > called with the hub already locked?  Or with the child device locked
> > (in which case locking the hub would violate the normal locking order:  
> > parent first, child second)?

I did a little checking.  In many cases the child device _will_ be 
locked at this point.

> Maybe introduce a new lock? The lock however will only be used by this specific hub.
> But I still want the LPM can be enabled for this hub.

Do you really need to lock the hub at all?  What would the lock protect 
against?

Alan Stern

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Kai-Heng Feng]

> On Jan 4, 2020, at 00:54, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> On Sat, 4 Jan 2020, Kai-Heng Feng wrote:
> 
>> Hi Alan,
>> 
>>> On Jan 3, 2020, at 23:21, Alan Stern <stern@rowland.harvard.edu> wrote:
>>> 
>>> On Fri, 3 Jan 2020, Kai-Heng Feng wrote:
>>> 
>>>> Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
>>>> bus when bringing underlying ports from U3 to U0.
>>>> 
>>>> After some expirements and guessworks, the hub itself needs to be U0
>>>> during setting its port's link state back to U0.
>>>> 
>>>> So add a new quirk to let the hub disables LPM on setting U0 for its
>>>> downstream facing ports.
>>>> 
>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>> ---
>>>> drivers/usb/core/hub.c     | 12 ++++++++++--
>>>> drivers/usb/core/quirks.c  |  7 +++++++
>>>> include/linux/usb/quirks.h |  3 +++
>>>> 3 files changed, 20 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>>>> index f229ad6952c0..35a035781c5a 100644
>>>> --- a/drivers/usb/core/hub.c
>>>> +++ b/drivers/usb/core/hub.c
>>>> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>>>> 	}
>>>> 
>>>> 	/* see 7.1.7.7; affects power usage, but not budgeting */
>>>> -	if (hub_is_superspeed(hub->hdev))
>>>> +	if (hub_is_superspeed(hub->hdev)) {
>>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
>>>> +			usb_lock_device(hub->hdev);
>>>> +			usb_unlocked_disable_lpm(hub->hdev);
>>>> +		}
>>>> 		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
>>>> -	else
>>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
>>>> +			usb_unlocked_enable_lpm(hub->hdev);
>>>> +			usb_unlock_device(hub->hdev);
>>> 
>>> The locking here seems questionable.  Doesn't this code sometimes get
>>> called with the hub already locked?  Or with the child device locked
>>> (in which case locking the hub would violate the normal locking order:  
>>> parent first, child second)?
> 
> I did a little checking.  In many cases the child device _will_ be 
> locked at this point.
> 
>> Maybe introduce a new lock? The lock however will only be used by this specific hub.
>> But I still want the LPM can be enabled for this hub.
> 
> Do you really need to lock the hub at all?  What would the lock protect 
> against?

There can be multiple usb_port_resume() run at the same time for different ports, so this is to prevent LPM enable/disable race.

Kai-Heng

> 
> Alan Stern

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Alan Stern]

On Sat, 4 Jan 2020, Kai-Heng Feng wrote:

> >>>> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
> >>>> 	}
> >>>> 
> >>>> 	/* see 7.1.7.7; affects power usage, but not budgeting */
> >>>> -	if (hub_is_superspeed(hub->hdev))
> >>>> +	if (hub_is_superspeed(hub->hdev)) {
> >>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> >>>> +			usb_lock_device(hub->hdev);
> >>>> +			usb_unlocked_disable_lpm(hub->hdev);
> >>>> +		}
> >>>> 		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
> >>>> -	else
> >>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> >>>> +			usb_unlocked_enable_lpm(hub->hdev);
> >>>> +			usb_unlock_device(hub->hdev);
> >>> 
> >>> The locking here seems questionable.  Doesn't this code sometimes get
> >>> called with the hub already locked?  Or with the child device locked
> >>> (in which case locking the hub would violate the normal locking order:  
> >>> parent first, child second)?
> > 
> > I did a little checking.  In many cases the child device _will_ be 
> > locked at this point.
> > 
> >> Maybe introduce a new lock? The lock however will only be used by this specific hub.
> >> But I still want the LPM can be enabled for this hub.
> > 
> > Do you really need to lock the hub at all?  What would the lock protect 
> > against?
> 
> There can be multiple usb_port_resume() run at the same time for different ports, so this is to prevent LPM enable/disable race.

But there can't really be an LPM enable/disable race, can there?  The 
individual function calls are protected by the bandwidth mutex taken by 
the usb_unlocked_{en|dis}able_lpm routines, and the overall LPM setting 
is controlled by the hub device's lpm_disable_counter.

So I think you don't need to lock the hub here.

Alan Stern

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Kai-Heng Feng]

> On Jan 5, 2020, at 00:20, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> On Sat, 4 Jan 2020, Kai-Heng Feng wrote:
> 
>>>>>> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>>>>>> 	}
>>>>>> 
>>>>>> 	/* see 7.1.7.7; affects power usage, but not budgeting */
>>>>>> -	if (hub_is_superspeed(hub->hdev))
>>>>>> +	if (hub_is_superspeed(hub->hdev)) {
>>>>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
>>>>>> +			usb_lock_device(hub->hdev);
>>>>>> +			usb_unlocked_disable_lpm(hub->hdev);
>>>>>> +		}
>>>>>> 		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
>>>>>> -	else
>>>>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
>>>>>> +			usb_unlocked_enable_lpm(hub->hdev);
>>>>>> +			usb_unlock_device(hub->hdev);
>>>>> 
>>>>> The locking here seems questionable.  Doesn't this code sometimes get
>>>>> called with the hub already locked?  Or with the child device locked
>>>>> (in which case locking the hub would violate the normal locking order:  
>>>>> parent first, child second)?
>>> 
>>> I did a little checking.  In many cases the child device _will_ be 
>>> locked at this point.
>>> 
>>>> Maybe introduce a new lock? The lock however will only be used by this specific hub.
>>>> But I still want the LPM can be enabled for this hub.
>>> 
>>> Do you really need to lock the hub at all?  What would the lock protect 
>>> against?
>> 
>> There can be multiple usb_port_resume() run at the same time for different ports, so this is to prevent LPM enable/disable race.
> 
> But there can't really be an LPM enable/disable race, can there?  The 
> individual function calls are protected by the bandwidth mutex taken by 
> the usb_unlocked_{en|dis}able_lpm routines, and the overall LPM setting 
> is controlled by the hub device's lpm_disable_counter.

For enable/disable LPM itself, there's no race.
But the lock here is to protect hub_set_port_link_state().
If we don't lock the hub, other instances of usb_port_resume() routine can enable LPM and we want the LPM stays disabled until hub_set_port_link_state() is done.

Kai-Heng

> 
> So I think you don't need to lock the hub here.
> 
> Alan Stern
> 

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Alan Stern]

On Mon, 6 Jan 2020, Kai-Heng Feng wrote:

> > On Jan 5, 2020, at 00:20, Alan Stern <stern@rowland.harvard.edu> wrote:
> > 
> > On Sat, 4 Jan 2020, Kai-Heng Feng wrote:
> > 
> >>>>>> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
> >>>>>> 	}
> >>>>>> 
> >>>>>> 	/* see 7.1.7.7; affects power usage, but not budgeting */
> >>>>>> -	if (hub_is_superspeed(hub->hdev))
> >>>>>> +	if (hub_is_superspeed(hub->hdev)) {
> >>>>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> >>>>>> +			usb_lock_device(hub->hdev);
> >>>>>> +			usb_unlocked_disable_lpm(hub->hdev);
> >>>>>> +		}
> >>>>>> 		status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
> >>>>>> -	else
> >>>>>> +		if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> >>>>>> +			usb_unlocked_enable_lpm(hub->hdev);
> >>>>>> +			usb_unlock_device(hub->hdev);
> >>>>> 
> >>>>> The locking here seems questionable.  Doesn't this code sometimes get
> >>>>> called with the hub already locked?  Or with the child device locked
> >>>>> (in which case locking the hub would violate the normal locking order:  
> >>>>> parent first, child second)?
> >>> 
> >>> I did a little checking.  In many cases the child device _will_ be 
> >>> locked at this point.
> >>> 
> >>>> Maybe introduce a new lock? The lock however will only be used by this specific hub.
> >>>> But I still want the LPM can be enabled for this hub.
> >>> 
> >>> Do you really need to lock the hub at all?  What would the lock protect 
> >>> against?
> >> 
> >> There can be multiple usb_port_resume() run at the same time for different ports, so this is to prevent LPM enable/disable race.
> > 
> > But there can't really be an LPM enable/disable race, can there?  The 
> > individual function calls are protected by the bandwidth mutex taken by 
> > the usb_unlocked_{en|dis}able_lpm routines, and the overall LPM setting 
> > is controlled by the hub device's lpm_disable_counter.
> 
> For enable/disable LPM itself, there's no race.
> But the lock here is to protect hub_set_port_link_state().
> If we don't lock the hub, other instances of usb_port_resume()
> routine can enable LPM and we want the LPM stays disabled until
> hub_set_port_link_state() is done.

That's what I was trying to explain above.  Other instances of 
usb_port_resume() _can't_ enable LPM while this instance is running, 
because the lpm_disable_counter value will be > 0.

Alan Stern

Re: [PATCH 3/3] USB: Disable LPM on WD19's Realtek Hub during setting its ports to U0

[Kai-Heng Feng]

On Mon, Jan 6, 2020 at 11:08 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Mon, 6 Jan 2020, Kai-Heng Feng wrote:
>
> > > On Jan 5, 2020, at 00:20, Alan Stern <stern@rowland.harvard.edu> wrote:
> > >
> > > On Sat, 4 Jan 2020, Kai-Heng Feng wrote:
> > >
> > >>>>>> @@ -3533,9 +3533,17 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
> > >>>>>>        }
> > >>>>>>
> > >>>>>>        /* see 7.1.7.7; affects power usage, but not budgeting */
> > >>>>>> -      if (hub_is_superspeed(hub->hdev))
> > >>>>>> +      if (hub_is_superspeed(hub->hdev)) {
> > >>>>>> +              if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> > >>>>>> +                      usb_lock_device(hub->hdev);
> > >>>>>> +                      usb_unlocked_disable_lpm(hub->hdev);
> > >>>>>> +              }
> > >>>>>>                status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U0);
> > >>>>>> -      else
> > >>>>>> +              if (hub->hdev->quirks & USB_QUIRK_DISABLE_LPM_ON_U0) {
> > >>>>>> +                      usb_unlocked_enable_lpm(hub->hdev);
> > >>>>>> +                      usb_unlock_device(hub->hdev);
> > >>>>>
> > >>>>> The locking here seems questionable.  Doesn't this code sometimes get
> > >>>>> called with the hub already locked?  Or with the child device locked
> > >>>>> (in which case locking the hub would violate the normal locking order:
> > >>>>> parent first, child second)?
> > >>>
> > >>> I did a little checking.  In many cases the child device _will_ be
> > >>> locked at this point.
> > >>>
> > >>>> Maybe introduce a new lock? The lock however will only be used by this specific hub.
> > >>>> But I still want the LPM can be enabled for this hub.
> > >>>
> > >>> Do you really need to lock the hub at all?  What would the lock protect
> > >>> against?
> > >>
> > >> There can be multiple usb_port_resume() run at the same time for different ports, so this is to prevent LPM enable/disable race.
> > >
> > > But there can't really be an LPM enable/disable race, can there?  The
> > > individual function calls are protected by the bandwidth mutex taken by
> > > the usb_unlocked_{en|dis}able_lpm routines, and the overall LPM setting
> > > is controlled by the hub device's lpm_disable_counter.
> >
> > For enable/disable LPM itself, there's no race.
> > But the lock here is to protect hub_set_port_link_state().
> > If we don't lock the hub, other instances of usb_port_resume()
> > routine can enable LPM and we want the LPM stays disabled until
> > hub_set_port_link_state() is done.
>
> That's what I was trying to explain above.  Other instances of
> usb_port_resume() _can't_ enable LPM while this instance is running,
> because the lpm_disable_counter value will be > 0.

Yes you are right, there's actually no race.
The hub is still a bit flaky with this approach, so I'll resend a v2
to simply disable LPM for this hub.

Kai-Heng

>
> Alan Stern
>

[PATCH v2 3/3] USB: Disable LPM on WD19's Realtek Hub

[Kai-Heng Feng]

Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
bus when bringing underlying ports from U3 to U0.

Disabling LPM on the hub during setting link state is not enough, so
let's disable LPM completely for this hub.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 6b6413073584..2fb7c1602280 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -371,6 +371,9 @@ static const struct usb_device_id usb_quirk_list[] = {
 	{ USB_DEVICE(0x0b05, 0x17e0), .driver_info =
 			USB_QUIRK_IGNORE_REMOTE_WAKEUP },
 
+	/* Realtek hub in Dell WD19 (Type-C) */
+	{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+
 	/* Action Semiconductor flash disk */
 	{ USB_DEVICE(0x10d6, 0x2200), .driver_info =
 			USB_QUIRK_STRING_FETCH_255 },
-- 
2.17.1

Re: [PATCH v2 3/3] USB: Disable LPM on WD19's Realtek Hub

[Alan Stern]

On Fri, 10 Jan 2020, Kai-Heng Feng wrote:

> Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> bus when bringing underlying ports from U3 to U0.
> 
> Disabling LPM on the hub during setting link state is not enough, so
> let's disable LPM completely for this hub.
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>  drivers/usb/core/quirks.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index 6b6413073584..2fb7c1602280 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -371,6 +371,9 @@ static const struct usb_device_id usb_quirk_list[] = {
>  	{ USB_DEVICE(0x0b05, 0x17e0), .driver_info =
>  			USB_QUIRK_IGNORE_REMOTE_WAKEUP },
>  
> +	/* Realtek hub in Dell WD19 (Type-C) */
> +	{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
> +
>  	/* Action Semiconductor flash disk */
>  	{ USB_DEVICE(0x10d6, 0x2200), .driver_info =
>  			USB_QUIRK_STRING_FETCH_255 },
> 

This is a very partial patch.  There were four hunks in the original 
version but there's only one hunk in V2.

Alan Stern

Re: [PATCH v2 3/3] USB: Disable LPM on WD19's Realtek Hub

[Kai-Heng Feng]

On Fri, Jan 10, 2020 at 11:40 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, 10 Jan 2020, Kai-Heng Feng wrote:
>
> > Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> > bus when bringing underlying ports from U3 to U0.
> >
> > Disabling LPM on the hub during setting link state is not enough, so
> > let's disable LPM completely for this hub.
> >
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > ---
> >  drivers/usb/core/quirks.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> > index 6b6413073584..2fb7c1602280 100644
> > --- a/drivers/usb/core/quirks.c
> > +++ b/drivers/usb/core/quirks.c
> > @@ -371,6 +371,9 @@ static const struct usb_device_id usb_quirk_list[] = {
> >       { USB_DEVICE(0x0b05, 0x17e0), .driver_info =
> >                       USB_QUIRK_IGNORE_REMOTE_WAKEUP },
> >
> > +     /* Realtek hub in Dell WD19 (Type-C) */
> > +     { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
> > +
> >       /* Action Semiconductor flash disk */
> >       { USB_DEVICE(0x10d6, 0x2200), .driver_info =
> >                       USB_QUIRK_STRING_FETCH_255 },
> >
>
> This is a very partial patch.  There were four hunks in the original
> version but there's only one hunk in V2.

Because the original approach is insufficient, it significantly
reduced the fail rate but the issue is still there.
USB_QUIRK_NO_LPM is used instead so no other parts are needed.

Kai-Heng

>
> Alan Stern
>

Re: [PATCH v2 3/3] USB: Disable LPM on WD19's Realtek Hub

[Alan Stern]

On Fri, 10 Jan 2020, Kai-Heng Feng wrote:

> On Fri, Jan 10, 2020 at 11:40 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Fri, 10 Jan 2020, Kai-Heng Feng wrote:
> >
> > > Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> > > bus when bringing underlying ports from U3 to U0.
> > >
> > > Disabling LPM on the hub during setting link state is not enough, so
> > > let's disable LPM completely for this hub.
> > >
> > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > > ---
> > >  drivers/usb/core/quirks.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> > > index 6b6413073584..2fb7c1602280 100644
> > > --- a/drivers/usb/core/quirks.c
> > > +++ b/drivers/usb/core/quirks.c
> > > @@ -371,6 +371,9 @@ static const struct usb_device_id usb_quirk_list[] = {
> > >       { USB_DEVICE(0x0b05, 0x17e0), .driver_info =
> > >                       USB_QUIRK_IGNORE_REMOTE_WAKEUP },
> > >
> > > +     /* Realtek hub in Dell WD19 (Type-C) */
> > > +     { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
> > > +
> > >       /* Action Semiconductor flash disk */
> > >       { USB_DEVICE(0x10d6, 0x2200), .driver_info =
> > >                       USB_QUIRK_STRING_FETCH_255 },
> > >
> >
> > This is a very partial patch.  There were four hunks in the original
> > version but there's only one hunk in V2.
> 
> Because the original approach is insufficient, it significantly
> reduced the fail rate but the issue is still there.
> USB_QUIRK_NO_LPM is used instead so no other parts are needed.

Oh, all right.  This change looks okay to me.  Has AceLan Kao tested 
it?

Alan Stern

Re: [PATCH v2 3/3] USB: Disable LPM on WD19's Realtek Hub

[Kai-Heng Feng]

On Sat, Jan 11, 2020 at 12:36 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, 10 Jan 2020, Kai-Heng Feng wrote:
>
> > On Fri, Jan 10, 2020 at 11:40 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > >
> > > On Fri, 10 Jan 2020, Kai-Heng Feng wrote:
> > >
> > > > Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> > > > bus when bringing underlying ports from U3 to U0.
> > > >
> > > > Disabling LPM on the hub during setting link state is not enough, so
> > > > let's disable LPM completely for this hub.
> > > >
> > > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > > > ---
> > > >  drivers/usb/core/quirks.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> > > > index 6b6413073584..2fb7c1602280 100644
> > > > --- a/drivers/usb/core/quirks.c
> > > > +++ b/drivers/usb/core/quirks.c
> > > > @@ -371,6 +371,9 @@ static const struct usb_device_id usb_quirk_list[] = {
> > > >       { USB_DEVICE(0x0b05, 0x17e0), .driver_info =
> > > >                       USB_QUIRK_IGNORE_REMOTE_WAKEUP },
> > > >
> > > > +     /* Realtek hub in Dell WD19 (Type-C) */
> > > > +     { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
> > > > +
> > > >       /* Action Semiconductor flash disk */
> > > >       { USB_DEVICE(0x10d6, 0x2200), .driver_info =
> > > >                       USB_QUIRK_STRING_FETCH_255 },
> > > >
> > >
> > > This is a very partial patch.  There were four hunks in the original
> > > version but there's only one hunk in V2.
> >
> > Because the original approach is insufficient, it significantly
> > reduced the fail rate but the issue is still there.
> > USB_QUIRK_NO_LPM is used instead so no other parts are needed.
>
> Oh, all right.  This change looks okay to me.  Has AceLan Kao tested
> it?

He didn't test it. I have physical access to the hardware and I've
thoroughly tested it.

Kai-Heng

>
> Alan Stern
>

Re: [PATCH v2 3/3] USB: Disable LPM on WD19's Realtek Hub

[Greg KH]

On Fri, Jan 10, 2020 at 04:02:11PM +0800, Kai-Heng Feng wrote:
> Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> bus when bringing underlying ports from U3 to U0.
> 
> Disabling LPM on the hub during setting link state is not enough, so
> let's disable LPM completely for this hub.
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>  drivers/usb/core/quirks.c | 3 +++
>  1 file changed, 3 insertions(+)

What changed from v1?  Always put that below the --- line.

Also I only see 1 patch here, what happened to the first two?

Please resend the whole series, and properly document what went on, you
know this...

thanks,

greg k-h

Re: [PATCH v2 3/3] USB: Disable LPM on WD19's Realtek Hub

[Kai-Heng Feng]

On Sun, Jan 12, 2020 at 4:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jan 10, 2020 at 04:02:11PM +0800, Kai-Heng Feng wrote:
> > Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
> > bus when bringing underlying ports from U3 to U0.
> >
> > Disabling LPM on the hub during setting link state is not enough, so
> > let's disable LPM completely for this hub.
> >
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > ---
> >  drivers/usb/core/quirks.c | 3 +++
> >  1 file changed, 3 insertions(+)
>
> What changed from v1?  Always put that below the --- line.
>
> Also I only see 1 patch here, what happened to the first two?

The first two are can be actually treat separately, since they are
more generic fixes for xHCI.

>
> Please resend the whole series, and properly document what went on, you
> know this...

I forgot that, will do in next version.

Kai-Heng

>
> thanks,
>
> greg k-h

Re: [PATCH 1/3] xhci: Ensure link state is U3 after setting USB_SS_PORT_LS_U3

[Mathias Nyman]

On 3.1.2020 10.40, Kai-Heng Feng wrote:
> The xHCI spec doesn't specify the upper bound of U3 transition time. For
> some devices 20ms is not enough, so we need to make sure the link state
> is in U3 before further actions.

Looking at the USB 3.2 spec (7.2.4.2 Link Power management and Flow) it seems
most timers related to U3 entry are a lot less than a millisecond (4-16us)
If port is in U1/U2,  Ux_EXIT_TIMER is 6ms which seems to be the longest timeout.

If we anyway are polling for the U3 state we could shorten the initial 20ms sleep
down to 10ms. I think many devices, especially if they are already in U0
could manage this.

are >
> I've tried to use U3 Entry Capability by setting U3 Entry Enable in
> config register, however the port change event for U3 transition
> interrupts the system suspend process.
> 
> For now let's use the less ideal method by polling PLS.
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
>   drivers/usb/host/xhci-hub.c | 13 +++++++++++--
>   1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 7a3a29e5e9d2..2b2e9d004dbf 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -1228,6 +1228,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>   			break;
>   		case USB_PORT_FEAT_LINK_STATE:
>   			temp = readl(ports[wIndex]->addr);
> +			xhci_dbg(xhci, "before setting link state, actual port %d-%d status = 0x%0x\n", hcd->self.busnum, wIndex + 1, temp);

xhci_set_link_state() already shows similar debugging,

>   			/* Disable port */
>   			if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
>   				xhci_dbg(xhci, "Disable port %d\n", wIndex);
> @@ -1316,9 +1317,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>   			msleep(20); /* wait device to enter */
>   			spin_lock_irqsave(&xhci->lock, flags);
>   
> -			temp = readl(ports[wIndex]->addr);
> -			if (link_state == USB_SS_PORT_LS_U3)
> +			if (link_state == USB_SS_PORT_LS_U3) {
> +				retval = xhci_handshake(ports[wIndex]->addr, PORT_PLS_MASK, XDEV_U3, 80 * 1000);
> +				if (retval)
> +					xhci_dbg(xhci, "polling XDEV_U3 on port %d-%d timeout\n", hcd->self.busnum, wIndex + 1);

In worst case we are busylooping for 80ms here, keeping the cpu busy.
It should be ok to sleep here, so how about just reading the register
every 10ms max 10 times, sleeping in between.

-Mathias

Re: [PATCH 1/3] xhci: Ensure link state is U3 after setting USB_SS_PORT_LS_U3

[Kai-Heng Feng]

On Fri, Jan 10, 2020 at 5:33 PM Mathias Nyman
<mathias.nyman@linux.intel.com> wrote:
>
> On 3.1.2020 10.40, Kai-Heng Feng wrote:
> > The xHCI spec doesn't specify the upper bound of U3 transition time. For
> > some devices 20ms is not enough, so we need to make sure the link state
> > is in U3 before further actions.
>
> Looking at the USB 3.2 spec (7.2.4.2 Link Power management and Flow) it seems
> most timers related to U3 entry are a lot less than a millisecond (4-16us)
> If port is in U1/U2,  Ux_EXIT_TIMER is 6ms which seems to be the longest timeout.
>
> If we anyway are polling for the U3 state we could shorten the initial 20ms sleep
> down to 10ms. I think many devices, especially if they are already in U0
> could manage this.

Ok.

>
> are >
> > I've tried to use U3 Entry Capability by setting U3 Entry Enable in
> > config register, however the port change event for U3 transition
> > interrupts the system suspend process.
> >
> > For now let's use the less ideal method by polling PLS.
> >
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > ---
> >   drivers/usb/host/xhci-hub.c | 13 +++++++++++--
> >   1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > index 7a3a29e5e9d2..2b2e9d004dbf 100644
> > --- a/drivers/usb/host/xhci-hub.c
> > +++ b/drivers/usb/host/xhci-hub.c
> > @@ -1228,6 +1228,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
> >                       break;
> >               case USB_PORT_FEAT_LINK_STATE:
> >                       temp = readl(ports[wIndex]->addr);
> > +                     xhci_dbg(xhci, "before setting link state, actual port %d-%d status = 0x%0x\n", hcd->self.busnum, wIndex + 1, temp);
>
> xhci_set_link_state() already shows similar debugging,

Ok, will remove it.

>
> >                       /* Disable port */
> >                       if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
> >                               xhci_dbg(xhci, "Disable port %d\n", wIndex);
> > @@ -1316,9 +1317,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
> >                       msleep(20); /* wait device to enter */
> >                       spin_lock_irqsave(&xhci->lock, flags);
> >
> > -                     temp = readl(ports[wIndex]->addr);
> > -                     if (link_state == USB_SS_PORT_LS_U3)
> > +                     if (link_state == USB_SS_PORT_LS_U3) {
> > +                             retval = xhci_handshake(ports[wIndex]->addr, PORT_PLS_MASK, XDEV_U3, 80 * 1000);
> > +                             if (retval)
> > +                                     xhci_dbg(xhci, "polling XDEV_U3 on port %d-%d timeout\n", hcd->self.busnum, wIndex + 1);
>
> In worst case we are busylooping for 80ms here, keeping the cpu busy.
> It should be ok to sleep here, so how about just reading the register
> every 10ms max 10 times, sleeping in between.

Ok. Is the polling safe outside of spin_lock_irqsave()?

Kai-Heng

>
> -Mathias

Re: [PATCH 1/3] xhci: Ensure link state is U3 after setting USB_SS_PORT_LS_U3

[Mathias Nyman]

On 13.1.2020 11.10, Kai-Heng Feng wrote:
> On Fri, Jan 10, 2020 at 5:33 PM Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
>>> @@ -1316,9 +1317,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>>>                        msleep(20); /* wait device to enter */
>>>                        spin_lock_irqsave(&xhci->lock, flags);
>>>
>>> -                     temp = readl(ports[wIndex]->addr);
>>> -                     if (link_state == USB_SS_PORT_LS_U3)
>>> +                     if (link_state == USB_SS_PORT_LS_U3) {
>>> +                             retval = xhci_handshake(ports[wIndex]->addr, PORT_PLS_MASK, XDEV_U3, 80 * 1000);
>>> +                             if (retval)
>>> +                                     xhci_dbg(xhci, "polling XDEV_U3 on port %d-%d timeout\n", hcd->self.busnum, wIndex + 1);
>>
>> In worst case we are busylooping for 80ms here, keeping the cpu busy.
>> It should be ok to sleep here, so how about just reading the register
>> every 10ms max 10 times, sleeping in between.
> 
> Ok. Is the polling safe outside of spin_lock_irqsave()?
> 

Should be, we only read one 32 bit register, and we anyway used to release
and re-acquire the lock right before this anyway.

-Mathias