Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Tudor Ambarus <tudor.ambarus@linaro.org>]

Hi, Geert,

Sorry for the delay, I just noticed this while cleaning the patchwork log.

On 12/6/22 08:32, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Mon, Dec 5, 2022 at 5:33 PM Rob Herring <robh@kernel.org> wrote:
>> On Fri, Dec 02, 2022 at 02:56:01PM +0100, Geert Uytterhoeven wrote:
>>> On Fri, Dec 2, 2022 at 2:50 PM Michael Walle <michael@walle.cc> wrote:
>>>> Am 2022-12-02 14:37, schrieb Geert Uytterhoeven:
>>>>> Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
>>>>> FLASHes.
>>>>>
>>>>> Merge the new entries with the existing entry for MT25QU02G.
>>>>>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> ---
>>>>> mt25qu512a is already in active use, causing "make dtbs_check" errors.
>>>>> mt25qu256a is supported by the Linux spi-nor driver, but there are no
>>>>> upstream users yet.
>>>>
>>>> Is it encouraged to use the specific compatible with SPI-NOR flashes?
>>>> As far as I know it isn't. The spi-nor subsys tries hard to identify
>>>> any flashes at runtime and any additional information in the device tree
>>>> is used as a last resort (just for flashes which doesn't support the
>>>> read jedec id command yet). And usually boards have different sources
>>>> for flash chips, so hardcoding a particular part in the device tree
>>>> doesn't make sense.
>>>
>>> Thanks, I am aware there have been pushbacks when trying to
>>> document more compatible values.
>>>
>>> IMHO either all or none of them should be documented.
>>> If device-specific compatible values are discouraged, the bindings
>>> should be updated to reflect that, and document a single compatible
>>> value ("jedec,spi-nor") only.
>>
>> That's already allowed, so there's your answer.
> 
> It's indeed allowed, but the alternative is documented, too (for some
> values).
> 
>> The caveat is don't be adding them later to your DT when you find an
>> issue and new quirk properties will probably be rejected.
> 
> Adding them later to your DT when you find an issue makes no sense,
> as that breaks compatibility with older DTBs.
> 

We won't break compatibility with older DTBs if we use a list of
compatibles. First the vendor specific one which will use some quirks,
and if that's not available, have as second the generic jedec,spi-nor to
fallback to.

Cheers,
ta