On Fri, 14 Mar 2014, Dan Williams wrote: > On Fri, 2014-03-14 at 12:11 -0400, Alan Stern wrote: > > On Thu, 13 Mar 2014, Dan Williams wrote: > > > > > Three reasons: > > > 1/ It's an invalid operation on usb3 ports > > > 2/ There's no guarantee of when / if a usb2 port has entered an error > > > state relative to PORT_POWER request > > > 3/ The port is active / powered at this point, so khubd will clear it as > > > a matter of course > > > > > > Signed-off-by: Dan Williams <dan.j.willi...@intel.com> > > > --- > > > drivers/usb/core/port.c | 1 - > > > 1 files changed, 0 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c > > > index 9d9a3bb00f40..96f7a29e2ac6 100644 > > > --- a/drivers/usb/core/port.c > > > +++ b/drivers/usb/core/port.c > > > @@ -106,7 +106,6 @@ static int usb_port_runtime_resume(struct device *dev) > > > if (retval < 0) > > > dev_dbg(&port_dev->dev, "can't get reconnection after > > > setting port power on, status %d\n", > > > retval); > > > - usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_C_ENABLE); > > > retval = 0; > > > } > > > > I trust that further changes in this series will prevent the "port N > > disabled by hub (EMI?), re-enabling..." message from being logged. > > Have you tested this? > > Yes, I've never seen that message in all my testing as the resume > recovery ops arrange for the portstatus to reflect USB_PORT_STAT_ENABLE > by the time khubd runs.
In that case, Acked-by: Alan Stern <st...@rowland.harvard.edu> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
