linux-kernel - Re: 2/5: Updates to SPI and mmc_spi: clock with cs inactive, kernel 2.6.19

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]

Message-Id: <200701251728.12119.david-b@pacbell.net>
Date:	Thu, 25 Jan 2007 17:28:11 -0800
From:	David Brownell <david-b@...bell.net>
To:	Hans-Peter Nilsson <hans-peter.nilsson@...s.com>
Cc:	dbrownell@...rs.sourceforge.net, mikael.starvik@...s.com,
	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: 2/5: Updates to SPI and mmc_spi: clock with cs inactive, kernel 2.6.19

On Wednesday 24 January 2007 8:50 pm, Hans-Peter Nilsson wrote:
> 
> There was a comment in the mmc_spi.c glue driver at
> <URL:http://www.gossamer-threads.com/lists/linux/kernel/671939#671939>:
> +                * some cards seemed happier if they were initialized first
> +                * by the native MMC stack, not SPI ... and in other cases
> +                * rmmod/modprobe of mmc_spi helped the card work better,
> +                * even without power cycling
> +                *
> +                * FIXME find out what that important state is, which is
> +                * not reset here... and makes robustness problems
> 
> I think I've spotted the problem, or at least a problem with a
> solution that fits the description.  What's missing is "at least
> 74 SD clocks to the SD card with keeping CMD line to high. In
> case of SPI mode, CS shall be held to high during 74 clock
> cycles" (from Section 6.4.1, in "Simplified Physical Layer
> Specification 2.0"). ...
> 
> The gotcha is that the SPI framework didn't have a way to
> express transfers with chip-select inactive.  Sure, you can set
> chip-select to inactive for a period of *time*, but never while
> also toggling the clock. 

Actually it _does_ have a way to handle it, if you think about the
problem a bit differently ... focus on high/low, not "inactive":

	spi->mode |= SPI_CS_HIGH;
	spi_setup(spi);
	// chipselect is now low (conventionally active)

	// ... then high during this next transfer:
	... write 74+ zero bits (10+ bytes)
	// now low again (conventionally "active")

	spi->mode &= ~SPI_CS_HIGH;
	spi_setup(spi);	
	// now high (conventionally "inactive")

That is, for just one one transfer, say the device uses inverse
chipselect polarity:  active-high, not active-low.  Then back to
normal.  Right?  So long as nobody else can access that SPI bus
(the claim/release issue), all should be fine.

That mechanism has been defined for some time, but not widely
implemented; a few chips rquite that semantic for chipselect in
normal operation.

If you agree on this, please update your patch #4 accordingly.
You may need to update your SPI controller driver to handle this
issue too.  (ISTR punting on making the bitbang framework handle
it, but so long as the chipselect is managed with a GPIO this
ought to be almost trivial.)

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