All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Christian Marangi <ansuelsmth@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Md Sadre Alam <quic_mdalam@quicinc.com>,
	Sricharan Ramabadhran <quic_srichara@quicinc.com>,
	linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/2] mtd: rawnand: qcom: Fix broken erase in misc_cmd_type in exec_op
Date: Thu, 28 Mar 2024 09:17:32 +0530	[thread overview]
Message-ID: <20240328034732.GA3212@thinkpad> (raw)
In-Reply-To: <20240327175131.3c0100c3@xps-13>

On Wed, Mar 27, 2024 at 05:51:31PM +0100, Miquel Raynal wrote:
> Hi,
> 
> ansuelsmth@gmail.com wrote on Wed, 27 Mar 2024 16:20:58 +0100:
> 
> > On Tue, Mar 26, 2024 at 12:55:12PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:  
> > > > misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409
> > > > ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was
> > > > reworked and generalized but actually broke the handling of the
> > > > ERASE_BLOCK command.
> > > > 
> > > > Additional logic was added to the erase command cycle without clear
> > > > explaination causing the erase command to be broken on testing it on
> > > > a ipq806x nandc.
> > > > 
> > > > Fix the erase command by reverting the additional logic and only adding
> > > > the NAND_DEV0_CFG0 additional call (required for erase command).
> > > > 
> > > > Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > ---
> > > > Changes v2:
> > > > - Split this and rework commit description and title
> > > > 
> > > >  drivers/mtd/nand/raw/qcom_nandc.c | 5 ++---
> > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> > > > index b079605c84d3..19d76e345a49 100644
> > > > --- a/drivers/mtd/nand/raw/qcom_nandc.c
> > > > +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> > > > @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub
> > > >  	nandc_set_reg(chip, NAND_EXEC_CMD, 1);
> > > >  
> > > >  	write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
> > > > -	(q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
> > > > -	2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
> > > > -	NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
> > > > +	if (q_op.cmd_reg == OP_BLOCK_ERASE)
> > > > +		write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);  
> > > 
> > > So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1,
> > > NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg ==
> > > OP_BLOCK_ERASE, the result is the same.
> > > 
> > > I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
> > > 
> > > Can you share the actual issue that you are seeing? Like error logs etc...
> > >  
> > 
> > Issue is that nandc goes to ADM timeout as soon as a BLOCK_ERASE is
> > called. BLOCK_ERASE operation match also another operation from MTD
> > read. (parser also maps to other stuff)
> > 
> > I will be away from the testing board for 7-10 days so I can't provide
> > logs currently.
> 
> So, shall we wait for additional logs from Christian or shall I merge
> the two-patches series? I'm not sure what's the status anymore.
> 

TBH, I don't know how OP_BLOCK_ERASE can fail without this change. But I can
clearly see the 2 patches required for OP_RESET_DEVICE command. But merging the
patches as it is doesn't look good to me.

So I think if Christian can club the two patches into 1 as like v1 and reword
the commit message and subject to reflect the fact that OP_RESET_DEVICE command
is being fixed would work for me.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Christian Marangi <ansuelsmth@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Md Sadre Alam <quic_mdalam@quicinc.com>,
	Sricharan Ramabadhran <quic_srichara@quicinc.com>,
	linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/2] mtd: rawnand: qcom: Fix broken erase in misc_cmd_type in exec_op
Date: Thu, 28 Mar 2024 09:17:32 +0530	[thread overview]
Message-ID: <20240328034732.GA3212@thinkpad> (raw)
In-Reply-To: <20240327175131.3c0100c3@xps-13>

On Wed, Mar 27, 2024 at 05:51:31PM +0100, Miquel Raynal wrote:
> Hi,
> 
> ansuelsmth@gmail.com wrote on Wed, 27 Mar 2024 16:20:58 +0100:
> 
> > On Tue, Mar 26, 2024 at 12:55:12PM +0530, Manivannan Sadhasivam wrote:
> > > On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:  
> > > > misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409
> > > > ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was
> > > > reworked and generalized but actually broke the handling of the
> > > > ERASE_BLOCK command.
> > > > 
> > > > Additional logic was added to the erase command cycle without clear
> > > > explaination causing the erase command to be broken on testing it on
> > > > a ipq806x nandc.
> > > > 
> > > > Fix the erase command by reverting the additional logic and only adding
> > > > the NAND_DEV0_CFG0 additional call (required for erase command).
> > > > 
> > > > Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > ---
> > > > Changes v2:
> > > > - Split this and rework commit description and title
> > > > 
> > > >  drivers/mtd/nand/raw/qcom_nandc.c | 5 ++---
> > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
> > > > index b079605c84d3..19d76e345a49 100644
> > > > --- a/drivers/mtd/nand/raw/qcom_nandc.c
> > > > +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> > > > @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub
> > > >  	nandc_set_reg(chip, NAND_EXEC_CMD, 1);
> > > >  
> > > >  	write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
> > > > -	(q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
> > > > -	2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
> > > > -	NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
> > > > +	if (q_op.cmd_reg == OP_BLOCK_ERASE)
> > > > +		write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);  
> > > 
> > > So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1,
> > > NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg ==
> > > OP_BLOCK_ERASE, the result is the same.
> > > 
> > > I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
> > > 
> > > Can you share the actual issue that you are seeing? Like error logs etc...
> > >  
> > 
> > Issue is that nandc goes to ADM timeout as soon as a BLOCK_ERASE is
> > called. BLOCK_ERASE operation match also another operation from MTD
> > read. (parser also maps to other stuff)
> > 
> > I will be away from the testing board for 7-10 days so I can't provide
> > logs currently.
> 
> So, shall we wait for additional logs from Christian or shall I merge
> the two-patches series? I'm not sure what's the status anymore.
> 

TBH, I don't know how OP_BLOCK_ERASE can fail without this change. But I can
clearly see the 2 patches required for OP_RESET_DEVICE command. But merging the
patches as it is doesn't look good to me.

So I think if Christian can club the two patches into 1 as like v1 and reword
the commit message and subject to reflect the fact that OP_RESET_DEVICE command
is being fixed would work for me.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2024-03-28  3:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-25 10:30 [PATCH v2 1/2] mtd: rawnand: qcom: Fix broken erase in misc_cmd_type in exec_op Christian Marangi
2024-03-25 10:30 ` Christian Marangi
2024-03-25 10:30 ` [PATCH v2 2/2] mtd: rawnand: qcom: Fix broken reset " Christian Marangi
2024-03-25 10:30   ` Christian Marangi
2024-03-26  7:42   ` Manivannan Sadhasivam
2024-03-26  7:42     ` Manivannan Sadhasivam
2024-03-26  7:25 ` [PATCH v2 1/2] mtd: rawnand: qcom: Fix broken erase " Manivannan Sadhasivam
2024-03-26  7:25   ` Manivannan Sadhasivam
2024-03-26  7:39   ` Manivannan Sadhasivam
2024-03-26  7:39     ` Manivannan Sadhasivam
2024-03-27 14:41     ` Christian Marangi
2024-03-27 14:41       ` Christian Marangi
2024-03-27 15:20   ` Christian Marangi
2024-03-27 15:20     ` Christian Marangi
2024-03-27 16:51     ` Miquel Raynal
2024-03-27 16:51       ` Miquel Raynal
2024-03-28  3:47       ` Manivannan Sadhasivam [this message]
2024-03-28  3:47         ` Manivannan Sadhasivam
2024-03-28 14:22         ` Christian Marangi
2024-03-28 14:22           ` Christian Marangi

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=20240328034732.GA3212@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=ansuelsmth@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=quic_mdalam@quicinc.com \
    --cc=quic_srichara@quicinc.com \
    --cc=richard@nod.at \
    --cc=stable@vger.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 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.