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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ