[PATCH] mtd: spi-nor: allow NULL as chip name and try to auto detect it

[Brian Norris]

On Wed, Dec 17, 2014 at 07:19:58AM +0100, Rafał Miłecki wrote:
> On 17 December 2014 at 02:15, Brian Norris <computersforpeace at gmail.com> wrote:
> > On Mon, Dec 01, 2014 at 10:49:28AM +0100, Rafał Miłecki wrote:
> >> The case with non-DT platforms is simple. There is
> >> struct flash_platform_data
> >> which contains "type". I was thinking about Introducing new type like
> >> "m25p80-rdid". What do you think about this?
> >
> > It should reflect "JEDEC RDID" in the name; it means the flash supports
> > the JEDEC opcode (0x9F), unlike some of the SST flash you've looked at.
> > I'm also not sure why it should still be tied to the m25p80 name. How
> > about "spi-nor,jedec-id" or "spi-flash,jedec-id"?
> 
> OK on "jedec-id".
> 
> However I'm not sure about this "spi-nor," because spi-not is a
> framework and it doesn't support all needed ops by itself.

No, SPI NOR is a (moderately) specific type of SPI device. It also
happens to be the name of the framework / library in
drivers/mtd/spi-nor/spi-nor.c and include/linux/mtd/spi-nor.h.

The point is that the name is descriptive of exactly what we expect of
it; it operates on the SPI bus, it's a NOR flash, and it supports the
JEDEC read ID command.

> And it
> wouldn't be clear if "spi-nor,jedec-id" should be handled by m25p80,
> fsl-quadspi, or even some different spi-nor driver.

fsl-quadspi (and other non-SPI flash drivers that may plug into
spi-nor.c) is not probed on a per flash device basis; it's probed based
on the controller compatibility (i.e., the "fsl,vf610-qspi" DT binding).
The driver then happens to use flash names when it calls into the SPI
NOR library.

As I see it, we only need to worry about true SPI devices when
considering this name. We'd need to be able to differentiate the kinds
of SPI devices which cannot be handled by m25p80.c + spi-nor.c. And as
far as I can see, that will only happen for devices which don't support
the JEDEC RDID opcode.

Brian