Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Brian Norris]

+ others

On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:
>    Hi All,

Hi Yao,

I'm not that interested in handling private requests, and this is
generally informative, so I've added the linux-mtd list, as well as the
other maintainers.

Also, when you're ready to send patches, make sure you use plain text
instead of HTML email.

>    I’m trying to add the QSPI NAND support in MTD.
> 
>    But I have reached a junction, could you please take some minutes and
>    give me some suggestions?
> 
> 
>    You know, we have the QSPI NOR support in
>    drivers/mtd/spi-nor/spi-nor.c,
> 
>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
>    and erase is different with SPI-NOR.

How similar is the controller hardware? Does your IP support standard
SPI protocol, or is it specialized for accelerating SPI NAND (e.g.,
memory-mapped, DMA, etc.)? Does it support SPI NOR?

>    So I have two ways to add QSPI-NAND:

I'll leave your options intact below, but I don't think either of them
are that good. SPI NOR and SPI NAND are different enough, I doubt that
we'll get much benefit from using the same framework, unless you happen
to have IP that's designed for both NOR and NAND, yet doesn't quite do
traditional SPI.

Particularly, NAND flash has a lot of issues that NOR flash generally
does not, around bad block management and wear leveling. Also, there may
be something to share around identification/ONFI? (Not sure how similar
the implementations are there.) There's been some prior discussion about
it, and maybe one of the CC'd people can direct you toward the latest
opinions, or else you can search the archives youreself ("SPI NAND"
should turn up several results).

So the main issues would probably be around abstracting out the
bad-block-related and chip identification code so you can share code
with existing (parallel) NAND support. At least, that's what I think
based on the last time I looked at things, and I think some of the other
active maintainers had ideas along the same lines.

Brian

>    1, rename
> 
>    drivers/mtd/spi-nor/spi-nor.c
> 
>    As
> 
>    drivers/mtd/spi-flash/spi-flash.c
> 
>    And then add:
> 
>    spi_nand_erase
> 
>    spi_nand_read
> 
>    spi_nand_write
> 
>    to support QSPI NAND.
> 
> 
>    2, rename
> 
>    drivers/mtd/spi-nor/
> 
>    to
> 
>    drivers/mtd/spi-flash/
> 
>    and then add:
> 
>    drivers/mtd/spi-flash/spi-nand.c
> 
>    to support QSPI NAND.
> 
> 
>    Thanks for your suggestions, and I will send the RFC patch once I can
>    select a way.
> 
> 
>    Best Regards,
> 
>    Yao

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Boris Brezillon]

+Peter

On Mon, 7 Nov 2016 18:01:15 -0800
Brian Norris <computersforpeace@gmail.com> wrote:

> + others
> 
> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:
> >    Hi All,  
> 
> Hi Yao,
> 
> I'm not that interested in handling private requests, and this is
> generally informative, so I've added the linux-mtd list, as well as the
> other maintainers.
> 
> Also, when you're ready to send patches, make sure you use plain text
> instead of HTML email.
> 
> >    I’m trying to add the QSPI NAND support in MTD.

Yao, can you sync with Peter who is currently working on a SPI NAND
framework (which would sit in drivers/mtd/nand/spi/).

> > 
> >    But I have reached a junction, could you please take some minutes and
> >    give me some suggestions?
> > 
> > 
> >    You know, we have the QSPI NOR support in
> >    drivers/mtd/spi-nor/spi-nor.c,
> > 
> >    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
> >    and erase is different with SPI-NOR.  
> 
> How similar is the controller hardware? Does your IP support standard
> SPI protocol, or is it specialized for accelerating SPI NAND (e.g.,
> memory-mapped, DMA, etc.)? Does it support SPI NOR?
> 
> >    So I have two ways to add QSPI-NAND:  
> 
> I'll leave your options intact below, but I don't think either of them
> are that good. SPI NOR and SPI NAND are different enough, I doubt that
> we'll get much benefit from using the same framework, unless you happen
> to have IP that's designed for both NOR and NAND, yet doesn't quite do
> traditional SPI.
> 
> Particularly, NAND flash has a lot of issues that NOR flash generally
> does not, around bad block management and wear leveling. Also, there may
> be something to share around identification/ONFI? (Not sure how similar
> the implementations are there.) There's been some prior discussion about
> it, and maybe one of the CC'd people can direct you toward the latest
> opinions, or else you can search the archives youreself ("SPI NAND"
> should turn up several results).
> 
> So the main issues would probably be around abstracting out the
> bad-block-related and chip identification code so you can share code
> with existing (parallel) NAND support. At least, that's what I think
> based on the last time I looked at things, and I think some of the other
> active maintainers had ideas along the same lines.

I'm not sure identification of raw and SPI NAND is working the same
way, but that's true for the BBT. And, as Brian said, you don't interact
with NANDs the same way you do with NORs, so it should IMO stay in
different frameworks.

Now, the remaining question is, how can we share QSPI controller code
between SPI-NOR and SPI-NAND (is it really needed?)?
I guess we could have a drivers/mtd/spi-flash directory containing such
controller drivers, and then each controller would register one or
several SPI-NOR/NAND devices to the spi-nor and spi-nand frameworks.

I'm just guessing here, and I don't know enough about SPI flashes to
have a definitive opinion on this.

Ezequiel, Cyrille, Marek, what's your opinion?

Regards,

Boris

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Cyrille Pitchen]

Hi all,

Le 08/11/2016 à 09:07, Boris Brezillon a écrit :
> +Peter
> 
> On Mon, 7 Nov 2016 18:01:15 -0800
> Brian Norris <computersforpeace@gmail.com> wrote:
> 
>> + others
>>
>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:
>>>    Hi All,  
>>
>> Hi Yao,
>>
>> I'm not that interested in handling private requests, and this is
>> generally informative, so I've added the linux-mtd list, as well as the
>> other maintainers.
>>
>> Also, when you're ready to send patches, make sure you use plain text
>> instead of HTML email.
>>
>>>    I’m trying to add the QSPI NAND support in MTD.
> 
> Yao, can you sync with Peter who is currently working on a SPI NAND
> framework (which would sit in drivers/mtd/nand/spi/).
> 
>>>
>>>    But I have reached a junction, could you please take some minutes and
>>>    give me some suggestions?
>>>
>>>
>>>    You know, we have the QSPI NOR support in
>>>    drivers/mtd/spi-nor/spi-nor.c,
>>>
>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
>>>    and erase is different with SPI-NOR.  
>>
>> How similar is the controller hardware? Does your IP support standard
>> SPI protocol, or is it specialized for accelerating SPI NAND (e.g.,
>> memory-mapped, DMA, etc.)? Does it support SPI NOR?
>>
>>>    So I have two ways to add QSPI-NAND:  
>>
>> I'll leave your options intact below, but I don't think either of them
>> are that good. SPI NOR and SPI NAND are different enough, I doubt that
>> we'll get much benefit from using the same framework, unless you happen
>> to have IP that's designed for both NOR and NAND, yet doesn't quite do
>> traditional SPI.
>>
>> Particularly, NAND flash has a lot of issues that NOR flash generally
>> does not, around bad block management and wear leveling. Also, there may
>> be something to share around identification/ONFI? (Not sure how similar
>> the implementations are there.) There's been some prior discussion about
>> it, and maybe one of the CC'd people can direct you toward the latest
>> opinions, or else you can search the archives youreself ("SPI NAND"
>> should turn up several results).
>>
>> So the main issues would probably be around abstracting out the
>> bad-block-related and chip identification code so you can share code
>> with existing (parallel) NAND support. At least, that's what I think
>> based on the last time I looked at things, and I think some of the other
>> active maintainers had ideas along the same lines.
> 
> I'm not sure identification of raw and SPI NAND is working the same
> way, but that's true for the BBT. And, as Brian said, you don't interact
> with NANDs the same way you do with NORs, so it should IMO stay in
> different frameworks.
> 

I agree with Brian and Boris about separating NORs and NANDs in different
frameworks. I know this is just a detail but for instance, the current
spi-nor framework starts sending the JEDEC Read ID command 9Fh to probe
the memory. At this point, you don't know yet what memory is connected to
the SPI controller. Hence you don't even know wether it is a NAND or a NOR.
Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its
datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy
clock cycles after the op code and before reading the actual memory ID.
Those dummy cycles don't exist with SPI NOR memories.
So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.

Also, the read operation can be performed with a single (Fast) Read
command with (Q)SPI NOR memories whereas it has to be done in two steps
for QSPI NAND memories:
1 - Page Read (13h): to transfer data from array to cache
2 - Random Data Read (03h or 0Bh): to read data from the cache and
                                   transfer them on the SPI bus.

So read operations are quite different as well between NORs and NANDs.
I didn't have a look at the Page Program operation but I expect
strong differences as well.

I think there are too many differences to handle both kind of memories
with a single framework.

Best regards,

Cyrille

> Now, the remaining question is, how can we share QSPI controller code
> between SPI-NOR and SPI-NAND (is it really needed?)?
> I guess we could have a drivers/mtd/spi-flash directory containing such
> controller drivers, and then each controller would register one or
> several SPI-NOR/NAND devices to the spi-nor and spi-nand frameworks.
> 
> I'm just guessing here, and I don't know enough about SPI flashes to
> have a definitive opinion on this.
> 
> Ezequiel, Cyrille, Marek, what's your opinion?
> 
> Regards,
> 
> Boris
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Marek Vasut]

On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:
> Hi all,
> 
> Le 08/11/2016 à 09:07, Boris Brezillon a écrit :
>> +Peter
>>
>> On Mon, 7 Nov 2016 18:01:15 -0800
>> Brian Norris <computersforpeace@gmail.com> wrote:
>>
>>> + others
>>>
>>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:
>>>>    Hi All,  
>>>
>>> Hi Yao,
>>>
>>> I'm not that interested in handling private requests, and this is
>>> generally informative, so I've added the linux-mtd list, as well as the
>>> other maintainers.
>>>
>>> Also, when you're ready to send patches, make sure you use plain text
>>> instead of HTML email.
>>>
>>>>    I’m trying to add the QSPI NAND support in MTD.
>>
>> Yao, can you sync with Peter who is currently working on a SPI NAND
>> framework (which would sit in drivers/mtd/nand/spi/).
>>
>>>>
>>>>    But I have reached a junction, could you please take some minutes and
>>>>    give me some suggestions?
>>>>
>>>>
>>>>    You know, we have the QSPI NOR support in
>>>>    drivers/mtd/spi-nor/spi-nor.c,
>>>>
>>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
>>>>    and erase is different with SPI-NOR.  
>>>
>>> How similar is the controller hardware? Does your IP support standard
>>> SPI protocol, or is it specialized for accelerating SPI NAND (e.g.,
>>> memory-mapped, DMA, etc.)? Does it support SPI NOR?
>>>
>>>>    So I have two ways to add QSPI-NAND:  
>>>
>>> I'll leave your options intact below, but I don't think either of them
>>> are that good. SPI NOR and SPI NAND are different enough, I doubt that
>>> we'll get much benefit from using the same framework, unless you happen
>>> to have IP that's designed for both NOR and NAND, yet doesn't quite do
>>> traditional SPI.
>>>
>>> Particularly, NAND flash has a lot of issues that NOR flash generally
>>> does not, around bad block management and wear leveling. Also, there may
>>> be something to share around identification/ONFI? (Not sure how similar
>>> the implementations are there.) There's been some prior discussion about
>>> it, and maybe one of the CC'd people can direct you toward the latest
>>> opinions, or else you can search the archives youreself ("SPI NAND"
>>> should turn up several results).
>>>
>>> So the main issues would probably be around abstracting out the
>>> bad-block-related and chip identification code so you can share code
>>> with existing (parallel) NAND support. At least, that's what I think
>>> based on the last time I looked at things, and I think some of the other
>>> active maintainers had ideas along the same lines.
>>
>> I'm not sure identification of raw and SPI NAND is working the same
>> way, but that's true for the BBT. And, as Brian said, you don't interact
>> with NANDs the same way you do with NORs, so it should IMO stay in
>> different frameworks.
>>
> 
> I agree with Brian and Boris about separating NORs and NANDs in different
> frameworks. I know this is just a detail but for instance, the current
> spi-nor framework starts sending the JEDEC Read ID command 9Fh to probe
> the memory. At this point, you don't know yet what memory is connected to
> the SPI controller. Hence you don't even know wether it is a NAND or a NOR.
> Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its
> datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy
> clock cycles after the op code and before reading the actual memory ID.
> Those dummy cycles don't exist with SPI NOR memories.
> So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
> 
> Also, the read operation can be performed with a single (Fast) Read
> command with (Q)SPI NOR memories whereas it has to be done in two steps
> for QSPI NAND memories:
> 1 - Page Read (13h): to transfer data from array to cache
> 2 - Random Data Read (03h or 0Bh): to read data from the cache and
>                                    transfer them on the SPI bus.
> 
> So read operations are quite different as well between NORs and NANDs.
> I didn't have a look at the Page Program operation but I expect
> strong differences as well.
> 
> I think there are too many differences to handle both kind of memories
> with a single framework.

Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the
question here. If so, we'd have the same driver for both, but different
layer on top of it (handling either NOR or NAND commands). I think the
different command sets are a detail which can be handled just fine and
it should be a detail handled in separate SPI NOR and SPI NAND layers.
Just my 5 cents ...

-- 
Best regards,
Marek Vasut

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Boris Brezillon]

On Fri, 25 Nov 2016 18:11:41 +0100
Marek Vasut <marek.vasut@gmail.com> wrote:

> On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:
> > Hi all,
> > 
> > Le 08/11/2016 à 09:07, Boris Brezillon a écrit :  
> >> +Peter
> >>
> >> On Mon, 7 Nov 2016 18:01:15 -0800
> >> Brian Norris <computersforpeace@gmail.com> wrote:
> >>  
> >>> + others
> >>>
> >>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:  
> >>>>    Hi All,    
> >>>
> >>> Hi Yao,
> >>>
> >>> I'm not that interested in handling private requests, and this is
> >>> generally informative, so I've added the linux-mtd list, as well as the
> >>> other maintainers.
> >>>
> >>> Also, when you're ready to send patches, make sure you use plain text
> >>> instead of HTML email.
> >>>  
> >>>>    I’m trying to add the QSPI NAND support in MTD.  
> >>
> >> Yao, can you sync with Peter who is currently working on a SPI NAND
> >> framework (which would sit in drivers/mtd/nand/spi/).
> >>  
> >>>>
> >>>>    But I have reached a junction, could you please take some minutes and
> >>>>    give me some suggestions?
> >>>>
> >>>>
> >>>>    You know, we have the QSPI NOR support in
> >>>>    drivers/mtd/spi-nor/spi-nor.c,
> >>>>
> >>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
> >>>>    and erase is different with SPI-NOR.    
> >>>
> >>> How similar is the controller hardware? Does your IP support standard
> >>> SPI protocol, or is it specialized for accelerating SPI NAND (e.g.,
> >>> memory-mapped, DMA, etc.)? Does it support SPI NOR?
> >>>  
> >>>>    So I have two ways to add QSPI-NAND:    
> >>>
> >>> I'll leave your options intact below, but I don't think either of them
> >>> are that good. SPI NOR and SPI NAND are different enough, I doubt that
> >>> we'll get much benefit from using the same framework, unless you happen
> >>> to have IP that's designed for both NOR and NAND, yet doesn't quite do
> >>> traditional SPI.
> >>>
> >>> Particularly, NAND flash has a lot of issues that NOR flash generally
> >>> does not, around bad block management and wear leveling. Also, there may
> >>> be something to share around identification/ONFI? (Not sure how similar
> >>> the implementations are there.) There's been some prior discussion about
> >>> it, and maybe one of the CC'd people can direct you toward the latest
> >>> opinions, or else you can search the archives youreself ("SPI NAND"
> >>> should turn up several results).
> >>>
> >>> So the main issues would probably be around abstracting out the
> >>> bad-block-related and chip identification code so you can share code
> >>> with existing (parallel) NAND support. At least, that's what I think
> >>> based on the last time I looked at things, and I think some of the other
> >>> active maintainers had ideas along the same lines.  
> >>
> >> I'm not sure identification of raw and SPI NAND is working the same
> >> way, but that's true for the BBT. And, as Brian said, you don't interact
> >> with NANDs the same way you do with NORs, so it should IMO stay in
> >> different frameworks.
> >>  
> > 
> > I agree with Brian and Boris about separating NORs and NANDs in different
> > frameworks. I know this is just a detail but for instance, the current
> > spi-nor framework starts sending the JEDEC Read ID command 9Fh to probe
> > the memory. At this point, you don't know yet what memory is connected to
> > the SPI controller. Hence you don't even know wether it is a NAND or a NOR.
> > Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its
> > datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy
> > clock cycles after the op code and before reading the actual memory ID.
> > Those dummy cycles don't exist with SPI NOR memories.
> > So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
> > 
> > Also, the read operation can be performed with a single (Fast) Read
> > command with (Q)SPI NOR memories whereas it has to be done in two steps
> > for QSPI NAND memories:
> > 1 - Page Read (13h): to transfer data from array to cache
> > 2 - Random Data Read (03h or 0Bh): to read data from the cache and
> >                                    transfer them on the SPI bus.
> > 
> > So read operations are quite different as well between NORs and NANDs.
> > I didn't have a look at the Page Program operation but I expect
> > strong differences as well.
> > 
> > I think there are too many differences to handle both kind of memories
> > with a single framework.  
> 
> Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the
> question here. If so, we'd have the same driver for both, but different
> layer on top of it (handling either NOR or NAND commands). I think the
> different command sets are a detail which can be handled just fine and
> it should be a detail handled in separate SPI NOR and SPI NAND layers.
> Just my 5 cents ...

That was my feeling too, but as I said, I know almost nothing about
spi-nor/nand, so I trust people who already worked on this topic.
If we have enough code to share (everything that is storage agnostic),
then let's do that, but AFAIU, there's not much to share. And if it's
really storage agnostic, shouldn't we place that code in the spi
framework?

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Marek Vasut]

On 11/25/2016 07:35 PM, Boris Brezillon wrote:
> On Fri, 25 Nov 2016 18:11:41 +0100
> Marek Vasut <marek.vasut@gmail.com> wrote:
> 
>> On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:
>>> Hi all,
>>>
>>> Le 08/11/2016 à 09:07, Boris Brezillon a écrit :  
>>>> +Peter
>>>>
>>>> On Mon, 7 Nov 2016 18:01:15 -0800
>>>> Brian Norris <computersforpeace@gmail.com> wrote:
>>>>  
>>>>> + others
>>>>>
>>>>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:  
>>>>>>    Hi All,    
>>>>>
>>>>> Hi Yao,
>>>>>
>>>>> I'm not that interested in handling private requests, and this is
>>>>> generally informative, so I've added the linux-mtd list, as well as the
>>>>> other maintainers.
>>>>>
>>>>> Also, when you're ready to send patches, make sure you use plain text
>>>>> instead of HTML email.
>>>>>  
>>>>>>    I’m trying to add the QSPI NAND support in MTD.  
>>>>
>>>> Yao, can you sync with Peter who is currently working on a SPI NAND
>>>> framework (which would sit in drivers/mtd/nand/spi/).
>>>>  
>>>>>>
>>>>>>    But I have reached a junction, could you please take some minutes and
>>>>>>    give me some suggestions?
>>>>>>
>>>>>>
>>>>>>    You know, we have the QSPI NOR support in
>>>>>>    drivers/mtd/spi-nor/spi-nor.c,
>>>>>>
>>>>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
>>>>>>    and erase is different with SPI-NOR.    
>>>>>
>>>>> How similar is the controller hardware? Does your IP support standard
>>>>> SPI protocol, or is it specialized for accelerating SPI NAND (e.g.,
>>>>> memory-mapped, DMA, etc.)? Does it support SPI NOR?
>>>>>  
>>>>>>    So I have two ways to add QSPI-NAND:    
>>>>>
>>>>> I'll leave your options intact below, but I don't think either of them
>>>>> are that good. SPI NOR and SPI NAND are different enough, I doubt that
>>>>> we'll get much benefit from using the same framework, unless you happen
>>>>> to have IP that's designed for both NOR and NAND, yet doesn't quite do
>>>>> traditional SPI.
>>>>>
>>>>> Particularly, NAND flash has a lot of issues that NOR flash generally
>>>>> does not, around bad block management and wear leveling. Also, there may
>>>>> be something to share around identification/ONFI? (Not sure how similar
>>>>> the implementations are there.) There's been some prior discussion about
>>>>> it, and maybe one of the CC'd people can direct you toward the latest
>>>>> opinions, or else you can search the archives youreself ("SPI NAND"
>>>>> should turn up several results).
>>>>>
>>>>> So the main issues would probably be around abstracting out the
>>>>> bad-block-related and chip identification code so you can share code
>>>>> with existing (parallel) NAND support. At least, that's what I think
>>>>> based on the last time I looked at things, and I think some of the other
>>>>> active maintainers had ideas along the same lines.  
>>>>
>>>> I'm not sure identification of raw and SPI NAND is working the same
>>>> way, but that's true for the BBT. And, as Brian said, you don't interact
>>>> with NANDs the same way you do with NORs, so it should IMO stay in
>>>> different frameworks.
>>>>  
>>>
>>> I agree with Brian and Boris about separating NORs and NANDs in different
>>> frameworks. I know this is just a detail but for instance, the current
>>> spi-nor framework starts sending the JEDEC Read ID command 9Fh to probe
>>> the memory. At this point, you don't know yet what memory is connected to
>>> the SPI controller. Hence you don't even know wether it is a NAND or a NOR.
>>> Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its
>>> datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy
>>> clock cycles after the op code and before reading the actual memory ID.
>>> Those dummy cycles don't exist with SPI NOR memories.
>>> So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
>>>
>>> Also, the read operation can be performed with a single (Fast) Read
>>> command with (Q)SPI NOR memories whereas it has to be done in two steps
>>> for QSPI NAND memories:
>>> 1 - Page Read (13h): to transfer data from array to cache
>>> 2 - Random Data Read (03h or 0Bh): to read data from the cache and
>>>                                    transfer them on the SPI bus.
>>>
>>> So read operations are quite different as well between NORs and NANDs.
>>> I didn't have a look at the Page Program operation but I expect
>>> strong differences as well.
>>>
>>> I think there are too many differences to handle both kind of memories
>>> with a single framework.  
>>
>> Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the
>> question here. If so, we'd have the same driver for both, but different
>> layer on top of it (handling either NOR or NAND commands). I think the
>> different command sets are a detail which can be handled just fine and
>> it should be a detail handled in separate SPI NOR and SPI NAND layers.
>> Just my 5 cents ...
> 
> That was my feeling too, but as I said, I know almost nothing about
> spi-nor/nand, so I trust people who already worked on this topic.
> If we have enough code to share (everything that is storage agnostic),
> then let's do that, but AFAIU, there's not much to share. And if it's
> really storage agnostic, shouldn't we place that code in the spi
> framework?

Either spi framework, or some spi-flash abstraction library, yes.
I really need to look into SPI NAND asap.

-- 
Best regards,
Marek Vasut

RE: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Yao Yuan]

On 11/26/2016 01:12am, Marek Vasut wrote:
> On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:
> > Hi all,
> >
> > Le 08/11/2016 à 09:07, Boris Brezillon a écrit :
> >> +Peter
> >>
> >> On Mon, 7 Nov 2016 18:01:15 -0800
> >> Brian Norris <computersforpeace@gmail.com> wrote:
> >>
> >>> + others
> >>>
> >>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:
> >>>>    Hi All,
> >>>
> >>> Hi Yao,
> >>>
> >>> I'm not that interested in handling private requests, and this is
> >>> generally informative, so I've added the linux-mtd list, as well as
> >>> the other maintainers.
> >>>
> >>> Also, when you're ready to send patches, make sure you use plain
> >>> text instead of HTML email.
> >>>
> >>>>    I’m trying to add the QSPI NAND support in MTD.
> >>
> >> Yao, can you sync with Peter who is currently working on a SPI NAND
> >> framework (which would sit in drivers/mtd/nand/spi/).
> >>
> >>>>
> >>>>    But I have reached a junction, could you please take some minutes and
> >>>>    give me some suggestions?
> >>>>
> >>>>
> >>>>    You know, we have the QSPI NOR support in
> >>>>    drivers/mtd/spi-nor/spi-nor.c,
> >>>>
> >>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
> >>>>    and erase is different with SPI-NOR.
> >>>
> >>> How similar is the controller hardware? Does your IP support
> >>> standard SPI protocol, or is it specialized for accelerating SPI
> >>> NAND (e.g., memory-mapped, DMA, etc.)? Does it support SPI NOR?
> >>>
> >>>>    So I have two ways to add QSPI-NAND:
> >>>
> >>> I'll leave your options intact below, but I don't think either of
> >>> them are that good. SPI NOR and SPI NAND are different enough, I
> >>> doubt that we'll get much benefit from using the same framework,
> >>> unless you happen to have IP that's designed for both NOR and NAND,
> >>> yet doesn't quite do traditional SPI.
> >>>
> >>> Particularly, NAND flash has a lot of issues that NOR flash
> >>> generally does not, around bad block management and wear leveling.
> >>> Also, there may be something to share around identification/ONFI?
> >>> (Not sure how similar the implementations are there.) There's been
> >>> some prior discussion about it, and maybe one of the CC'd people can
> >>> direct you toward the latest opinions, or else you can search the archives
> youreself ("SPI NAND"
> >>> should turn up several results).
> >>>
> >>> So the main issues would probably be around abstracting out the
> >>> bad-block-related and chip identification code so you can share code
> >>> with existing (parallel) NAND support. At least, that's what I think
> >>> based on the last time I looked at things, and I think some of the
> >>> other active maintainers had ideas along the same lines.
> >>
> >> I'm not sure identification of raw and SPI NAND is working the same
> >> way, but that's true for the BBT. And, as Brian said, you don't
> >> interact with NANDs the same way you do with NORs, so it should IMO
> >> stay in different frameworks.
> >>
> >
> > I agree with Brian and Boris about separating NORs and NANDs in
> > different frameworks. I know this is just a detail but for instance,
> > the current spi-nor framework starts sending the JEDEC Read ID command
> > 9Fh to probe the memory. At this point, you don't know yet what memory
> > is connected to the SPI controller. Hence you don't even know wether it is a
> NAND or a NOR.
> > Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its
> > datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy
> > clock cycles after the op code and before reading the actual memory ID.
> > Those dummy cycles don't exist with SPI NOR memories.
> > So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
> >
> > Also, the read operation can be performed with a single (Fast) Read
> > command with (Q)SPI NOR memories whereas it has to be done in two
> > steps for QSPI NAND memories:
> > 1 - Page Read (13h): to transfer data from array to cache
> > 2 - Random Data Read (03h or 0Bh): to read data from the cache and
> >                                    transfer them on the SPI bus.
> >
> > So read operations are quite different as well between NORs and NANDs.
> > I didn't have a look at the Page Program operation but I expect strong
> > differences as well.
> >
> > I think there are too many differences to handle both kind of memories
> > with a single framework.
> 
> Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the question
> here. If so, we'd have the same driver for both, but different layer on top of it
> (handling either NOR or NAND commands). I think the different command sets
> are a detail which can be handled just fine and it should be a detail handled in
> separate SPI NOR and SPI NAND layers.
> Just my 5 cents ...
> 
> --

Yes, at least the QSPI for Freescale(NXP) can support both SPI NOR and SPI NAND.
So I think the QSPI driver can be the same, I agree with you that we can add a top 
layer for different flash.

RE: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Yao Yuan]

On 11/25/2016 02:36 AM, Boris Brezillon wrote:
> On Fri, 25 Nov 2016 18:11:41 +0100
> Marek Vasut <marek.vasut@gmail.com> wrote:
> 
> > On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:
> > > Hi all,
> > >
> > > Le 08/11/2016 à 09:07, Boris Brezillon a écrit :
> > >> +Peter
> > >>
> > >> On Mon, 7 Nov 2016 18:01:15 -0800
> > >> Brian Norris <computersforpeace@gmail.com> wrote:
> > >>
> > >>> + others
> > >>>
> > >>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:
> > >>>>    Hi All,
> > >>>
> > >>> Hi Yao,
> > >>>
> > >>> I'm not that interested in handling private requests, and this is
> > >>> generally informative, so I've added the linux-mtd list, as well
> > >>> as the other maintainers.
> > >>>
> > >>> Also, when you're ready to send patches, make sure you use plain
> > >>> text instead of HTML email.
> > >>>
> > >>>>    I’m trying to add the QSPI NAND support in MTD.
> > >>
> > >> Yao, can you sync with Peter who is currently working on a SPI NAND
> > >> framework (which would sit in drivers/mtd/nand/spi/).
> > >>
> > >>>>
> > >>>>    But I have reached a junction, could you please take some minutes
> and
> > >>>>    give me some suggestions?
> > >>>>
> > >>>>
> > >>>>    You know, we have the QSPI NOR support in
> > >>>>    drivers/mtd/spi-nor/spi-nor.c,
> > >>>>
> > >>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
> > >>>>    and erase is different with SPI-NOR.
> > >>>
> > >>> How similar is the controller hardware? Does your IP support
> > >>> standard SPI protocol, or is it specialized for accelerating SPI
> > >>> NAND (e.g., memory-mapped, DMA, etc.)? Does it support SPI NOR?
> > >>>
> > >>>>    So I have two ways to add QSPI-NAND:
> > >>>
> > >>> I'll leave your options intact below, but I don't think either of
> > >>> them are that good. SPI NOR and SPI NAND are different enough, I
> > >>> doubt that we'll get much benefit from using the same framework,
> > >>> unless you happen to have IP that's designed for both NOR and
> > >>> NAND, yet doesn't quite do traditional SPI.
> > >>>
> > >>> Particularly, NAND flash has a lot of issues that NOR flash
> > >>> generally does not, around bad block management and wear leveling.
> > >>> Also, there may be something to share around identification/ONFI?
> > >>> (Not sure how similar the implementations are there.) There's been
> > >>> some prior discussion about it, and maybe one of the CC'd people
> > >>> can direct you toward the latest opinions, or else you can search the
> archives youreself ("SPI NAND"
> > >>> should turn up several results).
> > >>>
> > >>> So the main issues would probably be around abstracting out the
> > >>> bad-block-related and chip identification code so you can share
> > >>> code with existing (parallel) NAND support. At least, that's what
> > >>> I think based on the last time I looked at things, and I think
> > >>> some of the other active maintainers had ideas along the same lines.
> > >>
> > >> I'm not sure identification of raw and SPI NAND is working the same
> > >> way, but that's true for the BBT. And, as Brian said, you don't
> > >> interact with NANDs the same way you do with NORs, so it should IMO
> > >> stay in different frameworks.
> > >>
> > >
> > > I agree with Brian and Boris about separating NORs and NANDs in
> > > different frameworks. I know this is just a detail but for instance,
> > > the current spi-nor framework starts sending the JEDEC Read ID
> > > command 9Fh to probe the memory. At this point, you don't know yet
> > > what memory is connected to the SPI controller. Hence you don't even
> know wether it is a NAND or a NOR.
> > > Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example,
> > > its datasheet claims that the JEDEC Read ID command (9Fh) requires 8
> > > dummy clock cycles after the op code and before reading the actual
> memory ID.
> > > Those dummy cycles don't exist with SPI NOR memories.
> > > So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
> > >
> > > Also, the read operation can be performed with a single (Fast) Read
> > > command with (Q)SPI NOR memories whereas it has to be done in two
> > > steps for QSPI NAND memories:
> > > 1 - Page Read (13h): to transfer data from array to cache
> > > 2 - Random Data Read (03h or 0Bh): to read data from the cache and
> > >                                    transfer them on the SPI bus.
> > >
> > > So read operations are quite different as well between NORs and NANDs.
> > > I didn't have a look at the Page Program operation but I expect
> > > strong differences as well.
> > >
> > > I think there are too many differences to handle both kind of
> > > memories with a single framework.
> >
> > Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the
> > question here. If so, we'd have the same driver for both, but
> > different layer on top of it (handling either NOR or NAND commands). I
> > think the different command sets are a detail which can be handled
> > just fine and it should be a detail handled in separate SPI NOR and SPI NAND
> layers.
> > Just my 5 cents ...
> 
> That was my feeling too, but as I said, I know almost nothing about spi-
> nor/nand, so I trust people who already worked on this topic.
> If we have enough code to share (everything that is storage agnostic), then
> let's do that, but AFAIU, there's not much to share. And if it's really storage
> agnostic, shouldn't we place that code in the spi framework?

Hi Boris and Marek,

The QSPI controller is just used to send the command to the bus.
So it will not care about the NAND or NOR.

We can have a layer like spi-nor.c to make sure which command set we should 
Support for different flash and the timing sequence for every command.
Then QSPI controller can support all the flash with that information.

I'm working on QSPI SPI-NAND, and I have checked a lot of the SPI-NAND RM, 
like Cyrille said Macronix MX35LFxGE4AB and Micron MT29F1G01ABAFDSF.
I have found that all the SPI-NAND are almost the same.

But there is some difference with SPI-NOR.

So maybe we can have two ways:
1, There is one spi-flash layer can cover all the flash's common characters, and different flash
can achieve different final operation.
Like:
If(micron_spi_nand_read)
	mtd->_read = micron_spi_nand_read;
else if (of_property_read_bool(np, "spi, nand "))
	mtd->_read = spi_nand_read;
else
	mtd->_read = spi_nor_read;

2, There are two framework for SPI-NAND and SPI-NOR.
drivers/mtd/spi-nor/spi-nor.c specially for all the SPI-NOR flash
drivers/mtd/spi-nor/spi-nand.c specially for all the SPI-NAND flash

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Boris Brezillon]

On Mon, 28 Nov 2016 05:46:10 +0000
Yao Yuan <yao.yuan@nxp.com> wrote:

> On 11/26/2016 01:12am, Marek Vasut wrote:
> > On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:  
> > > Hi all,
> > >
> > > Le 08/11/2016 à 09:07, Boris Brezillon a écrit :  
> > >> +Peter
> > >>
> > >> On Mon, 7 Nov 2016 18:01:15 -0800
> > >> Brian Norris <computersforpeace@gmail.com> wrote:
> > >>  
> > >>> + others
> > >>>
> > >>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:  
> > >>>>    Hi All,  
> > >>>
> > >>> Hi Yao,
> > >>>
> > >>> I'm not that interested in handling private requests, and this is
> > >>> generally informative, so I've added the linux-mtd list, as well as
> > >>> the other maintainers.
> > >>>
> > >>> Also, when you're ready to send patches, make sure you use plain
> > >>> text instead of HTML email.
> > >>>  
> > >>>>    I’m trying to add the QSPI NAND support in MTD.  
> > >>
> > >> Yao, can you sync with Peter who is currently working on a SPI NAND
> > >> framework (which would sit in drivers/mtd/nand/spi/).
> > >>  
> > >>>>
> > >>>>    But I have reached a junction, could you please take some minutes and
> > >>>>    give me some suggestions?
> > >>>>
> > >>>>
> > >>>>    You know, we have the QSPI NOR support in
> > >>>>    drivers/mtd/spi-nor/spi-nor.c,
> > >>>>
> > >>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
> > >>>>    and erase is different with SPI-NOR.  
> > >>>
> > >>> How similar is the controller hardware? Does your IP support
> > >>> standard SPI protocol, or is it specialized for accelerating SPI
> > >>> NAND (e.g., memory-mapped, DMA, etc.)? Does it support SPI NOR?
> > >>>  
> > >>>>    So I have two ways to add QSPI-NAND:  
> > >>>
> > >>> I'll leave your options intact below, but I don't think either of
> > >>> them are that good. SPI NOR and SPI NAND are different enough, I
> > >>> doubt that we'll get much benefit from using the same framework,
> > >>> unless you happen to have IP that's designed for both NOR and NAND,
> > >>> yet doesn't quite do traditional SPI.
> > >>>
> > >>> Particularly, NAND flash has a lot of issues that NOR flash
> > >>> generally does not, around bad block management and wear leveling.
> > >>> Also, there may be something to share around identification/ONFI?
> > >>> (Not sure how similar the implementations are there.) There's been
> > >>> some prior discussion about it, and maybe one of the CC'd people can
> > >>> direct you toward the latest opinions, or else you can search the archives  
> > youreself ("SPI NAND"  
> > >>> should turn up several results).
> > >>>
> > >>> So the main issues would probably be around abstracting out the
> > >>> bad-block-related and chip identification code so you can share code
> > >>> with existing (parallel) NAND support. At least, that's what I think
> > >>> based on the last time I looked at things, and I think some of the
> > >>> other active maintainers had ideas along the same lines.  
> > >>
> > >> I'm not sure identification of raw and SPI NAND is working the same
> > >> way, but that's true for the BBT. And, as Brian said, you don't
> > >> interact with NANDs the same way you do with NORs, so it should IMO
> > >> stay in different frameworks.
> > >>  
> > >
> > > I agree with Brian and Boris about separating NORs and NANDs in
> > > different frameworks. I know this is just a detail but for instance,
> > > the current spi-nor framework starts sending the JEDEC Read ID command
> > > 9Fh to probe the memory. At this point, you don't know yet what memory
> > > is connected to the SPI controller. Hence you don't even know wether it is a  
> > NAND or a NOR.  
> > > Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example, its
> > > datasheet claims that the JEDEC Read ID command (9Fh) requires 8 dummy
> > > clock cycles after the op code and before reading the actual memory ID.
> > > Those dummy cycles don't exist with SPI NOR memories.
> > > So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
> > >
> > > Also, the read operation can be performed with a single (Fast) Read
> > > command with (Q)SPI NOR memories whereas it has to be done in two
> > > steps for QSPI NAND memories:
> > > 1 - Page Read (13h): to transfer data from array to cache
> > > 2 - Random Data Read (03h or 0Bh): to read data from the cache and
> > >                                    transfer them on the SPI bus.
> > >
> > > So read operations are quite different as well between NORs and NANDs.
> > > I didn't have a look at the Page Program operation but I expect strong
> > > differences as well.
> > >
> > > I think there are too many differences to handle both kind of memories
> > > with a single framework.  
> > 
> > Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the question
> > here. If so, we'd have the same driver for both, but different layer on top of it
> > (handling either NOR or NAND commands). I think the different command sets
> > are a detail which can be handled just fine and it should be a detail handled in
> > separate SPI NOR and SPI NAND layers.
> > Just my 5 cents ...
> > 
> > --  
> 
> Yes, at least the QSPI for Freescale(NXP) can support both SPI NOR and SPI NAND.
> So I think the QSPI driver can be the same, I agree with you that we can add a top 
> layer for different flash.
> 

Well, I'd like to see what can be shared before taking a decision.

Re: SPI NAND support in drivers/mtd/spi-nor/spi-nor.c

[Boris Brezillon]

Hi Yao,

On Mon, 28 Nov 2016 06:57:19 +0000
Yao Yuan <yao.yuan@nxp.com> wrote:

> On 11/25/2016 02:36 AM, Boris Brezillon wrote:
> > On Fri, 25 Nov 2016 18:11:41 +0100
> > Marek Vasut <marek.vasut@gmail.com> wrote:
> >   
> > > On 11/08/2016 11:52 AM, Cyrille Pitchen wrote:  
> > > > Hi all,
> > > >
> > > > Le 08/11/2016 à 09:07, Boris Brezillon a écrit :  
> > > >> +Peter
> > > >>
> > > >> On Mon, 7 Nov 2016 18:01:15 -0800
> > > >> Brian Norris <computersforpeace@gmail.com> wrote:
> > > >>  
> > > >>> + others
> > > >>>
> > > >>> On Mon, Nov 07, 2016 at 09:53:34AM +0000, Yao Yuan wrote:  
> > > >>>>    Hi All,  
> > > >>>
> > > >>> Hi Yao,
> > > >>>
> > > >>> I'm not that interested in handling private requests, and this is
> > > >>> generally informative, so I've added the linux-mtd list, as well
> > > >>> as the other maintainers.
> > > >>>
> > > >>> Also, when you're ready to send patches, make sure you use plain
> > > >>> text instead of HTML email.
> > > >>>  
> > > >>>>    I’m trying to add the QSPI NAND support in MTD.  
> > > >>
> > > >> Yao, can you sync with Peter who is currently working on a SPI NAND
> > > >> framework (which would sit in drivers/mtd/nand/spi/).
> > > >>  
> > > >>>>
> > > >>>>    But I have reached a junction, could you please take some minutes  
> > and  
> > > >>>>    give me some suggestions?
> > > >>>>
> > > >>>>
> > > >>>>    You know, we have the QSPI NOR support in
> > > >>>>    drivers/mtd/spi-nor/spi-nor.c,
> > > >>>>
> > > >>>>    And the QSPI NAND is very similar with QSPI NOR, but the Read, write
> > > >>>>    and erase is different with SPI-NOR.  
> > > >>>
> > > >>> How similar is the controller hardware? Does your IP support
> > > >>> standard SPI protocol, or is it specialized for accelerating SPI
> > > >>> NAND (e.g., memory-mapped, DMA, etc.)? Does it support SPI NOR?
> > > >>>  
> > > >>>>    So I have two ways to add QSPI-NAND:  
> > > >>>
> > > >>> I'll leave your options intact below, but I don't think either of
> > > >>> them are that good. SPI NOR and SPI NAND are different enough, I
> > > >>> doubt that we'll get much benefit from using the same framework,
> > > >>> unless you happen to have IP that's designed for both NOR and
> > > >>> NAND, yet doesn't quite do traditional SPI.
> > > >>>
> > > >>> Particularly, NAND flash has a lot of issues that NOR flash
> > > >>> generally does not, around bad block management and wear leveling.
> > > >>> Also, there may be something to share around identification/ONFI?
> > > >>> (Not sure how similar the implementations are there.) There's been
> > > >>> some prior discussion about it, and maybe one of the CC'd people
> > > >>> can direct you toward the latest opinions, or else you can search the  
> > archives youreself ("SPI NAND"  
> > > >>> should turn up several results).
> > > >>>
> > > >>> So the main issues would probably be around abstracting out the
> > > >>> bad-block-related and chip identification code so you can share
> > > >>> code with existing (parallel) NAND support. At least, that's what
> > > >>> I think based on the last time I looked at things, and I think
> > > >>> some of the other active maintainers had ideas along the same lines.  
> > > >>
> > > >> I'm not sure identification of raw and SPI NAND is working the same
> > > >> way, but that's true for the BBT. And, as Brian said, you don't
> > > >> interact with NANDs the same way you do with NORs, so it should IMO
> > > >> stay in different frameworks.
> > > >>  
> > > >
> > > > I agree with Brian and Boris about separating NORs and NANDs in
> > > > different frameworks. I know this is just a detail but for instance,
> > > > the current spi-nor framework starts sending the JEDEC Read ID
> > > > command 9Fh to probe the memory. At this point, you don't know yet
> > > > what memory is connected to the SPI controller. Hence you don't even  
> > know wether it is a NAND or a NOR.  
> > > > Then if I take the Macronix MX35LFxGE4AB QSPI NAND as an example,
> > > > its datasheet claims that the JEDEC Read ID command (9Fh) requires 8
> > > > dummy clock cycles after the op code and before reading the actual  
> > memory ID.  
> > > > Those dummy cycles don't exist with SPI NOR memories.
> > > > So spi_nor_scan() cannot be used probe (Q)SPI NAND memories.
> > > >
> > > > Also, the read operation can be performed with a single (Fast) Read
> > > > command with (Q)SPI NOR memories whereas it has to be done in two
> > > > steps for QSPI NAND memories:
> > > > 1 - Page Read (13h): to transfer data from array to cache
> > > > 2 - Random Data Read (03h or 0Bh): to read data from the cache and
> > > >                                    transfer them on the SPI bus.
> > > >
> > > > So read operations are quite different as well between NORs and NANDs.
> > > > I didn't have a look at the Page Program operation but I expect
> > > > strong differences as well.
> > > >
> > > > I think there are too many differences to handle both kind of
> > > > memories with a single framework.  
> > >
> > > Can a QSPI controller handle both SPI NOR and SPI NAND ? That is the
> > > question here. If so, we'd have the same driver for both, but
> > > different layer on top of it (handling either NOR or NAND commands). I
> > > think the different command sets are a detail which can be handled
> > > just fine and it should be a detail handled in separate SPI NOR and SPI NAND  
> > layers.  
> > > Just my 5 cents ...  
> > 
> > That was my feeling too, but as I said, I know almost nothing about spi-
> > nor/nand, so I trust people who already worked on this topic.
> > If we have enough code to share (everything that is storage agnostic), then
> > let's do that, but AFAIU, there's not much to share. And if it's really storage
> > agnostic, shouldn't we place that code in the spi framework?  
> 
> Hi Boris and Marek,
> 
> The QSPI controller is just used to send the command to the bus.
> So it will not care about the NAND or NOR.
> 
> We can have a layer like spi-nor.c to make sure which command set we should 
> Support for different flash and the timing sequence for every command.
> Then QSPI controller can support all the flash with that information.
> 
> I'm working on QSPI SPI-NAND, and I have checked a lot of the SPI-NAND RM, 
> like Cyrille said Macronix MX35LFxGE4AB and Micron MT29F1G01ABAFDSF.
> I have found that all the SPI-NAND are almost the same.
> 
> But there is some difference with SPI-NOR.
> 
> So maybe we can have two ways:
> 1, There is one spi-flash layer can cover all the flash's common characters, and different flash
> can achieve different final operation.
> Like:
> If(micron_spi_nand_read)
> 	mtd->_read = micron_spi_nand_read;
> else if (of_property_read_bool(np, "spi, nand "))
> 	mtd->_read = spi_nand_read;
> else
> 	mtd->_read = spi_nor_read;

And that's exactly what I'd like to avoid. As we (Brian, Cyrille and I)
already mentioned, NORs and NANDs are completely different, and NAND
devices need special care. It's not just about providing a different
->_read()/->_write() implementation. You have to deal with bad blocks
(and possibly use a bad block table), ECC, and probably other things I
can't remember.

> 
> 2, There are two framework for SPI-NAND and SPI-NOR.
> drivers/mtd/spi-nor/spi-nor.c specially for all the SPI-NOR flash
> drivers/mtd/spi-nor/spi-nand.c specially for all the SPI-NAND flash
> 
> 

That's not the plan for SPI NANDs. We're planning on putting the SPI
NAND framework in drivers/mtd/nand/spi/ and putting generic NAND
helpers in drivers/mtd/nand/ (we'll start with BBT code, and extend it
with other things when needed).
See [1] if you want more details.

For code sharing between spi-flashes, I see it as a set of helpers to
be able to send commands in different spi-modes (single, dual and
quad), and maybe a generic way to express timing requirements (how many
dummy cycles should be inserted after a specific command).
But again, I'm not a SPI flash expert. Cyrille, I know you looked at
SPI NANDs. What do you think can be shared, is it worth it, and how
could we do that?

[1]https://lkml.org/lkml/2016/11/21/295