linux-kernel - Re: [PATCH] mtd: sst25l: fix reads with broken spi-masters

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: <20110114222401.GA10504@angua.secretlab.ca>
Date:	Fri, 14 Jan 2011 15:24:01 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	H Hartley Sweeten <hartleys@...ionengravers.com>
Cc:	David Brownell <david-b@...bell.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"spi-devel-general@...ts.sourceforge.net" 
	<spi-devel-general@...ts.sourceforge.net>,
	David Woodhouse <dwmw2@...radead.org>,
	"Artem.Bityutskiy@...ia.com" <Artem.Bityutskiy@...ia.com>
Subject: Re: [PATCH] mtd: sst25l: fix reads with broken spi-masters

On Mon, Jan 10, 2011 at 04:36:50PM -0600, H Hartley Sweeten wrote:
> On Monday, January 10, 2011 3:20 PM, David Brownell wrote:
> > --- On Mon, 1/10/11, H Hartley Sweeten <hartleys@...ionengravers.com> wrote:
> > NAK.  I'm surprised you even thought to submit
> > such a clearly-wrong patch.
> >
> > The bug is in the SPI master driver, and thus
> > so should the fix be.  Or make your system use
> > the GPIO based SPI master driver.
> 
> Sorry.
> 
> The bug _is_ in the spi peripheral on the ep93xx.
> 
> Unfortunately, hardware does exist that uses the SFRMOUT signal as part of
> the chip select to access the device.  The only way to get this signal to
> do anything is by using the spi peripheral.  The SFRMOUT signal cannot be
> accessed using GPIO so the GPIO based SPI master driver is not an option.

No, David is correct.  The fault is in the master driver.  It is perfectly valid (and common) for spi peripherals to required the SS line to remain asserted over the entire transfer.  Unfortunately, it is also as common for spi master devices to not support this mode in hardware.

However, the fault is with the spi master hardware, and therefore it is the responsibility of the master driver to handle the buffering and magic required so that the transfer proceeds correctly.

g.

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