[U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.

[U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.

[Yauhen Kharuzhy]

Cards which are not compatible with SD 2.0 standard, cat return response
for CMD8 command, but it will be invalid in terms of SD 2.0. We should
accept this case as admissible.

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
 drivers/mmc/mmc.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 596e052..b284030 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -870,10 +870,6 @@ int mmc_init(struct mmc *mmc)
 	/* Test for SD version 2 */
 	err = mmc_send_if_cond(mmc);
 
-	/* If we got an error other than timeout, we bail */
-	if (err && err != TIMEOUT)
-		return err;
-
 	/* Now try to get the SD card's operating condition */
 	err = sd_send_op_cond(mmc);
 
-- 
1.6.2.4

[U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.

[Andy Fleming]

On Thu, May 7, 2009 at 5:08 AM, Yauhen Kharuzhy <jekhor@gmail.com> wrote:
> Cards which are not compatible with SD 2.0 standard, cat return response
> for CMD8 command, but it will be invalid in terms of SD 2.0. We should
> accept this case as admissible.
>
> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>


You've got a typo in the description on a key word, "cat".  Is it can't?  can?

I'm not convinced that this patch is valid.  My understanding is that
if a card receives a command it does not understand, it should not
respond.  Thus, if it responds with an error, it's an actual error.
Are you saying that some cards respond to cmd 8 that don't implement
2.0?  Because that would not totally surprise me, but would violate
not just 2.0, but 1.x, as CMD8 is reserved.  MMC cards should also not
respond to CMD8 at this stage in initialization, as they are in the
wrong state...

Andy

[U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.

[Yauhen Kharuzhy]

On Thu, May 07, 2009 at 03:13:40PM -0500, Andy Fleming wrote:
> On Thu, May 7, 2009 at 5:08 AM, Yauhen Kharuzhy <jekhor@gmail.com> wrote:
> > Cards which are not compatible with SD 2.0 standard, cat return response
> > for CMD8 command, but it will be invalid in terms of SD 2.0. We should
> > accept this case as admissible.
> >
> > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> 
> 
> You've got a typo in the description on a key word, "cat".  Is it can't?  can?
I am sorry, yes, it is 'can'.
> 
> I'm not convinced that this patch is valid.  My understanding is that
> if a card receives a command it does not understand, it should not
> respond.  Thus, if it responds with an error, it's an actual error.
> Are you saying that some cards respond to cmd 8 that don't implement
> 2.0?  Because that would not totally surprise me, but would violate
> not just 2.0, but 1.x, as CMD8 is reserved.  MMC cards should also not
> respond to CMD8 at this stage in initialization, as they are in the
> wrong state...
I just to try all my cards with my device, and every card responds to
CMD8. Probably, this is bug in the implementation of the my MMC host driver
(for Ingenic JZ4740 SoC). I compared card initialization procedure with
Linux kernel's one and found that any error is ignored in it and means
that the card is not SD 2.0 compatible.

I will re-check the host controller driver for timeout handling, but it
seems clear.

-- 
Yauhen Kharuzhy		jekhor _at_ gmail.com
			JID: jek at jabber.ru

A: No
Q: Should I quote below my post?

[U-Boot] [PATCH] mmc: Remove return from mmc_init for non SD 2.0 compatible cards.

[Andy Fleming]

On Thu, May 7, 2009 at 4:52 PM, Yauhen Kharuzhy <jekhor@gmail.com> wrote:

> On Thu, May 07, 2009 at 03:13:40PM -0500, Andy Fleming wrote:
> > On Thu, May 7, 2009 at 5:08 AM, Yauhen Kharuzhy <jekhor@gmail.com>
> wrote:
> > > Cards which are not compatible with SD 2.0 standard, cat return
> response
> > > for CMD8 command, but it will be invalid in terms of SD 2.0. We should
> > > accept this case as admissible.
> > >
> > > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
>

Applied to HEAD, with minor commit message modifications

Andy