All of lore.kernel.org
 help / color / mirror / Atom feed
From: dbaryshkov@gmail.com (Dmitry Eremin-Solenikov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend
Date: Wed, 22 Jun 2011 18:26:36 +0400	[thread overview]
Message-ID: <4E01FB9C.7020205@gmail.com> (raw)
In-Reply-To: <20110622142006.GC27654@legolas.emea.dhcp.ti.com>

On 22.06.2011 18:20, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jun 22, 2011 at 06:15:17PM +0400, Dmitry Eremin-Solenikov wrote:
>> On 6/22/11, Felipe Balbi<balbi@ti.com>  wrote:
>>> Hi,
>>>
>>> On Wed, Jun 22, 2011 at 05:52:18PM +0400, Dmitry Eremin-Solenikov wrote:
>>>> On 6/22/11, Felipe Balbi<balbi@ti.com>  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.

That was a rhetorical question. Basically there are plenty of situations
and cases (cable is not attached; cable attached, but no gadget driver;
cable attached, block gadget driver, but filesystems aren't mounted; 
cable attached, block gadget driver , filesystem mounted, but host
is also suspended, etc.).

> You could use osme VBUS IRQ to toggle a driver flag which, if true,
> would return -EBUSY on suspend().

I'm more and more thinking that this handling this -EBUSY isn't a task 
of gpio-vbus, but rather of some higher level driver. I'd assume that
if I hit this point, all previous drivers (which depend on this 
transceiver, so registered later) permit suspending at this moment,
so everything is OK :)

>
>> 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 ?

Yes. pxa27x udc driver disables D+ pullup on suspend and that's the 
behaviour asked from me by Robert Jarzmik in comments to first cleanup 
patch serie for pxa27x UDC driver.

-- 
With best wishes
Dmitry

  reply	other threads:[~2011-06-22 14:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-22 12:20 [PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend Dmitry Eremin-Solenikov
2011-06-22 12:20 ` [PATCH 2/2] mioa701: move gpio-pullup functionality to gpio-vbus Dmitry Eremin-Solenikov
2011-06-22 12:40   ` Dmitry Eremin-Solenikov
2011-06-22 13:23 ` [PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend Felipe Balbi
2011-06-22 13:52   ` Dmitry Eremin-Solenikov
2011-06-22 14:01     ` Felipe Balbi
2011-06-22 14:15       ` Dmitry Eremin-Solenikov
2011-06-22 14:20         ` Felipe Balbi
2011-06-22 14:26           ` Dmitry Eremin-Solenikov [this message]
2011-06-22 14:30             ` Felipe Balbi
2011-06-22 14:30   ` Alan Stern
2011-06-22 14:32     ` Felipe Balbi
2011-06-22 15:02       ` Alan Stern
2011-06-22 15:19         ` Felipe Balbi
2011-06-25  9:26           ` Robert Jarzmik
2011-06-25 10:33             ` Dmitry Eremin-Solenikov
2011-06-25 12:02             ` Alan Stern
2011-06-27 20:39               ` Robert Jarzmik
2011-06-28  2:41             ` Peter Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E01FB9C.7020205@gmail.com \
    --to=dbaryshkov@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.