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:	Tue, 27 May 2008 16:42:42 -0700
From:	David Brownell <david-b@...bell.net>
To:	mgross@...ux.intel.com
Cc:	spi-devel-general@...ts.sourceforge.net,
	Jonathan Cameron <Jonathan.Cameron@...il.com>,
	linux-kernel@...r.kernel.org,
	LM Sensors <lm-sensors@...sensors.org>
Subject: Re: Accelerometer, Gyros and ADC's etc within the kernel.

On Tuesday 27 May 2008, mark gross wrote:
> 
> > > Another problem area is around SPI itself.  There are variations of
> > > device implementations around chip select polarity, clock biasing
> > > (rising,falling, or midpoint) sampling from one SPI part to the next.
> > 
> > Midpoint?  That's not one I've come across before.  All four
> > standard SPI clock/sample/shift modes are already supported
> > in the SPI framework though.  Ditto active-high chipselects
> > (vs normal active-low) etc.
> 
> Yeah, its one of the sampling modes for the PIC18F4455 its one of the
> master mode sampling options  (see page 194 of
> http://ww1.microchip.com/downloads/en/DeviceDoc/39632D.pdf )

Actually figure 19-3 (p. 198) may be a bit more clear.

Curious.  That PIC18F controller has *three* bits ... equivalents
of CPOL and CPHA, plus a bit saying whether to wait a whole or
half clock after the leading clock edge before sampling it.

A quick survey of some other SPI chips suggests that the most
conventional interpretation is to sample on the trailing edge
of the clock, and not presume long hold times.

I would surely hope the SPI interface spec doesn't have to get
into the mess of timing variations which typify anyone trying to
make memory controllers do the Right thing ... *shudder* ...

- Dave


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