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-next>] [day] [month] [year] [list]
Date:	Thu, 29 Apr 2010 12:11:05 -0500
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	"dedekind1@...il.com" <dedekind1@...il.com>
CC:	David Woodhouse <dwmw2@...radead.org>,
	"ryan@...ewatersys.com" <ryan@...ewatersys.com>,
	"andre@...ewatersys.com" <andre@...ewatersys.com>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] sst25l.c: simplify reading the device ManID/DevID

On Wednesday, April 28, 2010 10:37 PM, Artem Bityutskiy wrote:
> On Tue, 2010-04-20 at 18:17 -0500, H Hartley Sweeten wrote:
>> The Read-ID command will continuously output the Manufacture ID and Device ID
>> until the command is terminated by a low to high transition on the CE# pin.
>> We can take advantage of this in the sst25l_match_device routine by reading
>> both bytes in one spi_write_then_read transaction.
>> 
>> Signed-off-by: H Hartley Sweeten <hsweeten@...ionengravers.com>
>> Cc: David Woodhouse <dwmw2@...radead.org>
>> Cc: Andre Renaud <andre@...ewatersys.com>
>> Cc: Ryan Mallon <ryan@...ewatersys.com>
>
> Pushed to l2-mtd-2.6.git / dunno.

Artem,

I have discovered that the Read-Status-Register command has the same problem.
With the SST25L SPI flash chips, if the chip enable is deasserted after sending
a command that command will get aborted.

I ran across this while testing a new spi master driver for the ep93xx on an
EDB9307A dev board.  That board uses the processors SFRMOUT signal as part of
the chip select logic.  Unfortunately the ep93xx only asserts the SFRMOUT
signal as long as the spi transmit fifo contains data.  As soon as the last
bit is clocked into the receive fifo it gets deasserted.  Many of the other
ep93xx based boards have that same issue.

I have an updated patch that changes both of these into one synchronous message
which fixes the sst25l_status and sst25l_match_device functions.  These changes
should be transparent to any users of this driver.

Could you drop the current patch and I will submit the updated one for review?

Regards,
Hartley

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ