[PATCH v4] mtd: spi-nor: Add support for sst26vf032b flash

[Michael Walle]

Hi,

>> Mhh, this flash has vendor tables. The sst26vf global unlock should
>> be discoverable. There is a table with all supported opcodes, which
>> could be used to see whether this flash needs the global unlock.
> 
> Is this logic already existing in the core?

No unfortunately not.

> Do you have a pointer?

It seems that we'd need to have some kind of parser support for
vendor specific SFPD tables. Then look for the sst25vf family
and the availability of the global unlock command, if both is
satisfied, set the locking ops.

>> I'd like to push as much as possible into auto-discovering
>> features.. after working on that flash db cleanup.
> 
> I understand, but as I said, testing latest versions of the kernel on
> my hardware is not straightforward.
> 
>> > Changes in v3:
>> > * Dropped the second patch (untested changes as advised by Tudor).
>> > * Avoided playing with locking as I cannot test it either: simplified
>> >   the diff by just using the PARSE_SFDP flag.
>> > * Rebased on top of -rc1 and adapted the patch to the current state.
>> >
>> >  drivers/mtd/spi-nor/sst.c | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
>> > index 688eb20c763e..414ee4692fd1 100644
>> > --- a/drivers/mtd/spi-nor/sst.c
>> > +++ b/drivers/mtd/spi-nor/sst.c
>> > @@ -111,6 +111,10 @@ static const struct flash_info sst_nor_parts[] = {
>> >  			      SPI_NOR_QUAD_READ) },
>> >  	{ "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32)
>> >  		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ) },
>> > +	{ "sst26vf032b", INFO(0xbf2642, 0, 0, 0)
>> > +		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> > +		PARSE_SFDP
>> > +		.fixups = &sst26vf_nor_fixups },
>> >  	{ "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128)
>> >  		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> >  		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
>> 
>> Honestly, this is such a mess. There are three identical chips:
>> sst26v016b, 032b and 064b and all have different flags :(
> 
> I only have the 32b variant, but I believe they are all identical. The
> FLAGS and fixups fields are missing from the 16b variant in mainline
> but they are all identical in the linux4microchip repository, I believe
> the missing patches have never been upstreamed, that's all.
> 
> And I am now using the PARSE_SFDP flag as advised because it works, but
> initially I wanted to keep the hardcoded flags.

Ah sorry, I was just stating a fact, not criticizing your patch. There
are also other places in the flash_info db with such a mess. But with
the current rule "not to touch anything untested" I guess that is
what we get. Funny enough, vendor trees seem to fix 'em.

-michael