All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Yijing Wang <wangyijing@huawei.com>
Cc: Liviu Dudau <liviu@dudau.co.uk>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Xinwei Hu <huxinwei@huawei.com>, Wuyun <wuyun.wu@huawei.com>,
	linux-arm-kernel@lists.infradead.org,
	Russell King <linux@arm.linux.org.uk>,
	linux-arch@vger.kernel.org, arnab.basu@freescale.com,
	Bharat.Bhushan@freescale.com, x86@kernel.org,
	Arnd Bergmann <arnd@arndb.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xenproject.org, Joerg Roedel <joro@8bytes.org>,
	iommu@lists.linux-foundation.org, linux-mips@linux-mips.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	sparclinux@vger.kernel.org, Chris Metcalf <cmetcalf@tilera.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Lucas Stach <l.stach@pengutronix.de>,
	David Vrabel <david.vrabel@citrix.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Subject: Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
Date: Fri, 26 Sep 2014 10:54:32 +0200	[thread overview]
Message-ID: <20140926085430.GG31106@ulmo> (raw)
In-Reply-To: <542505B3.7040208@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
> >> The PCI core can already deal with that. An MSI chip can be set per bus
> >> and the weak pcibios_add_bus() can be used to set that. Often it might
> >> not even be necessary to do it via pcibios_add_bus() if you create the
> >> root bus directly, since you can attach the MSI chip at that time.
> > 
> > But I'm thinking that we need to move away from pcibios_add_bus() interface to do
> > something that should be generic. You don't need to be called for every bus when all
> > you want is just the root bus in order to add the MSI chip. Also, from looking at
> > the current patchset, a lot of architectures would set the MSI chip to a global
> > variable, which means you don't have an option to choose the MSI chip based on the
> > bus.
> 
> I also agree to remove the pcibios_add_bus() in arm which call .add_bus() to associate msi_chip
> and PCI bus.
> 
> In my opinions, all PCI devices under the same PCI hostbridge must share same msi chip, right ?
> So if we can associate msi chip and PCI hostbridge, every PCI device can find correct msi chip.
> PCI hostbridge private attributes can be saved in PCI sysdata, and this data will be propagate to
> PCI root bus and its child buses.

struct pci_sys_data is architecture specific, so the code won't become
any more generic than it is now.

> >>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>> details like associated msi_chip into the host bridge and the child busses will
> >>> have an easy way of finding the information needed by finding the root bus and then
> >>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>> everyone and the drivers can remove their kludges that try to work around the
> >>> current limitations.
> >>
> >> I think both issues are orthogonal. Last time I checked a lot of work
> >> was still necessary to unify host bridges enough so that it could be
> >> shared across architectures. But perhaps some of that work has
> >> happened in the meantime.
> > 
> > Breaking out the host bridge creation from root bus creation is not difficult, just not
> > agree upon. That would be the first step in making the generic host brige structure
> > useful for sharing, specially if used as a sort of "parent" structure that you can
> > wrap with your actual host bridge structure.
> 
> Breaking out the host bridge creation is a good idea, but there need a lot of changes, we can
> do it in another series.

I agree, this can be done step by step.

> And if we save msi chip in pci sysdata now, it will be easy to
> move it to generic pci host bridge. We can also move the pci domain number and other common info to it.

But like I said above, we wouldn't gain anything by moving the MSI chip
into struct pci_sys_data, since the core code couldn't access it from
there. The code wouldn't become more generic than the current approach
of using pcibios_add_bus(). At least for Tegra it's trivial to just hook
it up in tegra_pcie_scan_bus() directly (patch attached). So I think a
generic solution would be to allow it to be easily associated with a
bus.

Perhaps it would be as simple as adding a pci_scan_root_bus_with_msi()
or something with a less awkward name, or extending the existing
pci_scan_root_bus() with an MSI chip parameter. The function already has
too many arguments for my taste, though, so I'd like to avoid the
latter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Yijing Wang <wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
	linux-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Xinwei Hu <huxinwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	Sebastian Ott
	<sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	Benjamin Herrenschmidt
	<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
	xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org,
	arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Chris Metcalf <cmetcalf-kv+TWInifGbQT0dZR+AlfA@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Thomas Petazzoni
	<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Liviu Dudau <liviu-I3yL/QOVVjH10XsdtD+oqA@public.gmane.org>,
	Tony Luck <tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Sergei Shtylyov
	<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
	iommu@lists.l
Subject: Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
Date: Fri, 26 Sep 2014 10:54:32 +0200	[thread overview]
Message-ID: <20140926085430.GG31106@ulmo> (raw)
In-Reply-To: <542505B3.7040208-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 3627 bytes --]

On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
> >> The PCI core can already deal with that. An MSI chip can be set per bus
> >> and the weak pcibios_add_bus() can be used to set that. Often it might
> >> not even be necessary to do it via pcibios_add_bus() if you create the
> >> root bus directly, since you can attach the MSI chip at that time.
> > 
> > But I'm thinking that we need to move away from pcibios_add_bus() interface to do
> > something that should be generic. You don't need to be called for every bus when all
> > you want is just the root bus in order to add the MSI chip. Also, from looking at
> > the current patchset, a lot of architectures would set the MSI chip to a global
> > variable, which means you don't have an option to choose the MSI chip based on the
> > bus.
> 
> I also agree to remove the pcibios_add_bus() in arm which call .add_bus() to associate msi_chip
> and PCI bus.
> 
> In my opinions, all PCI devices under the same PCI hostbridge must share same msi chip, right ?
> So if we can associate msi chip and PCI hostbridge, every PCI device can find correct msi chip.
> PCI hostbridge private attributes can be saved in PCI sysdata, and this data will be propagate to
> PCI root bus and its child buses.

struct pci_sys_data is architecture specific, so the code won't become
any more generic than it is now.

> >>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>> details like associated msi_chip into the host bridge and the child busses will
> >>> have an easy way of finding the information needed by finding the root bus and then
> >>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>> everyone and the drivers can remove their kludges that try to work around the
> >>> current limitations.
> >>
> >> I think both issues are orthogonal. Last time I checked a lot of work
> >> was still necessary to unify host bridges enough so that it could be
> >> shared across architectures. But perhaps some of that work has
> >> happened in the meantime.
> > 
> > Breaking out the host bridge creation from root bus creation is not difficult, just not
> > agree upon. That would be the first step in making the generic host brige structure
> > useful for sharing, specially if used as a sort of "parent" structure that you can
> > wrap with your actual host bridge structure.
> 
> Breaking out the host bridge creation is a good idea, but there need a lot of changes, we can
> do it in another series.

I agree, this can be done step by step.

> And if we save msi chip in pci sysdata now, it will be easy to
> move it to generic pci host bridge. We can also move the pci domain number and other common info to it.

But like I said above, we wouldn't gain anything by moving the MSI chip
into struct pci_sys_data, since the core code couldn't access it from
there. The code wouldn't become more generic than the current approach
of using pcibios_add_bus(). At least for Tegra it's trivial to just hook
it up in tegra_pcie_scan_bus() directly (patch attached). So I think a
generic solution would be to allow it to be easily associated with a
bus.

Perhaps it would be as simple as adding a pci_scan_root_bus_with_msi()
or something with a less awkward name, or extending the existing
pci_scan_root_bus() with an MSI chip parameter. The function already has
too many arguments for my taste, though, so I'd like to avoid the
latter.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Yijing Wang <wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
	linux-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Xinwei Hu <huxinwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	Sebastian Ott
	<sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	Benjamin Herrenschmidt
	<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
	xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org,
	arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Chris Metcalf <cmetcalf-kv+TWInifGbQT0dZR+AlfA@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Thomas Petazzoni
	<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Liviu Dudau <liviu-I3yL/QOVVjH10XsdtD+oqA@public.gmane.org>,
	Tony Luck <tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Sergei Shtylyov
	<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
	iommu@lists.l
Subject: Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
Date: Fri, 26 Sep 2014 08:54:32 +0000	[thread overview]
Message-ID: <20140926085430.GG31106@ulmo> (raw)
In-Reply-To: <542505B3.7040208-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
> >> The PCI core can already deal with that. An MSI chip can be set per bus
> >> and the weak pcibios_add_bus() can be used to set that. Often it might
> >> not even be necessary to do it via pcibios_add_bus() if you create the
> >> root bus directly, since you can attach the MSI chip at that time.
> > 
> > But I'm thinking that we need to move away from pcibios_add_bus() interface to do
> > something that should be generic. You don't need to be called for every bus when all
> > you want is just the root bus in order to add the MSI chip. Also, from looking at
> > the current patchset, a lot of architectures would set the MSI chip to a global
> > variable, which means you don't have an option to choose the MSI chip based on the
> > bus.
> 
> I also agree to remove the pcibios_add_bus() in arm which call .add_bus() to associate msi_chip
> and PCI bus.
> 
> In my opinions, all PCI devices under the same PCI hostbridge must share same msi chip, right ?
> So if we can associate msi chip and PCI hostbridge, every PCI device can find correct msi chip.
> PCI hostbridge private attributes can be saved in PCI sysdata, and this data will be propagate to
> PCI root bus and its child buses.

struct pci_sys_data is architecture specific, so the code won't become
any more generic than it is now.

> >>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>> details like associated msi_chip into the host bridge and the child busses will
> >>> have an easy way of finding the information needed by finding the root bus and then
> >>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>> everyone and the drivers can remove their kludges that try to work around the
> >>> current limitations.
> >>
> >> I think both issues are orthogonal. Last time I checked a lot of work
> >> was still necessary to unify host bridges enough so that it could be
> >> shared across architectures. But perhaps some of that work has
> >> happened in the meantime.
> > 
> > Breaking out the host bridge creation from root bus creation is not difficult, just not
> > agree upon. That would be the first step in making the generic host brige structure
> > useful for sharing, specially if used as a sort of "parent" structure that you can
> > wrap with your actual host bridge structure.
> 
> Breaking out the host bridge creation is a good idea, but there need a lot of changes, we can
> do it in another series.

I agree, this can be done step by step.

> And if we save msi chip in pci sysdata now, it will be easy to
> move it to generic pci host bridge. We can also move the pci domain number and other common info to it.

But like I said above, we wouldn't gain anything by moving the MSI chip
into struct pci_sys_data, since the core code couldn't access it from
there. The code wouldn't become more generic than the current approach
of using pcibios_add_bus(). At least for Tegra it's trivial to just hook
it up in tegra_pcie_scan_bus() directly (patch attached). So I think a
generic solution would be to allow it to be easily associated with a
bus.

Perhaps it would be as simple as adding a pci_scan_root_bus_with_msi()
or something with a less awkward name, or extending the existing
pci_scan_root_bus() with an MSI chip parameter. The function already has
too many arguments for my taste, though, so I'd like to avoid the
latter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Yijing Wang <wangyijing@huawei.com>
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-pci@vger.kernel.org, Xinwei Hu <huxinwei@huawei.com>,
	sparclinux@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-s390@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	Joerg Roedel <joro@8bytes.org>,
	x86@kernel.org, Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Bharat.Bhushan@freescale.com, xen-devel@lists.xenproject.org,
	arnab.basu@freescale.com, Arnd Bergmann <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Chris Metcalf <cmetcalf@tilera.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Liviu Dudau <liviu@dudau.co.uk>, Tony Luck <tony.luck@intel.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	iommu@lists.linux-foundation.org,
	David Vrabel <david.vrabel@citrix.com>,
	Wuyun <wuyun.wu@huawei.com>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>,
	Lucas Stach <l.stach@pengutronix.de>
Subject: Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
Date: Fri, 26 Sep 2014 10:54:32 +0200	[thread overview]
Message-ID: <20140926085430.GG31106@ulmo> (raw)
In-Reply-To: <542505B3.7040208@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
> >> The PCI core can already deal with that. An MSI chip can be set per bus
> >> and the weak pcibios_add_bus() can be used to set that. Often it might
> >> not even be necessary to do it via pcibios_add_bus() if you create the
> >> root bus directly, since you can attach the MSI chip at that time.
> > 
> > But I'm thinking that we need to move away from pcibios_add_bus() interface to do
> > something that should be generic. You don't need to be called for every bus when all
> > you want is just the root bus in order to add the MSI chip. Also, from looking at
> > the current patchset, a lot of architectures would set the MSI chip to a global
> > variable, which means you don't have an option to choose the MSI chip based on the
> > bus.
> 
> I also agree to remove the pcibios_add_bus() in arm which call .add_bus() to associate msi_chip
> and PCI bus.
> 
> In my opinions, all PCI devices under the same PCI hostbridge must share same msi chip, right ?
> So if we can associate msi chip and PCI hostbridge, every PCI device can find correct msi chip.
> PCI hostbridge private attributes can be saved in PCI sysdata, and this data will be propagate to
> PCI root bus and its child buses.

struct pci_sys_data is architecture specific, so the code won't become
any more generic than it is now.

> >>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>> details like associated msi_chip into the host bridge and the child busses will
> >>> have an easy way of finding the information needed by finding the root bus and then
> >>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>> everyone and the drivers can remove their kludges that try to work around the
> >>> current limitations.
> >>
> >> I think both issues are orthogonal. Last time I checked a lot of work
> >> was still necessary to unify host bridges enough so that it could be
> >> shared across architectures. But perhaps some of that work has
> >> happened in the meantime.
> > 
> > Breaking out the host bridge creation from root bus creation is not difficult, just not
> > agree upon. That would be the first step in making the generic host brige structure
> > useful for sharing, specially if used as a sort of "parent" structure that you can
> > wrap with your actual host bridge structure.
> 
> Breaking out the host bridge creation is a good idea, but there need a lot of changes, we can
> do it in another series.

I agree, this can be done step by step.

> And if we save msi chip in pci sysdata now, it will be easy to
> move it to generic pci host bridge. We can also move the pci domain number and other common info to it.

But like I said above, we wouldn't gain anything by moving the MSI chip
into struct pci_sys_data, since the core code couldn't access it from
there. The code wouldn't become more generic than the current approach
of using pcibios_add_bus(). At least for Tegra it's trivial to just hook
it up in tegra_pcie_scan_bus() directly (patch attached). So I think a
generic solution would be to allow it to be easily associated with a
bus.

Perhaps it would be as simple as adding a pci_scan_root_bus_with_msi()
or something with a less awkward name, or extending the existing
pci_scan_root_bus() with an MSI chip parameter. The function already has
too many arguments for my taste, though, so I'd like to avoid the
latter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
Date: Fri, 26 Sep 2014 10:54:32 +0200	[thread overview]
Message-ID: <20140926085430.GG31106@ulmo> (raw)
In-Reply-To: <542505B3.7040208@huawei.com>

On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
> >> The PCI core can already deal with that. An MSI chip can be set per bus
> >> and the weak pcibios_add_bus() can be used to set that. Often it might
> >> not even be necessary to do it via pcibios_add_bus() if you create the
> >> root bus directly, since you can attach the MSI chip at that time.
> > 
> > But I'm thinking that we need to move away from pcibios_add_bus() interface to do
> > something that should be generic. You don't need to be called for every bus when all
> > you want is just the root bus in order to add the MSI chip. Also, from looking at
> > the current patchset, a lot of architectures would set the MSI chip to a global
> > variable, which means you don't have an option to choose the MSI chip based on the
> > bus.
> 
> I also agree to remove the pcibios_add_bus() in arm which call .add_bus() to associate msi_chip
> and PCI bus.
> 
> In my opinions, all PCI devices under the same PCI hostbridge must share same msi chip, right ?
> So if we can associate msi chip and PCI hostbridge, every PCI device can find correct msi chip.
> PCI hostbridge private attributes can be saved in PCI sysdata, and this data will be propagate to
> PCI root bus and its child buses.

struct pci_sys_data is architecture specific, so the code won't become
any more generic than it is now.

> >>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>> details like associated msi_chip into the host bridge and the child busses will
> >>> have an easy way of finding the information needed by finding the root bus and then
> >>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>> everyone and the drivers can remove their kludges that try to work around the
> >>> current limitations.
> >>
> >> I think both issues are orthogonal. Last time I checked a lot of work
> >> was still necessary to unify host bridges enough so that it could be
> >> shared across architectures. But perhaps some of that work has
> >> happened in the meantime.
> > 
> > Breaking out the host bridge creation from root bus creation is not difficult, just not
> > agree upon. That would be the first step in making the generic host brige structure
> > useful for sharing, specially if used as a sort of "parent" structure that you can
> > wrap with your actual host bridge structure.
> 
> Breaking out the host bridge creation is a good idea, but there need a lot of changes, we can
> do it in another series.

I agree, this can be done step by step.

> And if we save msi chip in pci sysdata now, it will be easy to
> move it to generic pci host bridge. We can also move the pci domain number and other common info to it.

But like I said above, we wouldn't gain anything by moving the MSI chip
into struct pci_sys_data, since the core code couldn't access it from
there. The code wouldn't become more generic than the current approach
of using pcibios_add_bus(). At least for Tegra it's trivial to just hook
it up in tegra_pcie_scan_bus() directly (patch attached). So I think a
generic solution would be to allow it to be easily associated with a
bus.

Perhaps it would be as simple as adding a pci_scan_root_bus_with_msi()
or something with a less awkward name, or extending the existing
pci_scan_root_bus() with an MSI chip parameter. The function already has
too many arguments for my taste, though, so I'd like to avoid the
latter.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140926/a887458e/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Yijing Wang <wangyijing@huawei.com>
Cc: Liviu Dudau <liviu@dudau.co.uk>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Xinwei Hu <huxinwei@huawei.com>, Wuyun <wuyun.wu@huawei.com>,
	linux-arm-kernel@lists.infradead.org,
	Russell King <linux@arm.linux.org.uk>,
	linux-arch@vger.kernel.org, arnab.basu@freescale.com,
	Bharat.Bhushan@freescale.com, x86@kernel.org,
	Arnd Bergmann <arnd@arndb.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xenproject.org, Joerg Roedel <joro@8bytes.org>,
	iommu@lists.linux-foundation.org, linux-mips@linux-mips.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	Sebastian Ott <sebott@linux.vnet.ibm.com>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	sparclinux@vger.kernel.org, Chris Metcalf <cmetcalf@tilera.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Lucas Stach <l.stach@pengutronix.de>,
	David Vrabel <david.vrabel@citrix.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Subject: Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
Date: Fri, 26 Sep 2014 08:54:32 +0000	[thread overview]
Message-ID: <20140926085430.GG31106@ulmo> (raw)
In-Reply-To: <542505B3.7040208@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
> >> The PCI core can already deal with that. An MSI chip can be set per bus
> >> and the weak pcibios_add_bus() can be used to set that. Often it might
> >> not even be necessary to do it via pcibios_add_bus() if you create the
> >> root bus directly, since you can attach the MSI chip at that time.
> > 
> > But I'm thinking that we need to move away from pcibios_add_bus() interface to do
> > something that should be generic. You don't need to be called for every bus when all
> > you want is just the root bus in order to add the MSI chip. Also, from looking at
> > the current patchset, a lot of architectures would set the MSI chip to a global
> > variable, which means you don't have an option to choose the MSI chip based on the
> > bus.
> 
> I also agree to remove the pcibios_add_bus() in arm which call .add_bus() to associate msi_chip
> and PCI bus.
> 
> In my opinions, all PCI devices under the same PCI hostbridge must share same msi chip, right ?
> So if we can associate msi chip and PCI hostbridge, every PCI device can find correct msi chip.
> PCI hostbridge private attributes can be saved in PCI sysdata, and this data will be propagate to
> PCI root bus and its child buses.

struct pci_sys_data is architecture specific, so the code won't become
any more generic than it is now.

> >>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>> details like associated msi_chip into the host bridge and the child busses will
> >>> have an easy way of finding the information needed by finding the root bus and then
> >>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>> everyone and the drivers can remove their kludges that try to work around the
> >>> current limitations.
> >>
> >> I think both issues are orthogonal. Last time I checked a lot of work
> >> was still necessary to unify host bridges enough so that it could be
> >> shared across architectures. But perhaps some of that work has
> >> happened in the meantime.
> > 
> > Breaking out the host bridge creation from root bus creation is not difficult, just not
> > agree upon. That would be the first step in making the generic host brige structure
> > useful for sharing, specially if used as a sort of "parent" structure that you can
> > wrap with your actual host bridge structure.
> 
> Breaking out the host bridge creation is a good idea, but there need a lot of changes, we can
> do it in another series.

I agree, this can be done step by step.

> And if we save msi chip in pci sysdata now, it will be easy to
> move it to generic pci host bridge. We can also move the pci domain number and other common info to it.

But like I said above, we wouldn't gain anything by moving the MSI chip
into struct pci_sys_data, since the core code couldn't access it from
there. The code wouldn't become more generic than the current approach
of using pcibios_add_bus(). At least for Tegra it's trivial to just hook
it up in tegra_pcie_scan_bus() directly (patch attached). So I think a
generic solution would be to allow it to be easily associated with a
bus.

Perhaps it would be as simple as adding a pci_scan_root_bus_with_msi()
or something with a less awkward name, or extending the existing
pci_scan_root_bus() with an MSI chip parameter. The function already has
too many arguments for my taste, though, so I'd like to avoid the
latter.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2014-09-26  8:54 UTC|newest]

Thread overview: 540+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-25  2:55 [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms Yijing Wang
2014-09-25  3:14 ` Yijing Wang
2014-09-25  3:14 ` Yijing Wang
2014-09-25  3:14 ` Yijing Wang
2014-09-25  3:14 ` Yijing Wang
2014-09-25  3:14 ` Yijing Wang
2014-09-25  2:56 ` Yijing Wang
2014-09-25  2:50 ` [PATCH v2 07/22] PCI/MSI: Refactor struct msi_chip to make it become more common Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:54   ` Yijing Wang
2014-09-25  2:50 ` [PATCH v2 05/22] s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq() Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:50   ` Yijing Wang
2014-09-25  2:51 ` [PATCH v2 22/22] PCI/MSI: Clean up unused MSI arch functions Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:51   ` Yijing Wang
2014-09-25  2:51 ` [PATCH v2 19/22] IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:52   ` Yijing Wang
2014-09-25  2:51 ` [PATCH v2 21/22] tile/MSI: " Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:52   ` Yijing Wang
2014-09-25  2:51 ` [PATCH v2 20/22] Sparc/MSI: " Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:52   ` Yijing Wang
2014-09-25  2:52 ` [PATCH v2 18/22] arm/iop13xx/MSI: " Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:52   ` Yijing Wang
2014-09-25  2:52 ` [PATCH v2 17/22] s390/MSI: " Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:53   ` Yijing Wang
2014-09-25  7:38   ` Thierry Reding
2014-09-25  7:38     ` Thierry Reding
2014-09-25  7:38     ` Thierry Reding
2014-09-25  7:38     ` Thierry Reding
2014-09-25  7:38     ` Thierry Reding
2014-09-25  7:38     ` Thierry Reding
2014-09-26  2:14     ` Yijing Wang
2014-09-26  2:14     ` Yijing Wang
2014-09-26  2:14       ` Yijing Wang
2014-09-26  2:14       ` Yijing Wang
2014-09-26  2:14       ` Yijing Wang
2014-09-26  2:14       ` Yijing Wang
2014-09-26  2:14       ` Yijing Wang
2014-09-26  2:14       ` Yijing Wang
2014-09-25  7:38   ` Thierry Reding
2014-09-25  2:52 ` [PATCH v2 08/22] x86/MSI: " Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:52   ` Yijing Wang
2014-09-25  2:53 ` [PATCH v2 16/22] Powerpc/MSI: " Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:53   ` Yijing Wang
2014-09-25  2:54 ` [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:59   ` Yijing Wang
2014-09-25  7:26   ` Thierry Reding
2014-09-25  7:26   ` Thierry Reding
2014-09-25  7:26     ` Thierry Reding
2014-09-25  7:26     ` Thierry Reding
2014-09-25  7:26     ` Thierry Reding
2014-09-25  7:26     ` Thierry Reding
2014-09-25  7:26     ` Thierry Reding
2014-09-26  2:10     ` Yijing Wang
2014-09-26  2:10       ` Yijing Wang
2014-09-26  2:10       ` Yijing Wang
2014-09-26  2:10       ` Yijing Wang
2014-09-26  2:10       ` Yijing Wang
2014-09-26  2:10       ` Yijing Wang
2014-09-26  2:10       ` Yijing Wang
2014-09-26  2:10     ` Yijing Wang
2014-09-25 10:38   ` Thomas Gleixner
2014-09-25 10:38     ` Thomas Gleixner
2014-09-25 10:38     ` Thomas Gleixner
2014-09-25 10:38     ` Thomas Gleixner
2014-09-25 10:38     ` Thomas Gleixner
2014-09-25 10:38     ` Thomas Gleixner
2014-09-26  2:33     ` Yijing Wang
2014-09-26  2:33       ` Yijing Wang
2014-09-26  2:33       ` Yijing Wang
2014-09-26  2:33       ` Yijing Wang
2014-09-26  2:33       ` Yijing Wang
2014-09-26  2:33       ` Yijing Wang
2014-09-26  2:33       ` Yijing Wang
2014-09-26  2:33     ` Yijing Wang
2014-09-26  2:44     ` Yijing Wang
2014-09-26  2:44       ` Yijing Wang
2014-09-26  2:44       ` Yijing Wang
2014-09-26  2:44       ` Yijing Wang
2014-09-26  2:44       ` Yijing Wang
2014-09-26  2:44       ` Yijing Wang
2014-09-26  2:44       ` Yijing Wang
2014-09-26 10:38       ` Thomas Gleixner
2014-09-26 10:38       ` Thomas Gleixner
2014-09-26 10:38         ` Thomas Gleixner
2014-09-26 10:38         ` Thomas Gleixner
2014-09-26 10:38         ` Thomas Gleixner
2014-09-26 10:38         ` Thomas Gleixner
2014-09-26 10:38         ` Thomas Gleixner
2014-09-28  2:35         ` Yijing Wang
2014-09-28  2:35         ` Yijing Wang
2014-09-28  2:35           ` Yijing Wang
2014-09-28  2:35           ` Yijing Wang
2014-09-28  2:35           ` Yijing Wang
2014-09-28  2:35           ` Yijing Wang
2014-09-28  2:35           ` Yijing Wang
2014-09-28  2:35           ` Yijing Wang
2014-09-26  2:44     ` Yijing Wang
2014-09-25 10:38   ` Thomas Gleixner
2014-09-25  2:54 ` [PATCH v2 12/22] MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:54   ` Yijing Wang
2014-09-25  7:34   ` Thierry Reding
2014-09-25  7:34   ` Thierry Reding
2014-09-25  7:34     ` Thierry Reding
2014-09-25  7:34     ` Thierry Reding
2014-09-25  7:34     ` Thierry Reding
2014-09-25  7:34     ` Thierry Reding
2014-09-25  7:34     ` Thierry Reding
2014-09-26  2:12     ` Yijing Wang
2014-09-26  2:12       ` Yijing Wang
2014-09-26  2:12       ` Yijing Wang
2014-09-26  2:12       ` Yijing Wang
2014-09-26  2:12       ` Yijing Wang
2014-09-26  2:12       ` Yijing Wang
2014-09-26  2:12       ` Yijing Wang
2014-09-26  2:12     ` Yijing Wang
2014-09-25  2:54 ` [PATCH v2 13/22] MIPS/Xlp: Remove the dead function destroy_irq() to fix build error Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:54   ` Yijing Wang
2014-09-25  2:55 ` [PATCH v2 03/22] MSI: Remove the redundant irq_set_chip_data() Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:57   ` Yijing Wang
2014-09-25  7:19   ` Thierry Reding
2014-09-25  7:19   ` Thierry Reding
2014-09-25  7:19     ` Thierry Reding
2014-09-25  7:19     ` Thierry Reding
2014-09-25  7:19     ` Thierry Reding
2014-09-25  7:19     ` Thierry Reding
2014-09-25  7:19     ` Thierry Reding
2014-09-26  2:04     ` Yijing Wang
2014-09-26  2:04     ` Yijing Wang
2014-09-26  2:04       ` Yijing Wang
2014-09-26  2:04       ` Yijing Wang
2014-09-26  2:04       ` Yijing Wang
2014-09-26  2:04       ` Yijing Wang
2014-09-26  2:04       ` Yijing Wang
2014-09-26  2:04       ` Yijing Wang
2014-09-26  8:09       ` Thierry Reding
2014-09-26  8:09       ` Thierry Reding
2014-09-26  8:09         ` Thierry Reding
2014-09-26  8:09         ` Thierry Reding
2014-09-26  8:09         ` Thierry Reding
2014-09-26  8:09         ` Thierry Reding
2014-09-26  8:09         ` Thierry Reding
2014-09-26  8:09   ` Thierry Reding
2014-09-26  8:09   ` Thierry Reding
2014-09-26  8:09     ` Thierry Reding
2014-09-26  8:09     ` Thierry Reding
2014-09-26  8:09     ` Thierry Reding
2014-09-26  8:09     ` Thierry Reding
2014-09-26  8:09     ` Thierry Reding
     [not found] ` <1411614872-4009-1-git-send-email-wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-09-25  2:53   ` [PATCH v2 15/22] MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  2:53     ` Yijing Wang
2014-09-25  7:37     ` Thierry Reding
2014-09-25  7:37     ` Thierry Reding
2014-09-25  7:37       ` Thierry Reding
2014-09-25  7:37       ` Thierry Reding
2014-09-25  7:37       ` Thierry Reding
2014-09-25  7:37       ` Thierry Reding
2014-09-25  7:37       ` Thierry Reding
2014-09-26  2:13       ` Yijing Wang
2014-09-26  2:13       ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-25  2:54   ` [PATCH v2 14/22] MIPS/Xlp/MSI: " Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  2:55     ` Yijing Wang
2014-09-25  7:36     ` Thierry Reding
2014-09-25  7:36       ` Thierry Reding
2014-09-25  7:36       ` Thierry Reding
2014-09-25  7:36       ` Thierry Reding
2014-09-25  7:36       ` Thierry Reding
2014-09-25  7:36       ` Thierry Reding
2014-09-26  2:13       ` Yijing Wang
2014-09-26  2:13       ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-26  2:13         ` Yijing Wang
2014-09-25  7:36     ` Thierry Reding
2014-09-25  2:55   ` [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  2:56     ` Yijing Wang
2014-09-25  7:15     ` Thierry Reding
2014-09-25  7:15     ` Thierry Reding
2014-09-25  7:15       ` Thierry Reding
2014-09-25  7:15       ` Thierry Reding
2014-09-25  7:15       ` Thierry Reding
2014-09-25  7:15       ` Thierry Reding
2014-09-25  7:15       ` Thierry Reding
2014-09-25 10:20       ` Thomas Gleixner
2014-09-25 10:20       ` Thomas Gleixner
2014-09-25 10:20         ` Thomas Gleixner
2014-09-25 10:20         ` Thomas Gleixner
2014-09-25 10:20         ` Thomas Gleixner
2014-09-25 10:20         ` Thomas Gleixner
2014-09-25 10:20         ` Thomas Gleixner
2014-09-26  2:15         ` Yijing Wang
2014-09-26  2:15         ` Yijing Wang
2014-09-26  2:15           ` Yijing Wang
2014-09-26  2:15           ` Yijing Wang
2014-09-26  2:15           ` Yijing Wang
2014-09-26  2:15           ` Yijing Wang
2014-09-26  2:15           ` Yijing Wang
2014-09-26  2:15           ` Yijing Wang
2014-09-26  1:58       ` Yijing Wang
2014-09-26  1:58       ` Yijing Wang
2014-09-26  1:58         ` Yijing Wang
2014-09-26  1:58         ` Yijing Wang
2014-09-26  1:58         ` Yijing Wang
2014-09-26  1:58         ` Yijing Wang
2014-09-26  1:58         ` Yijing Wang
2014-09-26  1:58         ` Yijing Wang
2014-09-25  2:56   ` [PATCH v2 11/22] x86/MSI: Remove unused MSI weak arch functions Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  2:56     ` Yijing Wang
2014-09-25  2:56   ` [PATCH v2 04/22] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq() Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  2:57     ` Yijing Wang
2014-09-25 14:33     ` Konrad Rzeszutek Wilk
2014-09-25 14:33     ` Konrad Rzeszutek Wilk
2014-09-25 14:33       ` Konrad Rzeszutek Wilk
2014-09-25 14:33       ` Konrad Rzeszutek Wilk
2014-09-25 14:33       ` Konrad Rzeszutek Wilk
2014-09-25 14:33       ` Konrad Rzeszutek Wilk
2014-09-25 14:33       ` Konrad Rzeszutek Wilk
2014-09-26  3:12       ` Yijing Wang
2014-09-26  3:12         ` Yijing Wang
2014-09-26  3:12         ` Yijing Wang
2014-09-26  3:12         ` Yijing Wang
2014-09-26  3:12         ` Yijing Wang
2014-09-26  3:12         ` Yijing Wang
2014-09-26  3:12         ` Yijing Wang
2014-09-26  3:12       ` Yijing Wang
2014-09-25  2:57   ` [PATCH v2 02/22] PCI/MSI: Remove useless bus->msi assignment Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  3:14     ` Yijing Wang
2014-09-25  2:58     ` Yijing Wang
2014-09-25  7:06     ` Thierry Reding
2014-09-25  7:06       ` Thierry Reding
2014-09-25  7:06       ` Thierry Reding
2014-09-25  7:06       ` Thierry Reding
2014-09-25  7:06       ` Thierry Reding
2014-09-25  7:06       ` Thierry Reding
2014-09-26  1:55       ` Yijing Wang
2014-09-26  1:55         ` Yijing Wang
2014-09-26  1:55         ` Yijing Wang
2014-09-26  1:55         ` Yijing Wang
2014-09-26  1:55         ` Yijing Wang
2014-09-26  1:55         ` Yijing Wang
2014-09-26  1:55         ` Yijing Wang
2014-09-26  1:55       ` Yijing Wang
2014-09-25  7:06     ` Thierry Reding
2014-09-25  2:57 ` [PATCH v2 09/22] x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:58   ` Yijing Wang
2014-09-25  2:57 ` [PATCH v2 10/22] Irq_remapping/MSI: " Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  3:14   ` Yijing Wang
2014-09-25  2:58   ` Yijing Wang
2014-09-25  3:14 ` [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument Yijing Wang
2014-09-25  3:14 ` [PATCH v2 02/22] PCI/MSI: Remove useless bus->msi assignment Yijing Wang
2014-09-25  3:14 ` [PATCH v2 03/22] MSI: Remove the redundant irq_set_chip_data() Yijing Wang
2014-09-25  3:14 ` [PATCH v2 04/22] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq() Yijing Wang
2014-09-25  3:14 ` [PATCH v2 05/22] s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq() Yijing Wang
2014-09-25  3:14 ` [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip Yijing Wang
2014-09-25  3:14 ` [PATCH v2 07/22] PCI/MSI: Refactor struct msi_chip to make it become more common Yijing Wang
2014-09-25  3:14 ` [PATCH v2 08/22] x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq Yijing Wang
2014-09-25  3:14 ` [PATCH v2 09/22] x86/xen/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 10/22] Irq_remapping/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 11/22] x86/MSI: Remove unused MSI weak arch functions Yijing Wang
2014-09-25  3:14 ` [PATCH v2 12/22] MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq Yijing Wang
2014-09-25  3:14 ` [PATCH v2 13/22] MIPS/Xlp: Remove the dead function destroy_irq() to fix build error Yijing Wang
2014-09-25  3:14 ` [PATCH v2 14/22] MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq Yijing Wang
2014-09-25  3:14 ` [PATCH v2 15/22] MIPS/Xlr/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 16/22] Powerpc/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 17/22] s390/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 18/22] arm/iop13xx/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 19/22] IA64/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 20/22] Sparc/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 21/22] tile/MSI: " Yijing Wang
2014-09-25  3:14 ` [PATCH v2 22/22] PCI/MSI: Clean up unused MSI arch functions Yijing Wang
2014-09-25  7:42 ` [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms Thierry Reding
2014-09-25  7:42 ` Thierry Reding
2014-09-25  7:42   ` Thierry Reding
2014-09-25  7:42   ` Thierry Reding
2014-09-25  7:42   ` Thierry Reding
2014-09-25  7:42   ` Thierry Reding
2014-09-25  7:42   ` Thierry Reding
2014-09-25 14:48   ` Liviu Dudau
2014-09-25 14:48   ` Liviu Dudau
2014-09-25 14:48     ` Liviu Dudau
2014-09-25 14:48     ` Liviu Dudau
2014-09-25 14:48     ` Liviu Dudau
2014-09-25 14:48     ` Liviu Dudau
2014-09-25 14:48     ` Liviu Dudau
2014-09-25 14:48     ` Liviu Dudau
2014-09-25 16:49     ` Thierry Reding
2014-09-25 16:49       ` Thierry Reding
2014-09-25 16:49       ` Thierry Reding
2014-09-25 16:49       ` Thierry Reding
2014-09-25 16:49       ` Thierry Reding
2014-09-25 16:49       ` Thierry Reding
2014-09-25 17:16       ` Liviu Dudau
2014-09-25 17:16       ` Liviu Dudau
2014-09-25 17:16         ` Liviu Dudau
2014-09-25 17:16         ` Liviu Dudau
2014-09-25 17:16         ` Liviu Dudau
2014-09-25 17:16         ` Liviu Dudau
2014-09-25 17:16         ` Liviu Dudau
2014-09-26  6:20         ` Yijing Wang
2014-09-26  6:20         ` Yijing Wang
2014-09-26  6:20           ` Yijing Wang
2014-09-26  6:20           ` Yijing Wang
2014-09-26  6:20           ` Yijing Wang
2014-09-26  6:20           ` Yijing Wang
2014-09-26  6:20           ` Yijing Wang
2014-09-26  6:20           ` Yijing Wang
2014-09-26  8:54           ` Thierry Reding
2014-09-26  8:54           ` Thierry Reding [this message]
2014-09-26  8:54             ` Thierry Reding
2014-09-26  8:54             ` Thierry Reding
2014-09-26  8:54             ` Thierry Reding
2014-09-26  8:54             ` Thierry Reding
2014-09-26  8:54             ` Thierry Reding
2014-09-26  9:05             ` Thierry Reding
2014-09-26  9:05               ` Thierry Reding
2014-09-26  9:05               ` Thierry Reding
2014-09-26  9:05               ` Thierry Reding
2014-09-26  9:05               ` Thierry Reding
2014-09-26  9:05               ` Thierry Reding
2014-09-28  2:32               ` Yijing Wang
2014-09-28  2:32               ` Yijing Wang
2014-09-28  2:32                 ` Yijing Wang
2014-09-28  2:32                 ` Yijing Wang
2014-09-28  2:32                 ` Yijing Wang
2014-09-28  2:32                 ` Yijing Wang
2014-09-28  2:32                 ` Yijing Wang
2014-09-28  2:32                 ` Yijing Wang
2014-09-28  6:11                 ` Yijing Wang
2014-09-28  6:11                 ` Yijing Wang
2014-09-28  6:11                   ` Yijing Wang
2014-09-28  6:11                   ` Yijing Wang
2014-09-28  6:11                   ` Yijing Wang
2014-09-28  6:11                   ` Yijing Wang
2014-09-28  6:11                   ` Yijing Wang
2014-09-28  6:11                   ` Yijing Wang
2014-09-29  8:37                   ` Lucas Stach
2014-09-29  8:37                   ` Lucas Stach
2014-09-29  8:37                     ` Lucas Stach
2014-09-29  8:37                     ` Lucas Stach
2014-09-29  8:37                     ` Lucas Stach
2014-09-29  8:37                     ` Lucas Stach
2014-09-29  8:37                     ` Lucas Stach
2014-09-29  8:37                     ` Lucas Stach
2014-09-29 10:13                     ` Yijing Wang
2014-09-29 10:13                     ` Yijing Wang
2014-09-29 10:13                       ` Yijing Wang
2014-09-29 10:13                       ` Yijing Wang
2014-09-29 10:13                       ` Yijing Wang
2014-09-29 10:13                       ` Yijing Wang
2014-09-29 10:13                       ` Yijing Wang
2014-09-29 10:13                       ` Yijing Wang
2014-09-26  9:05             ` Thierry Reding
2014-09-26  3:42       ` Yijing Wang
2014-09-26  3:42         ` Yijing Wang
2014-09-26  3:42         ` Yijing Wang
2014-09-26  3:42         ` Yijing Wang
2014-09-26  3:42         ` Yijing Wang
2014-09-26  3:42         ` Yijing Wang
2014-09-26  3:42         ` Yijing Wang
2014-09-26  8:50         ` Liviu Dudau
2014-09-26  8:50         ` Liviu Dudau
2014-09-26  8:50           ` Liviu Dudau
2014-09-26  8:50           ` Liviu Dudau
2014-09-26  8:50           ` Liviu Dudau
2014-09-26  8:50           ` Liviu Dudau
2014-09-26  8:50           ` Liviu Dudau
2014-09-28  2:16           ` Yijing Wang
2014-09-28  2:16           ` Yijing Wang
2014-09-28  2:16             ` Yijing Wang
2014-09-28  2:16             ` Yijing Wang
2014-09-28  2:16             ` Yijing Wang
2014-09-28  2:16             ` Yijing Wang
2014-09-28  2:16             ` Yijing Wang
2014-09-28  2:16             ` Yijing Wang
2014-09-28  2:16             ` Yijing Wang
2014-09-28 11:21             ` Liviu Dudau
2014-09-28 11:21               ` Liviu Dudau
2014-09-28 11:21               ` Liviu Dudau
2014-09-28 11:21               ` Liviu Dudau
2014-09-28 11:21               ` Liviu Dudau
2014-09-28 11:21               ` Liviu Dudau
2014-09-29  1:44               ` Yijing Wang
2014-09-29  1:44               ` Yijing Wang
2014-09-29  1:44                 ` Yijing Wang
2014-09-29  1:44                 ` Yijing Wang
2014-09-29  1:44                 ` Yijing Wang
2014-09-29  1:44                 ` Yijing Wang
2014-09-29  1:44                 ` Yijing Wang
2014-09-29  1:44                 ` Yijing Wang
2014-09-29  1:44                 ` Yijing Wang
2014-09-29  9:26                 ` Liviu Dudau
2014-09-29  9:26                 ` Liviu Dudau
2014-09-29  9:26                   ` Liviu Dudau
2014-09-29  9:26                   ` Liviu Dudau
2014-09-29  9:26                   ` Liviu Dudau
2014-09-29  9:26                   ` Liviu Dudau
2014-09-29  9:26                   ` Liviu Dudau
2014-09-29 10:12                   ` Yijing Wang
2014-09-29 10:12                   ` Yijing Wang
2014-09-29 10:12                     ` Yijing Wang
2014-09-29 10:12                     ` Yijing Wang
2014-09-29 10:12                     ` Yijing Wang
2014-09-29 10:12                     ` Yijing Wang
2014-09-29 10:12                     ` Yijing Wang
2014-09-29 10:12                     ` Yijing Wang
2014-09-29 10:12                     ` Yijing Wang
2014-09-28 11:21             ` Liviu Dudau
2014-09-26  3:42       ` Yijing Wang
2014-09-25 16:49     ` Thierry Reding
2014-09-25 14:23 ` Konrad Rzeszutek Wilk
2014-09-25 14:23   ` Konrad Rzeszutek Wilk
2014-09-25 14:23   ` Konrad Rzeszutek Wilk
2014-09-25 14:23   ` Konrad Rzeszutek Wilk
2014-09-25 14:23   ` Konrad Rzeszutek Wilk
2014-09-25 14:23   ` Konrad Rzeszutek Wilk
2014-09-26  2:47   ` Yijing Wang
2014-09-26  2:47     ` Yijing Wang
2014-09-26  2:47     ` Yijing Wang
2014-09-26  2:47     ` Yijing Wang
2014-09-26  2:47     ` Yijing Wang
2014-09-26  2:47     ` Yijing Wang
2014-09-26  2:47     ` Yijing Wang
2014-09-26  2:47   ` Yijing Wang
2014-09-25 14:23 ` Konrad Rzeszutek Wilk
2014-09-25  3:14 Yijing Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140926085430.GG31106@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=arnab.basu@freescale.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=cmetcalf@tilera.com \
    --cc=davem@davemloft.net \
    --cc=david.vrabel@citrix.com \
    --cc=huxinwei@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=konrad.wilk@oracle.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=liviu@dudau.co.uk \
    --cc=mpe@ellerman.id.au \
    --cc=ralf@linux-mips.org \
    --cc=sebott@linux.vnet.ibm.com \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tony.luck@intel.com \
    --cc=wangyijing@huawei.com \
    --cc=wuyun.wu@huawei.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.