[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
> 
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.

Good.

> 
> Regards,
> Lucas
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
> 
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.

It's a good suggestion, thanks! :)

> 
>>
>>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> 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.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> > 
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
> 
> Most.
> 
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
> 
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
> 
> > 
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
> 
> Now, I got it, thanks!
> 
> > 
> >> and generic data struct should
> >> be created in generic PCI code.
> > 
> > Not necessarily. What I have in mind is something like this:
> 
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.

I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.

> 
> 
> > 
> >  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> >    and anything else that is needed (like find_pci_host_bridge() function).
> >  - arch code does:
> > 
> > 	struct pci_controller {
> > 		struct pci_host_bridge bridge;
> > 		.....
> > 	};
> > 
> > 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> > 
> > 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > 	{
> > 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > 		if (bridge)
> > 			return to_pci_controller(bridge);
> > 
> > 		return NULL;
> > 	}
> > 
> > 	int arch_pci_init(....)
> > 	{
> > 		struct pci_controller *hose;
> > 		....
> > 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > 		pci_init_host_bridge(&hose->bridge);
> > 		....
> > 		pci_scan_root_bus(...., &hose->bridge, &resources);
> > 		....
> > 		return 0;
> > 	}
> > 
> > Then finding the right structure will be easy.
> > 
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> > 
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
> 
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().

Best regards,
Liviu

> 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >  
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> 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.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> > 
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
> 
> Most.
> 
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
> 
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
> 
> > 
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
> 
> Now, I got it, thanks!
> 
> > 
> >> and generic data struct should
> >> be created in generic PCI code.
> > 
> > Not necessarily. What I have in mind is something like this:
> 
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.

I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.

> 
> 
> > 
> >  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> >    and anything else that is needed (like find_pci_host_bridge() function).
> >  - arch code does:
> > 
> > 	struct pci_controller {
> > 		struct pci_host_bridge bridge;
> > 		.....
> > 	};
> > 
> > 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> > 
> > 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > 	{
> > 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > 		if (bridge)
> > 			return to_pci_controller(bridge);
> > 
> > 		return NULL;
> > 	}
> > 
> > 	int arch_pci_init(....)
> > 	{
> > 		struct pci_controller *hose;
> > 		....
> > 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > 		pci_init_host_bridge(&hose->bridge);
> > 		....
> > 		pci_scan_root_bus(...., &hose->bridge, &resources);
> > 		....
> > 		return 0;
> > 	}
> > 
> > Then finding the right structure will be easy.
> > 
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> > 
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
> 
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().

Best regards,
Liviu

> 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >  
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> 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.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> > 
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
> 
> Most.
> 
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
> 
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
> 
> > 
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
> 
> Now, I got it, thanks!
> 
> > 
> >> and generic data struct should
> >> be created in generic PCI code.
> > 
> > Not necessarily. What I have in mind is something like this:
> 
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.

I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.

> 
> 
> > 
> >  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> >    and anything else that is needed (like find_pci_host_bridge() function).
> >  - arch code does:
> > 
> > 	struct pci_controller {
> > 		struct pci_host_bridge bridge;
> > 		.....
> > 	};
> > 
> > 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> > 
> > 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > 	{
> > 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > 		if (bridge)
> > 			return to_pci_controller(bridge);
> > 
> > 		return NULL;
> > 	}
> > 
> > 	int arch_pci_init(....)
> > 	{
> > 		struct pci_controller *hose;
> > 		....
> > 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > 		pci_init_host_bridge(&hose->bridge);
> > 		....
> > 		pci_scan_root_bus(...., &hose->bridge, &resources);
> > 		....
> > 		return 0;
> > 	}
> > 
> > Then finding the right structure will be easy.
> > 
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> > 
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
> 
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().

Best regards,
Liviu

> 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >  
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> 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.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> > 
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
> 
> Most.
> 
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
> 
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
> 
> > 
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
> 
> Now, I got it, thanks!
> 
> > 
> >> and generic data struct should
> >> be created in generic PCI code.
> > 
> > Not necessarily. What I have in mind is something like this:
> 
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.

I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.

> 
> 
> > 
> >  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> >    and anything else that is needed (like find_pci_host_bridge() function).
> >  - arch code does:
> > 
> > 	struct pci_controller {
> > 		struct pci_host_bridge bridge;
> > 		.....
> > 	};
> > 
> > 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> > 
> > 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > 	{
> > 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > 		if (bridge)
> > 			return to_pci_controller(bridge);
> > 
> > 		return NULL;
> > 	}
> > 
> > 	int arch_pci_init(....)
> > 	{
> > 		struct pci_controller *hose;
> > 		....
> > 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > 		pci_init_host_bridge(&hose->bridge);
> > 		....
> > 		pci_scan_root_bus(...., &hose->bridge, &resources);
> > 		....
> > 		return 0;
> > 	}
> > 
> > Then finding the right structure will be easy.
> > 
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> > 
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
> 
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().

Best regards,
Liviu

> 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >  
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> 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.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> > 
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
> 
> Most.
> 
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
> 
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
> 
> > 
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
> 
> Now, I got it, thanks!
> 
> > 
> >> and generic data struct should
> >> be created in generic PCI code.
> > 
> > Not necessarily. What I have in mind is something like this:
> 
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.

I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.

> 
> 
> > 
> >  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> >    and anything else that is needed (like find_pci_host_bridge() function).
> >  - arch code does:
> > 
> > 	struct pci_controller {
> > 		struct pci_host_bridge bridge;
> > 		.....
> > 	};
> > 
> > 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> > 
> > 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > 	{
> > 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > 		if (bridge)
> > 			return to_pci_controller(bridge);
> > 
> > 		return NULL;
> > 	}
> > 
> > 	int arch_pci_init(....)
> > 	{
> > 		struct pci_controller *hose;
> > 		....
> > 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > 		pci_init_host_bridge(&hose->bridge);
> > 		....
> > 		pci_scan_root_bus(...., &hose->bridge, &resources);
> > 		....
> > 		return 0;
> > 	}
> > 
> > Then finding the right structure will be easy.
> > 
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> > 
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
> 
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().

Best regards,
Liviu

> 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >  
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> 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.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> > 
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
> 
> Most.
> 
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
> 
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
> 
> > 
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
> 
> Now, I got it, thanks!
> 
> > 
> >> and generic data struct should
> >> be created in generic PCI code.
> > 
> > Not necessarily. What I have in mind is something like this:
> 
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.

I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.

> 
> 
> > 
> >  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> >    and anything else that is needed (like find_pci_host_bridge() function).
> >  - arch code does:
> > 
> > 	struct pci_controller {
> > 		struct pci_host_bridge bridge;
> > 		.....
> > 	};
> > 
> > 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> > 
> > 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > 	{
> > 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > 		if (bridge)
> > 			return to_pci_controller(bridge);
> > 
> > 		return NULL;
> > 	}
> > 
> > 	int arch_pci_init(....)
> > 	{
> > 		struct pci_controller *hose;
> > 		....
> > 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > 		pci_init_host_bridge(&hose->bridge);
> > 		....
> > 		pci_scan_root_bus(...., &hose->bridge, &resources);
> > 		....
> > 		return 0;
> > 	}
> > 
> > Then finding the right structure will be easy.
> > 
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> > 
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
> 
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().

Best regards,
Liviu

> 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >  
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> 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.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> > 
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
> 
> Most.
> 
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
> 
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
> 
> > 
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
> 
> Now, I got it, thanks!
> 
> > 
> >> and generic data struct should
> >> be created in generic PCI code.
> > 
> > Not necessarily. What I have in mind is something like this:
> 
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.

I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.

> 
> 
> > 
> >  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> >    and anything else that is needed (like find_pci_host_bridge() function).
> >  - arch code does:
> > 
> > 	struct pci_controller {
> > 		struct pci_host_bridge bridge;
> > 		.....
> > 	};
> > 
> > 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> > 
> > 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > 	{
> > 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > 		if (bridge)
> > 			return to_pci_controller(bridge);
> > 
> > 		return NULL;
> > 	}
> > 
> > 	int arch_pci_init(....)
> > 	{
> > 		struct pci_controller *hose;
> > 		....
> > 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > 		pci_init_host_bridge(&hose->bridge);
> > 		....
> > 		pci_scan_root_bus(...., &hose->bridge, &resources);
> > 		....
> > 		return 0;
> > 	}
> > 
> > Then finding the right structure will be easy.
> > 
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> > 
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
> 
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().

Best regards,
Liviu

> 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >  
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Lucas Stach]

Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> > 
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
> 
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.

Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> 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.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
> 
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to

Most.

> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.

Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.

> 
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.

Now, I got it, thanks!

> 
>> and generic data struct should
>> be created in generic PCI code.
> 
> Not necessarily. What I have in mind is something like this:

This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.


> 
>  - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
>    and anything else that is needed (like find_pci_host_bridge() function).
>  - arch code does:
> 
> 	struct pci_controller {
> 		struct pci_host_bridge bridge;
> 		.....
> 	};
> 
> 	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)
> 
> 	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> 	{
> 		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> 		if (bridge)
> 			return to_pci_controller(bridge);
> 
> 		return NULL;
> 	}
> 
> 	int arch_pci_init(....)
> 	{
> 		struct pci_controller *hose;
> 		....
> 		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> 		pci_init_host_bridge(&hose->bridge);
> 		....
> 		pci_scan_root_bus(...., &hose->bridge, &resources);
> 		....
> 		return 0;
> 	}
> 
> Then finding the right structure will be easy.
> 
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
> 
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.

Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>  
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> 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.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> > 
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
> 
> I inspected every arch and found there are almost no common stuff,

I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.

What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.

> and generic data struct should
> be created in generic PCI code.

Not necessarily. What I have in mind is something like this:

 - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
   and anything else that is needed (like find_pci_host_bridge() function).
 - arch code does:

	struct pci_controller {
		struct pci_host_bridge bridge;
		.....
	};

	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)

	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
	{
		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
		if (bridge)
			return to_pci_controller(bridge);

		return NULL;
	}

	int arch_pci_init(....)
	{
		struct pci_controller *hose;
		....
		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
		pci_init_host_bridge(&hose->bridge);
		....
		pci_scan_root_bus(...., &hose->bridge, &resources);
		....
		return 0;
	}

Then finding the right structure will be easy.

> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>

I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.

Best regards,
Liviu

 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >>
> >>>
> >>> 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.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> 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.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> > 
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
> 
> I inspected every arch and found there are almost no common stuff,

I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.

What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.

> and generic data struct should
> be created in generic PCI code.

Not necessarily. What I have in mind is something like this:

 - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
   and anything else that is needed (like find_pci_host_bridge() function).
 - arch code does:

	struct pci_controller {
		struct pci_host_bridge bridge;
		.....
	};

	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)

	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
	{
		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
		if (bridge)
			return to_pci_controller(bridge);

		return NULL;
	}

	int arch_pci_init(....)
	{
		struct pci_controller *hose;
		....
		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
		pci_init_host_bridge(&hose->bridge);
		....
		pci_scan_root_bus(...., &hose->bridge, &resources);
		....
		return 0;
	}

Then finding the right structure will be easy.

> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>

I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.

Best regards,
Liviu

 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >>
> >>>
> >>> 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.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> 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.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> > 
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
> 
> I inspected every arch and found there are almost no common stuff,

I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.

What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.

> and generic data struct should
> be created in generic PCI code.

Not necessarily. What I have in mind is something like this:

 - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
   and anything else that is needed (like find_pci_host_bridge() function).
 - arch code does:

	struct pci_controller {
		struct pci_host_bridge bridge;
		.....
	};

	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)

	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
	{
		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
		if (bridge)
			return to_pci_controller(bridge);

		return NULL;
	}

	int arch_pci_init(....)
	{
		struct pci_controller *hose;
		....
		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
		pci_init_host_bridge(&hose->bridge);
		....
		pci_scan_root_bus(...., &hose->bridge, &resources);
		....
		return 0;
	}

Then finding the right structure will be easy.

> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>

I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.

Best regards,
Liviu

 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >>
> >>>
> >>> 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.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> 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.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> > 
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
> 
> I inspected every arch and found there are almost no common stuff,

I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.

What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.

> and generic data struct should
> be created in generic PCI code.

Not necessarily. What I have in mind is something like this:

 - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
   and anything else that is needed (like find_pci_host_bridge() function).
 - arch code does:

	struct pci_controller {
		struct pci_host_bridge bridge;
		.....
	};

	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)

	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
	{
		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
		if (bridge)
			return to_pci_controller(bridge);

		return NULL;
	}

	int arch_pci_init(....)
	{
		struct pci_controller *hose;
		....
		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
		pci_init_host_bridge(&hose->bridge);
		....
		pci_scan_root_bus(...., &hose->bridge, &resources);
		....
		return 0;
	}

Then finding the right structure will be easy.

> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>

I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.

Best regards,
Liviu

 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >>
> >>>
> >>> 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.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> 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.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> > 
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
> 
> I inspected every arch and found there are almost no common stuff,

I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.

What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.

> and generic data struct should
> be created in generic PCI code.

Not necessarily. What I have in mind is something like this:

 - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
   and anything else that is needed (like find_pci_host_bridge() function).
 - arch code does:

	struct pci_controller {
		struct pci_host_bridge bridge;
		.....
	};

	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)

	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
	{
		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
		if (bridge)
			return to_pci_controller(bridge);

		return NULL;
	}

	int arch_pci_init(....)
	{
		struct pci_controller *hose;
		....
		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
		pci_init_host_bridge(&hose->bridge);
		....
		pci_scan_root_bus(...., &hose->bridge, &resources);
		....
		return 0;
	}

Then finding the right structure will be easy.

> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>

I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.

Best regards,
Liviu

 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >>
> >>>
> >>> 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.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> 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.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> > 
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
> 
> I inspected every arch and found there are almost no common stuff,

I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.

What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.

> and generic data struct should
> be created in generic PCI code.

Not necessarily. What I have in mind is something like this:

 - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
   and anything else that is needed (like find_pci_host_bridge() function).
 - arch code does:

	struct pci_controller {
		struct pci_host_bridge bridge;
		.....
	};

	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)

	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
	{
		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
		if (bridge)
			return to_pci_controller(bridge);

		return NULL;
	}

	int arch_pci_init(....)
	{
		struct pci_controller *hose;
		....
		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
		pci_init_host_bridge(&hose->bridge);
		....
		pci_scan_root_bus(...., &hose->bridge, &resources);
		....
		return 0;
	}

Then finding the right structure will be easy.

> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>

I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.

Best regards,
Liviu

 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >>
> >>>
> >>> 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.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> 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.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> > 
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
> 
> I inspected every arch and found there are almost no common stuff,

I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.

What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.

> and generic data struct should
> be created in generic PCI code.

Not necessarily. What I have in mind is something like this:

 - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
   and anything else that is needed (like find_pci_host_bridge() function).
 - arch code does:

	struct pci_controller {
		struct pci_host_bridge bridge;
		.....
	};

	#define to_pci_controller(bridge)	container_of(bridge, struct pci_controller, bridge)

	static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
	{
		struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
		if (bridge)
			return to_pci_controller(bridge);

		return NULL;
	}

	int arch_pci_init(....)
	{
		struct pci_controller *hose;
		....
		hose = kzalloc(sizeof(*hose), GFP_KERNEL);
		pci_init_host_bridge(&hose->bridge);
		....
		pci_scan_root_bus(...., &hose->bridge, &resources);
		....
		return 0;
	}

Then finding the right structure will be easy.

> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>

I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.

Best regards,
Liviu

 
> Thanks!
> Yijing.
> 
> > 
> > Best regards,
> > Liviu
> > 
> >>
> >>>
> >>> 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.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> -- 
> >> Thanks!
> >> Yijing
> >>
> >>
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
> 
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.

Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.

> 
> Thanks!
> Yijing.
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
> 
> Really attached this time.
> 
> Thierry
> 

It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.

Thanks!
Yijing.

-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>>>> 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.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> 
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.

I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.

Thanks!
Yijing.

> 
> Best regards,
> Liviu
> 
>>
>>>
>>> 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.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> -- 
>> Thanks!
>> Yijing
>>
>>
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).

Really attached this time.

Thierry

[-- Attachment #1.2: 0001-PCI-tegra-Remove-.add_bus-callback.patch --]
[-- Type: text/x-diff, Size: 1945 bytes --]

From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Fri, 26 Sep 2014 10:35:47 +0200
Subject: [PATCH] PCI: tegra: Remove .add_bus() callback

The .add_bus() callback is called for every bus and used to associate an
MSI chip with each bus. However the PCI core code already propagates the
root bus' MSI chip to child busses, so it is enough to associate the MSI
chip with the root bus upon creation. Conveniently the Tegra PCIe host
bridge driver creates the root bus directly, so the association can be
done at the same time.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/pci/host/pci-tegra.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874319be..d314e549ac0c 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
 	return irq;
 }
 
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
-		bus->msi = &pcie->msi.chip;
-	}
-}
-
 static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 {
 	struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -713,6 +704,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	if (!bus)
 		return NULL;
 
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		bus->msi = &pcie->msi.chip;
+
 	pci_scan_child_bus(bus);
 
 	return bus;
@@ -1885,7 +1879,6 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	hw.private_data = (void **)&pcie;
 	hw.setup = tegra_pcie_setup;
 	hw.map_irq = tegra_pcie_map_irq;
-	hw.add_bus = tegra_pcie_add_bus;
 	hw.scan = tegra_pcie_scan_bus;
 	hw.ops = &tegra_pcie_ops;
 
-- 
2.1.0


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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- Attachment #1.1.1: Type: text/plain, Size: 214 bytes --]

On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).

Really attached this time.

Thierry

[-- Attachment #1.1.2: 0001-PCI-tegra-Remove-.add_bus-callback.patch --]
[-- Type: text/x-diff, Size: 2003 bytes --]

From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Date: Fri, 26 Sep 2014 10:35:47 +0200
Subject: [PATCH] PCI: tegra: Remove .add_bus() callback

The .add_bus() callback is called for every bus and used to associate an
MSI chip with each bus. However the PCI core code already propagates the
root bus' MSI chip to child busses, so it is enough to associate the MSI
chip with the root bus upon creation. Conveniently the Tegra PCIe host
bridge driver creates the root bus directly, so the association can be
done at the same time.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 drivers/pci/host/pci-tegra.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874319be..d314e549ac0c 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
 	return irq;
 }
 
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
-		bus->msi = &pcie->msi.chip;
-	}
-}
-
 static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 {
 	struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -713,6 +704,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	if (!bus)
 		return NULL;
 
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		bus->msi = &pcie->msi.chip;
+
 	pci_scan_child_bus(bus);
 
 	return bus;
@@ -1885,7 +1879,6 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	hw.private_data = (void **)&pcie;
 	hw.setup = tegra_pcie_setup;
 	hw.map_irq = tegra_pcie_map_irq;
-	hw.add_bus = tegra_pcie_add_bus;
 	hw.scan = tegra_pcie_scan_bus;
 	hw.ops = &tegra_pcie_ops;
 
-- 
2.1.0


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

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).

Really attached this time.

Thierry

[-- Attachment #1.2: 0001-PCI-tegra-Remove-.add_bus-callback.patch --]
[-- Type: text/x-diff, Size: 1945 bytes --]

From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Fri, 26 Sep 2014 10:35:47 +0200
Subject: [PATCH] PCI: tegra: Remove .add_bus() callback

The .add_bus() callback is called for every bus and used to associate an
MSI chip with each bus. However the PCI core code already propagates the
root bus' MSI chip to child busses, so it is enough to associate the MSI
chip with the root bus upon creation. Conveniently the Tegra PCIe host
bridge driver creates the root bus directly, so the association can be
done at the same time.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/pci/host/pci-tegra.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874319be..d314e549ac0c 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
 	return irq;
 }
 
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
-		bus->msi = &pcie->msi.chip;
-	}
-}
-
 static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 {
 	struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -713,6 +704,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	if (!bus)
 		return NULL;
 
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		bus->msi = &pcie->msi.chip;
+
 	pci_scan_child_bus(bus);
 
 	return bus;
@@ -1885,7 +1879,6 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	hw.private_data = (void **)&pcie;
 	hw.setup = tegra_pcie_setup;
 	hw.map_irq = tegra_pcie_map_irq;
-	hw.add_bus = tegra_pcie_add_bus;
 	hw.scan = tegra_pcie_scan_bus;
 	hw.ops = &tegra_pcie_ops;
 
-- 
2.1.0


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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).

Really attached this time.

Thierry

[-- Attachment #1.2: 0001-PCI-tegra-Remove-.add_bus-callback.patch --]
[-- Type: text/x-diff, Size: 1945 bytes --]

From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Fri, 26 Sep 2014 10:35:47 +0200
Subject: [PATCH] PCI: tegra: Remove .add_bus() callback

The .add_bus() callback is called for every bus and used to associate an
MSI chip with each bus. However the PCI core code already propagates the
root bus' MSI chip to child busses, so it is enough to associate the MSI
chip with the root bus upon creation. Conveniently the Tegra PCIe host
bridge driver creates the root bus directly, so the association can be
done at the same time.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/pci/host/pci-tegra.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874319be..d314e549ac0c 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
 	return irq;
 }
 
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
-		bus->msi = &pcie->msi.chip;
-	}
-}
-
 static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 {
 	struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -713,6 +704,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	if (!bus)
 		return NULL;
 
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		bus->msi = &pcie->msi.chip;
+
 	pci_scan_child_bus(bus);
 
 	return bus;
@@ -1885,7 +1879,6 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	hw.private_data = (void **)&pcie;
 	hw.setup = tegra_pcie_setup;
 	hw.map_irq = tegra_pcie_map_irq;
-	hw.add_bus = tegra_pcie_add_bus;
 	hw.scan = tegra_pcie_scan_bus;
 	hw.ops = &tegra_pcie_ops;
 
-- 
2.1.0


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

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).

Really attached this time.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PCI-tegra-Remove-.add_bus-callback.patch
Type: text/x-diff
Size: 1887 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140926/f14452d9/attachment.bin>
-------------- 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/f14452d9/attachment.sig>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- Attachment #1.1.1: Type: text/plain, Size: 214 bytes --]

On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).

Really attached this time.

Thierry

[-- Attachment #1.1.2: 0001-PCI-tegra-Remove-.add_bus-callback.patch --]
[-- Type: text/x-diff, Size: 1945 bytes --]

From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Fri, 26 Sep 2014 10:35:47 +0200
Subject: [PATCH] PCI: tegra: Remove .add_bus() callback

The .add_bus() callback is called for every bus and used to associate an
MSI chip with each bus. However the PCI core code already propagates the
root bus' MSI chip to child busses, so it is enough to associate the MSI
chip with the root bus upon creation. Conveniently the Tegra PCIe host
bridge driver creates the root bus directly, so the association can be
done at the same time.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/pci/host/pci-tegra.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874319be..d314e549ac0c 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
 	return irq;
 }
 
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
-		bus->msi = &pcie->msi.chip;
-	}
-}
-
 static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 {
 	struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -713,6 +704,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	if (!bus)
 		return NULL;
 
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		bus->msi = &pcie->msi.chip;
+
 	pci_scan_child_bus(bus);
 
 	return bus;
@@ -1885,7 +1879,6 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	hw.private_data = (void **)&pcie;
 	hw.setup = tegra_pcie_setup;
 	hw.map_irq = tegra_pcie_map_irq;
-	hw.add_bus = tegra_pcie_add_bus;
 	hw.scan = tegra_pcie_scan_bus;
 	hw.ops = &tegra_pcie_ops;
 
-- 
2.1.0


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

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> directly (patch attached).

Really attached this time.

Thierry

[-- Attachment #1.2: 0001-PCI-tegra-Remove-.add_bus-callback.patch --]
[-- Type: text/x-diff, Size: 1945 bytes --]

From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Fri, 26 Sep 2014 10:35:47 +0200
Subject: [PATCH] PCI: tegra: Remove .add_bus() callback

The .add_bus() callback is called for every bus and used to associate an
MSI chip with each bus. However the PCI core code already propagates the
root bus' MSI chip to child busses, so it is enough to associate the MSI
chip with the root bus upon creation. Conveniently the Tegra PCIe host
bridge driver creates the root bus directly, so the association can be
done at the same time.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/pci/host/pci-tegra.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 3d43874319be..d314e549ac0c 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -694,15 +694,6 @@ static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
 	return irq;
 }
 
-static void tegra_pcie_add_bus(struct pci_bus *bus)
-{
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
-
-		bus->msi = &pcie->msi.chip;
-	}
-}
-
 static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 {
 	struct tegra_pcie *pcie = sys_to_pcie(sys);
@@ -713,6 +704,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	if (!bus)
 		return NULL;
 
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		bus->msi = &pcie->msi.chip;
+
 	pci_scan_child_bus(bus);
 
 	return bus;
@@ -1885,7 +1879,6 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	hw.private_data = (void **)&pcie;
 	hw.setup = tegra_pcie_setup;
 	hw.map_irq = tegra_pcie_map_irq;
-	hw.add_bus = tegra_pcie_add_bus;
 	hw.scan = tegra_pcie_scan_bus;
 	hw.ops = &tegra_pcie_ops;
 
-- 
2.1.0


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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- 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 --]

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- 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 --]

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- 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 --]

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- 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 --]

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- 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: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

[-- 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 --]

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> > 
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
> 
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
> 
> > 
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> > 
> > 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.
> 
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
> 
> > 
> >> 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.
> 
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.

Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.

Best regards,
Liviu

> 
> > 
> > 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.
> > 
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> > 
> > Thierry
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> > 
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
> 
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
> 
> > 
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> > 
> > 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.
> 
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
> 
> > 
> >> 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.
> 
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.

Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.

Best regards,
Liviu

> 
> > 
> > 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.
> > 
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> > 
> > Thierry
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> > 
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
> 
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
> 
> > 
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> > 
> > 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.
> 
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
> 
> > 
> >> 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.
> 
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.

Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.

Best regards,
Liviu

> 
> > 
> > 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.
> > 
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> > 
> > Thierry
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> > 
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
> 
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
> 
> > 
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> > 
> > 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.
> 
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
> 
> > 
> >> 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.
> 
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.

Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.

Best regards,
Liviu

> 
> > 
> > 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.
> > 
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> > 
> > Thierry
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> > 
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
> 
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
> 
> > 
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> > 
> > 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.
> 
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
> 
> > 
> >> 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.
> 
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.

Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.

Best regards,
Liviu

> 
> > 
> > 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.
> > 
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> > 
> > Thierry
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> > 
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
> 
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
> 
> > 
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> > 
> > 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.
> 
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
> 
> > 
> >> 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.
> 
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.

Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.

Best regards,
Liviu

> 
> > 
> > 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.
> > 
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> > 
> > Thierry
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Fri, Sep 26, 2014 at 11:42:23AM +0800, Yijing Wang wrote:
> >> I am actually in disagreement with you, Thierry. I don't like the general direction
> >> of the patches, or at least I don't like the fact that we don't have a portable
> >> way of setting up the msi_chip without having to rely on weak architectural hooks.
> > 
> > Oh, good. That's actually one of the things I said I wasn't happy with
> > either. =)
> 
> Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
> Let's find a better solution :)
> 
> > 
> >> I'm surprised no one considers the case of a platform having more than one host
> >> bridge and possibly more than one MSI unit. With the current proposed patchset I
> >> can't see how that would work.
> > 
> > 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.
> 
> Yes, PCI hostbridge driver find the matched msi chip during its initialization,
> and assign the msi chip to PCI bus in pcibios_add_bus().
> 
> > 
> >> 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.
> 
> So I think maybe save msi chip in PCI arch sysdata is a good candidate.

Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
sysdata around the pci_host_bridge*.

Best regards,
Liviu

> 
> > 
> > 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.
> > 
> > But like I said, when you create the root bus, you can easily attach the
> > MSI chip to it.
> > 
> > Thierry
> > 
> 
> 
> -- 
> Thanks!
> Yijing
> 
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> 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.

> 
>>
>>> 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. 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.

Thanks!
Yijing.

> 
>>
>> But like I said, when you create the root bus, you can easily attach the
>> MSI chip to it.
> 
> Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
> and add their own needed modifications. Which makes it hard to fix bugs and prevents code
> reuse.
> 
> Best regards,
> Liviu
> 
>>
>> Thierry
> 
> 
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

>> I am actually in disagreement with you, Thierry. I don't like the general direction
>> of the patches, or at least I don't like the fact that we don't have a portable
>> way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)

Hm, I decide to drop weak arch_find_msi_chip(), no one likes it.
Let's find a better solution :)

> 
>> I'm surprised no one considers the case of a platform having more than one host
>> bridge and possibly more than one MSI unit. With the current proposed patchset I
>> can't see how that would work.
> 
> 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.

Yes, PCI hostbridge driver find the matched msi chip during its initialization,
and assign the msi chip to PCI bus in pcibios_add_bus().

> 
>> 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.

So I think maybe save msi chip in PCI arch sysdata is a good candidate.

> 
> 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.
> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.
> 
> Thierry
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
>> This series is based Bjorn's pci/msi branch
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Is there a git tree for these patches?

Hi Konrad, my git tree in company can not be pulled from outside.
I will try to update this series to github these days.


>>
>> Currently, there are a lot of weak arch functions in MSI code.
>> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
>> This series use MSI chip framework to refactor MSI code across all platforms
>> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
>> unified framework. Because this series changed a lot of ARCH MSI code,
>> so tests in the platforms which MSI code modified are warmly welcomed!
>>
>> v1->v2:
>> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
>> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
>>
>> RFC->v1: 
>> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
>> of #ifdef to fix MSI bug in xen running in x86. 
>> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
>> Drop use struct device as the msi_chip argument, we will do that
>> later in another patchset.
>>
>> Yijing Wang (22):
>>   PCI/MSI: Clean up struct msi_chip argument
>>   PCI/MSI: Remove useless bus->msi assignment
>>   MSI: Remove the redundant irq_set_chip_data()
>>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>>   PCI/MSI: Refactor struct msi_chip to make it become more common
>>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   x86/MSI: Remove unused MSI weak arch functions
>>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>>   PCI/MSI: Clean up unused MSI arch functions
>>
>>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>>  arch/powerpc/kernel/msi.c                |   14 +++-
>>  arch/s390/pci/pci.c                      |   18 ++++-
>>  arch/sparc/kernel/pci.c                  |   14 +++-
>>  arch/tile/kernel/pci_gx.c                |   14 +++-
>>  arch/x86/include/asm/apic.h              |    4 +
>>  arch/x86/include/asm/pci.h               |    4 +-
>>  arch/x86/include/asm/x86_init.h          |    7 --
>>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>>  arch/x86/kernel/x86_init.c               |   34 ---------
>>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>>  drivers/iommu/irq_remapping.c            |    9 ++-
>>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>>  drivers/pci/host/pci-tegra.c             |    8 ++-
>>  drivers/pci/host/pcie-designware.c       |    4 +-
>>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>>  drivers/pci/probe.c                      |    1 -
>>  include/linux/msi.h                      |   26 ++-----
>>  27 files changed, 266 insertions(+), 202 deletions(-)
>>
> 
> .
> 


-- 
Thanks!
Yijing

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > > 
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > > 
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > > 
> > > Thierry
> > 
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
> 
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
> 
> 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.

> 
> > 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.

> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.

Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.

Best regards,
Liviu

> 
> Thierry



-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > > 
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > > 
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > > 
> > > Thierry
> > 
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
> 
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
> 
> 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.

> 
> > 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.

> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.

Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.

Best regards,
Liviu

> 
> Thierry



-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > > 
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > > 
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > > 
> > > Thierry
> > 
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
> 
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
> 
> 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.

> 
> > 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.

> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.

Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.

Best regards,
Liviu

> 
> Thierry



-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > > 
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > > 
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > > 
> > > Thierry
> > 
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
> 
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
> 
> 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.

> 
> > 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.

> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.

Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.

Best regards,
Liviu

> 
> Thierry



-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > > 
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > > 
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > > 
> > > Thierry
> > 
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
> 
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
> 
> 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.

> 
> > 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.

> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.

Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.

Best regards,
Liviu

> 
> Thierry



-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > > 
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > > 
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > > 
> > > Thierry
> > 
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
> 
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
> 
> 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.

> 
> > 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.

> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.

Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.

Best regards,
Liviu

> 
> Thierry



-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> > On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > > This series is based Bjorn's pci/msi branch
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > > 
> > > > Currently, there are a lot of weak arch functions in MSI code.
> > > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > > This series use MSI chip framework to refactor MSI code across all platforms
> > > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > > so tests in the platforms which MSI code modified are warmly welcomed!
> > > 
> > > Apart from the comments to the individual patches I very much like where
> > > this is going. Thanks for taking care of this.
> > > 
> > > Thierry
> > 
> > I am actually in disagreement with you, Thierry. I don't like the general direction
> > of the patches, or at least I don't like the fact that we don't have a portable
> > way of setting up the msi_chip without having to rely on weak architectural hooks.
> 
> Oh, good. That's actually one of the things I said I wasn't happy with
> either. =)
> 
> > I'm surprised no one considers the case of a platform having more than one host
> > bridge and possibly more than one MSI unit. With the current proposed patchset I
> > can't see how that would work.
> 
> 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.

> 
> > 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.

> 
> But like I said, when you create the root bus, you can easily attach the
> MSI chip to it.

Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code
and add their own needed modifications. Which makes it hard to fix bugs and prevents code
reuse.

Best regards,
Liviu

> 
> Thierry



-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > 
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> > 
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> > 
> > Thierry
> 
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.

Oh, good. That's actually one of the things I said I wasn't happy with
either. =)

> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.

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.

> 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.

But like I said, when you create the root bus, you can easily attach the
MSI chip to it.

Thierry

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > 
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> > 
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> > 
> > Thierry
> 
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.

Oh, good. That's actually one of the things I said I wasn't happy with
either. =)

> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.

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.

> 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.

But like I said, when you create the root bus, you can easily attach the
MSI chip to it.

Thierry

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

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > 
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> > 
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> > 
> > Thierry
> 
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.

Oh, good. That's actually one of the things I said I wasn't happy with
either. =)

> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.

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.

> 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.

But like I said, when you create the root bus, you can easily attach the
MSI chip to it.

Thierry

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > 
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> > 
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> > 
> > Thierry
> 
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.

Oh, good. That's actually one of the things I said I wasn't happy with
either. =)

> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.

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.

> 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.

But like I said, when you create the root bus, you can easily attach the
MSI chip to it.

Thierry

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

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > 
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> > 
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> > 
> > Thierry
> 
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.

Oh, good. That's actually one of the things I said I wasn't happy with
either. =)

> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.

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.

> 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.

But like I said, when you create the root bus, you can easily attach the
MSI chip to it.

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/20140925/6a446ea2/attachment.sig>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > 
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> > 
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> > 
> > Thierry
> 
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.

Oh, good. That's actually one of the things I said I wasn't happy with
either. =)

> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.

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.

> 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.

But like I said, when you create the root bus, you can easily attach the
MSI chip to it.

Thierry

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

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
> On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> > On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > > This series is based Bjorn's pci/msi branch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > > 
> > > Currently, there are a lot of weak arch functions in MSI code.
> > > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > > This series use MSI chip framework to refactor MSI code across all platforms
> > > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > > unified framework. Because this series changed a lot of ARCH MSI code,
> > > so tests in the platforms which MSI code modified are warmly welcomed!
> > 
> > Apart from the comments to the individual patches I very much like where
> > this is going. Thanks for taking care of this.
> > 
> > Thierry
> 
> I am actually in disagreement with you, Thierry. I don't like the general direction
> of the patches, or at least I don't like the fact that we don't have a portable
> way of setting up the msi_chip without having to rely on weak architectural hooks.

Oh, good. That's actually one of the things I said I wasn't happy with
either. =)

> I'm surprised no one considers the case of a platform having more than one host
> bridge and possibly more than one MSI unit. With the current proposed patchset I
> can't see how that would work.

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.

> 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.

But like I said, when you create the root bus, you can easily attach the
MSI chip to it.

Thierry

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Liviu Dudau]

On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> > This series is based Bjorn's pci/msi branch
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> > 
> > Currently, there are a lot of weak arch functions in MSI code.
> > Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> > This series use MSI chip framework to refactor MSI code across all platforms
> > to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> > unified framework. Because this series changed a lot of ARCH MSI code,
> > so tests in the platforms which MSI code modified are warmly welcomed!
> 
> Apart from the comments to the individual patches I very much like where
> this is going. Thanks for taking care of this.
> 
> Thierry

I am actually in disagreement with you, Thierry. I don't like the general direction
of the patches, or at least I don't like the fact that we don't have a portable
way of setting up the msi_chip without having to rely on weak architectural hooks.
I'm surprised no one considers the case of a platform having more than one host
bridge and possibly more than one MSI unit. With the current proposed patchset I
can't see how that would work.

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.

Best regards,
Liviu

---------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Is there a git tree for these patches?
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (22):
>   PCI/MSI: Clean up struct msi_chip argument
>   PCI/MSI: Remove useless bus->msi assignment
>   MSI: Remove the redundant irq_set_chip_data()
>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>  arch/powerpc/kernel/msi.c                |   14 +++-
>  arch/s390/pci/pci.c                      |   18 ++++-
>  arch/sparc/kernel/pci.c                  |   14 +++-
>  arch/tile/kernel/pci_gx.c                |   14 +++-
>  arch/x86/include/asm/apic.h              |    4 +
>  arch/x86/include/asm/pci.h               |    4 +-
>  arch/x86/include/asm/x86_init.h          |    7 --
>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>  arch/x86/kernel/x86_init.c               |   34 ---------
>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>  drivers/iommu/irq_remapping.c            |    9 ++-
>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>  drivers/pci/host/pci-tegra.c             |    8 ++-
>  drivers/pci/host/pcie-designware.c       |    4 +-
>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>  drivers/pci/probe.c                      |    1 -
>  include/linux/msi.h                      |   26 ++-----
>  27 files changed, 266 insertions(+), 202 deletions(-)
> 

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Is there a git tree for these patches?
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (22):
>   PCI/MSI: Clean up struct msi_chip argument
>   PCI/MSI: Remove useless bus->msi assignment
>   MSI: Remove the redundant irq_set_chip_data()
>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>  arch/powerpc/kernel/msi.c                |   14 +++-
>  arch/s390/pci/pci.c                      |   18 ++++-
>  arch/sparc/kernel/pci.c                  |   14 +++-
>  arch/tile/kernel/pci_gx.c                |   14 +++-
>  arch/x86/include/asm/apic.h              |    4 +
>  arch/x86/include/asm/pci.h               |    4 +-
>  arch/x86/include/asm/x86_init.h          |    7 --
>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>  arch/x86/kernel/x86_init.c               |   34 ---------
>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>  drivers/iommu/irq_remapping.c            |    9 ++-
>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>  drivers/pci/host/pci-tegra.c             |    8 ++-
>  drivers/pci/host/pcie-designware.c       |    4 +-
>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>  drivers/pci/probe.c                      |    1 -
>  include/linux/msi.h                      |   26 ++-----
>  27 files changed, 266 insertions(+), 202 deletions(-)
> 

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Is there a git tree for these patches?
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (22):
>   PCI/MSI: Clean up struct msi_chip argument
>   PCI/MSI: Remove useless bus->msi assignment
>   MSI: Remove the redundant irq_set_chip_data()
>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>  arch/powerpc/kernel/msi.c                |   14 +++-
>  arch/s390/pci/pci.c                      |   18 ++++-
>  arch/sparc/kernel/pci.c                  |   14 +++-
>  arch/tile/kernel/pci_gx.c                |   14 +++-
>  arch/x86/include/asm/apic.h              |    4 +
>  arch/x86/include/asm/pci.h               |    4 +-
>  arch/x86/include/asm/x86_init.h          |    7 --
>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>  arch/x86/kernel/x86_init.c               |   34 ---------
>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>  drivers/iommu/irq_remapping.c            |    9 ++-
>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>  drivers/pci/host/pci-tegra.c             |    8 ++-
>  drivers/pci/host/pcie-designware.c       |    4 +-
>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>  drivers/pci/probe.c                      |    1 -
>  include/linux/msi.h                      |   26 ++-----
>  27 files changed, 266 insertions(+), 202 deletions(-)
> 

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Is there a git tree for these patches?
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (22):
>   PCI/MSI: Clean up struct msi_chip argument
>   PCI/MSI: Remove useless bus->msi assignment
>   MSI: Remove the redundant irq_set_chip_data()
>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>  arch/powerpc/kernel/msi.c                |   14 +++-
>  arch/s390/pci/pci.c                      |   18 ++++-
>  arch/sparc/kernel/pci.c                  |   14 +++-
>  arch/tile/kernel/pci_gx.c                |   14 +++-
>  arch/x86/include/asm/apic.h              |    4 +
>  arch/x86/include/asm/pci.h               |    4 +-
>  arch/x86/include/asm/x86_init.h          |    7 --
>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>  arch/x86/kernel/x86_init.c               |   34 ---------
>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>  drivers/iommu/irq_remapping.c            |    9 ++-
>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>  drivers/pci/host/pci-tegra.c             |    8 ++-
>  drivers/pci/host/pcie-designware.c       |    4 +-
>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>  drivers/pci/probe.c                      |    1 -
>  include/linux/msi.h                      |   26 ++-----
>  27 files changed, 266 insertions(+), 202 deletions(-)
> 

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Is there a git tree for these patches?
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (22):
>   PCI/MSI: Clean up struct msi_chip argument
>   PCI/MSI: Remove useless bus->msi assignment
>   MSI: Remove the redundant irq_set_chip_data()
>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>  arch/powerpc/kernel/msi.c                |   14 +++-
>  arch/s390/pci/pci.c                      |   18 ++++-
>  arch/sparc/kernel/pci.c                  |   14 +++-
>  arch/tile/kernel/pci_gx.c                |   14 +++-
>  arch/x86/include/asm/apic.h              |    4 +
>  arch/x86/include/asm/pci.h               |    4 +-
>  arch/x86/include/asm/x86_init.h          |    7 --
>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>  arch/x86/kernel/x86_init.c               |   34 ---------
>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>  drivers/iommu/irq_remapping.c            |    9 ++-
>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>  drivers/pci/host/pci-tegra.c             |    8 ++-
>  drivers/pci/host/pcie-designware.c       |    4 +-
>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>  drivers/pci/probe.c                      |    1 -
>  include/linux/msi.h                      |   26 ++-----
>  27 files changed, 266 insertions(+), 202 deletions(-)
> 

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Is there a git tree for these patches?
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (22):
>   PCI/MSI: Clean up struct msi_chip argument
>   PCI/MSI: Remove useless bus->msi assignment
>   MSI: Remove the redundant irq_set_chip_data()
>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>  arch/powerpc/kernel/msi.c                |   14 +++-
>  arch/s390/pci/pci.c                      |   18 ++++-
>  arch/sparc/kernel/pci.c                  |   14 +++-
>  arch/tile/kernel/pci_gx.c                |   14 +++-
>  arch/x86/include/asm/apic.h              |    4 +
>  arch/x86/include/asm/pci.h               |    4 +-
>  arch/x86/include/asm/x86_init.h          |    7 --
>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>  arch/x86/kernel/x86_init.c               |   34 ---------
>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>  drivers/iommu/irq_remapping.c            |    9 ++-
>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>  drivers/pci/host/pci-tegra.c             |    8 ++-
>  drivers/pci/host/pcie-designware.c       |    4 +-
>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>  drivers/pci/probe.c                      |    1 -
>  include/linux/msi.h                      |   26 ++-----
>  27 files changed, 266 insertions(+), 202 deletions(-)
> 

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Is there a git tree for these patches?
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!
> 
> v1->v2:
> Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
> and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.
> 
> RFC->v1: 
> Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
> of #ifdef to fix MSI bug in xen running in x86. 
> Rename arch_get_match_msi_chip() to arch_find_msi_chip().
> Drop use struct device as the msi_chip argument, we will do that
> later in another patchset.
> 
> Yijing Wang (22):
>   PCI/MSI: Clean up struct msi_chip argument
>   PCI/MSI: Remove useless bus->msi assignment
>   MSI: Remove the redundant irq_set_chip_data()
>   x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
>   s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
>   PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
>   PCI/MSI: Refactor struct msi_chip to make it become more common
>   x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   x86/MSI: Remove unused MSI weak arch functions
>   MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
>   MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
>   PCI/MSI: Clean up unused MSI arch functions
> 
>  arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
>  arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
>  arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
>  arch/arm/mach-iop13xx/msi.c              |    9 ++-
>  arch/arm/mach-iop13xx/pci.c              |    6 ++
>  arch/ia64/kernel/msi_ia64.c              |   18 ++++-
>  arch/mips/pci/msi-octeon.c               |   35 ++++++----
>  arch/mips/pci/msi-xlp.c                  |   18 ++++--
>  arch/mips/pci/pci-xlr.c                  |   15 ++++-
>  arch/powerpc/kernel/msi.c                |   14 +++-
>  arch/s390/pci/pci.c                      |   18 ++++-
>  arch/sparc/kernel/pci.c                  |   14 +++-
>  arch/tile/kernel/pci_gx.c                |   14 +++-
>  arch/x86/include/asm/apic.h              |    4 +
>  arch/x86/include/asm/pci.h               |    4 +-
>  arch/x86/include/asm/x86_init.h          |    7 --
>  arch/x86/kernel/apic/io_apic.c           |   16 ++++-
>  arch/x86/kernel/x86_init.c               |   34 ---------
>  arch/x86/pci/xen.c                       |   60 +++++++++-------
>  drivers/iommu/irq_remapping.c            |    9 ++-
>  drivers/irqchip/irq-armada-370-xp.c      |    8 +--
>  drivers/pci/host/pci-tegra.c             |    8 ++-
>  drivers/pci/host/pcie-designware.c       |    4 +-
>  drivers/pci/host/pcie-rcar.c             |    8 ++-
>  drivers/pci/msi.c                        |  114 ++++++++++++++----------------
>  drivers/pci/probe.c                      |    1 -
>  include/linux/msi.h                      |   26 ++-----
>  27 files changed, 266 insertions(+), 202 deletions(-)
> 

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!

Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.

Thierry

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!

Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.

Thierry

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!

Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.

Thierry

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

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!

Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.

Thierry

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

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!

Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.

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/20140925/c9069230/attachment.sig>

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!

Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.

Thierry

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

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Thierry Reding]

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

On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
> 
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
> This series use MSI chip framework to refactor MSI code across all platforms
> to eliminate weak arch functions. Then all MSI irqs will be managed in a 
> unified framework. Because this series changed a lot of ARCH MSI code,
> so tests in the platforms which MSI code modified are warmly welcomed!

Apart from the comments to the individual patches I very much like where
this is going. Thanks for taking care of this.

Thierry

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

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)

[PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms

[Yijing Wang]

This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi

Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm.
This series use MSI chip framework to refactor MSI code across all platforms
to eliminate weak arch functions. Then all MSI irqs will be managed in a 
unified framework. Because this series changed a lot of ARCH MSI code,
so tests in the platforms which MSI code modified are warmly welcomed!

v1->v2:
Add a patch to make s390 MSI code build happy between patch "x86/xen/MSI: E.."
and "s390/MSI: Use MSI..". Fix several typo problems found by Lucas.

RFC->v1: 
Updated "[patch 4/21] x86/xen/MSI: Eliminate...", export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86. 
Rename arch_get_match_msi_chip() to arch_find_msi_chip().
Drop use struct device as the msi_chip argument, we will do that
later in another patchset.

Yijing Wang (22):
  PCI/MSI: Clean up struct msi_chip argument
  PCI/MSI: Remove useless bus->msi assignment
  MSI: Remove the redundant irq_set_chip_data()
  x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
  s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq()
  PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
  PCI/MSI: Refactor struct msi_chip to make it become more common
  x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  x86/MSI: Remove unused MSI weak arch functions
  MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq
  PCI/MSI: Clean up unused MSI arch functions

 arch/arm/mach-iop13xx/include/mach/pci.h |    2 +
 arch/arm/mach-iop13xx/iq81340mc.c        |    1 +
 arch/arm/mach-iop13xx/iq81340sc.c        |    1 +
 arch/arm/mach-iop13xx/msi.c              |    9 ++-
 arch/arm/mach-iop13xx/pci.c              |    6 ++
 arch/ia64/kernel/msi_ia64.c              |   18 ++++-
 arch/mips/pci/msi-octeon.c               |   35 ++++++----
 arch/mips/pci/msi-xlp.c                  |   18 ++++--
 arch/mips/pci/pci-xlr.c                  |   15 ++++-
 arch/powerpc/kernel/msi.c                |   14 +++-
 arch/s390/pci/pci.c                      |   18 ++++-
 arch/sparc/kernel/pci.c                  |   14 +++-
 arch/tile/kernel/pci_gx.c                |   14 +++-
 arch/x86/include/asm/apic.h              |    4 +
 arch/x86/include/asm/pci.h               |    4 +-
 arch/x86/include/asm/x86_init.h          |    7 --
 arch/x86/kernel/apic/io_apic.c           |   16 ++++-
 arch/x86/kernel/x86_init.c               |   34 ---------
 arch/x86/pci/xen.c                       |   60 +++++++++-------
 drivers/iommu/irq_remapping.c            |    9 ++-
 drivers/irqchip/irq-armada-370-xp.c      |    8 +--
 drivers/pci/host/pci-tegra.c             |    8 ++-
 drivers/pci/host/pcie-designware.c       |    4 +-
 drivers/pci/host/pcie-rcar.c             |    8 ++-
 drivers/pci/msi.c                        |  114 ++++++++++++++----------------
 drivers/pci/probe.c                      |    1 -
 include/linux/msi.h                      |   26 ++-----
 27 files changed, 266 insertions(+), 202 deletions(-)