linux-kernel - Re: [RFC] pata

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 9 Apr 2007 11:25:06 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jeff Garzik <jgarzik@...ox.com>
Subject: Re: [RFC] pata_icside driver

> The timings the drive sees clearly are not based upon a 16MHz clock
> period.  Therefore, I'd prefer to get the nanoseconds from the
> calculation and work from that.

Makes sense.

> Obviously I can demonstrate a bug. 8)
> 
> Lets say that we want to do MW DMA mode 2.  This has the minimum timing
> of 70ns active, 25ns recovery, 120ns cycle time.

Well it depends on the drive id data but assuming the defaults yes

> When you quantise those figures using a clock period of 62.5ns (16MHz)
> you end up with: 2 clocks active (2*62.5 > 70), 1 clock recovery
> (1*62.5 > 25) and 2 clocks cycle (2*62.5 > 120).
> 
> Last time I checked, active + recovery must always be equal to the cycle
> time, and unless my math is failing me, 2 + 1 does not equal 2.

The libata code does the following:

        if (t->active + t->recover < t->cycle) {
                t->active += (t->cycle - (t->active + t->recover)) / 2;
                t->recover = t->cycle - t->active;
        }

which probably means for 16MHz you don't have enough resolution to be sure
you'll error in this direction in all cases. If so you just need to try
adding

	if (t->active + t->recover > t->cycle)
		t->cycle = t->active + t->recover

to stretch the cycle time to fit the resolution as well.

And we should get this tested/fixed by someone seeing the problem, before
and instead of putting hacks/notes in drivers that may then get lost

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