From: Roger Quadros <rogerq@ti.com>
To: <computersforpeace@gmail.com>
Cc: nm@ti.com, nsekhar@ti.com, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org,
ezequiel.garcia@free-electrons.com, dwmw2@infradead.org
Subject: Re: [PATCH] mtd: nand: Prevent possible kernel lockup in nand_command()
Date: Tue, 24 Mar 2015 14:31:59 +0200 [thread overview]
Message-ID: <5511593F.2080407@ti.com> (raw)
In-Reply-To: <1424705199-11337-1-git-send-email-rogerq@ti.com>
Hi,
On 23/02/15 17:26, Roger Quadros wrote:
> If a NAND device is not really present or pin muxes are not correctly
> configured we can lock up the kernel waiting infinitely for NAND_STATUS
> to be ready.
>
> This can be easily reproduced on TI's DRA7-evm board by booting it
> without NAND support in u-boot and disabling NAND pin muxes in the kernel.
>
> Add timeout when waiting for NAND_CMD_RESET completion. As per ONFi v4.0
> tRST can be upto 250ms for EZ-NAND and 5ms for raw NAND.
Any comments on this patch?
cheers,
-roger
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Tested-by: Nishanth Menon <nm@ti.com>
> ---
> drivers/mtd/nand/nand_base.c | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index df7eb4f..d1e6695 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -566,6 +566,25 @@ void nand_wait_ready(struct mtd_info *mtd)
> EXPORT_SYMBOL_GPL(nand_wait_ready);
>
> /**
> + * nand_wait_status_ready - [GENERIC] Wait for the ready status after commands.
> + * @mtd: MTD device structure
> + * @timeo: Timeout in ms
> + *
> + * Wait for status ready (i.e. command done) or timeout.
> + */
> +static void nand_wait_status_ready(struct mtd_info *mtd, unsigned long timeo)
> +{
> + register struct nand_chip *chip = mtd->priv;
> +
> + timeo = jiffies + msecs_to_jiffies(timeo);
> + do {
> + if ((chip->read_byte(mtd) & NAND_STATUS_READY))
> + break;
> + touch_softlockup_watchdog();
> + } while (time_before(jiffies, timeo));
> +};
> +
> +/**
> * nand_command - [DEFAULT] Send command to NAND device
> * @mtd: MTD device structure
> * @command: the command to be sent
> @@ -643,8 +662,8 @@ static void nand_command(struct mtd_info *mtd, unsigned int command,
> NAND_CTRL_CLE | NAND_CTRL_CHANGE);
> chip->cmd_ctrl(mtd,
> NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE);
> - while (!(chip->read_byte(mtd) & NAND_STATUS_READY))
> - ;
> + /* EZ-NAND can take upto 250ms as per ONFi v4.0 */
> + nand_wait_status_ready(mtd, 250);
> return;
>
> /* This applies to read commands */
> @@ -740,8 +759,8 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
> NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
> chip->cmd_ctrl(mtd, NAND_CMD_NONE,
> NAND_NCE | NAND_CTRL_CHANGE);
> - while (!(chip->read_byte(mtd) & NAND_STATUS_READY))
> - ;
> + /* EZ-NAND can take upto 250ms as per ONFi v4.0 */
> + nand_wait_status_ready(mtd, 250);
> return;
>
> case NAND_CMD_RNDOUT:
>
WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com>
To: <computersforpeace@gmail.com>
Cc: <dwmw2@infradead.org>, <ezequiel.garcia@free-electrons.com>,
<nsekhar@ti.com>, <nm@ti.com>, <linux-mtd@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd: nand: Prevent possible kernel lockup in nand_command()
Date: Tue, 24 Mar 2015 14:31:59 +0200 [thread overview]
Message-ID: <5511593F.2080407@ti.com> (raw)
In-Reply-To: <1424705199-11337-1-git-send-email-rogerq@ti.com>
Hi,
On 23/02/15 17:26, Roger Quadros wrote:
> If a NAND device is not really present or pin muxes are not correctly
> configured we can lock up the kernel waiting infinitely for NAND_STATUS
> to be ready.
>
> This can be easily reproduced on TI's DRA7-evm board by booting it
> without NAND support in u-boot and disabling NAND pin muxes in the kernel.
>
> Add timeout when waiting for NAND_CMD_RESET completion. As per ONFi v4.0
> tRST can be upto 250ms for EZ-NAND and 5ms for raw NAND.
Any comments on this patch?
cheers,
-roger
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Tested-by: Nishanth Menon <nm@ti.com>
> ---
> drivers/mtd/nand/nand_base.c | 27 +++++++++++++++++++++++----
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index df7eb4f..d1e6695 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -566,6 +566,25 @@ void nand_wait_ready(struct mtd_info *mtd)
> EXPORT_SYMBOL_GPL(nand_wait_ready);
>
> /**
> + * nand_wait_status_ready - [GENERIC] Wait for the ready status after commands.
> + * @mtd: MTD device structure
> + * @timeo: Timeout in ms
> + *
> + * Wait for status ready (i.e. command done) or timeout.
> + */
> +static void nand_wait_status_ready(struct mtd_info *mtd, unsigned long timeo)
> +{
> + register struct nand_chip *chip = mtd->priv;
> +
> + timeo = jiffies + msecs_to_jiffies(timeo);
> + do {
> + if ((chip->read_byte(mtd) & NAND_STATUS_READY))
> + break;
> + touch_softlockup_watchdog();
> + } while (time_before(jiffies, timeo));
> +};
> +
> +/**
> * nand_command - [DEFAULT] Send command to NAND device
> * @mtd: MTD device structure
> * @command: the command to be sent
> @@ -643,8 +662,8 @@ static void nand_command(struct mtd_info *mtd, unsigned int command,
> NAND_CTRL_CLE | NAND_CTRL_CHANGE);
> chip->cmd_ctrl(mtd,
> NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE);
> - while (!(chip->read_byte(mtd) & NAND_STATUS_READY))
> - ;
> + /* EZ-NAND can take upto 250ms as per ONFi v4.0 */
> + nand_wait_status_ready(mtd, 250);
> return;
>
> /* This applies to read commands */
> @@ -740,8 +759,8 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
> NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
> chip->cmd_ctrl(mtd, NAND_CMD_NONE,
> NAND_NCE | NAND_CTRL_CHANGE);
> - while (!(chip->read_byte(mtd) & NAND_STATUS_READY))
> - ;
> + /* EZ-NAND can take upto 250ms as per ONFi v4.0 */
> + nand_wait_status_ready(mtd, 250);
> return;
>
> case NAND_CMD_RNDOUT:
>
next prev parent reply other threads:[~2015-03-24 12:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 15:26 [PATCH] mtd: nand: Prevent possible kernel lockup in nand_command() Roger Quadros
2015-02-23 15:26 ` Roger Quadros
2015-03-24 12:31 ` Roger Quadros [this message]
2015-03-24 12:31 ` Roger Quadros
2015-03-31 0:45 ` Brian Norris
2015-03-31 0:45 ` Brian Norris
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=5511593F.2080407@ti.com \
--to=rogerq@ti.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nm@ti.com \
--cc=nsekhar@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.