linux-kernel - Re: [PATCH] Configure FSL eSPI CSBEF, CSAFT, and whether to send all received data to user

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] [day] [month] [year] [list]

Message-ID: <20140416172830.GV12304@sirena.org.uk>
Date:	Wed, 16 Apr 2014 18:28:30 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Jane Wan <Jane.Wan@...nspeed.com>
Cc:	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"Emilian.Medve@...escale.com" <Emilian.Medve@...escale.com>,
	"kenth.eriksson@...nsmode.com" <kenth.eriksson@...nsmode.com>,
	"thomas.de.schampheleire@...il.com" 
	<thomas.de.schampheleire@...il.com>,
	"b48286@...escale.com" <b48286@...escale.com>,
	"jg1.han@...sung.com" <jg1.han@...sung.com>,
	"sr@...x.de" <sr@...x.de>, Insop Song <Insop.Song@...nspeed.com>,
	"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH] Configure FSL eSPI CSBEF, CSAFT, and whether to send all
 received data to user

On Wed, Apr 16, 2014 at 04:39:47PM +0000, Jane Wan wrote:
> On Mon, Apr 14, 2014 at 09:51:56PM +0100, Mark Brown wrote:

> > > +		if (spi_raw_rxdata_to_user[m->spi->chip_select])
> > > +			espi_trans->len = n_tx;
> > > +		else
> > > +			espi_trans->len = trans_len + n_tx;

> > Why is there even an option for the buggy behaviour?

> We have three devices attached to the FSL eSPI interface, with chip select (CS) 
> 0-2. The device driver for the device at CS #2 requires to know all the data that 
> the slave device put on MISO.  But the device drivers for the other two devices 
> (at CS #0 and #1) work with the existing FSL eSPI driver.  The device at CS #0 is 
> Micron n25q512a compatible.

> We make the FSL eSPI driver configurable through device tree.  If we make a fix 
> without the DT option, the fix will break other device drivers working with the 
> existing FSL eSPI driver.

> Could this still be considered as a solution?  If this is ok, I can send it as a separate 
> patch.  Otherwise, we will look if this driver can be modified without DT option.

No, this is completely unaceptable.  The drivers relying on the buggy
behaviour are broken and must be fixed.  The whole point of DT is to
describe the hardware, not to allow the OS to implement workarounds for
itself.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)