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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 18 Feb 2008 23:49:18 +0100
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	David Brownell <david-b@...bell.net>
Cc:	spi-devel-general@...ts.sourceforge.net,
	Atsushi Nemoto <anemo@....ocn.ne.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: [spi-devel-general] atmel_spi clock polarity

On Mon, 18 Feb 2008 11:57:56 -0800
David Brownell <david-b@...bell.net> wrote:

> On Monday 18 February 2008, Atsushi Nemoto wrote:
> > 	 IIRC the clock state follows
> > CSRn.CPOL just before the real transfer.
> 
> No ... clock state should be valid *before* chipselect goes
> active.  So I'm thinking the patch from Haavard is likely
> the right change.

Hopefully it is...

> > CLK     ______________________|~|___|~~~|___|~~~|___|~~~|___
> 
> ... and at T1 CPOL is changed??  That's wrong.  There should
> never be a partial clock period while a chipselect is active.
> While it's inactive, sure -- no chip should care.

...but what I'm afraid of is that since we're using GPIO chipselects,
the controller may _think_ that no chip is selected and change the
clock polarity just before it would pull the chipselect low if we were
using automatic chipselects...

If that's the case, it would be a bit strange if it actually helped to
initialize all the CSRn registers, but it would also offer us a nice
workaround...

Atsushi, do you by any chance have debugging enabled? That would
explain the long delay from CS activation to the change of clock
polarity. Compared to printk() the DMA setup takes almost no time at
all.

If you can confirm that my patch helps, I think that's the one we want
in mainline.

Haavard
--
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