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

[Peter Pan]

Hi Boris and Arnaud,

On Sat, Mar 18, 2017 at 1:48 AM, Boris Brezillon
<boris.brezillon at free-electrons.com> wrote:
> On Fri, 17 Mar 2017 18:32:28 +0100
> Arnaud Mouiche <arnaud.mouiche at 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.

Thanks,
Peter Pan