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]
Message-ID: <VI1PR0502MB3008B179278931A3D2519A07D12F0@VI1PR0502MB3008.eurprd05.prod.outlook.com>
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_*()?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ