On Wed, May 28, 2014 at 12:41 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 28 May 2014, Dan Williams wrote: > >> On Tue, May 27, 2014 at 5:26 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Tue, May 20, 2014 at 06:08:01PM -0700, Dan Williams wrote: >> >> Greg, >> >> >> >> Here is the port power control rework for your consideration now that >> >> Alan has finished acking it (see summary below). Patch 9 had one >> >> outstanding minor question from Alan that I believe I have addressed. >> >> Patch 16 has a checkpatch warning "WARNING: msleep < 20ms can sleep for >> >> up to 20ms", but it's flagging old code that simply moved and a 20ms >> >> timeout is acceptable. >> >> >> >> Changes since v9 [1]: >> >> * Reworked the forced wakeup mechanism in patch 17 to use >> >> pm_request_resume() >> >> >> >> * Random collection of fixlets and rewordings suggested by Alan. >> > >> > I've applied the first 17 patches as it seemed that the last 2 needed >> > some changes. >> >> Much appreciated. I'll address Alan's comments and get those re-posted. >> >> > Also, should I notice anything "different" with these patches applied? >> >> Hopefully not, probably a bug if you do. Port power control was >> already default-disabled before this patchset and this update does not >> affect that. The largest user visible change is that the kernel now >> enforces that USB2 ports must be powered-off before their USB3 peer. >> Outside of that this is just fixes to the recovery path when >> re-powering a port. > > Also, the device names of the ports in sysfs are now different. > "2-1-port3" instead of "port3", for example. This is a user API > change; we hope it won't break anything because until now there has > been very little reason for userspace tools to do anything with port > devices. > Yes, the proposed mitigation plan is "revert if somebody screams". In the meantime it cleans up and standardizes several dev_printk()'s in the usb core. -- 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
