linux-kernel - RE: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Mar 2017 18:27:17 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Bart Van Assche <Bart.VanAssche@...disk.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "sebott@...ux.vnet.ibm.com" <sebott@...ux.vnet.ibm.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "dledford@...hat.com" <dledford@...hat.com>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>
Subject: RE: [PATCH 1/2] device: Stop requiring that struct device is embedded
 in struct pci_dev



> -----Original Message-----
> From: gregkh@...uxfoundation.org [mailto:gregkh@...uxfoundation.org]
> Sent: Tuesday, March 7, 2017 11:14 AM
> To: Bart Van Assche <Bart.VanAssche@...disk.com>
> Cc: linux-kernel@...r.kernel.org; linux-rdma@...r.kernel.org; Parav Pandit
> <parav@...lanox.com>; sebott@...ux.vnet.ibm.com;
> linux@...linux.org.uk; hpa@...or.com; mingo@...hat.com;
> dwmw2@...radead.org; bhelgaas@...gle.com; dledford@...hat.com;
> benh@...nel.crashing.org
> 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_*()?