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

Michael Walle michael at walle.cc
Sun Oct 24 10:44:00 PDT 2021


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?

That's the only way I see how this can work.

-michael



More information about the linux-arm-kernel mailing list