Re: [PATCH v3 7/8] nand: spi: Add generic SPI controller support

[Boris Brezillon <boris.brezillon@free-electrons.com>]

+Cyrille and Marek.

On Mon, 20 Mar 2017 12:58:26 +0800
Peter Pan <peterpansjtu@gmail.com> wrote:

> Hi Boris and Arnaud,
> 
> On Sat, Mar 18, 2017 at 1:48 AM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > On Fri, 17 Mar 2017 18:32:28 +0100
> > Arnaud Mouiche <arnaud.mouiche@gmail.com> wrote:
> >  
> >> On 17/03/2017 15:20, Boris Brezillon wrote:  
> >> > [...]
> >> > Should be done before calling spinand_detect(), just in case some DT
> >> > props need to be parsed before the detection step.
> >> >
> >> > This being said, I'm not sure we should let the spinand controller
> >> > driver do the registration step. I'm currently trying to rework the
> >> > parallel NAND framework to act like all other busses, and I think SPI
> >> > NAND controllers should also follow this road:
> >> >
> >> > 1/ spinand controller driver register a controller to the spinand core
> >> >    (spinand_controller_register())
> >> > 2/ the core parses the DT (or board info if DT is not available) and
> >> >     creates N spinand devices (the N value depends on the number of SPI
> >> >     nands connected to the controller)
> >> > 3/ for each spinand device the detection/initialization takes place
> >> >     directly in the core (the spinand_controller_ops should contain
> >> >     anything required to do the detection)
> >> > 4/ for each spinand dev the spinand_controller_ops->add() is called, to
> >> >     let the controller driver attach private data to the device (if
> >> >     required), and/or let it use it's own ECC engine (optional as well).
> >> > 5/ underlying MTD device registered by spinand core code and spinand
> >> >     dev added to the list of devices controlled by this controller (done
> >> >     in the core)
> >> >
> >> > When removing a device, you just have the reverse steps:
> >> >
> >> > 1/ remove from list and unregister the MTD dev
> >> > 2/ call spinand_controller_ops->remove()
> >> > 3/ core/manufacturer cleanup
> >> >
> >> > Not sure how feasible this is, especially for the generic SPI NAND
> >> > controller case where the SPI NAND controller does not have a node in
> >> > the DT, but that would avoid all this boiler-plate duplication we have
> >> > in the // NAND framework.  
> >>
> >> Since the probe for generic spi devices is generally triggered by the
> >> SPI layer, it will not match easily in the way you would like the
> >> registration done.  
> >
> > That's true, but I think we can find something to handle this case.
> >  
> >> Can we let this registration question not be a showstopper for Peter's
> >> effort ?  
> >
> > Sure, I was just thinking out loud.  
> 
> Excellent idea, It's a quite big change, Let me try to how far I can go in v4.

Let's keep that for later. Also, can you wait a bit before sending a
v4, I know Cyrille wanted to comment on the SPI/dual-SPI/quad-SPI
handling. Actually, I'd like to have feedback from both SPI NOR
maintainers (Cyrille and Marek), can you Cc them in your next version?