| Message ID | 20200103084008.3579-3-kai.heng.feng@canonical.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/3] xhci: Ensure link state is U3 after setting USB_SS_PORT_LS_U3 | expand |
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
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
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
> 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
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
> 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 >
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
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 >
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 */
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(-)