Hi, On Wed, Jun 22, 2011 at 06:15:17PM +0400, Dmitry Eremin-Solenikov wrote: > On 6/22/11, Felipe Balbi <balbi@xxxxxx> wrote: > > Hi, > > > > On Wed, Jun 22, 2011 at 05:52:18PM +0400, Dmitry Eremin-Solenikov wrote: > >> On 6/22/11, Felipe Balbi <balbi@xxxxxx> wrote: > >> > Hi, > >> > > >> > On Wed, Jun 22, 2011 at 04:20:16PM +0400, Dmitry Eremin-Solenikov wrote: > >> >> Some platforms would like to disable D+ pullup on suspend, to drain as > >> >> low power, as possible. E.g. this was requested by mioa701 board > >> >> maintainers. > >> > > >> > I think this makes sense to many platforms, but by doing so, you would > >> > loose connection to the Host PC, so you need to make sure your device > >> > isn't been used before you go down this road. > >> > >> I've thought about this. Should UDC driver should somehow call into OTG > >> layer on suspend? My understanding is that otg_set_suspend isn't the call > >> that should be done here, is it true? > >> > >> My idea was that board can ask for D+ disabling, knowing itself the > >> behaviour > >> of the platform driver on suspend (e.g. PXA27x does disable UDC on > >> suspend, > >> but I dunno what effect this will cause on Host PC). > > > > Host PC will only see the device disconnecting. So, what happens if the > > user has mounted file systems when you decide to go into suspend ? > > What happens if user has mounted filesystems when I decide to pull out > the cable? for starters you could have filesystem corruption. In short, the best way would be to return -EBUSY in your suspend if the cable is still attached. You could use osme VBUS IRQ to toggle a driver flag which, if true, would return -EBUSY on suspend(). > I agree with you generally, but I'd like to hear any suggestions. I'm not sure how to solve this, but OTOH the original code already did this, just on a different way, right ? -- balbi
Attachment:
signature.asc
Description: Digital signature
