On Thu, 20 Feb 2014, Dan Williams wrote:
> > You forgot to acquire the port lock in usb_reset_device. The lock and
> > unlock calls should surround the call to usb_reset_and_verify_device.
> > Both that routine and hub_port_init should be documented as requiring
> > their caller to hold the port
On Fri, Feb 7, 2014 at 2:11 PM, Alan Stern wrote:
> On Fri, 31 Jan 2014, Dan Williams wrote:
>
>> In general we do not want khubd to act on port status changes that are
>> the result of in progress resets or port pm runtime operations.
>
> The nomenclature is a little confusing. Let's agree that
On Fri, 31 Jan 2014, Dan Williams wrote:
> In general we do not want khubd to act on port status changes that are
> the result of in progress resets or port pm runtime operations.
The nomenclature is a little confusing. Let's agree that "port runtime
PM operations" will refer to usb_port_runtime
In general we do not want khubd to act on port status changes that are
the result of in progress resets or port pm runtime operations.
Specifically port power control testing has been able to trigger an
unintended disconnect in hub_port_connect_change(), paraphrasing:
if ((portstatus & USB
