[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150116095244.40249284@thirdoffive.cmf.nrl.navy.mil>
Date: Fri, 16 Jan 2015 09:52:44 -0500
From: chas williams - CONTRACTOR <chas@....nrl.navy.mil>
To: Quentin Lambert <lambert.quentin@...il.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [net-next PATCH v3 1/1] atm: remove deprecated use of pci api
On Fri, 16 Jan 2015 15:10:25 +0100
Quentin Lambert <lambert.quentin@...il.com> wrote:
> > - u32 dma_addr = pci_map_single((struct pci_dev*)fore200e->bus_dev, virt_addr, size, direction);
> > + u32 dma_addr = dma_map_single(&((struct pci_dev *) fore200e->bus_dev)->dev, virt_addr, size, direction);
> >
> > DPRINTK(3, "PCI DVMA mapping: virt_addr = 0x%p, size = %d, direction = %d, --> dma_addr = 0x%08x\n",
> > virt_addr, size, direction, dma_addr);
> >
> []
>
> I am going try to make similar changes in some other part of the kernel and
> I was wondering if you could explain how you decided it wasn't necessary to
> check for "((struct pci_dev *) fore200e->bus_dev" nullity for instance.
This gets set up in fore200e_pca_detect() which is pretty early in the
intialization process. We don't get as far as using any of the "DVMA"
stubs unless pci_enable_device() succeeds, meaning pci_dev is good, and
fore200e->bus_dev is assigned to pci_dev (around line 2724).
fore200e->bus_dev is never cleared back to NULL, but obviously you
shouldn't be using any of the DMA routines after disabling the pci
device. Hopefully the driver shuts down in an orderly fashion such
that all DMA is over by the time the driver disables the pci device.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists