Re: [PATCH] mtd: spi-nor: Provide default address width and latency for map selection

[Boris Brezillon <boris.brezillon@xxxxxxxxxxx>]

On Mon, 3 Dec 2018 08:03:18 +0000
"Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@xxxxxxxxx>
wrote:

> Hello Boris!
> 
> On 30/11/2018 11:40, Boris Brezillon wrote:
> >> +		/*
> >> +		 * JESD216 allows to omit particular address length or latency
> >> +		 * specification in the header and at this point they are still
> >> +		 * unset, so we need some heuristics. One example is S25FS128S.
> >> +		 */
> >> +		if (!nor->addr_width)
> >> +			nor->addr_width = 3;
> >> +		if (!nor->read_dummy)
> >> +			nor->read_dummy = 8;
> >> +  
> > Looks like the same problem was reported by Yogesh here [1]. One more  
> 
> This is indeed the same problem, although I was not aware of the [1] discussion.
> 
> > proof that parsing SFDP is not trivial. I mean, what's the point of
> > defining a generic tables to describe NOR capabilities if you then
> > depend on vendor/chip specific init to read those tables...
> > 
> > Anyway, I think this sort of initialization should be placed in a
> > pre_sfdp() fixup hook, as getting the right values likely requires  
> 
> This is still on my TODO list, to learn about new hooks.

->pre_sfdp() does not exist yet, but I'm about to add it for other
reasons, and it looks like a good place to put this sort of
initialization.

> 
> > reading some volatile/non-volatile regs.  
> 
> This is the same instruction 65h which is used to read regs and which
> appears in SMPT headers, it is a chicken-egg problem.

Oh, right, I remember now. Not a smart decision from Spansion :-/.

> 
> Therefore, I don't know if it's possible to provide smarter heuristics
> here.

Maybe:

ref_cr1 = read_CR1_using_RDCR()

for_each_possible_dummy_and_addr_width
	cr1 = read_CR1_using_RDAR()
	if (cr1 == ref_cr1)
		break;


> But without it Spansion S25FS-S Family is now broken by SFDP.

Do you have [1] in your tree? IIRC, this fixed Yogesh issue.

[1]https://patchwork.ozlabs.org/patch/994765/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/