On Wednesday 18 July 2012 21:06:39 Lan Tianyu wrote: > On 2012/7/18 12:43, Oliver Neukum wrote: > > On Tuesday 17 July 2012 14:52:51 Sarah Sharp wrote: > >> That policy would be safe, because for 1) we would never see a USB > >> device connection, and thus wouldn't miss the connection when we powered > >> off the port. 2) is safe because we won't miss a remote wakeup while > >> the port is powered off, and the device can't be disconnected by the > >> user because it's an internal USB device. > > > > That is still problematic. Because it depends on the driver and the core > > being able to reinit a device from a cold start. For devices that take > > a firmware this is untrue. Unfortunately internal BT and 3G devices are > > the most prominent examples of devices needing firmware. > hi oliver: > we can add a new variable for driver to indicate whether it can > support usb port power off mechanism to deal with this issue. We could add such a flag, but it would be nearly useless. The typical case is that the driver does not upload the firmware. Either another driver (e.g. ath3k) or user space do the job. > I have a question that reset-resume still can not resolve firmware > problem? I think this depend on driver. right? Right, but this is not really useful information. We can infer from a lack of support for reset_resume() that we must not cut power. The reverse conclusion is invalid, unfortunately. Regards Oliver -- 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
