Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Re: [PATCH] USB: Don't enable LPM if it's already enabled
From:   Kai Heng Feng <kai.heng.feng@canonical.com>
In-Reply-To: <Pine.LNX.4.44L0.1810301058540.1515-100000@iolanthe.rowland.org>
Date:   Tue, 30 Oct 2018 23:07:47 +0800
Cc:     Mathias Nyman <mathias.nyman@linux.intel.com>,
        gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8BIT
Message-Id: <DDDD403E-601C-4AAB-B872-21781D9DA822@canonical.com>
References: <Pine.LNX.4.44L0.1810301058540.1515-100000@iolanthe.rowland.org>
To:     Alan Stern <stern@rowland.harvard.edu>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Oct 30, 2018, at 23:00, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> On Tue, 30 Oct 2018, Mathias Nyman wrote:
> 
>> On 30.10.2018 07:54, Kai-Heng Feng wrote:
>>> USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working
>>> after S3:
>>> [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
>>> [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110)
>>> 
>>> After some experiments, I found that disabling LPM can workaround the
>>> issue.
>>> 
>>> On some platforms, the USB power is cut during S3, so the driver uses
>>> reset-resume to resume the device. During port resume, LPM gets enabled
>>> twice, by usb_reset_and_verify_device() and usb_port_resume().
>>> 
>>> So let's enable LPM for just once, as this solves the issue for the
>>> device in question.
>>> 
>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>> ---
>>>  drivers/usb/core/driver.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
>>> index 53564386ed57..e11d2eac76b6 100644
>>> --- a/drivers/usb/core/driver.c
>>> +++ b/drivers/usb/core/driver.c
>>> @@ -1901,7 +1901,8 @@ int usb_set_usb2_hardware_lpm(struct usb_device *udev, int enable)
>>>  	struct usb_hcd *hcd = bus_to_hcd(udev->bus);
>>>  	int ret = -EPERM;
>>> 
>>> -	if (enable && !udev->usb2_hw_lpm_allowed)
>>> +	if (enable && !udev->usb2_hw_lpm_allowed ||
>>> +	    udev->usb2_hw_lpm_enabled == enable)
>>>  		return 0;
>>> 
>>>  	if (hcd->driver->set_usb2_hw_lpm) {
>>> 
>> 
>> Something like that would probably work.
>> 
>> Would it make sense to skip USB2 hw LPM enabling in usb_port_resume() if
>> port was just reset (and thus LPM enabled)?
>> 
>> something like this:
>> 
>> --- a/drivers/usb/core/hub.c
>> +++ b/drivers/usb/core/hub.c
>> @@ -3520,7 +3520,7 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>>                 hub_port_logical_disconnect(hub, port1);
>>         } else  {
>>                 /* Try to enable USB2 hardware LPM */
>> -               if (udev->usb2_hw_lpm_capable == 1)
>> +               if (udev->usb2_hw_lpm_capable == 1 && !udev->reset_resume)
>>                         usb_set_usb2_hardware_lpm(udev, 1);
>> 
>>                 /* Try to enable USB3 LTM */
> 
> Why not simply test whether udev->usb2_hw_lpm_enabled is already true?
> 
> 		if (udev->usb2_hw_lpm_capable == 1 &&
> 				!udev->usb2_hw_lpm_enabled)
> 
> Or even put this extra test into usb_set_usb2_hardware_lpm().

I think it makes sense to merge all checks into usb_set_usb2_hardware_lpm().

I’ll resend one with this suggestion.

Kai-Heng

> 
> Alan Stern