[PATCH] mtd: spi-nor: fix options for mx66l51235f

[Cédric Le Goater]

[ ... ]

> Not exactly. Currently, spi-nor driver for devices over 16MB in size checks
> whether or not the SPI_NOR_4B_OPCODES is set. If it is not, it simply issues
> an EN4B command to set legacy opcodes to 4-byte mode. If the option is there,
> the driver replaces pointers to legacy-3-byte-command-based functions with pointers
> to modern-4-byte-comand-based functions.

yes

> My proposal is to add an option that would force EN4B always, leaving the 
> rest as is.

ok. so you want to force the call to set_4byte() in spi_nor_init(). 

There :
	...

	if ((nor->addr_width == 4) &&
	    (JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
	    !(nor->info->flags & SPI_NOR_4B_OPCODES))
		set_4byte(nor, nor->info, 1);


It should be possible initiate a SPI transfer from the driver also but
I am sure this is acceptable.

> That is, the driver will still use 4-byte commands if they are supported, 
> but the default mode of the chip will be switched to 4-byte as well.

ok.

>> I think it would be better to introduce the property in the aspeed-smc
>> driver because this is very specific usage of the Aspeed SoC done 
>> by a platform.
> The aspeed-smc driver configures the Aspeed SMC controller, not the flash chip.

Not exactly, yes, but it does configure the controller registers for a 
specific flash chip: timings, opcodes, hclk, dummies. 
 
>> and/or, maybe, introduce a new SNOR_HWCAPS to inform spi_nor_scan() 
>> that some driver we doesn't want the SPI_NOR_4B_OPCODES ? 
>
> If I understand correctly, SNOR_HWCAPS are defined as per JEDEC standard 
> and are set according to chip's SFDP table.

and according to the SPI controller. The driver performs a scan with its 
capabilities. So we could extend the hwcaps struct for this purpose.

> Where do you propose the information that "we don't want SPI_NOR_4B_OPCODES" 
> to come from?

The DT.

> My proposal is to put the option into DTS where it quite naturally belongs 
> because it's a platform-specific configuration.

yes  but I don't think we can ask the common SPI-NOR layer to handle a 
platform specific property. We need a way to provide that information. 
 
>>> How do I do it if you approve? Send patches separately in here and in 
>>> the devicetree mailing list or cross-post both patches to both lists?
>> You need to send a patch to both mailing lists, openbmc@ and linux-mtd@
> Sorry, I wasn't asking about openbmc at . I was asking about devicetree@ and @linux-mtd.

ok but I think we can keep openbmc@ in the loop too.

Thanks,

C.