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

[Cédric Le Goater]

> The flash chip in question is the one used to boot the host (OpenPOWER P8), 
> not the BMC (ASpeed AST2400). U-boot on AST2400 has nothing to do with 
> the chip. 

yes. The Aspeed SoCs has multiple SMC Controllers. 

On the AST2400, the first SMC controller (called FMC) is for the 
BMC Firmware and supports SPI, NOR, NAND flash devices. The second 
is a SPI only controller for the host Firmware. In the OpenBMC 
terminology, the flash device holding the host Firmware is referred 
as the "PNOR" ... 

On the AST2500, the FMC controller supports SPI and NOR flash devices. 
There are two other controllers supporting only SPI, the first is used
for the host Firmware.


OpenPOWER platforms using the AST2500 don't have the problem because
the flash content is accessed differently from the host.

[ ... ]

> I start thinking about maybe adding an option to "jedec,spi-nor" DTS 
> binding like "enable-4byte-mode", so that we could get rid of our local
> patch and just specify that option in the devicetree. The option would
> force EN4B on the chip if it supports that mode. What do you think? 

Are you proposing to add an extra property  that would be handled at
the spi-nor level to choose which set of SPI commands should be the 
default read_opcode ? either the ones requiring EN4B (SPINOR_OP_READ*)  
or the others which would not (SPINOR_OP_READ*_4B) ? 

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.

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 ? 

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

Thanks,

C.