From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] mmc tests incorrectly implemented
Date: Wed, 10 Apr 2019 13:22:10 -0400 [thread overview]
Message-ID: <20190410172210.GV4664@bill-the-cat> (raw)
In-Reply-To: <0a90f1fb-607a-6227-f079-206ae957420c@wwwdotorg.org>
On Wed, Apr 10, 2019 at 11:13:32AM -0600, Stephen Warren wrote:
> On 4/10/19 10:23 AM, Marek Vasut wrote:
> > On 4/10/19 5:12 PM, Stephen Warren wrote:
> >
> > Hi,
> >
> > it would be nice if I was CCed on this.
>
> Sorry, I didn't drill down in Jenkins/git data to find out where the
> commits came from; I just had a list of commit descriptions and knew
> which branch they showed up in,
>
> >> I see that some mmc tests have been added to test/py, but I see problems
> >> with them:
> >>
> >> 1) test_mmc_rescan assumes that each entry in env__mmc_rd_configs is a
> >> separate device that can be rescanned. This isn't actually true; entries
> >> in that array are intended to drive the mmc read test, and so can point
> >> at partitions or specific sector numbers.
> >
> > Is that documented somewhere ? I assumed they are separate devices and
> > if you need to test multiple partitions, you will have multiple entries
> > in this array, one for each device:partition pair.
>
> There is an example in a comment at the top of test_mmc_rd.py, since
> that's what is intended to use this data. Admittedly, it doesn't
> explicitly spell out that the data array is intended for sole use by
> that test, but I assumed it was obvious enough since the array was named
> after the test and only used/mentioned in that one tests.
>
> >> Running an mmc rescan test on
> >> the entire array results in duplicated tests. A new data array should be
> >> created for different tests.
> >
> > I don't have such a usecase, but the fix should be easy to implement.
> > Can you do that ?
>
> Surely you have a use-case for the new test, or you wouldn't have
> implemented it?
>
> I'm afraid I barely have time to keep the test system running. I don't
> have time to patch up test failures in most cases. The only option I
> have available is to disable all MMC testing on my boards if that's
> what's needed to keep the test system going to other tests. Sorry.
Wait, these are running and failing on your setup? That wasn't clear,
sorry. These showed up as skips on my setup as I haven't tried to
enable them here yet.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190410/febc285b/attachment.sig>
next prev parent reply other threads:[~2019-04-10 17:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 15:12 [U-Boot] mmc tests incorrectly implemented Stephen Warren
2019-04-10 16:23 ` Marek Vasut
2019-04-10 16:40 ` Tom Rini
2019-04-10 17:13 ` Stephen Warren
2019-04-10 17:22 ` Tom Rini [this message]
2019-04-10 18:09 ` Stephen Warren
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=20190410172210.GV4664@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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