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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
