[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Doug Anderson]

Bing Zhao at Marvell found a problem with dw_mmc where interrupts
weren't firing sometimes.  He tracked it down to a read-modify-write
problem with the INTMASK.  These patches fix the problem.

Note: I've picked up a > 1-year old series here to make another
attempt at landing it upstream.  These patches have been in shipping
Chromebooks for the last year.  Note that v3 to v4 has no changes
other than a rebase and a small commit message update.

The first two patches extend the "init_card()" mechanism of MMC core
to actually be called for all card types, not just SDIO.  That could
be applied any time and should fix at least one longstanding bug
(untested).

The third patch is a cleanup patch to use init_card() to move things
around a bit so we don't need to handle SDIO cards in such a strange
place.  On earlier versions of this patch Seungwon brought up a few
points which I have _not_ addressed.  See
<https://patchwork.kernel.org/patch/3049071/>.  Other than talk of
cards with out of band interrupts maybe being able to gate their
clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
that because of the ordering of init_card() and when the quirks are
set.  Some users of init_card() like pandora_wl1251_init_card() rely
on it being called very early in the process.
pandora_wl1251_init_card() hardcodes a vendor and device and thus need
to be called super early.  On the other hand the code that adds quirks
_reads_ the vendor and device.  It can't possibly move before
init_card().  If folks are willing to take an additional host op of
init_card_late() I can certainly go that way, though.

The fourth patch is (I think) reviewed and ready to go assuming the
other two land.

Changes in v5:
- Split fixup to pandora_wl1251_init_card() into its own patch.

Changes in v3:
- Add fixup to pandora_wl1251_init_card().

Changes in v2:
- mmc core change new for this version.
- Fixed "|" to "&".
- intmask_lock renamed to irq_lock

Doug Anderson (4):
  ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only
  mmc: core: Support the optional init_card() callback for MMC and SD
  mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts
  mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock

 arch/arm/mach-omap2/board-omap3pandora.c | 14 +++---
 drivers/mmc/core/mmc.c                   |  6 +++
 drivers/mmc/core/sd.c                    |  7 ++-
 drivers/mmc/host/dw_mmc.c                | 80 +++++++++++++++++++-------------
 drivers/mmc/host/dw_mmc.h                |  1 +
 include/linux/mmc/dw_mmc.h               |  6 +++
 6 files changed, 74 insertions(+), 40 deletions(-)

-- 
2.2.0.rc0.207.ga3a616c

[PATCH v5 1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only

[Doug Anderson]

In preparation for having init_card() called for all card types (not
just SDIO), change pandora_wl1251_init_card() so it checks whether the
card type is SDIO.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Changes in v5:
- Split fixup to pandora_wl1251_init_card() into its own patch.

Changes in v3: None
Changes in v2: None

 arch/arm/mach-omap2/board-omap3pandora.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 7f17087..969e100 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -254,12 +254,14 @@ static void pandora_wl1251_init_card(struct mmc_card *card)
 	 * We have TI wl1251 attached to MMC3. Pass this information to
 	 * SDIO core because it can't be probed by normal methods.
 	 */
-	card->quirks |= MMC_QUIRK_NONSTD_SDIO;
-	card->cccr.wide_bus = 1;
-	card->cis.vendor = 0x104c;
-	card->cis.device = 0x9066;
-	card->cis.blksize = 512;
-	card->cis.max_dtr = 20000000;
+	if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) {
+		card->quirks |= MMC_QUIRK_NONSTD_SDIO;
+		card->cccr.wide_bus = 1;
+		card->cis.vendor = 0x104c;
+		card->cis.device = 0x9066;
+		card->cis.blksize = 512;
+		card->cis.max_dtr = 20000000;
+	}
 }
 
 static struct omap2_hsmmc_info omap3pandora_mmc[] = {
-- 
2.2.0.rc0.207.ga3a616c

[PATCH v5 1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only

[Tony Lindgren]

* Doug Anderson <dianders@chromium.org> [141202 15:45]:
> In preparation for having init_card() called for all card types (not
> just SDIO), change pandora_wl1251_init_card() so it checks whether the
> card type is SDIO.

Seems OK to me and should not conflict with linux-omap patches:

Acked-by: Tony Lindgren <tony@atomide.com>

> Signed-off-by: Doug Anderson <dianders@chromium.org>
> ---
> Changes in v5:
> - Split fixup to pandora_wl1251_init_card() into its own patch.
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-omap2/board-omap3pandora.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
> index 7f17087..969e100 100644
> --- a/arch/arm/mach-omap2/board-omap3pandora.c
> +++ b/arch/arm/mach-omap2/board-omap3pandora.c
> @@ -254,12 +254,14 @@ static void pandora_wl1251_init_card(struct mmc_card *card)
>  	 * We have TI wl1251 attached to MMC3. Pass this information to
>  	 * SDIO core because it can't be probed by normal methods.
>  	 */
> -	card->quirks |= MMC_QUIRK_NONSTD_SDIO;
> -	card->cccr.wide_bus = 1;
> -	card->cis.vendor = 0x104c;
> -	card->cis.device = 0x9066;
> -	card->cis.blksize = 512;
> -	card->cis.max_dtr = 20000000;
> +	if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) {
> +		card->quirks |= MMC_QUIRK_NONSTD_SDIO;
> +		card->cccr.wide_bus = 1;
> +		card->cis.vendor = 0x104c;
> +		card->cis.device = 0x9066;
> +		card->cis.blksize = 512;
> +		card->cis.max_dtr = 20000000;
> +	}
>  }
>  
>  static struct omap2_hsmmc_info omap3pandora_mmc[] = {
> -- 
> 2.2.0.rc0.207.ga3a616c
> 

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Ulf Hansson]

On 3 December 2014 at 00:42, Doug Anderson <dianders@chromium.org> wrote:
> Bing Zhao at Marvell found a problem with dw_mmc where interrupts
> weren't firing sometimes.  He tracked it down to a read-modify-write
> problem with the INTMASK.  These patches fix the problem.
>
> Note: I've picked up a > 1-year old series here to make another
> attempt at landing it upstream.  These patches have been in shipping
> Chromebooks for the last year.  Note that v3 to v4 has no changes
> other than a rebase and a small commit message update.
>
> The first two patches extend the "init_card()" mechanism of MMC core
> to actually be called for all card types, not just SDIO.  That could
> be applied any time and should fix at least one longstanding bug
> (untested).
>
> The third patch is a cleanup patch to use init_card() to move things
> around a bit so we don't need to handle SDIO cards in such a strange
> place.  On earlier versions of this patch Seungwon brought up a few
> points which I have _not_ addressed.  See
> <https://patchwork.kernel.org/patch/3049071/>.  Other than talk of
> cards with out of band interrupts maybe being able to gate their
> clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
> that because of the ordering of init_card() and when the quirks are
> set.  Some users of init_card() like pandora_wl1251_init_card() rely
> on it being called very early in the process.
> pandora_wl1251_init_card() hardcodes a vendor and device and thus need
> to be called super early.  On the other hand the code that adds quirks
> _reads_ the vendor and device.  It can't possibly move before
> init_card().  If folks are willing to take an additional host op of
> init_card_late() I can certainly go that way, though.
>
> The fourth patch is (I think) reviewed and ready to go assuming the
> other two land.

I have queued this up for 3.20. It was a bit hard to follow the
updated the revisions, please don't send patches "in-reply-to" for
future sets.

In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.

Kind regards
Uffe

>
> Changes in v5:
> - Split fixup to pandora_wl1251_init_card() into its own patch.
>
> Changes in v3:
> - Add fixup to pandora_wl1251_init_card().
>
> Changes in v2:
> - mmc core change new for this version.
> - Fixed "|" to "&".
> - intmask_lock renamed to irq_lock
>
> Doug Anderson (4):
>   ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only
>   mmc: core: Support the optional init_card() callback for MMC and SD
>   mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts
>   mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock
>
>  arch/arm/mach-omap2/board-omap3pandora.c | 14 +++---
>  drivers/mmc/core/mmc.c                   |  6 +++
>  drivers/mmc/core/sd.c                    |  7 ++-
>  drivers/mmc/host/dw_mmc.c                | 80 +++++++++++++++++++-------------
>  drivers/mmc/host/dw_mmc.h                |  1 +
>  include/linux/mmc/dw_mmc.h               |  6 +++
>  6 files changed, 74 insertions(+), 40 deletions(-)
>
> --
> 2.2.0.rc0.207.ga3a616c
>

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Doug Anderson]

Ulf,

On Fri, Dec 19, 2014 at 2:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 3 December 2014 at 00:42, Doug Anderson <dianders@chromium.org> wrote:
>> Bing Zhao at Marvell found a problem with dw_mmc where interrupts
>> weren't firing sometimes.  He tracked it down to a read-modify-write
>> problem with the INTMASK.  These patches fix the problem.
>>
>> Note: I've picked up a > 1-year old series here to make another
>> attempt at landing it upstream.  These patches have been in shipping
>> Chromebooks for the last year.  Note that v3 to v4 has no changes
>> other than a rebase and a small commit message update.
>>
>> The first two patches extend the "init_card()" mechanism of MMC core
>> to actually be called for all card types, not just SDIO.  That could
>> be applied any time and should fix at least one longstanding bug
>> (untested).
>>
>> The third patch is a cleanup patch to use init_card() to move things
>> around a bit so we don't need to handle SDIO cards in such a strange
>> place.  On earlier versions of this patch Seungwon brought up a few
>> points which I have _not_ addressed.  See
>> <https://patchwork.kernel.org/patch/3049071/>.  Other than talk of
>> cards with out of band interrupts maybe being able to gate their
>> clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
>> that because of the ordering of init_card() and when the quirks are
>> set.  Some users of init_card() like pandora_wl1251_init_card() rely
>> on it being called very early in the process.
>> pandora_wl1251_init_card() hardcodes a vendor and device and thus need
>> to be called super early.  On the other hand the code that adds quirks
>> _reads_ the vendor and device.  It can't possibly move before
>> init_card().  If folks are willing to take an additional host op of
>> init_card_late() I can certainly go that way, though.
>>
>> The fourth patch is (I think) reviewed and ready to go assuming the
>> other two land.
>
> I have queued this up for 3.20.

Thanks!


> It was a bit hard to follow the
> updated the revisions, please don't send patches "in-reply-to" for
> future sets.

Very strange.  I didn't send out anything in-reply-to other than what
git-send-email usually does.  I believe I had:

[0] - no in reply to.
 [1] - in reply to [0]
 [2] - in reply to [0]
 [3] - in reply to [0]
 [4] - in reply to [0]

Is there some other way you'd prefer?

Looking full headers in <https://patchwork.kernel.org/patch/5425241/>,
I confirm it is "in-reply-to"
"1417563767-32181-1-git-send-email-dianders at chromium.org".  Patchwork
doesn't keep cover letters, but you can see at
<http://www.spinics.net/lists/linux-mmc/msg29699.html>) that there is
no in-reply-to.

I'm more than happy to adjust my workflow if you can give me some
specifics.  Thanks!  :)


> In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.

Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
will try to do better in the future.  Sorry.  :(  You were in the To
line, though.  You can see at
<https://patchwork.kernel.org/patch/5425241/>.

Do you want me to repost it and CC linux-mmc with Tony's Ack?

---

Note: patchwork seems to find all my patches:

pwclient list -w dianders at chromium.org -p ""

5425241 New          [v5,1/4] ARM: OMAP2+: Make sure
pandora_wl1251_init_card() applies to SDIO only
5425291 New          [v5,1/4] ARM: OMAP2+: Make sure
pandora_wl1251_init_card() applies to SDIO only
5425311 New          [v5,1/4] ARM: OMAP2+: Make sure
pandora_wl1251_init_card() applies to SDIO only
5425231 New          [v5,2/4] mmc: core: Support the optional
init_card() callback for MMC and SD
5425301 New          [v5,2/4] mmc: core: Support the optional
init_card() callback for MMC and SD
5425271 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
power mode w/ SDIO interrupts
5425281 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
power mode w/ SDIO interrupts
5425251 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
of INTMASK with a lock
5425261 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
of INTMASK with a lock

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Ulf Hansson]

On 19 December 2014 at 20:02, Doug Anderson <dianders@chromium.org> wrote:
> Ulf,
>
> On Fri, Dec 19, 2014 at 2:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 3 December 2014 at 00:42, Doug Anderson <dianders@chromium.org> wrote:
>>> Bing Zhao at Marvell found a problem with dw_mmc where interrupts
>>> weren't firing sometimes.  He tracked it down to a read-modify-write
>>> problem with the INTMASK.  These patches fix the problem.
>>>
>>> Note: I've picked up a > 1-year old series here to make another
>>> attempt at landing it upstream.  These patches have been in shipping
>>> Chromebooks for the last year.  Note that v3 to v4 has no changes
>>> other than a rebase and a small commit message update.
>>>
>>> The first two patches extend the "init_card()" mechanism of MMC core
>>> to actually be called for all card types, not just SDIO.  That could
>>> be applied any time and should fix at least one longstanding bug
>>> (untested).
>>>
>>> The third patch is a cleanup patch to use init_card() to move things
>>> around a bit so we don't need to handle SDIO cards in such a strange
>>> place.  On earlier versions of this patch Seungwon brought up a few
>>> points which I have _not_ addressed.  See
>>> <https://patchwork.kernel.org/patch/3049071/>.  Other than talk of
>>> cards with out of band interrupts maybe being able to gate their
>>> clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
>>> that because of the ordering of init_card() and when the quirks are
>>> set.  Some users of init_card() like pandora_wl1251_init_card() rely
>>> on it being called very early in the process.
>>> pandora_wl1251_init_card() hardcodes a vendor and device and thus need
>>> to be called super early.  On the other hand the code that adds quirks
>>> _reads_ the vendor and device.  It can't possibly move before
>>> init_card().  If folks are willing to take an additional host op of
>>> init_card_late() I can certainly go that way, though.
>>>
>>> The fourth patch is (I think) reviewed and ready to go assuming the
>>> other two land.
>>
>> I have queued this up for 3.20.
>
> Thanks!
>
>
>> It was a bit hard to follow the
>> updated the revisions, please don't send patches "in-reply-to" for
>> future sets.
>
> Very strange.  I didn't send out anything in-reply-to other than what
> git-send-email usually does.  I believe I had:
>
> [0] - no in reply to.
>  [1] - in reply to [0]
>  [2] - in reply to [0]
>  [3] - in reply to [0]
>  [4] - in reply to [0]

That's good. As long as there are no in-reply to previous versions of
patches/patchsets.

I am using gmails web-based client so it could very well be that it
does some magic, which I am not yet aware of.

>
> Is there some other way you'd prefer?
>
> Looking full headers in <https://patchwork.kernel.org/patch/5425241/>,
> I confirm it is "in-reply-to"
> "1417563767-32181-1-git-send-email-dianders at chromium.org".  Patchwork
> doesn't keep cover letters, but you can see at
> <http://www.spinics.net/lists/linux-mmc/msg29699.html>) that there is
> no in-reply-to.
>
> I'm more than happy to adjust my workflow if you can give me some
> specifics.  Thanks!  :)
>
>
>> In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.
>
> Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
> will try to do better in the future.  Sorry.  :(  You were in the To
> line, though.  You can see at
> <https://patchwork.kernel.org/patch/5425241/>.
>
> Do you want me to repost it and CC linux-mmc with Tony's Ack?

I suggest you have a look at my next branch and to verify that I
haven't screwed things up. If so, either I should drop the patches and
you make a resend or if it's possible to just send an incremental path
on top?

Kind regards
Uffe

>
> ---
>
> Note: patchwork seems to find all my patches:
>
> pwclient list -w dianders at chromium.org -p ""
>
> 5425241 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425291 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425311 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425231 New          [v5,2/4] mmc: core: Support the optional
> init_card() callback for MMC and SD
> 5425301 New          [v5,2/4] mmc: core: Support the optional
> init_card() callback for MMC and SD
> 5425271 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
> power mode w/ SDIO interrupts
> 5425281 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
> power mode w/ SDIO interrupts
> 5425251 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
> of INTMASK with a lock
> 5425261 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
> of INTMASK with a lock

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Javier Martinez Canillas]

Hello Ulf,

On Tue, Dec 30, 2014 at 11:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 19 December 2014 at 20:02, Doug Anderson <dianders@chromium.org> wrote:
>>
>>> It was a bit hard to follow the
>>> updated the revisions, please don't send patches "in-reply-to" for
>>> future sets.
>>
>> Very strange.  I didn't send out anything in-reply-to other than what
>> git-send-email usually does.  I believe I had:
>>
>> [0] - no in reply to.
>>  [1] - in reply to [0]
>>  [2] - in reply to [0]
>>  [3] - in reply to [0]
>>  [4] - in reply to [0]
>
> That's good. As long as there are no in-reply to previous versions of
> patches/patchsets.
>
> I am using gmails web-based client so it could very well be that it
> does some magic, which I am not yet aware of.
>

I think that you were confused because Gmail's "conversation view"
groups emails in a thread not by the email subject but by the email
body.

So if a new revision of a series is sent and a patch did not change
from the previous version, Gmail will add it to the old patch thread
since the body is basically the same even when a version is present in
the subject (e.g: PATCH v2 foo).

I found that annoying as well so I disabled conversation view going to
Gmail's settings -> General -> Conversation view off

Hope it helps.

Best regards,
Javier

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Doug Anderson]

Ulf,

On Tue, Dec 30, 2014 at 2:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.
>>
>> Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
>> will try to do better in the future.  Sorry.  :(  You were in the To
>> line, though.  You can see at
>> <https://patchwork.kernel.org/patch/5425241/>.
>>
>> Do you want me to repost it and CC linux-mmc with Tony's Ack?
>
> I suggest you have a look at my next branch and to verify that I
> haven't screwed things up. If so, either I should drop the patches and
> you make a resend or if it's possible to just send an incremental path
> on top?

The patches that landed look good to me, but I think you might break
omap3pandora's WiFi until you land patch #1 in the series.  It has
Tony's Ack so I think he intends for you to land it in your tree.

[v5,1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only

-Doug

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Tony Lindgren]

* Doug Anderson <dianders@chromium.org> [150102 09:09]:
> Ulf,
> 
> On Tue, Dec 30, 2014 at 2:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >>> In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.
> >>
> >> Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
> >> will try to do better in the future.  Sorry.  :(  You were in the To
> >> line, though.  You can see at
> >> <https://patchwork.kernel.org/patch/5425241/>.
> >>
> >> Do you want me to repost it and CC linux-mmc with Tony's Ack?
> >
> > I suggest you have a look at my next branch and to verify that I
> > haven't screwed things up. If so, either I should drop the patches and
> > you make a resend or if it's possible to just send an incremental path
> > on top?
> 
> The patches that landed look good to me, but I think you might break
> omap3pandora's WiFi until you land patch #1 in the series.  It has
> Tony's Ack so I think he intends for you to land it in your tree.
> 
> [v5,1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only

Yes please pick that one up too to avoid breakage. The changes to the
mach-omap2/board-*.c files are only minimal fixes, so it should not
conflict with anything I'll be applying.

Regards,

Tony

[PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc

[Ulf Hansson]

On 2 January 2015 at 18:11, Tony Lindgren <tony@atomide.com> wrote:
> * Doug Anderson <dianders@chromium.org> [150102 09:09]:
>> Ulf,
>>
>> On Tue, Dec 30, 2014 at 2:29 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> >>> In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.
>> >>
>> >> Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
>> >> will try to do better in the future.  Sorry.  :(  You were in the To
>> >> line, though.  You can see at
>> >> <https://patchwork.kernel.org/patch/5425241/>.
>> >>
>> >> Do you want me to repost it and CC linux-mmc with Tony's Ack?
>> >
>> > I suggest you have a look at my next branch and to verify that I
>> > haven't screwed things up. If so, either I should drop the patches and
>> > you make a resend or if it's possible to just send an incremental path
>> > on top?
>>
>> The patches that landed look good to me, but I think you might break
>> omap3pandora's WiFi until you land patch #1 in the series.  It has
>> Tony's Ack so I think he intends for you to land it in your tree.
>>
>> [v5,1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only
>
> Yes please pick that one up too to avoid breakage. The changes to the
> mach-omap2/board-*.c files are only minimal fixes, so it should not
> conflict with anything I'll be applying.

Tony, Doug,

I have picked it up from the arm patch tracker and applied it for my
next branch. I have put it prior the following patch:
"mmc: core: Support the optional init_card() callback for MMC and SD".

Kind regards
Uffe

>
> Regards,
>
> Tony