All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@stericsson.com>
To: Daniel Drake <dsd@laptop.org>
Cc: Vitaly Wool <vitalywool@gmail.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Chris Ball <cjb@laptop.org>,
	Per FORLIN <per.forlin@stericsson.com>,
	Johan RUDHOLM <johan.rudholm@stericsson.com>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH] mmc: core: Do not pre-claim host in suspend
Date: Fri, 20 Apr 2012 10:55:33 +0200	[thread overview]
Message-ID: <4F912485.2020906@stericsson.com> (raw)
In-Reply-To: <CAMLZHHQVrog2srUhOjH5T3bQN4DjjP04x0ko3Bv9CXYyo_8i9Q@mail.gmail.com>

On 04/19/2012 05:48 PM, Daniel Drake wrote:
> On Thu, Apr 19, 2012 at 4:02 AM, Vitaly Wool<vitalywool@gmail.com>  wrote:
>> I think it looks like a hack. Can you provide a better description of
>> where this deadlock actually happens?
>>
>> If libertas_sdio claims host as a part of its suspend operation from a
>> context different from the suspend context, isn't it libertas_sdio
>> that has to be fixed?
>
> libertas_sdio performs work in a workqueue during the suspend routine.
> It doesn't take long, but it is essential.
>
> Technically it would be possible to do the same work from the suspend
> thread without changing context. However, implementation-wise this is
> quite difficult. We cannot simply blast commands off to the card
> directly, we have to obey various rules and keep things in sync. This
> is done with an abstraction layer in the driver which is also shared
> with equivalent devices that connect over USB, SPI, etc. Sometimes we
> send commands from atomic context, or asynchronously, so thats why we
> do things in a workqueue.
>
> Breaking this abstraction for the suspend corner-case would be a pain,
> and I don't agree with the strange requirement that SDIO drivers can't
> communicate from other contexts in the suspend routine. My thoughts
> are here: http://article.gmane.org/gmane.linux.kernel.mmc/13899
>
> Ulf, you have understood the problem correctly and your patch solves
> the issue. Thanks for the fast response.
>
> Daniel

Thanks Daniel for testing, could we add your "Tested-by" to this patch then?

Myself, would like to do some more testing for MMC/SD, before adding 
mine Tested-by tag... get back to this soon..

Kind regards
Uffe


  reply	other threads:[~2012-04-20  8:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19  9:55 [PATCH] mmc: core: Do not pre-claim host in suspend Ulf Hansson
2012-04-19 10:02 ` Vitaly Wool
2012-04-19 15:48   ` Daniel Drake
2012-04-20  8:55     ` Ulf Hansson [this message]
2012-04-20 13:39       ` Daniel Drake
2012-04-20 13:41 ` Chris Ball
2012-04-20 17:17 ` Sujit Reddy Thumma

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=4F912485.2020906@stericsson.com \
    --to=ulf.hansson@stericsson.com \
    --cc=cjb@laptop.org \
    --cc=dsd@laptop.org \
    --cc=johan.rudholm@stericsson.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=per.forlin@stericsson.com \
    --cc=vitalywool@gmail.com \
    /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.