[U-Boot] [RFC PATCH] sf: New SF-NOR framework

[Marek Vasut]

On Wednesday, November 12, 2014 at 01:19:02 AM, Jagan Teki wrote:
> On 12 November 2014 04:26, Marek Vasut <marex at denx.de> wrote:
> > On Tuesday, November 11, 2014 at 10:37:33 PM, Jagan Teki wrote:
> >> On 12 November 2014 02:52, Marek Vasut <marex at denx.de> wrote:
> >> > On Tuesday, November 11, 2014 at 09:50:35 PM, Jagannadha Sutradharudu
> >> > Teki
> >> > 
> >> > wrote:
> >> >> This is long lasting work that I did last few months back,
> >> >> I'm sure it's where much need now.
> >> >> 
> >> >> - spi driver: drivers/spi/fsl_qspi.c
> >> >> - flash attributes in spi_slave {} and
> >> >> - etc ...
> >> >> making spi subsystem becomes more flash specific rather operating
> >> >> as a generic spi bus. So SF-NOR divides normal spi flash operations
> >> >> through generic SPI API's(sf_spi.c) and more spi flash(sf) specific
> >> >> operations through SF NOR API's.
> >> >> 
> >> >> So the controllers those are operating more on flash needs to
> >> >> write a driver on drivers/mtd/spi/ example fsl_qspi.c
> >> >> 
> >> >> I have not tested more accuratly as of now, will come back again
> >> >> with new feature additions/removal, zynq_qspi additions and more...
> >> >> 
> >> >> Note: dm-spi ops can gets effected with this new framework
> >> >> { .ops            = &spi_flash_std_ops, } and will fix that in next
> >> >> version patches.
> >> >> 
> >> >> Signed-off-by: Jagannadha Sutradharudu Teki
> >> >> <jagannadh.teki at gmail.com>
> >> > 
> >> > I have but a general question -- why did you not just import the
> >> > spi-nor framework from Linux ?
> >> 
> >> Well, importing spi-nor from Linux is may not be a good idea as we
> >> have a working stuff
> >> at our end along with different dependencies and I'm sure this will
> >> becomes similar way as
> >> spi-nor at some point of time.
> > 
> > What you said doesn't add up to me -- you introduced a completely new
> > framework in this patch, right ? So what exact "working stuff" do we
> > have if this is a completely new code ?
> 
> Yes - this is a new framework with exiting working code by maintain sf_nor
> {} to common for spi_sf drivers and flash based drivers.
> 
> Not completely new code, It's a re-arranged proven/working existing
> code, please understand this.
> re-arranged as we have an issue with spi is handling more flash stuff.

OK, I will not argue about which one is more proven, that's not the point here.

> > Compared to that, the SPI NOR framework in Linux is being actively
> > maintained and actively used for a while now, so it's actually a proven
> > code already. Also, we just recently resynced MTD subsystem with Linux,
> > adding the SPI NOR framework which is based on that same MTD framework
> > would probably be pretty straighforward.
> 
> Even sf stuff in u-boot is actively maintained and code in sf and
> Linux are almost similar
> except Linux specific stuff. I don't see any point to import the Linux
> stuff as we have working
> and actively maintained stuff. By addition of this I'm sure something
> proved will not effect.

Given that the MTD code is imported from Linux, pulling in another part of
that MTD code (the SPI NOR framework) would trim down the divergence of the
codebase. This would make things easier in the long run too, since we could
then just sync with Linux and the bugfixes and new features could be simply 
imported from Linux too . It would make things easier for contributors too, 
since they won't have to learn two codebases, but just one (the linux one).

Best regards,
Marek Vasut