Re: [PATCH 5/7] mtd: spi-nor: Introduce Manufacturer ID collisions driver

From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <vigneshr@ti.com>, <figgyc@figgyc.uk>,
	<mail@david-bauer.net>, <linux@rasmusvillemoes.dk>,
	<esben@geanix.com>, <knaerzche@gmail.com>,
	<code@reto-schneider.ch>, <zhengxunli@mxic.com.tw>,
	<jaimeliao@mxic.com.tw>, <heiko.thiery@gmail.com>,
	<macromorgan@hotmail.com>,  <sr@denx.de>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>,
	<linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 5/7] mtd: spi-nor: Introduce Manufacturer ID collisions driver
Date: Tue, 6 Jul 2021 06:46:56 +0000	[thread overview]
Message-ID: <f4f86e38-9952-081e-4e2b-68a085839237@microchip.com> (raw)
In-Reply-To: <20210706063451.z5z5mb5z7jshifme@ti.com>

On 7/6/21 9:34 AM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 02/07/21 05:41PM, Tudor Ambarus wrote:
>> Some manufacturers completely ignore the manufacturer's identification code
>> standard (JEP106) and do not define the manufacturer ID continuation
>> scheme. This will result in manufacturer ID collisions.
>>
>> An an example, JEP106BA requires Boya that it's manufacturer ID to be
>> preceded by 8 continuation codes. Boya's identification code must be:
>> 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x68. But Boya ignores the
>> continuation scheme and its ID collides with the manufacturer defined in
>> bank one: Convex Computer.
>>
>> Introduce the manuf-id-collisions driver in order to address ID collisions
>> between manufacturers. flash_info entries will be added in a first come,
> 
> So all manufacturers with an ID collision will be placed in this file,
> and won't get a separate file of their own. Ok.

manuf-id-collisions will be the place to add new flash additions where the
manufacturer is ignorant enough to not implement the ID continuation scheme.

Collisions between flashes of the same manufacturer can be handled in their
own manufacturer driver, macronix being an example.

> 
>> first served manner. Differentiation between flashes will be done at
>> runtime if possible. Where runtime differentiation is not possible, new
>> compatibles will be introduced, but this will be done as a last resort.
>> Every new flash addition that define the SFDP tables, should dump its SFDP
>> tables in the patch's comment section below the --- line, so that we can
>> reference it in case of collisions.
> 
> Can we have this rule documented somewhere? Anyone who doesn't closely
> follow the list won't know about this rule, and having to ask for it on
> every new patch would be tedious. I am not sure if we have a place to
> document this that has high visibility though.

Yes, I thought of adding some guidelines on how to propose a new flash addition.
We can add them in Documentation/driver-api/mtd/spi-nor.rst
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/