From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752609AbbFYOuU (ORCPT ); Thu, 25 Jun 2015 10:50:20 -0400 Received: from mga11.intel.com ([192.55.52.93]:10702 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751648AbbFYOuO (ORCPT ); Thu, 25 Jun 2015 10:50:14 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,677,1427785200"; d="scan'208";a="717552399" Message-ID: <558C15D5.9020802@linux.intel.com> Date: Thu, 25 Jun 2015 17:53:09 +0300 From: Mathias Nyman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lu Baolu , Greg Kroah-Hartman , Mathias Nyman , Alan Stern CC: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 3/3] usb: xhci: remove stop device and ring doorbell in hub control and bus suspend References: <1431134130-7922-1-git-send-email-baolu.lu@linux.intel.com> <1431134130-7922-4-git-send-email-baolu.lu@linux.intel.com> In-Reply-To: <1431134130-7922-4-git-send-email-baolu.lu@linux.intel.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09.05.2015 04:15, Lu Baolu wrote: > There is no need to call xhci_stop_device() and xhci_ring_device() in > hub control and bus suspend functions since all device suspend and > resume have been notified through device_suspend/device_resume interfaces. I was looking through this code again before sending it forward, and it occurred to me that this might be breaking the PORT_SUSPEND and PORT_SET_LINK_STATE port features for xhci root hub. In normal use these requests are called by usb core in usb_port_suspend(), which also now notifies xhci, which makes sure xhci_stop_device() is called. But I don't think there is anything preventing an URB to be sent to the xhci roothub with a PORT_SUSPEND or PORT_SET_LINK_STATE port feature request. In this case the usb_port_suspend() is not called, and no notify will stop the device. For example hub validation tests might do this -Mathias