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

[Brian Norris]

On Mon, Dec 01, 2014 at 10:49:28AM +0100, Rafał Miłecki wrote:
> On 1 December 2014 at 09:40, Brian Norris <computersforpeace at gmail.com> wrote:
> > I think this is a good time to consider this question: how do we
> > *really* want a SPI NOR driver to interact with spi-nor.c, regarding
> > device detection? I like how this patch removes the string-matching
> > requirement, so we can just auto-detect by JEDEC RDID alone. But I don't
> > like how it leaves around the function parameter 'name', which really
> > we should really be moving to deprecate if possible.
> >
> > Anyway, I can take a rebased version of this patch. But I'd like to
> > encourage more thought here for the future. I don't yet have a specific
> > proposal, so any thoughts are welcome.
> 
> My purpose is to make use of auto-detect by RDID wherever possible. As
> you noticed, it's the first step. Now we should modify m25p80 to use
> it when possible.
> 
> 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"?

> I'm not exactly sure how m25p80 is handled when used in DT. Does
> anyone know that? m25p80 itself doesn't register as DT driver. So I
> guess there is some code translating DT m25p80 entries into platform
> data. Is that right? Where is this code located?

m25p80.c is a SPI device driver, and it gets probed via the kernel bus
infrastructure. See spi_match_device().

Brian