From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Markus Stockhausen <markus.stockhausen@gmx.de>
Cc: richard@nod.at, vigneshr@ti.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] mtd: nand: realtek-ecc: Add Realtek external ECC engine support
Date: Sun, 24 Aug 2025 18:51:28 +0200 [thread overview]
Message-ID: <87ldn8hddb.fsf@bootlin.com> (raw)
In-Reply-To: <20250818092725.1977105-3-markus.stockhausen@gmx.de> (Markus Stockhausen's message of "Mon, 18 Aug 2025 05:27:25 -0400")
Hi Markus,
On 18/08/2025 at 05:27:25 -04, Markus Stockhausen <markus.stockhausen@gmx.de> wrote:
> The Realtek RTl93xx switch SoC series has a built in ECC controller
> that can provide BCH6 or BCH12 over 512 data and 6 tag bytes. It
> generates 10 (BCH6) or 20 (BCH12) bytes of parity.
>
> This engine will most likely work in conjunction with the Realtek
> spi-mem based NAND controller but can work on its own. Therefore
> the initial implementation will be of type external.
>
> Remark! The engine can support any data blocks that are multiples
> of 512 bytes. For now limit it to data+oob layouts that have been
> analyzed from existing devices. This way it keeps compatibility
> and pre-existing vendor data can be read.
>
> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
> ---
Very happy to see a new external ECC driver!
> drivers/mtd/nand/Kconfig | 8 +
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/ecc-realtek.c | 433 +++++++++++++++++++++++++++++++++
> 3 files changed, 442 insertions(+)
> create mode 100644 drivers/mtd/nand/ecc-realtek.c
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 5b0c2c95f10c..4a17271076bc 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -61,6 +61,14 @@ config MTD_NAND_ECC_MEDIATEK
> help
> This enables support for the hardware ECC engine from Mediatek.
>
> +config MTD_NAND_ECC_REALTEK
> + tristate "Realtek RTL93xx hardware ECC engine"
> + depends on HAS_IOMEM
> + depends on MACH_REALTEK_RTL || COMPILE_TEST
> + select MTD_NAND_ECC
> + help
> + This enables support for the hardware ECC engine from Realtek.
> +
> endmenu
>
> endmenu
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 44913ff1bf12..2e0e56267718 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -3,6 +3,7 @@
> nandcore-objs := core.o bbt.o
> obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> obj-$(CONFIG_MTD_NAND_ECC_MEDIATEK) += ecc-mtk.o
> +obj-$(CONFIG_MTD_NAND_ECC_REALTEK) += ecc-realtek.o
> obj-$(CONFIG_SPI_QPIC_SNAND) += qpic_common.o
> obj-$(CONFIG_MTD_NAND_QCOM) += qpic_common.o
> obj-y += onenand/
> diff --git a/drivers/mtd/nand/ecc-realtek.c b/drivers/mtd/nand/ecc-realtek.c
> new file mode 100644
> index 000000000000..a9c2a3a23b78
> --- /dev/null
> +++ b/drivers/mtd/nand/ecc-realtek.c
> @@ -0,0 +1,433 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Support for Realtek hardware ECC engine in RTL93xx SoCs
> + */
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/mtd/nand.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +/*
> + * The Realtek ECC engine has two operation modes.
> + *
> + * - BCH6 : Generate 10 ECC bytes from 512 data bytes plus 6 tag bytes
> + * - BCH12: Generate 20 ECC bytes from 512 data bytes plus 6 tag
> bytes
What is a tag? I believe it is Realtek wording and we need to find a
more generic translation.
> + *
> + * It can run for arbitrary NAND flash chips with different block and OOB sizes. Currently there
> + * are only two known devices in the wild that have NAND flash and make use of this ECC engine
> + * (Linksys LGS328C & LGS352C). To keep compatibility with vendor firmware, new modes can only
> + * be added when new data layouts have been analyzed. For now allow BCH6 on flash with 2048 byte
> + * blocks and 64 bytes oob.
> + */
> +
> +#define RTL_ECC_ALLOWED_PAGE_SIZE 2048
> +#define RTL_ECC_ALLOWED_OOB_SIZE 64
> +#define RTL_ECC_ALLOWED_STRENGTH 6
> +
> +#define RTL_ECC_BLOCK_SIZE 512
> +#define RTL_ECC_TAG_SIZE 6
> +#define RTL_ECC_PARITY_SIZE_BCH6 10
> +#define RTL_ECC_PARITY_SIZE_BCH12 20
> +
> +/*
> + * The engine is fed with two DMA regions. One for data (always 512 bytes) and one for tag and
> + * parity (either 16 bytes for BCH6 or 26 bytes for BCH12). Start and length of each must be
> + * aligned to a multiple of 4.
> + */
> +
> +#define RTL_ECC_DMA_TAG_PARITY_SIZE ALIGN(RTL_ECC_TAG_SIZE + RTL_ECC_PARITY_SIZE_BCH12, 4)
> +#define RTL_ECC_DMA_SIZE (RTL_ECC_BLOCK_SIZE + RTL_ECC_DMA_TAG_PARITY_SIZE)
> +
> +#define RTL_ECC_CFG 0x00
> +#define RTL_ECC_BCH6 0
> +#define RTL_ECC_BCH12 BIT(28)
> +#define RTL_ECC_DMA_PRECISE BIT(12)
> +#define RTL_ECC_BURST_128 GENMASK(1, 0)
> +#define RTL_ECC_DMA_TRIGGER 0x08
> +#define RTL_ECC_OP_DECODE 0
> +#define RTL_ECC_OP_ENCODE BIT(0)
> +#define RTL_ECC_DMA_START 0x0c
> +#define RTL_ECC_DMA_TAG 0x10
> +#define RTL_ECC_STATUS 0x14
> +#define RTL_ECC_CORR_COUNT GENMASK(19, 12)
> +#define RTL_ECC_RESULT BIT(8)
> +#define RTL_ECC_ALL_ONE BIT(4)
> +#define RTL_ECC_OP_STATUS BIT(0)
> +
> +struct rtl_ecc_engine {
> + struct device *dev;
> + struct nand_ecc_engine engine;
> + struct mutex lock;
> + char *buf;
> + dma_addr_t buf_dma;
> + struct regmap *regmap;
> +};
> +
> +struct rtl_ecc_ctx {
> + struct rtl_ecc_engine * rtlc;
> + struct nand_ecc_req_tweak_ctx req_ctx;
> + int steps;
> + int bch_mode;
> + int parity_size;
> + int rc_bitflips;
> + int rc_status;
> +};
> +
> +static const struct regmap_config rtl_ecc_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static inline void *nand_to_ctx(struct nand_device *nand)
> +{
> + return nand->ecc.ctx.priv;
> +}
> +
> +static inline struct rtl_ecc_engine *nand_to_rtlc(struct nand_device *nand)
> +{
> + struct nand_ecc_engine *eng = nand->ecc.engine;
> +
> + return container_of(eng, struct rtl_ecc_engine, engine);
> +}
> +
> +static int rtl_ecc_ooblayout_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + struct nand_device *nand = mtd_to_nanddev(mtd);
> + struct rtl_ecc_ctx *ctx = nand_to_ctx(nand);
> +
> + if (section < 0 || section >= ctx->steps)
> + return -ERANGE;
> +
> + oobregion->offset = ctx->steps * RTL_ECC_TAG_SIZE + section * ctx->parity_size;
> + oobregion->length = ctx->parity_size;
Please reserve 2 bytes for BBM.
For me it looks like you have a bit free section and a bit ECC
section. If that simplifies your life, you can just return a single
section for both.
> +
> + return 0;
> +}
> +
> +static int rtl_ecc_ooblayout_free(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + struct nand_device *nand = mtd_to_nanddev(mtd);
> + struct rtl_ecc_ctx *ctx = nand_to_ctx(nand);
> +
> + if (section < 0 || section >= ctx->steps)
> + return -ERANGE;
> +
> + /* Tags can hold arbitrary values, so they are free for user data */
> + oobregion->offset = section * RTL_ECC_TAG_SIZE;
> + oobregion->length = RTL_ECC_TAG_SIZE;
> +
> + return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops rtl_ecc_ooblayout_ops = {
> + .ecc = rtl_ecc_ooblayout_ecc,
> + .free = rtl_ecc_ooblayout_free,
> +};
> +
> +static void rtl_ecc_kick_engine(struct rtl_ecc_ctx *ctx, int operation)
> +{
> + struct rtl_ecc_engine *rtlc = ctx->rtlc;
> +
> + regmap_write(rtlc->regmap, RTL_ECC_CFG,
> + ctx->bch_mode | RTL_ECC_BURST_128 | RTL_ECC_DMA_PRECISE);
> +
> + regmap_write(rtlc->regmap, RTL_ECC_DMA_START, rtlc->buf_dma);
> + regmap_write(rtlc->regmap, RTL_ECC_DMA_TAG, rtlc->buf_dma + RTL_ECC_BLOCK_SIZE);
> + regmap_write(rtlc->regmap, RTL_ECC_DMA_TRIGGER, operation);
> +}
> +
> +static void rtl_ecc_wait_for_engine(struct rtl_ecc_ctx *ctx)
> +{
> + struct rtl_ecc_engine *rtlc = ctx->rtlc;
> + int ret, status;
> + bool all_one;
> +
> + /*
> + * The ECC engine needs 6-8 us to encode/decode a BCH6 syndrome for 512 bytes of data
> + * and 6 tag bytes. In case the NAND area has been erased and all data and oob is
> + * set to 0xff, decoding takes 30us (reason unknown). Although the engine can trigger
> + * interrupts when finished, use active polling for now. 12 us maximum wait time has
> + * proven to be a good tradeoff between performance and overhead.
> + */
> +
> + ret = regmap_read_poll_timeout(rtlc->regmap, RTL_ECC_STATUS, status,
> + !(status & RTL_ECC_OP_STATUS), 12, 600);
> + if (ret) {
> + ctx->rc_status = ret;
> + return;
Please make this function return an int and use it in the caller instead
of using an intermediate status variable for that.
> + }
> +
> + all_one = FIELD_GET(RTL_ECC_ALL_ONE, status);
> + ctx->rc_status = FIELD_GET(RTL_ECC_RESULT, status);
> + ctx->rc_bitflips = FIELD_GET(RTL_ECC_CORR_COUNT, status);
> +
> + /* For erased blocks (all bits one) error status can be ignored */
> + if (ctx->rc_status && all_one)
> + ctx->rc_status = 0;
> +}
> +
> +static void rtl_ecc_run_engine(struct rtl_ecc_ctx *ctx, char *data, char *tag,
> + char *parity, int operation)
> +{
> + struct rtl_ecc_engine *rtlc = ctx->rtlc;
> + char *buf_parity = rtlc->buf + RTL_ECC_BLOCK_SIZE + RTL_ECC_TAG_SIZE;
> + char *buf_tag = rtlc->buf + RTL_ECC_BLOCK_SIZE;
> + char *buf_data = rtlc->buf;
> +
> + mutex_lock(&rtlc->lock);
> +
> + memcpy(buf_data, data, RTL_ECC_BLOCK_SIZE);
> + memcpy(buf_tag, tag, RTL_ECC_TAG_SIZE);
> + memcpy(buf_parity, parity, ctx->parity_size);
> +
> + dma_sync_single_for_device(rtlc->dev, rtlc->buf_dma, RTL_ECC_DMA_SIZE, DMA_TO_DEVICE);
> + rtl_ecc_kick_engine(ctx, operation);
> + rtl_ecc_wait_for_engine(ctx);
> + dma_sync_single_for_cpu(rtlc->dev, rtlc->buf_dma, RTL_ECC_DMA_SIZE, DMA_FROM_DEVICE);
> +
> + if (!ctx->rc_status) {
> + memcpy(data, buf_data, RTL_ECC_BLOCK_SIZE);
> + memcpy(tag, buf_tag, RTL_ECC_TAG_SIZE);
> + memcpy(parity, buf_parity, ctx->parity_size);
> + }
> +
> + mutex_unlock(&rtlc->lock);
> +}
> +
> +static int rtl_ecc_prepare_io_req(struct nand_device *nand, struct nand_page_io_req *req)
> +{
> + struct rtl_ecc_engine *rtlc = nand_to_rtlc(nand);
> + struct rtl_ecc_ctx *ctx = nand_to_ctx(nand);
> + char *data, *tag, *parity;
> + int failure = 0;
> +
> + if (req->mode == MTD_OPS_RAW)
> + return 0;
> +
> + nand_ecc_tweak_req(&ctx->req_ctx, req);
> +
> + if (req->type == NAND_PAGE_READ)
> + return 0;
> +
> + tag = req->oobbuf.in;
> + data = req->databuf.in;
> + parity = req->oobbuf.in + ctx->steps * RTL_ECC_TAG_SIZE;
> +
> + for (int i = 0; i < ctx->steps; i++) {
> + rtl_ecc_run_engine(ctx, data, tag, parity, RTL_ECC_OP_ENCODE);
> + failure |= ctx->rc_status;
> +
> + tag += RTL_ECC_TAG_SIZE;
> + data += RTL_ECC_BLOCK_SIZE;
> + parity += ctx->parity_size;
> + }
> +
> + if (unlikely(failure))
> + dev_err(rtlc->dev, "ECC calculation failed\n");
This is not helpful as the other layers will complain if that's
relevant. For instance in case you use this driver with a NAND with read
retry support, it would be very noisy. Please turn this into a dev_dbg
call at most.
> +
> + return failure ? -EBADMSG : 0;
> +}
> +
> +static int rtl_ecc_finish_io_req(struct nand_device *nand, struct nand_page_io_req *req)
> +{
> + struct rtl_ecc_engine *rtlc = nand_to_rtlc(nand);
> + struct rtl_ecc_ctx *ctx = nand_to_ctx(nand);
> + struct mtd_info *mtd = nanddev_to_mtd(nand);
> + char *data, *tag, *parity;
> + unsigned int bitflips = 0;
> + int failure = 0;
> +
> + if (req->mode == MTD_OPS_RAW)
> + return 0;
> +
> + if (req->type == NAND_PAGE_WRITE) {
> + nand_ecc_restore_req(&ctx->req_ctx, req);
> + return 0;
> + }
> +
> + tag = req->oobbuf.in;
> + data = req->databuf.in;
> + parity = req->oobbuf.in + ctx->steps * RTL_ECC_TAG_SIZE;
> +
> + for (int i = 0 ; i < ctx->steps; i++) {
> + rtl_ecc_run_engine(ctx, data, tag, parity, RTL_ECC_OP_DECODE);
> + failure |= ctx->rc_status;
> + mtd->ecc_stats.failed += !!ctx->rc_status;
> + bitflips = max_t(unsigned int, ctx->rc_bitflips, bitflips);
> +
> + tag += RTL_ECC_TAG_SIZE;
> + data += RTL_ECC_BLOCK_SIZE;
> + parity += ctx->parity_size;
> + }
> +
> + nand_ecc_restore_req(&ctx->req_ctx, req);
> +
> + if (unlikely(failure))
> + dev_err(rtlc->dev, "ECC correction failed\n");
> + else if (unlikely(bitflips > 2))
> + dev_warn(rtlc->dev, "%d bitflips detected\n", ctx->rc_bitflips);
Same here. Way too noisy for something (a bitflip) that happens normally.
> +
> + return failure ? -EBADMSG : bitflips;
> +}
> +
> +static int rtl_ecc_check_support(struct nand_device *nand)
> +{
> + struct mtd_info *mtd = nanddev_to_mtd(nand);
> + struct device *dev = nand->ecc.engine->dev;
> +
> + if (mtd->oobsize != RTL_ECC_ALLOWED_OOB_SIZE ||
> + mtd->writesize != RTL_ECC_ALLOWED_PAGE_SIZE) {
> + dev_err(dev, "only flash geometry data=%d, oob=%d supported\n",
> + RTL_ECC_ALLOWED_PAGE_SIZE, RTL_ECC_ALLOWED_OOB_SIZE);
> + return -EINVAL;
> + }
> +
> + if (nand->ecc.user_conf.algo != NAND_ECC_ALGO_BCH ||
> + nand->ecc.user_conf.strength != RTL_ECC_ALLOWED_STRENGTH ||
> + nand->ecc.user_conf.placement != NAND_ECC_PLACEMENT_OOB ||
> + nand->ecc.user_conf.step_size != RTL_ECC_BLOCK_SIZE) {
> + dev_err(dev, "only algo=bch, strength=%d, placement=oob, step=%d supported\n",
> + RTL_ECC_ALLOWED_STRENGTH, RTL_ECC_BLOCK_SIZE);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int rtl_ecc_init_ctx(struct nand_device *nand)
> +{
> + struct nand_ecc_props *conf = &nand->ecc.ctx.conf;
> + struct rtl_ecc_engine *rtlc = nand_to_rtlc(nand);
> + struct mtd_info *mtd = nanddev_to_mtd(nand);
> + int strength = nand->ecc.user_conf.strength;
> + struct device *dev = nand->ecc.engine->dev;
> + struct rtl_ecc_ctx *ctx;
> + int ret;
> +
> + ret = rtl_ecc_check_support(nand);
> + if (ret)
> + return ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + nand->ecc.ctx.priv = ctx;
> + mtd_set_ooblayout(mtd, &rtl_ecc_ooblayout_ops);
> +
> + conf->algo = NAND_ECC_ALGO_BCH;
> + conf->strength = strength;
> + conf->step_size = RTL_ECC_BLOCK_SIZE;
> + conf->engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST;
> +
> + ctx->rtlc = rtlc;
> + ctx->steps = mtd->writesize / RTL_ECC_BLOCK_SIZE;
> + ctx->bch_mode = strength == 6 ? RTL_ECC_BCH6 : RTL_ECC_BCH12;
> + ctx->parity_size = strength == 6 ? RTL_ECC_PARITY_SIZE_BCH6 : RTL_ECC_PARITY_SIZE_BCH12;
> +
> + ret = nand_ecc_init_req_tweaking(&ctx->req_ctx, nand);
> + if (ret)
> + return ret;
> +
> + dev_info(dev, "using bch%d with geometry data=%dx%d, tag=%dx6, parity=%dx%d",
> + conf->strength, ctx->steps, conf->step_size,
> + ctx->steps, ctx->steps, ctx->parity_size);
Same, dev_dbg is fine, but otherwise no need.
> +
> + return 0;
> +}
> +
> +static void rtl_ecc_cleanup_ctx(struct nand_device *nand)
> +{
> + struct rtl_ecc_ctx *ctx = nand_to_ctx(nand);
> +
> + if (ctx)
> + nand_ecc_cleanup_req_tweaking(&ctx->req_ctx);
> +}
> +
> +static struct nand_ecc_engine_ops rtl_ecc_engine_ops = {
> + .init_ctx = rtl_ecc_init_ctx,
> + .cleanup_ctx = rtl_ecc_cleanup_ctx,
> + .prepare_io_req = rtl_ecc_prepare_io_req,
> + .finish_io_req = rtl_ecc_finish_io_req,
> +};
> +
> +static int rtl_ecc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct rtl_ecc_engine *rtlc;
> + void __iomem *base;
> + int ret;
> +
> + rtlc = devm_kzalloc(dev, sizeof(*rtlc), GFP_KERNEL);
> + if (!rtlc)
> + return -ENOMEM;
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + ret = devm_mutex_init(dev, &rtlc->lock);
> + if (ret)
> + return ret;
> +
> + rtlc->regmap = devm_regmap_init_mmio(dev, base, &rtl_ecc_regmap_config);
> + if (IS_ERR(rtlc->regmap))
> + return PTR_ERR(rtlc->regmap);
> +
> + /*
> + * Focus on simplicity and use a preallocated DMA buffer for data exchange with the
> + * engine. Make it a noncoherent memory model as invalidating/flushing caches is
> + * faster than reading/writing uncached memory.
> + */
I guess it depends on the architecture, but that's fine.
> +
> + rtlc->buf = dma_alloc_noncoherent(dev, RTL_ECC_DMA_SIZE, &rtlc->buf_dma,
> + DMA_BIDIRECTIONAL, GFP_KERNEL);
> + if (IS_ERR(rtlc->buf))
> + return PTR_ERR(rtlc->buf);
> +
> + rtlc->dev = dev;
> + rtlc->engine.dev = dev;
> + rtlc->engine.ops = &rtl_ecc_engine_ops;
> + rtlc->engine.integration = NAND_ECC_ENGINE_INTEGRATION_EXTERNAL;
> +
> + nand_ecc_register_on_host_hw_engine(&rtlc->engine);
> +
> + platform_set_drvdata(pdev, rtlc);
> +
> + return 0;
> +}
> +
> +static void rtl_ecc_remove(struct platform_device *pdev)
> +{
> + struct rtl_ecc_engine *rtlc = platform_get_drvdata(pdev);
> +
> + nand_ecc_unregister_on_host_hw_engine(&rtlc->engine);
> + dma_free_noncoherent(rtlc->dev, RTL_ECC_DMA_SIZE, rtlc->buf, rtlc->buf_dma,
> + DMA_BIDIRECTIONAL);
> +}
> +
> +static const struct of_device_id rtl_ecc_of_ids[] = {
> + {
> + .compatible = "realtek,rtl9301-ecc",
> + },
> + { /* sentinel */ },
> +};
> +
> +static struct platform_driver rtl_ecc_driver = {
> + .driver = {
> + .name = "rtl-nand-ecc-engine",
> + .of_match_table = rtl_ecc_of_ids,
> + },
> + .probe = rtl_ecc_probe,
> + .remove = rtl_ecc_remove,
> +};
> +module_platform_driver(rtl_ecc_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Markus Stockhausen <markus.stockhausen@gmx.de>");
> +MODULE_DESCRIPTION("Realtek NAND hardware ECC controller");
Great work nevertheless! Looking forward to get it upstreamed.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2025-08-24 16:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 9:27 [PATCH 0/2] Realtek ECC engine Markus Stockhausen
2025-08-18 9:27 ` [PATCH 1/2] dt-bindings: mtd: Add realtek,rtl9301-ecc Markus Stockhausen
2025-08-18 10:49 ` Rob Herring (Arm)
2025-08-18 9:27 ` [PATCH 2/2] mtd: nand: realtek-ecc: Add Realtek external ECC engine support Markus Stockhausen
2025-08-19 5:11 ` kernel test robot
2025-08-24 16:51 ` Miquel Raynal [this message]
2025-08-24 19:16 ` AW: " markus.stockhausen
2025-08-28 10:07 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ldn8hddb.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=markus.stockhausen@gmx.de \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).