[PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR

[Huang Shijie]

On Thu, Dec 05, 2013 at 05:43:05AM +0000, Gupta, Pekon wrote:
> >From: Huang Shijie [mailto:b32955 at freescale.com]
> >
> >>于 2013年12月04日 23:36, Marek Vasut 写道:
> >> I disagree we should bloat the API with features, that will be used by "possible
> >> future controllers" or "possible single controller", right from the start. The
> >> real question here is, can the API be designed in such a way, that the SR
> >> polling will happen in software NOW and only when a controller appears that can
> >> do polling in HW will the API be extended to support it ?
> >ok. Let's add this feature in the future when a real case occurs.
> >
> Sorry got lost.. Can you please summarize following plans for your next patch:
> 
> (1) Polling of status registers should be 
>   (a) done in S/W (generic driver)
>   (b) done controller driver, which can be optimized for specific hardware
> 
For (b), we can implement the @wait_till_ready hook for the controller driver.

For (a), we use the default hook for @wait_till_ready.



> (2) How do you plan to have timeout value, (as serial flash can be pretty slow
>    to access) ?
>   (a) independent for each access
>        - read timeouts per sector, which can be multiplied with read_len/sector_size
>        - write timeout per sector, which can be multiplied with write_len/sector_size
>        - erase timeout per block, which can be multiplied with erase_len/block_size
>   (b) Any other method, or leave it to controller driver ?
> 

Since i have no idea about this kind of spi-nor controller, so I prefer the (b). 

> In my view, before proceeding to writing down a patch, I think
> we should come-up with a doc/Readme, which defines all API and interface
> structs (taking Angus' proposal as baseline). And then refine that spec first.
> Otherwise there may be too many revisions spent on patch RFC's .. 
> 
> Any thoughts ?
> And is there a space in kernel_docs for such specs ?

maybe the best solution is I send out the new version as soon as possible.

thanks
Huang Shijie