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

[Alexander Amelkin]

29.08.2018 15:05, Cédric Le Goater wrote:
>
>> 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) ? 
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.

My proposal is to add an option that would force EN4B always, leaving the rest as is.
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.
> 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.

> 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.
Where do you propose the information that "we don't want SPI_NOR_4B_OPCODES" to come from?
My proposal is to put the option into DTS where it quite naturally belongs because it's a platform-specific configuration.

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

Alexander.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180829/cb18f657/attachment-0001.sig>