BMC/Intel-BMC/linux.git/drivers/mtd, branch dev-5.3

Merge tag 'v5.3.7' into dev-5.3

2019-10-20T23:37:22+00:00

This is the 5.3.7 stable release Signed-off-by: Joel Stanley

mtd: rawnand: au1550nd: Fix au_read_buf16() prototype

2019-10-17T20:47:32+00:00

commit df8fed831cbcdce7b283b2d9c1aadadcf8940d05 upstream. Commit 7e534323c416 ("mtd: rawnand: Pass a nand_chip object to chip->read_xxx() hooks") modified the prototype of the struct nand_chip read_buf function pointer. In the au1550nd driver we have 2 implementations of read_buf. The previously mentioned commit modified the au_read_buf() implementation to match the function pointer, but not au_read_buf16(). This results in a compiler warning for MIPS db1xxx_defconfig builds: drivers/mtd/nand/raw/au1550nd.c:443:57: warning: pointer type mismatch in conditional expression Fix this by updating the prototype of au_read_buf16() to take a struct nand_chip pointer as its first argument, as is expected after commit 7e534323c416 ("mtd: rawnand: Pass a nand_chip object to chip->read_xxx() hooks"). Note that this shouldn't have caused any functional issues at runtime, since the offset of the struct mtd_info within struct nand_chip is 0 making mtd_to_nand() effectively a type-cast. Signed-off-by: Paul Burton Fixes: 7e534323c416 ("mtd: rawnand: Pass a nand_chip object to chip->read_xxx() hooks") Cc: stable@vger.kernel.org # v4.20+ Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

Merge tag 'v5.3.5' into dev-5.3

2019-10-07T22:53:23+00:00

This is the 5.3.5 stable release Signed-off-by: Joel Stanley

mtd: rawnand: stm32_fmc2: avoid warnings when building with W=1 option

2019-10-05T13:12:35+00:00

commit b410f4eb01a1950ed73ae40859d0978b1a924380 upstream. This patch solves warnings detected by setting W=1 when building. Warnings type detected: drivers/mtd/nand/raw/stm32_fmc2_nand.c: In function ‘stm32_fmc2_calc_timings’: drivers/mtd/nand/raw/stm32_fmc2_nand.c:1417:23: warning: comparison is always false due to limited range of data type [-Wtype-limits] else if (tims->twait > FMC2_PMEM_PATT_TIMING_MASK) Signed-off-by: Christophe Kerello Cc: stable@vger.kernel.org Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver") Signed-off-by: Miquel Raynal Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Use chip_good() to retry in do_write_oneword()

2019-10-01T06:24:47+00:00

commit 37c673ade35c707d50583b5b25091ff8ebdeafd7 upstream. As reported by the OpenWRT team, write requests sometimes fail on some platforms. Currently to check the state chip_ready() is used correctly as described by the flash memory S29GL256P11TFI01 datasheet. Also chip_good() is used to check if the write is succeeded and it was implemented by the commit fb4a90bfcd6d8 ("[MTD] CFI-0002 - Improve error checking"). But actually the write failure is caused on some platforms and also it can be fixed by using chip_good() to check the state and retry instead. Also it seems that it is caused after repeated about 1,000 times to retry the write one word with the reset command. By using chip_good() to check the state to be done it can be reduced the retry with reset. It is depended on the actual flash chip behavior so the root cause is unknown. Cc: Chris Packham Cc: Joakim Tjernlund Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Reported-by: Fabio Bettoni Signed-off-by: Felix Fietkau Signed-off-by: Hauke Mehrtens Signed-off-by: Tokunori Ikegami [vigneshr@ti.com: Fix a checkpatch warning] Signed-off-by: Vignesh Raghavendra Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: aspeed: Disable zero size segments on the AST2600

2019-09-30T13:31:19+00:00

A disabled segment for a CS should have a zero value in its segment register. The driver was generating an incorrect value which overlapped with segment CS0. Accesses to the flash were blocked and Linux hung. OpenBMC-Staging-Count: 1 Fixes: 3635b880313a ("mtd: spi-nor: aspeed: add initial support for ast2600") Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed: fix training of multiple CS on the AST2600

2019-09-30T13:31:19+00:00

Each CE has its own read timing compensation register. OpenBMC-Staging-Count: 1 Fixes: c62871befcdb ("mtd: spi-nor: aspeed: add support for AST2600 training") Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed: add support for AST2600 training

2019-09-26T08:33:53+00:00

The training consists of finding the appropriate read timing delays for the HCLK dividers 2, 3, 4, and 5 and store the results in the Read Timing Compensation register. The previous SoC AST2500 and AST2400 were covering a broader HCLK range [ 1 - 5 ] because the AHB frequency was lower. The algorithm first reads a golden buffer at low speed and then performs reads with different clocks and delay cycles settings to find a breaking point. This selects the default clock frequency for the CEx control register. The current settings are bit optimistic as we pick the first delay giving good results. A safer approach would be to determine an interval and choose the middle value. We might change the approach depending on the results on other systems. Only CS0 is taken into account for the moment. OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed: check upper freq limit when doing training

2019-09-26T08:33:53+00:00

OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed: Introduce a HCLK mask for training

2019-09-26T08:33:52+00:00

The AST2600 handles more HCLK divisors than its predecessors. OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley