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

[Miquel Raynal]

Hi Michael,

michael at walle.cc wrote on Tue, 08 Aug 2023 10:35:08 +0200:

> 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.

Do you mind if we actually take that one which, on this regard should
be absolutely identical to the existing 64b entry?

If one ever brings the logic you described I'll be pleased to test it
as long as I have the board.

> >> 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.

;-)

Thanks,
Miquèl