Messages in this thread Patch in this message | | | From | "hyunho747.kim" <> | Subject | [PATCH] usb: core: Fix side effect of clear port feature in hub port reset | Date | Tue, 1 Sep 2015 16:31:21 +0900 |
| |
After successful port reset by set_port_feature, some devices show immediate link connection which generates port connect change interrupt. But, the next step is an unconditional usb_clear_port_feature and this flow always clears USB_PORT_FEAT_C_CONNECTION bit in port status though next kick_khubd is reserved by link connection interrupt. This flow can make an ambiguous state in the next port_evnet operation, port_status is connected state such as 0x203 but port_change is zero value caused by the previous clear port feature. So, port_event can't call hub_port_connect_change and there is no other way to peform connect procedure.
Signed-off-by: hyunho747.kim <hyunho747.kim@lge.com> --- drivers/usb/core/hub.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 73dfa19..4508aff 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2761,18 +2761,21 @@ static int hub_port_reset(struct usb_hub *hub, int port1, /* Check for disconnect or reset */ if (status == 0 || status == -ENOTCONN || status == -ENODEV) { - usb_clear_port_feature(hub->hdev, port1, + if (status) + usb_clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_C_RESET); if (!hub_is_superspeed(hub->hdev)) goto done; - usb_clear_port_feature(hub->hdev, port1, + if (status) { + usb_clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_C_BH_PORT_RESET); - usb_clear_port_feature(hub->hdev, port1, + usb_clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_C_PORT_LINK_STATE); - usb_clear_port_feature(hub->hdev, port1, + usb_clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_C_CONNECTION); + } /* * If a USB 3.0 device migrates from reset to an error -- 2.2.1
| |