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

[Rafał Miłecki]

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:
>> 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"?

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. 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.

-- 
Rafał