linux-kernel - Re: [RFC][PATCH 1/3] usb: add a hcd notify entry in hc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5549694D.6000505@linux.intel.com>
Date:	Wed, 06 May 2015 09:07:25 +0800
From:	"Lu, Baolu" <baolu.lu@...ux.intel.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mathias Nyman <mathias.nyman@...el.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/3] usb: add a hcd notify entry in hc_driver



On 05/05/2015 10:50 PM, Alan Stern wrote:
> On Tue, 5 May 2015, Lu, Baolu wrote:
>
>> The order that software should do during device suspend/resume is
>> defined in 4.15.1.1 of xHCI spec 1.1.
>>
>> Spec 4.15.1.1:
>>
>> Software shall stop all endpoints of a device using the Stop Endpoint
>> Command and setting the Suspend
>> (SP) flag to 1 prior to selectively suspending a device.
> But _after_ all the URBs sent to the device have completed, right?
Yes, that's right.

>
>>   After the
>> device is resumed software shall ring an
>> endpoint's doorbell to restart it.
> The driver would ring the endpoint's doorbell anyway when a new URB is
> submitted, wouldn't it?  Which means the resume callback doesn't
> actually have to do anything.
The value of ringing door bell after resume is that hcd can fetch
endpoint state from memory to cache and get ready for transfer
as early as possible.

>
>> --end--
>>
>> So the order looks like:
>>
>> tell hcd device suspend
>> usb_port_suspend()
> You have forgotten that usb_port_suspend() can send URBs to the device
> (to enable remote wakeup, for example).  Therefore you shouldn't notify
> the HCD until usb_port_suspend() is partly or totally finished.
Yes, I agree with you. I will move the notification into usb_port_suspend(),
just before sending suspend request to parent hub.

>
>> usb_port_resume()
>> tell hcd device resume
> You have also forgotten that usb_port_resume() calls various functions
> that send URBs to ep0 on the device.  Therefore if the HCD's
> device_resume callback needs to do something (like ringing ep0's
> doorbell), you had better invoke the callback _before_ calling
> usb_port_resume().  Or maybe you had better do this _within_
> usb_port_resume().
Agree. I will do this within usb_port_resume() just after completing
sending clear port feature.

>
> Alan Stern
Thank you for the comments. I will send the v2 patch series with all
your comments addressed.

Thanks,
Baolu

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/