[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1411140211480.3935@nanos>
Date: Fri, 14 Nov 2014 02:31:23 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Yijing Wang <wangyijing@...wei.com>
cc: Jiang Liu <jiang.liu@...ux.intel.com>,
Marc Zyngier <marc.zyngier@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
Yingjoe Chen <yingjoe.chen@...iatek.com>,
Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Tony Luck <tony.luck@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Patch V1 0/6] Refine generic/PCI MSI irqodmian interfaces
On Fri, 14 Nov 2014, Yijing Wang wrote:
Could you please use a mail client which does proper line wraps or
configure yours to do so?
> Associate the irq domain and PCI bus is not necessary, because all
> PCI buses under same host bridge always share same MSI chip/irq
> domain, we only need associate them and pci host bridge.
>
> I'm refactoring the pci_host_bridge, make it be a generic one, rip
> out of the pci root bus creation, so we could put the irq domain and
> pci domain etc.. in it. Finally, we could eliminate lots platform
> arch functions. I will post it out within one week.
That's a completely orthogonal problem. From the MSI/interrupt
handling POV it does not matter at all where that information is
stored. All we care about is that it is retrievable via the (pci)
device which tries to setup MSI[X].
So we can store/retrieve it via generic functions into/from whatever
is available right now. If the irq side has generic interfaces to do
so then this wont conflict with your decisions to change the final
storage point because all it takes is to tweak the storage/retrieve
functions.
So all we need at the moment is an agreed on way to store/retrieve
that information which is based on the current shared infrastructure,
aka. Linus tree. If we can utilize that you are completely free to
change the association mechanism underneath.
Thanks,
tglx
--
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