From: Philip Langdale <philipl@overt.org>
To: Pierre Ossman <pierre@ossman.eu>
Cc: David Vrabel <david.vrabel@csr.com>,
Ohad Ben-Cohen <ohad@bencohen.org>,
akpm@linux-foundation.org, p <hilipl@overt.org>,
ian@mnementh.co.uk, matt@console-pimps.org,
roberto.foglietta@gmail.com, linux-mmc@vger.kernel.org
Subject: Re: [PATCH] sdio: add MMC_CAP_VDD_165_195 host capability
Date: Tue, 29 Sep 2009 16:20:38 -0400 [thread overview]
Message-ID: <f6ee8ef9d3da123c11433b52ec8d6a60@localhost> (raw)
In-Reply-To: <20090929202833.179fb521@mjolnir.ossman.eu>
On Tue, 29 Sep 2009 20:28:33 +0200, Pierre Ossman <pierre@ossman.eu> wrote:
> On Mon, 28 Sep 2009 19:25:48 -0700
> Philip Langdale <philipl@overt.org> wrote:
>
>>
>> Hi David,
>>
>> Ok, that sounds reasonable, but my concern is a controller that
>> publishes support for MMC_VDD_165_195 for mmc cards but doesn't
>> claim support for SDIO cards - particularly considering the
>> signalling implications you mentioned. Now, maybe you don't see
>> this happening in the wild, but it seems to me that it has to
>> be possible. It seems that to guard against this, you'd need a
>> host cap that says "165_195 for SD" and if it's not present,
>> mask it out of the OCR when dealing with SD/IO cards.
>>
>> Am I being too paranoid?
>>
>
> There is no way the vendor of the SD controller can know what this bit
> means to the vendor of the SD/SDIO card as it is undefined. I'm afraid
> I see no safe way of supporting this bit. The only thing we can do is
> interpret it as being the same as the MMC bit, but then only with an
> opt-in configuration as we might be killing hardware with this.
My understanding from the previous discussion was that SD 3.0 (and
presumably
a matching SDHCI 3.0) fully define the low voltage range. As such, a
controller
that is documented to conform to this spec, or is otherwise documented to
implement the functionality, can be safely allowed to run SD cards that
also
claim to support the bit.
Yes, there is a danger of pre 3.0 cards claiming to suport the low voltage
range,
but I think there's a credible chance that no such cards actually exist,
and if
they do, I think they're obscure enough to ignore - if they were a problem,
the
SD association would have had to abandon using the same bit as MMC uses.
If you're really paranoid, you could also cross-check the SD card version
but
that would have to happen after establishing basic communication so you'd
have
to go back and re-negotiate the voltage after starting at 3.3V.
It seems a reasonable compromise to me to assume that a card which claims
low
voltage support knows what its talking about, and then have host support be
opt
in, either by explicitly reporting SDHCI 3.0 compliance or because the
controller
docs state that it supports SD 3.0 cards.
--phil
next prev parent reply other threads:[~2009-09-29 20:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 17:51 [PATCH] sdio: add MMC_CAP_VDD_165_195 host capability Ohad Ben-Cohen
2009-09-28 18:09 ` David Vrabel
2009-09-28 20:02 ` Ohad Ben-Cohen
2009-09-29 2:25 ` Philip Langdale
2009-09-29 18:28 ` Pierre Ossman
2009-09-29 20:20 ` Philip Langdale [this message]
2009-09-29 21:37 ` Pierre Ossman
2009-09-30 6:10 ` Philip Langdale
2009-10-08 18:38 ` Pierre Ossman
2009-10-10 18:42 ` Philip Langdale
2009-10-12 13:11 ` David Vrabel
2009-10-13 2:39 ` Philip Langdale
2009-10-14 7:56 ` Ohad Ben-Cohen
2009-10-14 8:48 ` Pierre Ossman
2009-10-14 10:34 ` David Vrabel
2009-10-14 11:05 ` Pierre Ossman
-- strict thread matches above, loose matches on Subject: below --
2009-09-28 17:55 Ohad Ben-Cohen
2009-09-28 17:58 Ohad Ben-Cohen
2009-09-28 18:10 ` Matt Fleming
2009-09-28 20:10 ` Ohad Ben-Cohen
2009-09-28 22:59 ` Andrew Morton
2009-09-29 5:53 ` Matt Fleming
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=f6ee8ef9d3da123c11433b52ec8d6a60@localhost \
--to=philipl@overt.org \
--cc=akpm@linux-foundation.org \
--cc=david.vrabel@csr.com \
--cc=hilipl@overt.org \
--cc=ian@mnementh.co.uk \
--cc=linux-mmc@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=ohad@bencohen.org \
--cc=pierre@ossman.eu \
--cc=roberto.foglietta@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox