From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Md Sadre Alam <quic_mdalam@quicinc.com>
Cc: mani@kernel.org, richard@nod.at, vigneshr@ti.com,
linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_srichara@quicinc.com
Subject: Re: [PATCH v2 1/5] mtd: rawnand: qcom: Implement exec_op()
Date: Mon, 22 May 2023 15:35:19 +0200 [thread overview]
Message-ID: <20230522153519.6b574789@xps-13> (raw)
In-Reply-To: <20230511133017.6307-2-quic_mdalam@quicinc.com>
Hello,
quic_mdalam@quicinc.com wrote on Thu, 11 May 2023 19:00:13 +0530:
> Implement exec_op() so we can later get rid of the legacy interface
> implementation.
>
> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
> ---
> Change in [v2]
>
> * Missed to post Cover-letter, so posting v2 patch with cover-letter
>
> drivers/mtd/nand/raw/qcom_nandc.c | 214 +++++++++++++++++++++++++++++-
> 1 file changed, 213 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> index 72d6168d8a1b..dae460e2aa0b 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -157,6 +157,7 @@
> #define OP_PAGE_PROGRAM_WITH_ECC 0x7
> #define OP_PROGRAM_PAGE_SPARE 0x9
> #define OP_BLOCK_ERASE 0xa
> +#define OP_CHECK_STATUS 0xc
> #define OP_FETCH_ID 0xb
> #define OP_RESET_DEVICE 0xd
>
> @@ -235,6 +236,7 @@ nandc_set_reg(chip, reg, \
> */
> #define NAND_ERASED_CW_SET BIT(4)
>
> +#define MAX_ADDRESS_CYCLE 5
> /*
> * This data type corresponds to the BAM transaction which will be used for all
> * NAND transfers.
> @@ -447,6 +449,29 @@ struct qcom_nand_boot_partition {
> u32 page_size;
> };
>
> +/*
> + * Qcom op for each exec_op transfer
> + *
> + * @data_instr: data instruction pointer
> + * @data_instr_idx: data instruction index
> + * @rdy_timeout_ms: wait ready timeout in ms
> + * @rdy_delay_ns: Additional delay in ns
> + * @addr1_reg: Address1 register value
> + * @addr2_reg: Address2 register value
> + * @cmd_reg: CMD register value
> + * @flag: flag for misc instruction
> + */
> +struct qcom_op {
> + const struct nand_op_instr *data_instr;
> + unsigned int data_instr_idx;
> + unsigned int rdy_timeout_ms;
> + unsigned int rdy_delay_ns;
> + u32 addr1_reg;
> + u32 addr2_reg;
> + u32 cmd_reg;
> + u8 flag;
> +};
> +
> /*
> * NAND chip structure
> *
> @@ -1517,7 +1542,8 @@ static void pre_command(struct qcom_nand_host *host, int command)
> clear_read_regs(nandc);
>
> if (command == NAND_CMD_RESET || command == NAND_CMD_READID ||
> - command == NAND_CMD_PARAM || command == NAND_CMD_ERASE1)
> + command == NAND_CMD_PARAM || command == NAND_CMD_ERASE1 ||
> + command == NAND_CMD_STATUS)
I don't like this much, is there another way to derive whether
clear_bam_transaction() is needed? What is the rationale behind it?
> clear_bam_transaction(nandc);
> }
>
> @@ -2867,8 +2893,194 @@ static int qcom_nand_attach_chip(struct nand_chip *chip)
> return 0;
> }
>
> +static int qcom_op_cmd_mapping(struct qcom_nand_controller *nandc, u8 cmd,
> + struct qcom_op *q_op)
> +{
> + int ret = 0;
> +
> + switch (cmd) {
> + case NAND_CMD_RESET:
> + ret = OP_RESET_DEVICE;
> + break;
> + case NAND_CMD_READID:
> + ret = OP_FETCH_ID;
> + break;
> + case NAND_CMD_PARAM:
> + if (nandc->props->qpic_v2)
> + ret = OP_PAGE_READ_ONFI_READ;
> + else
> + ret = OP_PAGE_READ;
> + break;
> + case NAND_CMD_ERASE1:
> + case NAND_CMD_ERASE2:
> + ret = OP_BLOCK_ERASE;
> + break;
> + case NAND_CMD_STATUS:
> + ret = OP_CHECK_STATUS;
> + break;
> + case NAND_CMD_PAGEPROG:
> + ret = OP_PROGRAM_PAGE;
> + break;
> + default:
This should error out and the error be catch in the check_only path.
> + break;
> + }
> +
> + return ret;
> +}
> +
> +/* NAND framework ->exec_op() hooks and related helpers */
> +static void qcom_parse_instructions(struct nand_chip *chip,
> + const struct nand_subop *subop,
> + struct qcom_op *q_op)
> +{
> + struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
> + const struct nand_op_instr *instr = NULL;
> + unsigned int op_id;
> + int i;
> +
> + memset(q_op, 0, sizeof(*q_op));
> +
> + for (op_id = 0; op_id < subop->ninstrs; op_id++) {
> + unsigned int offset, naddrs;
> + const u8 *addrs;
> +
> + instr = &subop->instrs[op_id];
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + q_op->cmd_reg = qcom_op_cmd_mapping(nandc, instr->ctx.cmd.opcode, q_op);
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> +
> + case NAND_OP_ADDR_INSTR:
> + offset = nand_subop_get_addr_start_off(subop, op_id);
> + naddrs = nand_subop_get_num_addr_cyc(subop, op_id);
> + addrs = &instr->ctx.addr.addrs[offset];
> + for (i = 0; i < min(5U, naddrs); i++) {
Is this min() useful? You already limit the number of cycles to 5,
otherwise the pattern won't match, right?
> + if (i < 4)
> + q_op->addr1_reg |= (u32)addrs[i] << i * 8;
> + else
> + q_op->addr2_reg |= addrs[i];
> + }
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + q_op->data_instr = instr;
> + q_op->data_instr_idx = op_id;
> + q_op->rdy_delay_ns = instr->delay_ns;
> + fallthrough;
> + case NAND_OP_DATA_OUT_INSTR:
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> +
> + case NAND_OP_WAITRDY_INSTR:
> + q_op->rdy_timeout_ms = instr->ctx.waitrdy.timeout_ms;
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> + }
> + }
> +}
> +
> +static int qcom_read_status_exec(struct nand_chip *chip,
> + const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_erase_cmd_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_param_page_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_read_id_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_data_read_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + /* currently read_exec_op() return 0 , and all the read operation handle in
> + * actual API itself
> + */
> + return 0;
Please make all exec_op additions in the same patch, unless you're
truly adding a feature, in this case it can be split, but no pattern
should match what's unsupported by ->exec_op(). This way we avoid these
very strange (and wrong) empty functions).
> +}
> +
> +static int qcom_data_write_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + /* currently write_exec_op() return 0, and all the write operation handle in
> + * actual API itself
> + */
> + struct qcom_op q_op;
> +
> + qcom_parse_instructions(chip, subop, &q_op);
> +
> + return 0;
> +}
> +
> +static const struct nand_op_parser qcom_op_parser = NAND_OP_PARSER(
> + NAND_OP_PARSER_PATTERN(
> + qcom_misc_cmd_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(false)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_read_id_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 8)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_param_page_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(true),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 512)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_read_status_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 1)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_erase_cmd_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(false)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_data_read_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(true),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 2048)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_data_write_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(true),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(true, MAX_ADDRESS_CYCLE)),
> + );
> +
> +static int qcom_nand_exec_op(struct nand_chip *chip,
> + const struct nand_operation *op,
> + bool check_only)
> +{
> + if (check_only)
> + return 0;
This is wrong, you cannot blindly return 0 if check_only is true.
> + return nand_op_parser_exec_op(chip, &qcom_op_parser,
> + op, check_only);
> +}
> +
> static const struct nand_controller_ops qcom_nandc_ops = {
> .attach_chip = qcom_nand_attach_chip,
> + .exec_op = qcom_nand_exec_op,
> };
>
> static void qcom_nandc_unalloc(struct qcom_nand_controller *nandc)
Thanks,
Miquèl
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Md Sadre Alam <quic_mdalam@quicinc.com>
Cc: mani@kernel.org, richard@nod.at, vigneshr@ti.com,
linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_srichara@quicinc.com
Subject: Re: [PATCH v2 1/5] mtd: rawnand: qcom: Implement exec_op()
Date: Mon, 22 May 2023 15:35:19 +0200 [thread overview]
Message-ID: <20230522153519.6b574789@xps-13> (raw)
In-Reply-To: <20230511133017.6307-2-quic_mdalam@quicinc.com>
Hello,
quic_mdalam@quicinc.com wrote on Thu, 11 May 2023 19:00:13 +0530:
> Implement exec_op() so we can later get rid of the legacy interface
> implementation.
>
> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
> ---
> Change in [v2]
>
> * Missed to post Cover-letter, so posting v2 patch with cover-letter
>
> drivers/mtd/nand/raw/qcom_nandc.c | 214 +++++++++++++++++++++++++++++-
> 1 file changed, 213 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> index 72d6168d8a1b..dae460e2aa0b 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -157,6 +157,7 @@
> #define OP_PAGE_PROGRAM_WITH_ECC 0x7
> #define OP_PROGRAM_PAGE_SPARE 0x9
> #define OP_BLOCK_ERASE 0xa
> +#define OP_CHECK_STATUS 0xc
> #define OP_FETCH_ID 0xb
> #define OP_RESET_DEVICE 0xd
>
> @@ -235,6 +236,7 @@ nandc_set_reg(chip, reg, \
> */
> #define NAND_ERASED_CW_SET BIT(4)
>
> +#define MAX_ADDRESS_CYCLE 5
> /*
> * This data type corresponds to the BAM transaction which will be used for all
> * NAND transfers.
> @@ -447,6 +449,29 @@ struct qcom_nand_boot_partition {
> u32 page_size;
> };
>
> +/*
> + * Qcom op for each exec_op transfer
> + *
> + * @data_instr: data instruction pointer
> + * @data_instr_idx: data instruction index
> + * @rdy_timeout_ms: wait ready timeout in ms
> + * @rdy_delay_ns: Additional delay in ns
> + * @addr1_reg: Address1 register value
> + * @addr2_reg: Address2 register value
> + * @cmd_reg: CMD register value
> + * @flag: flag for misc instruction
> + */
> +struct qcom_op {
> + const struct nand_op_instr *data_instr;
> + unsigned int data_instr_idx;
> + unsigned int rdy_timeout_ms;
> + unsigned int rdy_delay_ns;
> + u32 addr1_reg;
> + u32 addr2_reg;
> + u32 cmd_reg;
> + u8 flag;
> +};
> +
> /*
> * NAND chip structure
> *
> @@ -1517,7 +1542,8 @@ static void pre_command(struct qcom_nand_host *host, int command)
> clear_read_regs(nandc);
>
> if (command == NAND_CMD_RESET || command == NAND_CMD_READID ||
> - command == NAND_CMD_PARAM || command == NAND_CMD_ERASE1)
> + command == NAND_CMD_PARAM || command == NAND_CMD_ERASE1 ||
> + command == NAND_CMD_STATUS)
I don't like this much, is there another way to derive whether
clear_bam_transaction() is needed? What is the rationale behind it?
> clear_bam_transaction(nandc);
> }
>
> @@ -2867,8 +2893,194 @@ static int qcom_nand_attach_chip(struct nand_chip *chip)
> return 0;
> }
>
> +static int qcom_op_cmd_mapping(struct qcom_nand_controller *nandc, u8 cmd,
> + struct qcom_op *q_op)
> +{
> + int ret = 0;
> +
> + switch (cmd) {
> + case NAND_CMD_RESET:
> + ret = OP_RESET_DEVICE;
> + break;
> + case NAND_CMD_READID:
> + ret = OP_FETCH_ID;
> + break;
> + case NAND_CMD_PARAM:
> + if (nandc->props->qpic_v2)
> + ret = OP_PAGE_READ_ONFI_READ;
> + else
> + ret = OP_PAGE_READ;
> + break;
> + case NAND_CMD_ERASE1:
> + case NAND_CMD_ERASE2:
> + ret = OP_BLOCK_ERASE;
> + break;
> + case NAND_CMD_STATUS:
> + ret = OP_CHECK_STATUS;
> + break;
> + case NAND_CMD_PAGEPROG:
> + ret = OP_PROGRAM_PAGE;
> + break;
> + default:
This should error out and the error be catch in the check_only path.
> + break;
> + }
> +
> + return ret;
> +}
> +
> +/* NAND framework ->exec_op() hooks and related helpers */
> +static void qcom_parse_instructions(struct nand_chip *chip,
> + const struct nand_subop *subop,
> + struct qcom_op *q_op)
> +{
> + struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
> + const struct nand_op_instr *instr = NULL;
> + unsigned int op_id;
> + int i;
> +
> + memset(q_op, 0, sizeof(*q_op));
> +
> + for (op_id = 0; op_id < subop->ninstrs; op_id++) {
> + unsigned int offset, naddrs;
> + const u8 *addrs;
> +
> + instr = &subop->instrs[op_id];
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + q_op->cmd_reg = qcom_op_cmd_mapping(nandc, instr->ctx.cmd.opcode, q_op);
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> +
> + case NAND_OP_ADDR_INSTR:
> + offset = nand_subop_get_addr_start_off(subop, op_id);
> + naddrs = nand_subop_get_num_addr_cyc(subop, op_id);
> + addrs = &instr->ctx.addr.addrs[offset];
> + for (i = 0; i < min(5U, naddrs); i++) {
Is this min() useful? You already limit the number of cycles to 5,
otherwise the pattern won't match, right?
> + if (i < 4)
> + q_op->addr1_reg |= (u32)addrs[i] << i * 8;
> + else
> + q_op->addr2_reg |= addrs[i];
> + }
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + q_op->data_instr = instr;
> + q_op->data_instr_idx = op_id;
> + q_op->rdy_delay_ns = instr->delay_ns;
> + fallthrough;
> + case NAND_OP_DATA_OUT_INSTR:
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> +
> + case NAND_OP_WAITRDY_INSTR:
> + q_op->rdy_timeout_ms = instr->ctx.waitrdy.timeout_ms;
> + q_op->rdy_delay_ns = instr->delay_ns;
> + break;
> + }
> + }
> +}
> +
> +static int qcom_read_status_exec(struct nand_chip *chip,
> + const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_erase_cmd_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_param_page_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_read_id_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + return 0;
> +}
> +
> +static int qcom_data_read_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + /* currently read_exec_op() return 0 , and all the read operation handle in
> + * actual API itself
> + */
> + return 0;
Please make all exec_op additions in the same patch, unless you're
truly adding a feature, in this case it can be split, but no pattern
should match what's unsupported by ->exec_op(). This way we avoid these
very strange (and wrong) empty functions).
> +}
> +
> +static int qcom_data_write_type_exec(struct nand_chip *chip, const struct nand_subop *subop)
> +{
> + /* currently write_exec_op() return 0, and all the write operation handle in
> + * actual API itself
> + */
> + struct qcom_op q_op;
> +
> + qcom_parse_instructions(chip, subop, &q_op);
> +
> + return 0;
> +}
> +
> +static const struct nand_op_parser qcom_op_parser = NAND_OP_PARSER(
> + NAND_OP_PARSER_PATTERN(
> + qcom_misc_cmd_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(false)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_read_id_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 8)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_param_page_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(true),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 512)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_read_status_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 1)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_erase_cmd_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(false)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_data_read_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDRESS_CYCLE),
> + NAND_OP_PARSER_PAT_CMD_ELEM(false),
> + NAND_OP_PARSER_PAT_WAITRDY_ELEM(true),
> + NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 2048)),
> + NAND_OP_PARSER_PATTERN(
> + qcom_data_write_type_exec,
> + NAND_OP_PARSER_PAT_CMD_ELEM(true),
> + NAND_OP_PARSER_PAT_ADDR_ELEM(true, MAX_ADDRESS_CYCLE)),
> + );
> +
> +static int qcom_nand_exec_op(struct nand_chip *chip,
> + const struct nand_operation *op,
> + bool check_only)
> +{
> + if (check_only)
> + return 0;
This is wrong, you cannot blindly return 0 if check_only is true.
> + return nand_op_parser_exec_op(chip, &qcom_op_parser,
> + op, check_only);
> +}
> +
> static const struct nand_controller_ops qcom_nandc_ops = {
> .attach_chip = qcom_nand_attach_chip,
> + .exec_op = qcom_nand_exec_op,
> };
>
> static void qcom_nandc_unalloc(struct qcom_nand_controller *nandc)
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-05-22 13:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 13:30 [PATCH 0/5] mtd: rawnand: qcom: Implement exec_op() Md Sadre Alam
2023-05-11 13:30 ` Md Sadre Alam
2023-05-11 13:30 ` [PATCH v2 1/5] " Md Sadre Alam
2023-05-11 13:30 ` Md Sadre Alam
2023-05-22 13:35 ` Miquel Raynal [this message]
2023-05-22 13:35 ` Miquel Raynal
2023-05-24 9:13 ` Md Sadre Alam
2023-05-24 9:13 ` Md Sadre Alam
2023-05-11 13:30 ` [PATCH v2 2/5] mtd: rawnand: qcom: Add support for reset, readid, status exec_op Md Sadre Alam
2023-05-11 13:30 ` Md Sadre Alam
2023-05-22 13:45 ` Miquel Raynal
2023-05-22 13:45 ` Miquel Raynal
2023-05-24 9:24 ` Md Sadre Alam
2023-05-24 9:24 ` Md Sadre Alam
2023-05-26 17:27 ` Miquel Raynal
2023-05-26 17:27 ` Miquel Raynal
2023-05-11 13:30 ` [PATCH v2 3/5] mtd: rawnand: qcom: Add support for param_page read exec_ops Md Sadre Alam
2023-05-11 13:30 ` Md Sadre Alam
2023-05-22 13:49 ` Miquel Raynal
2023-05-22 13:49 ` Miquel Raynal
2023-05-24 9:28 ` Md Sadre Alam
2023-05-24 9:28 ` Md Sadre Alam
2023-05-11 13:30 ` [PATCH v2 4/5] mtd: rawnand: qcom: Add support for read, write, erase exec_ops Md Sadre Alam
2023-05-11 13:30 ` Md Sadre Alam
2023-05-22 13:53 ` Miquel Raynal
2023-05-22 13:53 ` Miquel Raynal
2023-05-24 9:32 ` Md Sadre Alam
2023-05-24 9:32 ` Md Sadre Alam
2023-05-11 13:30 ` [PATCH v2 5/5] mtd: rawnand: qcom: Remove legacy interface implementation Md Sadre Alam
2023-05-11 13:30 ` Md Sadre Alam
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=20230522153519.6b574789@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mani@kernel.org \
--cc=quic_mdalam@quicinc.com \
--cc=quic_srichara@quicinc.com \
--cc=richard@nod.at \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.