On 04/19/2012 01:01 PM, Alan Stern wrote:
> On Thu, 19 Apr 2012, Stephen Warren wrote:
>
>>> If you make that change, does the driver continue to work as well as it
>>> did before?
>>
>> Yes, I believe so.
>>
>> Note: I found that the immediate resume is because hcd_bus_suspend()
>> aborts part-way through due to "suspend raced with wakeup event", which
>> is due to ehci_hub_status_data() finding that port_status has all of
>> PORT_CSC | PORT_PEC | PORT_OCC set. Is it worth tracking that down
>> further? I have no idea if it's an ehci-tegra.c issue or quirk in our
>> EHCI HW.
>
> It's probably because of the recent change to hcd_bus_suspend().
> Before that change, it did not call ehci_hub_status_data() after doing
> the suspend. But now you see the problem: ehci_hub_status_data()
> returns bogus information because the controller has been powered down.
> That's the reason why I wanted to update ehci-tegra.c.
Aha, I'm beginning to understand!
> If you revert commit 879d38e6bc36d73b0ac40ec9b0d839fda9fa8b1a, how well
> does the current driver behave?
It's basically the same as the patch you posted at the start of this
thread. In other words:
* When nothing is plugged in, the port(hub) suspends and stays
suspended; no oscillating.
* When I plug something in, the system doesn't see it.
* If I then manually resume the hub ("echo on > usb3/power/control"),
new devices are seen, and devices can be unplugged/replugged and seen.
* While a device is plugged in, I can "echo auto > usb3/power/control"
and it stays operational.
So, I guess the only question is: the patch you posted was to solve the
problem of seeing bogus status during suspend, which causes the
immediate resume; Why doesn't that work?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
