Re: [PATCH v3] mtd: spi-nor: add dt support for Everspin MRAMs

[Cyrille Pitchen <cyrille.pitchen@atmel.com>]

Le 17/01/2017 à 14:16, Rafał Miłecki a écrit :
> On 17 January 2017 at 12:03, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
>> The MR25 family doesn't support JEDEC, so they need explicit mentioning
>> in the list of supported spi IDs. This makes it possible to add these
>> using for example:
>>
>>         compatible = "everspin,mr25h40";
> 
> (...)
> 
>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> index 2c91c03e7eb0..3e920ec5c4d3 100644
>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> @@ -14,6 +14,8 @@ Required properties:
>>                   at25df641
>>                   at26df081a
>>                   mr25h256
>> +                 mr25h10
>> +                 mr25h40
>>                   mx25l4005a
>>                   mx25l1606e
>>                   mx25l6405d
> 
> Uh, this is getting a never-ending-story...
> If these chipsets don't support JEDEC, should we keep them in jedec,spi-nor.txt?
> 

Maybe not but I think the new compatible strings should be documented
somewhere. Currently jedec,spi-nor.txt already documents all the
"m25p*-nonjedec" memories. So maybe just renaming the jedec,spi-nor.txt
file into spi-nor.txt or mtd,spi-nor.txt could be a solution. Otherwise, we
can let it as is. I have no idea of what would be the best solution.

To be honest, I don't always fully understand the DT policy/philosophy and
its requirements. I just thought when a new property or a new value is
introduced it has to be documented.
Generally speaking, when DT is involved in some series of patches, it often
generates many discussions about the proper way to do thinks and about
choosing the best between many technically functional solutions.

If you think jedec,spi-nor.txt is not suited to document the new value for
the compatible string, why not, I perfectly understand your point.

I don't mind choosing another way. I just want to be sure that, if not all,
most of people agree on that solution and if possible, it is compliant with
DT policy so everybody is happy and works together.
That's why I involve DT people, even if it's a small detail, so they can
advise us.

Anyway, at some point we have to take a decision to carry on thinks.
So actually, I would like to avoid a never-ending story :)