On 2012年11月11日 23:55, Alan Stern wrote: > On Sun, 11 Nov 2012, Lan Tianyu wrote: > >> On 2012/11/10 0:10, Alan Stern wrote: >>> On Fri, 9 Nov 2012, Lan Tianyu wrote: >>> >>>> Some usb devices can't be resumed correctly after power off. This >>>> patch is to add pm qos flags request to change NO_POWER_OFF and >>>> provide usb_device_allow_power_off() for device drivers to allow or >>>> prohibit usb core to power off the device. >>> >>> If the reason for adding this request is to prevent the device from >>> being powered off, then shouldn't the PM QOS flag be associated with >>> device rather than with the port? >> Hi Alan: >> Great thanks for your review and good suggestions. >> For pm qos flags, If put it on the port device, there is an advantage >> that it can cover port without device or unused port and this part >> didn't present in my this patchset. > > Right. That's a big advantage. > >>> In fact, it seems reasonable to have such a flag for both the device >>> and the port. >> You mean for usb device or usb interface device? > > USB device. > >> I think port and device are bound. Power off port also means to power >> off device. So prevent device from power off also means to prevent port >> from power off. They just like a power domain. Because power is on the >> port and so I thought we just needed to have pm qos flag on the port. > > Consider what happens when the device is unplugged. The restriction > against powering off the device won't be needed any more, but the PM > QOS flag will still be set for the port. You are saying outside port. For outside port, currently our plan is to set NO_POWER_OFF flag defaultly. So it doesn't matter after device unplugged. Moreover, we can change the port's pm qos flag when device is disconnected. > >> This maybe a simple version. If necessary, I also could add pm qos flag >> for usb or usb interface device later. > > Okay. > > Alan Stern > -- Best regards Tianyu Lan -- 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
