[PATCH] nvme-fc: use pci device as parent for nvme controller

[PATCH] nvme-fc: use pci device as parent for nvme controller

[Hannes Reinecke]

To allow system tools to figure out which pci device provides a
given NVMe controller this patch moves the nvme controller sysfs
entry as a child of the PCI device.

With this tools like dracut can traverse the device hierarchy to figure
out which modules to include.

Signed-off-by: Hannes Reinecke <hare at suse.com>
---
 drivers/nvme/host/fc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index feb86b59170e..1ecdec6b8b4a 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -3117,7 +3117,7 @@ nvme_fc_init_ctrl(struct device *dev, struct nvmf_ctrl_options *opts,
 	 * Defer this to the connect path.
 	 */
 
-	ret = nvme_init_ctrl(&ctrl->ctrl, dev, &nvme_fc_ctrl_ops, 0);
+	ret = nvme_init_ctrl(&ctrl->ctrl, ctrl->dev, &nvme_fc_ctrl_ops, 0);
 	if (ret)
 		goto out_cleanup_admin_q;
 
-- 
2.16.4

[PATCH] nvme-fc: use pci device as parent for nvme controller

[Christoph Hellwig]

On Thu, Jan 17, 2019@08:42:41AM +0100, Hannes Reinecke wrote:
> To allow system tools to figure out which pci device provides a
> given NVMe controller this patch moves the nvme controller sysfs
> entry as a child of the PCI device.
> 
> With this tools like dracut can traverse the device hierarchy to figure
> out which modules to include.

Doesn't ->create_ctrl consumer the reference to the passed in device,
or in other words you create a leak on the fabrics device here?

[PATCH] nvme-fc: use pci device as parent for nvme controller

[James Smart]

On 1/16/2019 11:42 PM, Hannes Reinecke wrote:
> To allow system tools to figure out which pci device provides a
> given NVMe controller this patch moves the nvme controller sysfs
> entry as a child of the PCI device.
>
> With this tools like dracut can traverse the device hierarchy to figure
> out which modules to include.
>
> Signed-off-by: Hannes Reinecke <hare at suse.com>
> ---
>   drivers/nvme/host/fc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
> index feb86b59170e..1ecdec6b8b4a 100644
> --- a/drivers/nvme/host/fc.c
> +++ b/drivers/nvme/host/fc.c
> @@ -3117,7 +3117,7 @@ nvme_fc_init_ctrl(struct device *dev, struct nvmf_ctrl_options *opts,
>   	 * Defer this to the connect path.
>   	 */
>   
> -	ret = nvme_init_ctrl(&ctrl->ctrl, dev, &nvme_fc_ctrl_ops, 0);
> +	ret = nvme_init_ctrl(&ctrl->ctrl, ctrl->dev, &nvme_fc_ctrl_ops, 0);
>   	if (ret)
>   		goto out_cleanup_admin_q;
>   

So how do you solve this with rdma and tcp ??? I'm not sure I like 
deviating from them.? Did it pick up the fc-nvme and fabric modules too ?

I think this is one more reason the FC transport needs to be pulled out 
of scsi and layered under the pci device, then shared by scsi and nvme.

-- james

[PATCH] nvme-fc: use pci device as parent for nvme controller

[Hannes Reinecke]

On 1/19/19 2:08 PM, Christoph Hellwig wrote:
> On Thu, Jan 17, 2019@08:42:41AM +0100, Hannes Reinecke wrote:
>> To allow system tools to figure out which pci device provides a
>> given NVMe controller this patch moves the nvme controller sysfs
>> entry as a child of the PCI device.
>>
>> With this tools like dracut can traverse the device hierarchy to figure
>> out which modules to include.
> 
> Doesn't ->create_ctrl consumer the reference to the passed in device,
> or in other words you create a leak on the fabrics device here?
> 
Hmm. Have to check.

Cheers,

Hannes

-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare at suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: F. Imend?rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG N?rnberg)

[PATCH] nvme-fc: use pci device as parent for nvme controller

[Christoph Hellwig]

On Sun, Jan 20, 2019@08:38:59AM -0800, James Smart wrote:
>> diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
>> index feb86b59170e..1ecdec6b8b4a 100644
>> --- a/drivers/nvme/host/fc.c
>> +++ b/drivers/nvme/host/fc.c
>> @@ -3117,7 +3117,7 @@ nvme_fc_init_ctrl(struct device *dev, struct nvmf_ctrl_options *opts,
>>   	 * Defer this to the connect path.
>>   	 */
>>   -	ret = nvme_init_ctrl(&ctrl->ctrl, dev, &nvme_fc_ctrl_ops, 0);
>> +	ret = nvme_init_ctrl(&ctrl->ctrl, ctrl->dev, &nvme_fc_ctrl_ops, 0);
>>   	if (ret)
>>   		goto out_cleanup_admin_q;
>>   
>
> So how do you solve this with rdma and tcp ??? I'm not sure I like 
> deviating from them.? Did it pick up the fc-nvme and fabric modules too ?

All fabrics drivers currently use the passed in 'fake' fabrics device.