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

[Peter Pan <peterpansjtu@gmail.com>]

On Mon, Mar 20, 2017 at 1:56 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> +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?

Yes, Let's wait for their feed back.

Peter Pan