From 4ce341de6c02d02aba7c78a6447ccfcaa9eeb328 Mon Sep 17 00:00:00 2001 From: Arseniy Krasnov Date: Mon, 27 Feb 2023 13:24:25 +0300 Subject: [PATCH 1/5] mtd: rawnand: meson: initialize struct with zeroes This structure must be zeroed, because it's field 'hw->core' is used as 'parent' in 'clk_core_fill_parent_index()', but it will be uninitialized. This happens, because when this struct is not zeroed, pointer 'hw' is "initialized" by garbage, which is valid pointer, but points to some garbage. So 'hw' will be dereferenced, but 'core' contains some random data which will be interpreted as a pointer. The following backtrace is result of dereference of such pointer: [ 1.081319] __clk_register+0x414/0x820 [ 1.085113] devm_clk_register+0x64/0xd0 [ 1.088995] meson_nfc_probe+0x258/0x6ec [ 1.092875] platform_probe+0x70/0xf0 [ 1.096498] really_probe+0xc8/0x3e0 [ 1.100034] __driver_probe_device+0x84/0x190 [ 1.104346] driver_probe_device+0x44/0x120 [ 1.108487] __driver_attach+0xb4/0x220 [ 1.112282] bus_for_each_dev+0x78/0xd0 [ 1.116077] driver_attach+0x2c/0x40 [ 1.119613] bus_add_driver+0x184/0x240 [ 1.123408] driver_register+0x80/0x140 [ 1.127203] __platform_driver_register+0x30/0x40 [ 1.131860] meson_nfc_driver_init+0x24/0x30 Fixes: 1e4d3ba66888 ("mtd: rawnand: meson: fix the clock") Signed-off-by: Arseniy Krasnov Acked-by: Martin Blumenstingl Reviewed-by: Neil Armstrong Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20230227102425.793841-1-AVKrasnov@sberdevices.ru --- drivers/mtd/nand/raw/meson_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index 5ee01231ac4cd..30e326adabfc1 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -991,7 +991,7 @@ static const struct mtd_ooblayout_ops meson_ooblayout_ops = { static int meson_nfc_clk_init(struct meson_nfc *nfc) { - struct clk_parent_data nfc_divider_parent_data[1]; + struct clk_parent_data nfc_divider_parent_data[1] = {0}; struct clk_init_data init = {0}; int ret; From 75dce6a941e3f16c3b4878c8b2f46d5d07c619ce Mon Sep 17 00:00:00 2001 From: Christophe JAILLET Date: Wed, 15 Feb 2023 12:08:45 +0100 Subject: [PATCH 2/5] mtd: nand: mxic-ecc: Fix mxic_ecc_data_xfer_wait_for_completion() when irq is used wait_for_completion_timeout() and readl_poll_timeout() don't handle their return value the same way. wait_for_completion_timeout() returns 0 on time out (and >0 in all other cases) readl_poll_timeout() returns 0 on success and -ETIMEDOUT upon a timeout. In order for the error handling path to work in both cases, the logic against wait_for_completion_timeout() needs to be inverted. Fixes: 48e6633a9fa2 ("mtd: nand: mxic-ecc: Add Macronix external ECC engine support") Signed-off-by: Christophe JAILLET Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/beddbc374557e44ceec897e68c4a5d12764ddbb9.1676459308.git.christophe.jaillet@wanadoo.fr --- drivers/mtd/nand/ecc-mxic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/ecc-mxic.c b/drivers/mtd/nand/ecc-mxic.c index 8afdca731b874..6b487ffe2f2dc 100644 --- a/drivers/mtd/nand/ecc-mxic.c +++ b/drivers/mtd/nand/ecc-mxic.c @@ -429,6 +429,7 @@ static int mxic_ecc_data_xfer_wait_for_completion(struct mxic_ecc_engine *mxic) mxic_ecc_enable_int(mxic); ret = wait_for_completion_timeout(&mxic->complete, msecs_to_jiffies(1000)); + ret = ret ? 0 : -ETIMEDOUT; mxic_ecc_disable_int(mxic); } else { ret = readl_poll_timeout(mxic->regs + INTRPT_STS, val, From a56cde41340ac4049fa6edac9e6cfbcd2804074e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 14 Feb 2023 15:26:43 +0100 Subject: [PATCH 3/5] dt-bindings: mtd: jedec,spi-nor: Document CPOL/CPHA support SPI EEPROMs typically support both SPI Mode 0 (CPOL=CPHA=0) and Mode 3 (CPOL=CPHA=1). However, using the latter is currently flagged as an error by "make dtbs_check", e.g.: arch/arm/boot/dts/r8a7791-koelsch.dtb: flash@0: Unevaluated properties are not allowed ('spi-cpha', 'spi-cpol' were unexpected) From schema: Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml Fix this by documenting support for CPOL=CPHA=1. Fixes: 233363aba72ac638 ("spi/panel: dt-bindings: drop CPHA and CPOL from common properties") Cc: stable@vger.kernel.org Signed-off-by: Geert Uytterhoeven Reviewed-by: Miquel Raynal Reviewed-by: Krzysztof Kozlowski Reviewed-by: Tudor Ambarus Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/afe470603028db9374930b0c57464b1f6d52bdd3.1676384304.git.geert+renesas@glider.be --- Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 3fe981b14e2cb..54736362378eb 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -76,6 +76,13 @@ properties: If "broken-flash-reset" is present then having this property does not make any difference. + spi-cpol: true + spi-cpha: true + +dependencies: + spi-cpol: [ spi-cpha ] + spi-cpha: [ spi-cpol ] + unevaluatedProperties: false examples: From 9b043c649022ec55040aa9315cc72059c4ec254c Mon Sep 17 00:00:00 2001 From: Miquel Raynal Date: Fri, 10 Mar 2023 09:54:52 +0100 Subject: [PATCH 4/5] mtd: rawnand: nandsim: Artificially prevent sequential page reads The continuous read support added recently makes nandsim unhappy. Indeed, all the supported commands should be re-encoded into internal commands, so of course there is currently no support for the commands and patterns needed for continuous reads to work. I tried to add support for them but nandsim (which is more a tool to develop/debug upper layers rather than the raw NAND core) suffers from a big limitation: it's internal parser needs to know what exact operation is happening when the address cycles are performed. The research is then sequential from the start up to the address cycles, but does not check what's coming next even though the information is available. This is a limitation which is related to the old API used by the core which kind of forced the controllers to guess what operation was being performed rather early. Today the core uses a more transparent API called ->exec_op() which no longer requires controller drivers to do any more guessing, but despite being updated to ->exec_op(), nandsim is still a bit constrained on this regard and thus cannot handle sequential page reads because the start sequence beginning is identical to a regular page read. If the internal algorithm is updated some day, it should be possible to make it support sequential page reads by adding something like: /* Large page devices continuous read page start */ {OPT_LARGEPAGE, {STATE_CMD_READ0, STATE_ADDR_PAGE, STATE_CMD_READSTART, STATE_CMD_READCACHESEQ | ACTION_CPY, STATE_DATAOUT, STATE_READY}}, /* Large page devices continuous read page continue */ {OPT_LARGEPAGE, {STATE_CMD_READCACHESEQ | ACTION_CPY_NEXT, STATE_DATAOUT, STATE_READY}}, /* Large page devices continuous read page end */ {OPT_LARGEPAGE, {STATE_CMD_READCACHEEND | ACTION_CPY_NEXT, STATE_DATAOUT, STATE_READY}}, For now, we just return -EOPNOTSUPP when the core asks controller drivers if they support the feature in order to prevent any further use of these opcodes. Note: This is a hack, ->exec_op() is not supposed to check against the COMMAND opcodes unless _really_ needed. Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Reported-by: Zhihao Cheng Link: https://lore.kernel.org/linux-mtd/fd34fe55-7f4a-030d-8653-9bb9cf08410d@huawei.com/ Signed-off-by: Miquel Raynal Tested-by: Zhihao Cheng Acked-by: Richard Weinberger Link: https://lore.kernel.org/linux-mtd/20230310085452.1368716-1-miquel.raynal@bootlin.com --- drivers/mtd/nand/raw/nandsim.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c index c21abf7489481..179b28459b4bd 100644 --- a/drivers/mtd/nand/raw/nandsim.c +++ b/drivers/mtd/nand/raw/nandsim.c @@ -2160,8 +2160,23 @@ static int ns_exec_op(struct nand_chip *chip, const struct nand_operation *op, const struct nand_op_instr *instr = NULL; struct nandsim *ns = nand_get_controller_data(chip); - if (check_only) + if (check_only) { + /* The current implementation of nandsim needs to know the + * ongoing operation when performing the address cycles. This + * means it cannot make the difference between a regular read + * and a continuous read. Hence, this hack to manually refuse + * supporting sequential cached operations. + */ + for (op_id = 0; op_id < op->ninstrs; op_id++) { + instr = &op->instrs[op_id]; + if (instr->type == NAND_OP_CMD_INSTR && + (instr->ctx.cmd.opcode == NAND_CMD_READCACHEEND || + instr->ctx.cmd.opcode == NAND_CMD_READCACHESEQ)) + return -EOPNOTSUPP; + } + return 0; + } ns->lines.ce = 1; From e732e39ed9929c05fd219035bc9653ba4100d4fa Mon Sep 17 00:00:00 2001 From: Arseniy Krasnov Date: Mon, 13 Mar 2023 10:32:44 +0300 Subject: [PATCH 5/5] mtd: rawnand: meson: invalidate cache on polling ECC bit 'info_buf' memory is cached and driver polls ECC bit in it. This bit is set by the NAND controller. If 'usleep_range()' returns before device sets this bit, 'info_buf' will be cached and driver won't see update of this bit and will loop forever. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Arseniy Krasnov Reviewed-by: Neil Armstrong Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/d4ef0bd6-816e-f6fa-9385-f05f775f0ae2@sberdevices.ru --- drivers/mtd/nand/raw/meson_nand.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index 30e326adabfc1..a28574c009003 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -176,6 +176,7 @@ struct meson_nfc { dma_addr_t daddr; dma_addr_t iaddr; + u32 info_bytes; unsigned long assigned_cs; }; @@ -503,6 +504,7 @@ static int meson_nfc_dma_buffer_setup(struct nand_chip *nand, void *databuf, nfc->daddr, datalen, dir); return ret; } + nfc->info_bytes = infolen; cmd = GENCMDIADDRL(NFC_CMD_AIL, nfc->iaddr); writel(cmd, nfc->reg_base + NFC_REG_CMD); @@ -520,8 +522,10 @@ static void meson_nfc_dma_buffer_release(struct nand_chip *nand, struct meson_nfc *nfc = nand_get_controller_data(nand); dma_unmap_single(nfc->dev, nfc->daddr, datalen, dir); - if (infolen) + if (infolen) { dma_unmap_single(nfc->dev, nfc->iaddr, infolen, dir); + nfc->info_bytes = 0; + } } static int meson_nfc_read_buf(struct nand_chip *nand, u8 *buf, int len) @@ -710,6 +714,8 @@ static void meson_nfc_check_ecc_pages_valid(struct meson_nfc *nfc, usleep_range(10, 15); /* info is updated by nfc dma engine*/ smp_rmb(); + dma_sync_single_for_cpu(nfc->dev, nfc->iaddr, nfc->info_bytes, + DMA_FROM_DEVICE); ret = *info & ECC_COMPLETE; } while (!ret); }