[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131118133940.GC14306@sirena.org.uk>
Date: Mon, 18 Nov 2013 13:39:40 +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 09:32:29AM +0000, Lee Jones wrote:
> I've actually travelled down the route of separating the SPI
> Controller parts to drivers/spi. It's possible to do that and perhaps
> we could then use the generic m25p80 Serial Flash driver as the
> back-end, but it would be incredibly complicated and would mean we'd
> need to duplicate almost all of the m25p80 driver into the SPI
> Controller. The Falcon SPI driver tried to do something similar, but
> now looks broken due to some incompatible changes in m25p80. We also
> want to avoid putting ourselves in that position of fragility.
What I've said to people doing similar drivers before is that it seems
like there should be an abstraction added in the MTD framework for SPI
flash controllers like this is that if there is genunie flash-specific
stuff going on then the mp25p80 driver ought to be split so that the
code that understands what commands to send to the flash chip is split
out from the code that actually sends those commands to the chip. The
existing SPI support would then be a function driver for this. This
would mean we don't need to support the flash chips multiple times.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists