All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Pratyush Anand <pratyush.anand@gmail.com>,
	Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Will Deacon <will.deacon@arm.com>,
	Michal Simek <michal.simek@xilinx.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Tanmay Inamdar <tinamdar@apm.com>,
	Matthew Minter <matt@masarand.com>, Rob Herring <robh@kernel.org>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	Wenrui Li <wenrui.li@rock-chips.com>,
	Russell King <linux@armlinux.org.uk>,
	Murali Karicheri <m-karicheri2@ti.com>,
	Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>,
	Simon Horman <horms@verge.net.au>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mingkai Hu <mingkai.hu@freescale.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Stanimir Varbanov <svarbanov@mm-sol.com>,
	Minghuan Lian <minghuan.Lian@freescale.com>,
	Zhou Wang <wangzhou1@hisilicon.com>,
	Roy Zang <tie-fei.zang@freescale.com>
Subject: Re: [RFC/RFT PATCH 03/18] PCI: Introduce pci_scan_root_bus_bridge()
Date: Tue, 2 May 2017 18:15:01 +0100	[thread overview]
Message-ID: <20170502171501.GA5545@red-moon> (raw)
In-Reply-To: <CAK8P3a0HmrrYBP5em1s4VOY4Tb6=bwOrDDN6K8rPp8OEXtpMtA@mail.gmail.com>

On Fri, Apr 28, 2017 at 02:28:38PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 26, 2017 at 1:17 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Current pci_scan_root_bus() interface is made up of two main
> > code paths:
> >
> > - pci_create_root_bus()
> > - pci_scan_child_bus()
> >
> > pci_create_root_bus() is a wrapper function that allows to create
> > a struct pci_host_bridge structure, initialize it with the passed
> > parameters and register it with the kernel.
> >
> > As the struct pci_host_bridge require additional struct members,
> > pci_create_root_bus() parameters list has grown in time, making
> > it unwieldy to add further parameters to it in case the struct
> > pci_host_bridge gains more members fields to augment its functionality.
> >
> > Since PCI core code provides functions to allocate struct
> > pci_host_bridge, instead of forcing the pci_create_root_bus() interface
> > to add new parameters to cater for new struct pci_host_bridge
> > functionality, it is more suitable to add an interface in PCI
> > core code to scan a PCI bus straight from a struct pci_host_bridge
> > created and customized by each specific PCI host controller driver.
> >
> > Add a pci_scan_root_bus_bridge() function to allow PCI host controller
> > drivers to create and initialize struct pci_host_bridge and scan
> > the resulting bus.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> 
> Good idea, yes. To avoid growing the number of interfaces too
> much, should we change the existing users of pci_register_host_bridge
> in host drivers over to this entry point, and make the other one
> local to probe.c then?

Yes, the problem is that there are drivers (ie pcie-iproc.c) that
require the struct pci_bus (created by pci_register_host_bridge())
to fiddle with it to check link status and THEN scan the bus (so
the pci_register_host_bridge() call can't be embedded in the scan
interface - the driver requires struct pci_bus for pci_ops to work
before scanning the bus itself).

I will see how I can accommodate this change because you definitely
have a point.

> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 7e4ffc4..c7a7f72 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -2412,6 +2412,44 @@ void pci_bus_release_busn_res(struct pci_bus *b)
> >                         res, ret ? "can not be" : "is");
> >  }
> >
> > +int pci_scan_root_bus_bridge(struct pci_host_bridge *bridge)
> > +{
> > +       struct resource_entry *window;
> > +       bool found = false;
> > +       struct pci_bus *b;
> > +       int max, bus, ret;
> > +
> > +       if (!bridge)
> > +               return -EINVAL;
> > +
> > +       resource_list_for_each_entry(window, &bridge->windows)
> > +               if (window->res->flags & IORESOURCE_BUS) {
> > +                       found = true;
> > +                       break;
> > +               }
> > +
> > +       ret = pci_register_host_bridge(bridge);
> > +       if (ret < 0)
> > +               return ret;
> > +
> > +       b = bridge->bus;
> > +       bus = bridge->busnr;
> > +
> > +       if (!found) {
> > +               dev_info(&b->dev,
> > +                "No busn resource found for root bus, will use [bus %02x-ff]\n",
> > +                       bus);
> > +               pci_bus_insert_busn_res(b, bus, 255);
> > +       }
> > +
> > +       max = pci_scan_child_bus(b);
> > +
> > +       if (!found)
> > +               pci_bus_update_busn_res_end(b, max);
> > +
> > +       return 0;
> > +}
> > +
> 
> We probably want an EXPORT_SYMBOL() here as well.

Yep, sure.

Thanks for having a look !

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/RFT PATCH 03/18] PCI: Introduce pci_scan_root_bus_bridge()
Date: Tue, 2 May 2017 18:15:01 +0100	[thread overview]
Message-ID: <20170502171501.GA5545@red-moon> (raw)
In-Reply-To: <CAK8P3a0HmrrYBP5em1s4VOY4Tb6=bwOrDDN6K8rPp8OEXtpMtA@mail.gmail.com>

On Fri, Apr 28, 2017 at 02:28:38PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 26, 2017 at 1:17 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Current pci_scan_root_bus() interface is made up of two main
> > code paths:
> >
> > - pci_create_root_bus()
> > - pci_scan_child_bus()
> >
> > pci_create_root_bus() is a wrapper function that allows to create
> > a struct pci_host_bridge structure, initialize it with the passed
> > parameters and register it with the kernel.
> >
> > As the struct pci_host_bridge require additional struct members,
> > pci_create_root_bus() parameters list has grown in time, making
> > it unwieldy to add further parameters to it in case the struct
> > pci_host_bridge gains more members fields to augment its functionality.
> >
> > Since PCI core code provides functions to allocate struct
> > pci_host_bridge, instead of forcing the pci_create_root_bus() interface
> > to add new parameters to cater for new struct pci_host_bridge
> > functionality, it is more suitable to add an interface in PCI
> > core code to scan a PCI bus straight from a struct pci_host_bridge
> > created and customized by each specific PCI host controller driver.
> >
> > Add a pci_scan_root_bus_bridge() function to allow PCI host controller
> > drivers to create and initialize struct pci_host_bridge and scan
> > the resulting bus.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> 
> Good idea, yes. To avoid growing the number of interfaces too
> much, should we change the existing users of pci_register_host_bridge
> in host drivers over to this entry point, and make the other one
> local to probe.c then?

Yes, the problem is that there are drivers (ie pcie-iproc.c) that
require the struct pci_bus (created by pci_register_host_bridge())
to fiddle with it to check link status and THEN scan the bus (so
the pci_register_host_bridge() call can't be embedded in the scan
interface - the driver requires struct pci_bus for pci_ops to work
before scanning the bus itself).

I will see how I can accommodate this change because you definitely
have a point.

> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 7e4ffc4..c7a7f72 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -2412,6 +2412,44 @@ void pci_bus_release_busn_res(struct pci_bus *b)
> >                         res, ret ? "can not be" : "is");
> >  }
> >
> > +int pci_scan_root_bus_bridge(struct pci_host_bridge *bridge)
> > +{
> > +       struct resource_entry *window;
> > +       bool found = false;
> > +       struct pci_bus *b;
> > +       int max, bus, ret;
> > +
> > +       if (!bridge)
> > +               return -EINVAL;
> > +
> > +       resource_list_for_each_entry(window, &bridge->windows)
> > +               if (window->res->flags & IORESOURCE_BUS) {
> > +                       found = true;
> > +                       break;
> > +               }
> > +
> > +       ret = pci_register_host_bridge(bridge);
> > +       if (ret < 0)
> > +               return ret;
> > +
> > +       b = bridge->bus;
> > +       bus = bridge->busnr;
> > +
> > +       if (!found) {
> > +               dev_info(&b->dev,
> > +                "No busn resource found for root bus, will use [bus %02x-ff]\n",
> > +                       bus);
> > +               pci_bus_insert_busn_res(b, bus, 255);
> > +       }
> > +
> > +       max = pci_scan_child_bus(b);
> > +
> > +       if (!found)
> > +               pci_bus_update_busn_res_end(b, max);
> > +
> > +       return 0;
> > +}
> > +
> 
> We probably want an EXPORT_SYMBOL() here as well.

Yep, sure.

Thanks for having a look !

Lorenzo

  reply	other threads:[~2017-05-02 17:15 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26 11:17 [RFC/RFT PATCH 00/18] PCI: ARM/ARM64: remove pci_fixup_irqs() usage Lorenzo Pieralisi
2017-04-26 11:17 ` Lorenzo Pieralisi
2017-04-26 11:17 ` [RFC/RFT PATCH 01/18] PCI: Initialize bridge release function at bridge allocation Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-28 12:13   ` Arnd Bergmann
2017-04-28 12:13     ` Arnd Bergmann
2017-04-26 11:17 ` [RFC/RFT PATCH 02/18] PCI: Add pci_free_host_bridge interface Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-28 12:14   ` Arnd Bergmann
2017-04-28 12:14     ` Arnd Bergmann
2017-04-26 11:17 ` [RFC/RFT PATCH 03/18] PCI: Introduce pci_scan_root_bus_bridge() Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-28 12:28   ` Arnd Bergmann
2017-04-28 12:28     ` Arnd Bergmann
2017-05-02 17:15     ` Lorenzo Pieralisi [this message]
2017-05-02 17:15       ` Lorenzo Pieralisi
2017-05-02 19:36       ` Arnd Bergmann
2017-05-02 19:36         ` Arnd Bergmann
2017-05-25 20:56       ` Bjorn Helgaas
2017-05-25 20:56         ` Bjorn Helgaas
2017-05-26 13:07         ` Lorenzo Pieralisi
2017-05-26 13:07           ` Lorenzo Pieralisi
2017-05-26 17:29           ` Ray Jui
2017-05-26 17:29             ` Ray Jui
2017-05-31 10:20             ` Lorenzo Pieralisi
2017-05-31 10:20               ` Lorenzo Pieralisi
2017-05-30 11:16           ` Oza Oza
2017-05-30 11:16             ` Oza Oza
2017-05-31 11:13         ` Lorenzo Pieralisi
2017-05-31 11:13           ` Lorenzo Pieralisi
2017-04-26 11:17 ` [RFC/RFT PATCH 04/18] ARM: PCI: bios32: Convert PCI scan API to pci_scan_root_bus_bridge() Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-28 12:41   ` Arnd Bergmann
2017-04-28 12:41     ` Arnd Bergmann
2017-04-26 11:17 ` [RFC/RFT PATCH 05/18] ARM: PCI: dove: " Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-28 12:38   ` Arnd Bergmann
2017-04-28 12:38     ` Arnd Bergmann
2017-04-28 12:52     ` Arnd Bergmann
2017-04-28 12:52       ` Arnd Bergmann
2017-05-03 10:31     ` Lorenzo Pieralisi
2017-05-03 10:31       ` Lorenzo Pieralisi
2017-05-03 12:02       ` Arnd Bergmann
2017-05-03 12:02         ` Arnd Bergmann
2017-04-26 11:17 ` [RFC/RFT PATCH 06/18] ARM: PCI: iop13xx: " Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-26 11:17 ` [RFC/RFT PATCH 07/18] ARM: PCI: orion5x: " Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-26 15:12   ` Andrew Lunn
2017-04-26 15:12     ` Andrew Lunn
2017-04-26 16:13     ` Lorenzo Pieralisi
2017-04-26 16:13       ` Lorenzo Pieralisi
2017-04-26 18:53       ` Andrew Lunn
2017-04-26 18:53         ` Andrew Lunn
2017-04-27 10:40         ` Lorenzo Pieralisi
2017-04-27 10:40           ` Lorenzo Pieralisi
2017-04-26 11:17 ` [RFC/RFT PATCH 08/18] PCI: designware: " Lorenzo Pieralisi
2017-04-26 11:17   ` Lorenzo Pieralisi
2017-04-28 13:13   ` Arnd Bergmann
2017-04-28 13:13     ` Arnd Bergmann
2017-05-03 10:16     ` Lorenzo Pieralisi
2017-05-03 10:16       ` Lorenzo Pieralisi
2017-06-02 11:49     ` Lorenzo Pieralisi
2017-06-02 11:49       ` Lorenzo Pieralisi
2017-06-02 13:12       ` Arnd Bergmann
2017-06-02 13:12         ` Arnd Bergmann
2017-06-02 13:56         ` Lorenzo Pieralisi
2017-06-02 13:56           ` Lorenzo Pieralisi
2017-06-02 14:44           ` Arnd Bergmann
2017-06-02 14:44             ` Arnd Bergmann
2017-04-26 11:18 ` [RFC/RFT PATCH 09/18] PCI: aardvark: " Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 10/18] PCI: rcar: " Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-28 12:53   ` Arnd Bergmann
2017-04-28 12:53     ` Arnd Bergmann
2017-04-26 11:18 ` [RFC/RFT PATCH 11/18] PCI: Remove pci_scan_root_bus_msi() Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 12/18] PCI: Build setup-irq.o on all arches Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 13/18] PCI: Add IRQ mapping function pointers to pci_host_bridge struct Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 14/18] PCI: Add pci_assign_irq() function and have pci_fixup_irqs() use it Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 15/18] OF/PCI: Update of_irq_parse_and_map_pci() comment Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 16/18] PCI: Add a call to pci_assign_irq() in pci_device_probe() Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 17/18] ARM: PCI: Remove pci_fixup_irqs() call for bios32 host controllers Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-26 11:18 ` [RFC/RFT PATCH 18/18] ARM/ARM64: PCI: Drop pci_fixup_irqs() usage for DT based " Lorenzo Pieralisi
2017-04-26 11:18   ` Lorenzo Pieralisi
2017-04-28 13:05   ` Arnd Bergmann
2017-04-28 13:05     ` Arnd Bergmann
2017-05-03 10:51     ` Lorenzo Pieralisi
2017-05-03 10:51       ` Lorenzo Pieralisi
2017-04-27 20:06 ` [RFC/RFT PATCH 00/18] PCI: ARM/ARM64: remove pci_fixup_irqs() usage Thierry Reding
2017-04-27 20:06   ` Thierry Reding
2017-05-03 10:34   ` Lorenzo Pieralisi
2017-05-03 10:34     ` Lorenzo Pieralisi

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20170502171501.GA5545@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=bharat.kumar.gogada@xilinx.com \
    --cc=bhelgaas@google.com \
    --cc=gabriele.paoloni@huawei.com \
    --cc=horms@verge.net.au \
    --cc=jingoohan1@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m-karicheri2@ti.com \
    --cc=matt@masarand.com \
    --cc=michal.simek@xilinx.com \
    --cc=minghuan.Lian@freescale.com \
    --cc=mingkai.hu@freescale.com \
    --cc=pratyush.anand@gmail.com \
    --cc=robh@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=svarbanov@mm-sol.com \
    --cc=thierry.reding@gmail.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tie-fei.zang@freescale.com \
    --cc=tinamdar@apm.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=wenrui.li@rock-chips.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

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

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