From patchwork Tue Apr 28 18:24:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 226846 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BB81C83007 for ; Tue, 28 Apr 2020 18:46:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4B97820575 for ; Tue, 28 Apr 2020 18:46:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588099562; bh=HYsQ9JIU9Fsat3k7Hi/+HkG+kVINNcgWMUAtSB2DgDo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=j6LNK+n8tm+WDQrKpSwJZQn7eWaptY/7s4gUaaelTanry5dG4KfARWLoyoVCj89v6 vX+Poh/yfXu8W6TYgQl+fiq27eWazIpv/eMsMgZru3ibQ//UHCOjxMAZvX2mZPP2EX epL74APU/RibxUQshgkG46y8jSWc6wLJxx5+C7wI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731265AbgD1Snh (ORCPT ); Tue, 28 Apr 2020 14:43:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:36058 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731260AbgD1Sng (ORCPT ); Tue, 28 Apr 2020 14:43:36 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 15C8820575; Tue, 28 Apr 2020 18:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588099415; bh=HYsQ9JIU9Fsat3k7Hi/+HkG+kVINNcgWMUAtSB2DgDo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UY6/uZbIF0tnZqUPXbhrrWHFv9w6+UvQxvKIbB4Ar8n4cWNfAdXSdP47ttcJtuEzn mtpHP0D8l1uOIFJmYqJkF1QYlvnzbuNi1HfYJM9x8QKwjyj74OABp35fLgON+ZsmN5 PJr2gk6eN/OCFrQFKYKZ+q2miOEKjbJJAwvoU/AM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , Paul Zimmerman , Peter Chen Subject: [PATCH 5.4 099/168] USB: hub: Fix handling of connect changes during sleep Date: Tue, 28 Apr 2020 20:24:33 +0200 Message-Id: <20200428182244.871650455@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200428182231.704304409@linuxfoundation.org> References: <20200428182231.704304409@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Alan Stern commit 9f952e26295d977dbfc6fedeaf8c4f112c818d37 upstream. Commit 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") wasn't very well conceived. The problem it tried to fix was that if a connect-change event occurred while the system was asleep (such as a device disconnecting itself from the bus when it is suspended and then reconnecting when it resumes) requiring a reset-resume during the system wakeup transition, the hub port's change_bit entry would remain set afterward. This would cause the hub driver to believe another connect-change event had occurred after the reset-resume, which was wrong and would lead the driver to send unnecessary requests to the device (which could interfere with a firmware update). The commit tried to fix this by not setting the change_bit during the wakeup. But this was the wrong thing to do; it means that when a device is unplugged while the system is asleep, the hub driver doesn't realize anything has happened: The change_bit flag which would tell it to handle the disconnect event is clear. The commit needs to be reverted and the problem fixed in a different way. Fortunately an alternative solution was noted in the commit's Changelog: We can continue to set the change_bit entry in hub_activate() but then clear it when a reset-resume occurs. That way the the hub driver will see the change_bit when a device is disconnected but won't see it when the device is still present. That's what this patch does. Reported-and-tested-by: Peter Chen Signed-off-by: Alan Stern Fixes: 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") Tested-by: Paul Zimmerman CC: Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221602480.11262-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/hub.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1222,6 +1222,11 @@ static void hub_activate(struct usb_hub #ifdef CONFIG_PM udev->reset_resume = 1; #endif + /* Don't set the change_bits when the device + * was powered off. + */ + if (test_bit(port1, hub->power_bits)) + set_bit(port1, hub->change_bits); } else { /* The power session is gone; tell hub_wq */ @@ -3087,6 +3092,15 @@ static int check_port_resume_type(struct if (portchange & USB_PORT_STAT_C_ENABLE) usb_clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_C_ENABLE); + + /* + * Whatever made this reset-resume necessary may have + * turned on the port1 bit in hub->change_bits. But after + * a successful reset-resume we want the bit to be clear; + * if it was on it would indicate that something happened + * following the reset-resume. + */ + clear_bit(port1, hub->change_bits); } return status;