From: Philip Langdale <philipl@overt.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matt Fleming <matt@console-pimps.org>,
ohad@bencohen.org, ian@mnementh.co.uk, pierre@ossman.eu,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
nico@cam.org, nicolas.ferre@rfo.atmel.com, hskinnemoen@atmel.com,
tony@atomide.com, david-b@pacbell.net, manuel.lauss@gmail.com,
mirq-l@jasper.es
Subject: Re: New MMC maintainer needed
Date: Sun, 26 Jul 2009 23:06:30 -0700 [thread overview]
Message-ID: <20090726230630.7598fbe4@fido2.homeip.net> (raw)
In-Reply-To: <20090724152944.51402e87.akpm@linux-foundation.org>
On Fri, 24 Jul 2009 15:29:44 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 23 Jul 2009 14:52:09 +0100
> Matt Fleming <matt@console-pimps.org> wrote:
>
> > On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
> > > Hi Andrew,
> > >
> > > On Thu, Jul 23, 2009 at 9:22 AM, Andrew
> > > Morton<akpm@linux-foundation.org> wrote:
> > > > I actually already have a little pile of MMC things queued:
> > >
> > > Please also consider queuing up the attached patch as well.
> > >
> > > The patch is removing the current SDIO cards 1.8V limit, which is
> > > needed for embedded
> > > SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers
> > > like we have on the ZOOM2 boards for example).
> > >
> > > Thank you,
> > > Ohad.
> >
> > > From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00
> > > 2001 From: Ohad Ben-Cohen <ohad@bencohen.org>
> > > Date: Wed, 15 Jul 2009 09:21:41 +0300
> > > Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
> > >
> > > This is needed for 1.8V embedded SDIO devices and supporting host
> > > controllers (e.g. TI 127x and ZOOM2 boards)
> > >
> > > Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
> > > ---
> > > drivers/mmc/core/sdio.c | 7 -------
> > > 1 files changed, 0 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> > > index fb99ccf..6f221dc 100644
> > > --- a/drivers/mmc/core/sdio.c
> > > +++ b/drivers/mmc/core/sdio.c
> > > @@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host,
> > > u32 ocr) ocr &= ~0x7F;
> > > }
> > >
> > > - if (ocr & MMC_VDD_165_195) {
> > > - printk(KERN_WARNING "%s: SDIO card claims to
> > > support the "
> > > - "incompletely defined 'low voltage
> > > range'. This "
> > > - "will be ignored.\n", mmc_hostname(host));
> > > - ocr &= ~MMC_VDD_165_195;
> > > - }
> > > -
> > > host->ocr = mmc_select_voltage(host, ocr);
> > >
> > > /*
> > > --
> > > 1.5.4.3
> > >
> >
> > Looks OK to me, I'm unaware of a reason to not allow a card to use
> > MMC_VDD_165_195 if that's what it wants.
> >
>
> Yes, that code was there from day #1, via Pierre's original commit.
> There is no indication in either the code comments or the changelog
> why it was done this way.
>
> Other ways of finding out why this code is there include:
>
> a) search the mailing list for review discussion. I can't find it
> in my lkml archive.
>
> b) ask Pierre :)
Both the (Simplified) SD and SDIO specifications do not formally define
the 'low voltage' range in the way the MMC spec does. ie: You won't
find anything in the SD specs that even tell you what the range is -
it just says that it exists.
So we (I wrote the first incarnation of this check for normal SD cards)
decided to bail if a card requested the low voltage range. Now, if
there's actually hardware out there that is SD/SDIO and operates at
1.8V, we should probably do something more appropriate. :-)
It's obviously an easy change but I'd feel a lot more comfortable if
someone can point us to a document that states that the SD/SDIO low
voltage range is defined to match the MMC one. Maybe one of the NDA
docs actually states this.
Andrew - I'm also willing to be cc'ed on MMC changes and I'll respond
to the best of my (limited) abilities.
--phil
next prev parent reply other threads:[~2009-07-27 6:06 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-14 13:36 New MMC maintainer needed Pierre Ossman
2009-07-14 21:04 ` Ian Molton
2009-07-22 22:17 ` Andrew Morton
2009-07-23 0:08 ` Ian Molton
2009-07-23 5:54 ` Matt Fleming
2009-07-23 6:22 ` Andrew Morton
2009-07-23 6:42 ` Paul Mundt
2009-07-23 6:50 ` Ohad Ben-Cohen
2009-07-23 13:52 ` Matt Fleming
2009-07-24 22:29 ` Andrew Morton
2009-07-27 6:06 ` Philip Langdale [this message]
2009-07-27 12:09 ` David Vrabel
2009-07-27 21:40 ` Matt Fleming
2009-07-28 0:52 ` Philip Langdale
2009-07-28 12:51 ` David Vrabel
2009-07-23 7:01 ` Adrian Hunter
2009-07-23 7:25 ` Stephen Rothwell
2009-07-23 7:32 ` Andrew Morton
2009-07-23 7:38 ` Stephen Rothwell
2009-07-23 16:29 ` Andi Kleen
2009-07-23 10:57 ` Roberto A. Foglietta
2009-07-28 20:22 ` Pierre Ossman
2009-07-30 2:36 ` Segher Boessenkool
2009-07-28 20:20 ` Pierre Ossman
2009-07-28 21:14 ` Ian Molton
2009-07-28 22:41 ` Andrew Morton
2009-07-29 6:35 ` Sam Ravnborg
2009-07-29 10:35 ` Ian Molton
2009-07-28 20:23 ` Pierre Ossman
2009-07-31 10:26 ` Pierre Ossman
2009-07-31 10:54 ` Matt Fleming
2009-08-03 10:34 ` Pierre Ossman
2009-08-03 11:10 ` Matt Fleming
2009-08-03 11:13 ` Adrian Hunter
2009-08-03 21:41 ` Andrew Morton
2009-08-11 14:02 ` Matt Fleming
2009-08-12 22:27 ` Andrew Morton
2009-08-13 8:21 ` Matt Fleming
2009-08-13 7:01 ` Adrian Hunter
2009-08-13 17:03 ` Nicolas Pitre
2009-08-04 1:51 ` David Brownell
2009-08-05 1:42 ` David VomLehn
2009-08-06 8:54 ` Pierre Ossman
2009-08-18 9:33 ` Nicolas Ferre
-- strict thread matches above, loose matches on Subject: below --
2009-07-15 4:59 Alex Dubov
2009-07-31 13:36 ` Maxim Levitsky
2009-08-01 6:53 ` Alex Dubov
2009-08-01 7:21 ` Maxim Levitsky
2009-08-12 22:52 ellis
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=20090726230630.7598fbe4@fido2.homeip.net \
--to=philipl@overt.org \
--cc=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=hskinnemoen@atmel.com \
--cc=ian@mnementh.co.uk \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manuel.lauss@gmail.com \
--cc=matt@console-pimps.org \
--cc=mirq-l@jasper.es \
--cc=nico@cam.org \
--cc=nicolas.ferre@rfo.atmel.com \
--cc=ohad@bencohen.org \
--cc=pierre@ossman.eu \
--cc=tony@atomide.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).