From: keith.busch@intel.com (Busch, Keith)
Subject: [PATCH 06/18] nvme: split a new struct nvme_ctrl out of struct nvme_dev
Date: Wed, 21 Oct 2015 22:51:00 +0000 [thread overview]
Message-ID: <20151021225059.GA21840@localhost.localdomain> (raw)
In-Reply-To: <1445462626.3307.64.camel@linux.intel.com>
On Wed, Oct 21, 2015@02:23:46PM -0700, J Freyensee wrote:
> > char firmware_rev[8];
> > - bool subsystem;
>
> Also, this is something probably a bit more far visioned, but I think
> struct nvme_ctrl would need a mechanism to know what NVMe subsystem it
> sits in. Even if 'subsystem' stayed in the struct, I'm not sure how a
> bool would work for this.
The bool is not to identify a specific subsystem. It's only to notify
the driver that this controller is subsystem capable. In other words,
please periodically check the subsystem reset notification since that
can happen at anytime externally from host connected to the controller,
and we want to know when such events occur.
> > @@ -78,7 +48,7 @@ struct nvme_dev {
> > struct nvme_ns {
> > struct list_head list;
> >
> > - struct nvme_dev *dev;
> > + struct nvme_ctrl *ctrl;
>
> This seems a bit backwards to me. It's the controller (cntlid) that is
> going to tell the host how many namespaces are associated with it via
> the NVMe Identify commands. Thus, I would have thought that a list of
> struct nvme_ns instances would be in a struct nvme_ctrl definition, not
> vice-versa. Unless '*ctrl' is going to be used as a back pointer? But
> then in 'struct nvme_ctrl' I didn't see initially see anything that
> associates itself to the namespaces attached to it.
The 'ctrl' pointer is a back pointer to the owning controller.
The controller itself contains a list_head appropriately called
'namespaces' to hold a reference to all its namespaces. The nvme_ns
list_head 'list' is simply the entry item for that list.
next prev parent reply other threads:[~2015-10-21 22:51 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 5:58 nvme driver split V2 Christoph Hellwig
2015-10-16 5:58 ` [PATCH 01/18] nvme: add missing unmaps in nvme_queue_rq Christoph Hellwig
2015-10-20 10:04 ` Sagi Grimberg
2015-10-20 14:07 ` Busch, Keith
2015-10-16 5:58 ` [PATCH 02/18] nvme: move struct nvme_iod to pci.c Christoph Hellwig
2015-10-20 10:04 ` Sagi Grimberg
2015-10-16 5:58 ` [PATCH 03/18] nvme: split command submission helpers out of pci.c Christoph Hellwig
2015-10-20 10:07 ` Sagi Grimberg
2015-10-21 18:48 ` J Freyensee
2015-10-16 5:58 ` [PATCH 04/18] nvme: add a vendor field to struct nvme_dev Christoph Hellwig
2015-10-20 10:08 ` Sagi Grimberg
2015-10-21 18:58 ` J Freyensee
2015-10-21 19:10 ` Busch, Keith
2015-10-16 5:58 ` [PATCH 05/18] nvme: use offset instead of a struct for registers Christoph Hellwig
2015-10-16 17:30 ` Busch, Keith
2015-10-21 20:28 ` J Freyensee
2015-10-16 5:58 ` [PATCH 06/18] nvme: split a new struct nvme_ctrl out of struct nvme_dev Christoph Hellwig
2015-10-20 10:19 ` Sagi Grimberg
2015-10-20 10:26 ` Christoph Hellwig
2015-10-20 10:44 ` Sagi Grimberg
2015-10-20 11:30 ` Christoph Hellwig
2015-10-21 14:40 ` Sagi Grimberg
2015-10-21 21:23 ` J Freyensee
2015-10-21 22:51 ` Busch, Keith [this message]
2015-10-22 0:15 ` J Freyensee
2015-10-22 7:37 ` Christoph Hellwig
2015-10-16 5:58 ` [PATCH 07/18] nvme: simplify nvme_setup_prps calling convention Christoph Hellwig
2015-10-20 10:30 ` Sagi Grimberg
2015-10-16 5:58 ` [PATCH 08/18] nvme: refactor nvme_queue_rq Christoph Hellwig
2015-10-16 5:58 ` [PATCH 09/18] nvme: move nvme_error_status to common code Christoph Hellwig
2015-10-20 10:54 ` Sagi Grimberg
2015-10-16 5:58 ` [PATCH 10/18] nvme: move nvme_setup_flush and nvme_setup_rw " Christoph Hellwig
2015-10-20 11:01 ` Sagi Grimberg
2015-10-21 6:55 ` Christoph Hellwig
2015-10-21 14:41 ` Sagi Grimberg
2015-10-16 5:58 ` [PATCH 11/18] nvme: split __nvme_submit_sync_cmd Christoph Hellwig
2015-10-16 5:58 ` [PATCH 12/18] nvme: use the block layer for userspace passthrough metadata Christoph Hellwig
2015-10-16 20:04 ` Busch, Keith
2015-10-18 18:22 ` Christoph Hellwig
2015-10-16 5:58 ` [PATCH 13/18] nvme: move block_device_operations and ns/ctrl freeing to common code Christoph Hellwig
2015-10-16 5:58 ` [PATCH 14/18] nvme: add explicit quirk handling Christoph Hellwig
2015-10-16 5:58 ` [PATCH 15/18] nvme: add a common helper to read Identify Controller data Christoph Hellwig
2015-10-21 22:44 ` J Freyensee
2015-10-22 7:38 ` Christoph Hellwig
2015-10-16 5:58 ` [PATCH 16/18] nvme: move the call to nvme_init_identify earlier Christoph Hellwig
2015-10-16 5:58 ` [PATCH 17/18] nvme: move namespace scanning to common code Christoph Hellwig
2015-10-16 6:14 ` Ming Lin
2015-10-16 6:16 ` Christoph Hellwig
2015-10-21 23:27 ` J Freyensee
2015-10-22 7:39 ` Christoph Hellwig
2015-10-22 13:48 ` Busch, Keith
2015-10-22 16:30 ` Christoph Hellwig
2015-10-22 21:24 ` Busch, Keith
2015-10-23 5:41 ` Christoph Hellwig
2015-10-16 5:58 ` [PATCH 18/18] nvme: move chardev and sysfs interface " Christoph Hellwig
2015-10-22 0:11 ` J Freyensee
2015-10-22 7:45 ` Christoph Hellwig
2015-10-22 18:36 ` J Freyensee
2015-10-22 18:59 ` Jon Derrick
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=20151021225059.GA21840@localhost.localdomain \
--to=keith.busch@intel.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).