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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 18 Nov 2013 17:32:01 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Mark Brown <broonie@...nel.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, 18 Nov 2013, Mark Brown wrote:

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

We could do that, although I'd have to insist on extending the current
framework to add a configuration call-back, as it's the neatest way to
configure chip specific attributes.

I can get a patch out tomorrow if the MTD guys agree. Where are they
by the way? I haven't seen hide nor hair of them since sending out the
patch set.

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

I agree.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/