linux-kernel - Re: [PATCH 02/10] mtd: st_spi_fsm: Supply all register address and bit logic defines

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131118172243.GO2674@sirena.org.uk>
Date:	Mon, 18 Nov 2013 17:22:43 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	angus.clark@...com
Subject: Re: [PATCH 02/10] mtd: st_spi_fsm: Supply all register address and
 bit logic defines

On Mon, Nov 18, 2013 at 04:02:26PM +0000, Lee Jones wrote:
> On Mon, 18 Nov 2013, Mark Brown wrote:

> > Like I say I'm suggesting that the bit of the code that understands the
> > flash chip is separate to the bit of code that knows the mechanics of
> > sending commands and data to the chip.

> The issue is that almost the entire driver is controller side. The
> only bits that are the same (and not in all cases) are the OPCODEs,
> but they are one liners (21 lines out of 1153). Most of the
> controllers which use this stuff could reuse quite a bit of the m25p80
> driver as they just write the message containing the OPCODE as the
> m25p80 driver sets it up, but that's simply not the case with our
> controller. We would have to pull the OPCODE out and based on which
> one it is, we'd have to build our own message.

OK, so then perhaps the abstraction here is simply to export the table
with the opcodes from the m25p80 driver so that when someone comes along
and adds a new chip they can just add it there and other drivers will
get the update too.

> Put it this way, if we tried to use the m25p80 our controller driver
> would most likely be twice as large and twice as complex as it is
> currently, which is exactly the inverse of what we're trying to
> achieve here.

If we're having to add new flashes to multiple drivers I'd not say we're
winning.

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