[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150127004005.GC11624@google.com>
Date: Mon, 26 Jan 2015 18:40:05 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Marc Zyngier <marc.zyngier@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Jiang Liu <jiang.liu@...ux.intel.com>,
linux-arm-kernel@...ts.infradead.org, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, Will Deacon <Will.Deacon@....com>,
Yijing Wang <wangyijing@...wei.com>,
Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>
Subject: Re: [PATCH 2/6] PCI/MSI: add hooks to populate the msi_domain field
On Mon, Dec 08, 2014 at 08:12:19PM +0000, Marc Zyngier wrote:
> In order to be able to populate the device msi_domain field,
> add the necesary hooks to propagate the PHB msi_domain across
> secondary busses to devices.
>
> So far, nobody populates the initial msi_domain.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@....com>
> ---
> drivers/pci/probe.c | 24 ++++++++++++++++++++++++
> include/linux/pci.h | 1 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index c8ca98c..d1009a2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -670,6 +670,20 @@ static void pci_set_bus_speed(struct pci_bus *bus)
> }
> }
>
> +void __weak pcibios_set_phb_msi_domain(struct pci_bus *bus)
We haven't previously used the "phb" abbreviation in the PCI core, so I'd
rather not start now. I'm not really sure how relevant it is anyway --
maybe the name doesn't need to include a reference to the host bridge at
all?
> +{
> +}
> +
> +static void pci_set_bus_msi_domain(struct pci_bus *bus)
> +{
> + struct pci_dev *bridge = bus->self;
> +
> + if (!bridge)
> + pcibios_set_phb_msi_domain(bus);
> + else
> + dev_set_msi_domain(&bus->dev, dev_get_msi_domain(&bridge->dev));
> +}
> +
> static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
> struct pci_dev *bridge, int busnr)
> {
> @@ -723,6 +737,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
> bridge->subordinate = child;
>
> add_dev:
> + pci_set_bus_msi_domain(child);
> ret = device_register(&child->dev);
> WARN_ON(ret < 0);
>
> @@ -1517,6 +1532,11 @@ static void pci_init_capabilities(struct pci_dev *dev)
> pci_enable_acs(dev);
> }
>
> +static void pci_set_msi_domain(struct pci_dev *dev)
> +{
> + dev_set_msi_domain(&dev->dev, dev_get_msi_domain(&dev->bus->dev));
> +}
> +
> void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> {
> int ret;
> @@ -1546,6 +1566,9 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> /* Initialize various capabilities */
> pci_init_capabilities(dev);
>
> + /* Setup MSI irq domain */
This is *really* a nitpick, but "setup" suggests that we're doing more than
just setting a pointer, i.e., it suggests that we're doing something more
involved to get it all ready for use. But here, I think we really are just
setting a pointer, so I think the comment is pointless since the function
name already says that.
> + pci_set_msi_domain(dev);
> +
> /*
> * Add the device to our list of discovered devices
> * and the bus list for fixup functions, etc.
> @@ -1947,6 +1970,7 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> b->bridge = get_device(&bridge->dev);
> device_enable_async_suspend(b->bridge);
> pci_set_bus_of_node(b);
> + pci_set_bus_msi_domain(b);
>
> if (!parent)
> set_dev_node(b->bridge, pcibus_to_node(b));
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index a523cee..3266764 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1637,6 +1637,7 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
> int pcibios_add_device(struct pci_dev *dev);
> void pcibios_release_device(struct pci_dev *dev);
> void pcibios_penalize_isa_irq(int irq, int active);
> +void pcibios_set_phb_msi_domain(struct pci_bus *bus);
>
> #ifdef CONFIG_HIBERNATE_CALLBACKS
> extern struct dev_pm_ops pcibios_pm_ops;
> --
> 2.1.3
>
--
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