From: "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org" <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: Bart Van Assche <Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"parav-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org"
<parav-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
"sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org"
<sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
"linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org"
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
"hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org"
<hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
"mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org"
<dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
"bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org"
<bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org"
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev
Date: Tue, 7 Mar 2017 18:14:03 +0100 [thread overview]
Message-ID: <20170307171403.GA19293@kroah.com> (raw)
In-Reply-To: <1488905685.2739.1.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On Tue, Mar 07, 2017 at 04:54:58PM +0000, Bart Van Assche wrote:
> On Tue, 2017-03-07 at 05:52 +0100, Greg Kroah-Hartman wrote:
> > Somehow all other subsystems work just fine, don't instantly think that
> > the driver core needs to bend to the will of the IB code, because you
> > are somehow "special". Hint, you aren't :)
>
> Hi Greg,
>
> In another e-mail Parav compared IB drivers with networking drivers.
Great, then notice that networking drivers don't need to do this type of
crud :)
> But I think that's a bad comparison: in the networking stack it's the
> network driver itself that sets up and triggers DMA while in the IB
> stack it's the upper layer protocol (ULP) driver that calls the
> functions defined in struct dma_ops. For some IB HW drivers (hfi1, qib
> and rdma_rxe) the ULP driver must
> use the DMA mapping operations from lib/dma-virt.c while for all other IB HW
> drivers the ULP driver must use the PCI DMA mapping functions. The ib_dma_*()
> functions select the right DMA mapping operations - either the PCI DMA
> mapping operations or those from lib/dma-virt.c. My question to you is how we
> should organize struct ib_device such that we can get rid of the ib_dma_*()
> helper functions. How to make sure that the to_pci_dev() translation works
> correctly for the device structure that is embedded in struct ib_device?
> Should a pointer to struct pci_dev be embedded in struct device (as done in
> patch 1/2 in this series)
I already said no to this, why do you think that it is still ok?
> or should the struct device in ib_device be changed
> into a struct pci_dev
Ick, no.
> and should the pci_dev information from /sys/devices/pci*/*/* be
> duplicated into the pci_dev information in struct ib_device
> (/sys/devices/pci*/*/*/infiniband/*)?
I don't think you really thought that one through :)
> For the latter approach, would
> there be a risk that the duplicated information becomes inconsistent?
No, it just wouldn't work :)
Why not just save off a pointer to your pci_dev in your ib_device
structure? That way you know what the type is, and you have access to
everything you need.
But hey, I know nothing about IB and I really want to keep it that way.
You do what you want to, as long as you don't abuse the driver model,
like your patch 1/2 did. Remember, not all the world is IB.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"parav@mellanox.com" <parav@mellanox.com>,
"sebott@linux.vnet.ibm.com" <sebott@linux.vnet.ibm.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"dledford@redhat.com" <dledford@redhat.com>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>
Subject: Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev
Date: Tue, 7 Mar 2017 18:14:03 +0100 [thread overview]
Message-ID: <20170307171403.GA19293@kroah.com> (raw)
In-Reply-To: <1488905685.2739.1.camel@sandisk.com>
On Tue, Mar 07, 2017 at 04:54:58PM +0000, Bart Van Assche wrote:
> On Tue, 2017-03-07 at 05:52 +0100, Greg Kroah-Hartman wrote:
> > Somehow all other subsystems work just fine, don't instantly think that
> > the driver core needs to bend to the will of the IB code, because you
> > are somehow "special". Hint, you aren't :)
>
> Hi Greg,
>
> In another e-mail Parav compared IB drivers with networking drivers.
Great, then notice that networking drivers don't need to do this type of
crud :)
> But I think that's a bad comparison: in the networking stack it's the
> network driver itself that sets up and triggers DMA while in the IB
> stack it's the upper layer protocol (ULP) driver that calls the
> functions defined in struct dma_ops. For some IB HW drivers (hfi1, qib
> and rdma_rxe) the ULP driver must
> use the DMA mapping operations from lib/dma-virt.c while for all other IB HW
> drivers the ULP driver must use the PCI DMA mapping functions. The ib_dma_*()
> functions select the right DMA mapping operations - either the PCI DMA
> mapping operations or those from lib/dma-virt.c. My question to you is how we
> should organize struct ib_device such that we can get rid of the ib_dma_*()
> helper functions. How to make sure that the to_pci_dev() translation works
> correctly for the device structure that is embedded in struct ib_device?
> Should a pointer to struct pci_dev be embedded in struct device (as done in
> patch 1/2 in this series)
I already said no to this, why do you think that it is still ok?
> or should the struct device in ib_device be changed
> into a struct pci_dev
Ick, no.
> and should the pci_dev information from /sys/devices/pci*/*/* be
> duplicated into the pci_dev information in struct ib_device
> (/sys/devices/pci*/*/*/infiniband/*)?
I don't think you really thought that one through :)
> For the latter approach, would
> there be a risk that the duplicated information becomes inconsistent?
No, it just wouldn't work :)
Why not just save off a pointer to your pci_dev in your ib_device
structure? That way you know what the type is, and you have access to
everything you need.
But hey, I know nothing about IB and I really want to keep it that way.
You do what you want to, as long as you don't abuse the driver model,
like your patch 1/2 did. Remember, not all the world is IB.
thanks,
greg k-h
next prev parent reply other threads:[~2017-03-07 17:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-07 0:35 [PATCH 0/2] IB/core fixes for kernel v4.11-rc Bart Van Assche
2017-03-07 0:35 ` Bart Van Assche
[not found] ` <20170307003549.3872-1-bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2017-03-07 0:35 ` [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev Bart Van Assche
2017-03-07 0:35 ` Bart Van Assche
[not found] ` <20170307003549.3872-2-bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2017-03-07 2:41 ` Parav Pandit
2017-03-07 2:41 ` Parav Pandit
2017-03-07 2:44 ` Bart Van Assche
[not found] ` <1488854653.2997.1.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2017-03-07 4:50 ` gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
2017-03-07 4:50 ` gregkh
2017-03-07 3:21 ` Parav Pandit
2017-03-07 3:21 ` Parav Pandit
2017-03-07 4:52 ` Greg Kroah-Hartman
2017-03-07 4:52 ` Greg Kroah-Hartman
[not found] ` <20170307045236.GC3913-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2017-03-07 5:08 ` Parav Pandit
2017-03-07 5:08 ` Parav Pandit
[not found] ` <VI1PR0502MB3008BEC2FB8747DDA40A10FCD12F0-o1MPJYiShExKsLr+rGaxW8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2017-03-07 5:13 ` Bart Van Assche
2017-03-07 5:13 ` Bart Van Assche
[not found] ` <1488863593.2997.3.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2017-03-07 5:20 ` Parav Pandit
2017-03-07 5:20 ` Parav Pandit
2017-03-08 1:52 ` Benjamin Herrenschmidt
2017-03-08 1:52 ` Benjamin Herrenschmidt
2017-03-07 16:54 ` Bart Van Assche
[not found] ` <1488905685.2739.1.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2017-03-07 17:14 ` gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r [this message]
2017-03-07 17:14 ` gregkh
2017-03-07 18:27 ` Parav Pandit
2017-03-07 0:35 ` [PATCH 2/2] IB/core: Restore I/O MMU, s390 and powerpc support Bart Van Assche
2017-03-07 0:35 ` Bart Van Assche
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=20170307171403.GA19293@kroah.com \
--to=gregkh-hqyy1w1ycw8ekmwlsbkhg0b+6bgklq7r@public.gmane.org \
--cc=Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org \
--cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=parav-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
/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.