On Mon, 18 Nov 2013, Mark Brown wrote:

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

quoted

On Mon, 18 Nov 2013, Mark Brown wrote:

quoted

quoted

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.

quoted

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.

quoted

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