From: Christoph Hellwig <hch@lst.de>
To: Balbir Singh <sblbir@amzn.com>
Cc: kbusch@kernel.org, axboe@fb.com, hch@lst.de,
linux-nvme@lists.infradead.org, sagi@grimberg.me
Subject: Re: [PATCH v2 2/2] nvme/host/core: Allow overriding of wait_ready timeout
Date: Mon, 16 Sep 2019 09:41:53 +0200 [thread overview]
Message-ID: <20190916074153.GA25606@lst.de> (raw)
In-Reply-To: <20190913233631.15352-2-sblbir@amzn.com>
On Fri, Sep 13, 2019 at 11:36:31PM +0000, Balbir Singh wrote:
> +unsigned int nvme_wait_ready_timeout = 0;
> +module_param_named(wait_ready_timeout, nvme_wait_ready_timeout, uint, 0644);
> +MODULE_PARM_DESC(wait_ready_timeout, "timeout in seconds for wait ready on reset");
This is only used in core.c, so it can be marked static.
Also it introduces a > 80 char line.
> +
> static unsigned char shutdown_timeout = 5;
> module_param(shutdown_timeout, byte, 0644);
> MODULE_PARM_DESC(shutdown_timeout, "timeout in seconds for controller shutdown");
> @@ -1938,6 +1942,9 @@ static int nvme_wait_ready(struct nvme_ctrl *ctrl, u64 cap, bool enabled)
> u32 csts, bit = enabled ? NVME_CSTS_RDY : 0;
> int ret;
>
> + if (nvme_wait_ready_timeout)
> + timeout = NVME_WAIT_READY_TIMEOUT + jiffies;
I'm not sure the NVME_WAIT_READY_TIMEOUT #define really helps much here.
Also the code is a little confusing as as, why not and if / else with
the normal timeout definition?
Then again I'm not even sure we really want this. The debugging use
case is somethign where you can easily hack a line in the driver, and
we really don't want normal users to mess with a random parameter like
this one.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2019-09-16 7:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 23:36 [PATCH v2 1/2] nvme/host/pci: Fix a race in controller removal Balbir Singh
2019-09-13 23:36 ` [PATCH v2 2/2] nvme/host/core: Allow overriding of wait_ready timeout Balbir Singh
2019-09-16 7:41 ` Christoph Hellwig [this message]
2019-09-16 12:33 ` Singh, Balbir
2019-09-16 16:01 ` hch
2019-09-16 21:04 ` Singh, Balbir
2019-09-17 1:14 ` Keith Busch
2019-09-17 2:56 ` Singh, Balbir
2019-09-17 3:17 ` Bart Van Assche
2019-09-17 5:02 ` Singh, Balbir
2019-09-17 17:21 ` James Smart
2019-09-17 20:08 ` James Smart
2019-09-17 3:54 ` Keith Busch
2019-09-16 7:49 ` [PATCH v2 1/2] nvme/host/pci: Fix a race in controller removal Christoph Hellwig
2019-09-16 12:07 ` Singh, Balbir
2019-09-16 15:40 ` Bart Van Assche
2019-09-16 19:38 ` Singh, Balbir
2019-09-16 19:56 ` Bart Van Assche
2019-09-16 20:40 ` Singh, Balbir
2019-09-17 17:55 ` Bart Van Assche
2019-09-17 20:30 ` Keith Busch
2019-09-17 20:44 ` Singh, Balbir
2019-09-16 20:07 ` Keith Busch
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=20190916074153.GA25606@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=sblbir@amzn.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.