nvme_fc: add controller reset support
authorJames Smart <jsmart2021@gmail.com>
Sun, 23 Apr 2017 15:30:08 +0000 (08:30 -0700)
committerChristoph Hellwig <hch@lst.de>
Mon, 24 Apr 2017 07:16:29 +0000 (09:16 +0200)
commit61bff8ef0088459e32bc0a7cc8c23144d324df90
tree7e0bad9d95fc9a13d44350b397dacb977598e9c4
parent78a7ac260e38d511d3f62a9e574cf34aac48d7d3
nvme_fc: add controller reset support

This patch actually does quite a few things.  When looking to add
controller reset support, the organization modeled after rdma was
very fragmented. rdma duplicates the reset and teardown paths and does
different things to the block layer on the two paths. The code to build
up the controller is also duplicated between the initial creation and
the reset/error recovery paths. So I decided to make this sane.

I reorganized the controller creation and teardown so that there is a
connect path and a disconnect path.  Initial creation obviously uses
the connect path.  Controller teardown will use the disconnect path,
followed last access code. Controller reset will use the disconnect
path to stop operation, and then the connect path to re-establish
the controller.

Along the way, several things were fixed
- aens were not properly set up. They are allocated differently from
  the per-request structure on the blk queues.
- aens were oddly torn down. the prior patch corrected to abort, but
  we still need to dma unmap and free relative elements.
- missed a few ref counting points: in aen completion and on i/o's
  that fail
- controller initial create failure paths were still confused vs teardown
  before converting to ref counting vs after we convert to refcounting.

Signed-off-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
drivers/nvme/host/fc.c