> -----Original Message----- > From: gregkh@xxxxxxxxxxxxxxxxxxx [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, March 7, 2017 11:14 AM > To: Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> > Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; Parav Pandit > <parav@xxxxxxxxxxxx>; sebott@xxxxxxxxxxxxxxxxxx; > linux@xxxxxxxxxxxxxxx; hpa@xxxxxxxxx; mingo@xxxxxxxxxx; > dwmw2@xxxxxxxxxxxxx; bhelgaas@xxxxxxxxxx; dledford@xxxxxxxxxx; > benh@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] device: Stop requiring that struct device is > embedded in struct pci_dev > > 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 > :) > Well what I compared is: netdev has struct device and it also has underlying pci_dev based device. ibdev has struct device and it also has underlying pci_dev based device. So let us try to treat them in same way wherever possible and keep setup needed in ib drivers. > > 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 DMA mapping and allocation is done in different layer for its own reason unrelated to this change. If rxe, qib, hfi1 point to right dma_device, can't we remove the ib_dma_*()? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
