mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: Timo Teras <timo.teras@solidboot.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MMC: Select only one voltage bit in OCR response
Date: Tue, 31 Oct 2006 10:05:03 +0000	[thread overview]
Message-ID: <20061031100503.GB19812@flint.arm.linux.org.uk> (raw)
In-Reply-To: <453327EC.1000402@drzeus.cx>

On Mon, Oct 16, 2006 at 08:34:20AM +0200, Pierre Ossman wrote:
> Timo Teras wrote:
> > I see. But if we do send an OCR with an unsupported bit set, the card will
> > go to inactive state and is unusable. This problem is masked on controllers
> > with only 3.3V support, but I'm working with a controller supporting several
> > different voltages.
> >
> > For example, I have a card giving an OCR reply of 0x0ff80080. The current
> > code will reply to this with 0x00000180 which is clearly incorrect.
> >
> > Maybe something like "ocr &= 3 << bit;" would be more approriate?
> >   
> 
> Russell? Comments? Do you still have the offending card?

It wasn't my cards, but was reported by several other folk.  I don't think
we can revert on this without breakage.

However, we should probably ensure that we don't end up setting voltage
bits which the cards don't support.  So maybe masking the resulting OCR
value with the received combined OCR would be a good idea?  Such as:

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index ee8863c..45e0598 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -467,23 +467,24 @@ static inline void mmc_delay(unsigned in
  */
 static u32 mmc_select_voltage(struct mmc_host *host, u32 ocr)
 {
+	u32 selected_ocr;
 	int bit;
 
-	ocr &= host->ocr_avail;
+	selected_ocr = ocr & host->ocr_avail;
 
-	bit = ffs(ocr);
+	bit = ffs(selected_ocr);
 	if (bit) {
 		bit -= 1;
 
-		ocr = 3 << bit;
+		selected_ocr = 3 << bit;
 
 		host->ios.vdd = bit;
 		mmc_set_ios(host);
 	} else {
-		ocr = 0;
+		selected_ocr = 0;
 	}
 
-	return ocr;
+	return selected_ocr & ocr;
 }
 
 #define UNSTUFF_BITS(resp,start,size)					\


-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

  parent reply	other threads:[~2006-10-31 10:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-09 15:00 Timo Teras
2006-10-09 16:53 ` Russell King
2006-10-09 17:23   ` Timo Teras
2006-10-16  6:34     ` Pierre Ossman
2006-10-22  9:25       ` Pierre Ossman
2006-10-31 10:05       ` Russell King [this message]
2006-10-31 15:24         ` Juha Yrjola
2006-11-02 18:37           ` Pierre Ossman
2006-10-10 13:23   ` [PATCH] MMC: Do not set unsupported bits " Timo Teras

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=20061031100503.GB19812@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=timo.teras@solidboot.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

Powered by JetHome