linux-kernel - Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

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]

Date:	Thu, 4 Jun 2015 17:15:12 +0200
From:	Marek Vasut <marex@...x.de>
To:	Michal Suchanek <hramrach@...il.com>
Cc:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	Kukjin Kim <kgene@...nel.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Han Xu <han.xu@...escale.com>, Mark Brown <broonie@...nel.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Rafał Miłecki <zajec5@...il.com>,
	Alison Chaiken <alison_chaiken@...tor.com>,
	Huang Shijie <b32955@...escale.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Knut Wohlrab <knut.wohlrab@...bosch.com>,
	"Bean Huo 霍斌斌 (beanhuo)" 
	<beanhuo@...ron.com>, "grmoore@...era.com" <grmoore@...era.com>,
	devicetree <devicetree@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-samsung-soc" <linux-samsung-soc@...r.kernel.org>,
	dmaengine <dmaengine@...r.kernel.org>,
	linux-mtd@...ts.infradead.org,
	"linux-spi" <linux-spi@...r.kernel.org>
Subject: Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

On Thursday, June 04, 2015 at 06:31:45 AM, Michal Suchanek wrote:
> On 4 June 2015 at 01:03, Marek Vasut <marex@...x.de> wrote:
> > On Wednesday, June 03, 2015 at 11:26:41 PM, Michal Suchanek wrote:
> >> On sunxi the SPI controller currently does not have DMA support and
> >> fails any transfer larger than 63 bytes.
> >> 
> >> On Exynos the pl330 DMA controller fails any transfer larger than 64kb
> >> when using slower speed like 40MHz and any transfer larger than 128bytes
> >> when running at 133MHz.
> > 
> > This smells more like some corruption of the data on the bus or something
> > even more obscure.
> 
> If the data was corrupted you would get corrupted data and not
> transfer failure. AFAIK there is no checksum or anything. I actually
> do get corrupted data when I use wrong feedback delay setting.

OK

> >> The best thing is that in both cases the controller can just lock up and
> >> never finish potentially leaving the hardware in unusable state.

[...]

> >> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> 
> >> @@ -19,6 +19,12 @@ Optional properties:
> >>                     all chips and support for it can not be detected at
> >> 
> >> runtime. Refer to your chips' datasheet to check if this is supported by
> >> your chip.
> >> +- linux,max_tx_len : With some SPI controller drivers possible transfer
> >> size is +                     limited. This may be hardware or driver
> >> bug. +                     Transfer data in chunks no larger than this
> >> value. +
> >> 
> >>                     Using this option may severely degrade performance
> >>                     and
> >> 
> >> +                     possibly flash memory life when max_tx_len is
> >> smaller than +                     flash page size (typically 256 bytes)
> > 
> > Will we need similar patch for all other SPI slave drivers, like SPI NAND
> > ?
> 
> Probably. Some SPI slave drivers already do have similar option.

So the SPI device drivers are implementing workarounds for buggy SPI hosts,
even if those SPI devices themselves don't suffer from such limitations. Yes,
this seems like the seriously wrong thing to do.

> In general it cannot be expected that you can reliably transfer
> arbitrarily large data over SPI it seems.

This is what should be expected because this is how the bus is supposed
to work in fact. You can transfer an arbitrary amount of data over SPI
bus.

If some driver has a limitation, it's that (bus, dma) driver which needs
to implement a fix or a workaround.

> However, if the nand driver transfers data a page at a time it should
> be fine.

... until someone issues multi-block read, in which case it all falls
down like a house of cards. It is impossible to build a reliable system
on "should" and similar assumptions ; the driver must be solid.

Best regards,
Marek Vasut
--
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/