linux-kernel - Questions on mmc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ba4215e10904150213o628cc9d1ke80bd6dd9bfad089@mail.gmail.com>
Date:	Wed, 15 Apr 2009 11:13:44 +0200
From:	Martin Fuzzey <mfuzzey@...il.com>
To:	pierre@...man.eu
Cc:	Sascha Hauer <s.hauer@...gutronix.de>, linux-kernel@...r.kernel.org
Subject: Questions on mmc_test suite

Hi,
I'm currently updating the mxcmmc driver for the i.MX21 platform
[patches have been posted to the arm list] and have a couple of
questions about the test suite.

1) I'm getting an error on testcase 10 (weird reads) which does reads
of 3 to 512 bytes by steps of 7.
Modifying the test so it continues in case of error shows that it
_only_ fails on the 395 byte read.

It fails with a software timeout (-110)
The card sends the same response to CMD17 (READ_SINGLE_BLOCK) as the
reads that work
but hardware never indicates transfer complete.

Changing the test to start at 395 makes it fail immediately (so not
dependent on previous reads).
Has anyone seen this before?

2) I'm getting "Warning: Host did not wait for busy state to end" on
the multiblock write tests (Tests 5 and 13) but they still pass.
Seems to be timing related since this doesn't occur with MMC debugging enabled.
My understanding of this is that the driver should wait for the
hardware to stop signalling busy on the data line (response R1b) after
sending
command 12 (stop transmission) before replying - is this correct?
However the MX2 SDHC doesn't have a register for this.

Should I:
a) ignore it? [apart from the testcase warning everything seems to work]
b) try reading the data line as GPIO  - seems a bit of a hack
c) issue CMD13 (SEND_STATUS) from the driver to poll the card  - seems
to be the wrong layer.

If b) is the way to go how long can the delay be - is polling
acceptable or must it be interrupt driven?

Regards,

Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/