[PATCH v2 05/35] mtd: spi-nor: Introduce Manufacturer ID collisions driver

[Tudor.Ambarus at microchip.com]

On 10/24/21 8:44 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am 2021-07-27 06:51, schrieb Tudor Ambarus:
>> 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,
>> 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.
> 
> Btw. how will this work in practice? Let's say we have a flash of a
> "bad" manufacturer B which is using the manufacturer id of another
> "good" manufacturer G. Now flashes of B are added to the kernel.
> 
> Some kernel versions later G releases a flash of which uses the exact
> same id. How can we now add support for this flash now? If we can
> differentiate at runtime, fine. But what if not? Will then
> the legitimate owner of the ID will need a new compatible string?
> 

Yes, in order to not break support for the first flash added.

Cheers,
ta