On Tue, 9 Sep 2014, Oliver Neukum wrote: > On Tue, 2014-09-09 at 13:25 -0400, Alan Stern wrote: > > On Tue, 9 Sep 2014, Alan Stern wrote: > > > > > On Tue, 9 Sep 2014, Oliver Neukum wrote: > > > > > > > On Tue, 2014-09-09 at 11:23 -0400, Alan Stern wrote: > > > > > On Tue, 9 Sep 2014, Oliver Neukum wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > Johan's patch means that for the affected touchscreen the port > > > > > > can never be powered off. It seems to me that this needs a special > > > > > > flag. What do you think? > > > > > > > > > > Why can't the port be powered off? > > > > > > > > needs_remote_wakeup is permanently set. > > > > > > That's okay, then. We never power-down a port if the attached device > > > is enabled for remote wakeup. See the last few lines in > > > usb_port_suspend() in hub.c. > > > > Sorry, I misunderstood. You meant that the port can't be powered off > > because remote wakeup is enabled, but the driver doesn't really need > > remote wakeup even though it sets the needs_remote_wakeup flag. > > > > In other words, you want to power-off the port, but are prevented from > > doing so by the fact that the device disconnects itself from the bus if > > it is suspended without remote wakeup. > > > > My feeling is that this is not worth the effort. Leave the port > > powered on. Or let the device disconnect itself and then power-off the > > port. > > It would reconnect. For a mouse I wouldn't bother, but here we are > dealing with a laptop's touchscreen. We'd break D3cold for the HC > permanently and totally. Only runtime D3cold would be affected. System suspend would still be able to use D3cold. Also, if the user doesn't care about the touchscreen, you could unbind it from the driver. Then the kernel would suspend it and power-off the port before the device could reconnect. Alan Stern -- 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
