Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933415AbbGVRmS (ORCPT ); Wed, 22 Jul 2015 13:42:18 -0400 Received: from foss.arm.com ([217.140.101.70]:37161 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933119AbbGVRmP (ORCPT ); Wed, 22 Jul 2015 13:42:15 -0400 Message-ID: <55AFD5F3.3000705@arm.com> Date: Wed, 22 Jul 2015 18:42:11 +0100 From: Marc Zyngier Organization: ARM Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Bjorn Helgaas CC: Thomas Gleixner , Jiang Liu , Jason Cooper , "linux-arm-kernel@lists.infradead.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Yijing Wang , Ma Jun , Lorenzo Pieralisi , Duc Dang Subject: Re: [PATCH v4 04/19] PCI/MSI: Add hooks to populate the msi_domain field References: <1436962613-17359-1-git-send-email-marc.zyngier@arm.com> <1436962613-17359-5-git-send-email-marc.zyngier@arm.com> <20150721212644.GB3691@google.com> <55AFABF3.5050303@arm.com> <55AFAE96.4070401@arm.com> <20150722165318.GA27197@google.com> In-Reply-To: <20150722165318.GA27197@google.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2964 Lines: 79 On 22/07/15 17:53, Bjorn Helgaas wrote: > On Wed, Jul 22, 2015 at 03:54:14PM +0100, Marc Zyngier wrote: >> On 22/07/15 15:48, Bjorn Helgaas wrote: >>> On Wed, Jul 22, 2015 at 9:42 AM, Marc Zyngier wrote: >>>> Hi Bjorn, >>>> >>>> On 21/07/15 22:26, Bjorn Helgaas wrote: >>>>> On Wed, Jul 15, 2015 at 01:16:38PM +0100, Marc Zyngier wrote: >>>>>> In order to be able to populate the device msi_domain field, >>>>>> add the necesary hooks to propagate the host bridge msi_domain >>>>>> across secondary busses to devices. >>>>>> >>>>>> So far, nobody populates the initial msi_domain. >>>>>> >>>>>> Signed-off-by: Marc Zyngier >>>>>> --- >>>>>> drivers/pci/probe.c | 30 ++++++++++++++++++++++++++++++ >>>>>> include/linux/pci.h | 1 + >>>>>> 2 files changed, 31 insertions(+) >>>>>> >>>>>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c >>>>>> index cefd636..376f6fa 100644 >>>>>> --- a/drivers/pci/probe.c >>>>>> +++ b/drivers/pci/probe.c >>>>>> @@ -661,6 +661,20 @@ static void pci_set_bus_speed(struct pci_bus *bus) >>>>>> } >>>>>> } >>>>>> >>>>>> +void __weak pcibios_set_host_bridge_msi_domain(struct pci_bus *bus) >>>>>> +{ >>>>>> +} >>>>> >>>>> I don't think there's anything in this series that requires this to be a >>>>> weak function, is there? This is the only definition I see. >>>> >>>> It looks like all the pcibios_* functions so far have a weak attribute, >>>> and I've added it as a matter of consistency. >>> >>> We've used pcibios_* names where we might need an arch-specific >>> implementation. I'm not sure that's the case here -- do you envision >>> an implementation under arch/* someday? If not, maybe it should just >>> be a pci_* function instead of pcibios_*. >> >> I could definitely see non-OF driven architectures wanting to override this. >> >> Or maybe we should turn it the other way around and make it call the >> various firmware interfaces (OF, ACPI...) until one of them succeeds. In >> which case your suggestion of making it a pci_* function makes a lot of >> sense. > > Here's my advice, FWIW: > > - remove __weak > > - rename pcibios_set_host_bridge_msi_domain() to > pci_host_bridge_msi_domain() and have it return a struct irq_domain * > > - pci_host_bridge_msi_domain() can call whatever firmware- or > arch-specific code you need to look up the irq_domain > > - move the dev_set_msi_domain() call from pci_set_phb_of_msi_domain() to > pci_set_bus_msi_domain() > Yes, seems to make sense. I end-up with something that looks much more readable (pci_set_bus_msi_domain looks fairly neat now). I'll post a new version shortly. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/