Hi Bart,
> -----Original Message-----
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Bart Van Assche
> Sent: Monday, March 6, 2017 6:36 PM
> To: Doug Ledford <dledf...@redhat.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>; Sebastian Ott
> <seb...@linux.vnet.ibm.com>; Parav Pandit <pa...@mellanox.com>; linux-
> r...@vger.kernel.org; linux-kernel@vger.kernel.org; Bart Van Assche
> <bart.vanass...@sandisk.com>; Bjorn Helgaas <bhelg...@google.com>;
> Benjamin Herrenschmidt <b...@kernel.crashing.org>; David Woodhouse
> <dw...@infradead.org>; H . Peter Anvin <h...@zytor.com>; Ingo Molnar
> <mi...@redhat.com>; Russell King <li...@armlinux.org.uk>
> Subject: [PATCH 1/2] device: Stop requiring that struct device is embedded in
> struct pci_dev
>
> The dma mapping operations of several architectures and also of several I/O
> MMU implementations need to translate a struct device pointer into a struct
> pci_dev pointer. This translation is performed by to_pci_dev(). That macro
> assumes that struct device is embedded in struct pci_dev. However, that is
> not the case for the device structure in struct ib_device. Since that device
> structure is passed to DMA mapping operations since kernel v4.11-rc1,
> introduce a pointer in struct device to make the translation from struct
> device into struct pci_dev more flexible.
>
> Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Bjorn Helgaas <bhelg...@google.com>
> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> Cc: David Woodhouse <dw...@infradead.org>
> Cc: H. Peter Anvin <h...@zytor.com>
> Cc: Ingo Molnar <mi...@redhat.com>
> Cc: Russell King <li...@armlinux.org.uk>
> ---
> drivers/pci/probe.c | 1 +
> include/linux/device.h | 5 +++++
> include/linux/pci.h | 5 ++++-
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/device.h b/include/linux/device.h index
> 30c4570e928d..c18afd376d2a 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -42,6 +42,7 @@ struct fwnode_handle;
> struct iommu_ops;
> struct iommu_group;
> struct iommu_fwspec;
> +struct pci_dev;
>
> struct bus_attribute {
> struct attribute attr;
> @@ -860,6 +861,9 @@ struct dev_links_info {
> * segment limitations.
> * @dma_pools: Dma pools (if dma'ble device).
> * @dma_mem: Internal for coherent mem override.
> + * @pci_dev: PCI device associated with this device. Used by DMA
> mapping
> + * operations on architectures that need access to PCI device
> + * members that are not in struct device.
> * @cma_area: Contiguous memory area for dma allocations
> * @archdata: For arch-specific additions.
> * @of_node: Associated device tree node.
> @@ -940,6 +944,7 @@ struct device {
>
> struct dma_coherent_mem *dma_mem; /* internal for coherent
> mem
> override */
> + struct pci_dev *pci_dev; /* for DMA mapping operations */
Compilation would break when CONFIG_PCI is not defined for some embedded
platforms.
More than that, including specific pci_dev structure pointer in generic
structure such as device just doesn't sound right.
I tested equivalent patch that you sent, but I don't think this is right
direction to fix this bug.
> #ifdef CONFIG_DMA_CMA
> struct cma *cma_area; /* contiguous memory area for dma
> allocations */
> diff --git a/include/linux/pci.h b/include/linux/pci.h index
> eb3da1a04e6c..eca790eaae20 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -409,7 +409,10 @@ static inline struct pci_dev *pci_physfn(struct
> pci_dev *dev)
>
> struct pci_dev *pci_alloc_dev(struct pci_bus *bus);
>
> -#define to_pci_dev(n) container_of(n, struct pci_dev, dev)
> +static inline struct pci_dev *to_pci_dev(const struct device *dev) {
> + return dev->pci_dev;
> +}
> #define for_each_pci_dev(d) while ((d = pci_get_device(PCI_ANY_ID,
> PCI_ANY_ID, d)) != NULL)
>
> static inline int pci_channel_offline(struct pci_dev *pdev)
> --
> 2.12.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
