All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Jayachandran C <jchandra@broadcom.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Arnd Bergmann <arnd@arndb.de>, Liviu Dudau <Liviu.Dudau@arm.com>,
	Ming Lei <ming.lei@canonical.com>
Subject: Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
Date: Tue, 12 May 2015 17:34:12 +0100	[thread overview]
Message-ID: <20150512163412.GD16079@red-moon> (raw)
In-Reply-To: <20150512133431.GA2898@google.com>

On Tue, May 12, 2015 at 02:34:31PM +0100, Bjorn Helgaas wrote:

[...]

> > +void pci_claim_one_bus(struct pci_bus *b)
> > +{
> > +	struct pci_dev *pdev;
> > +	struct pci_bus *child_bus;
> > +
> > +	list_for_each_entry(pdev, &b->devices, bus_list) {
> > +		int i;
> > +
> > +		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> > +			struct resource *r = &pdev->resource[i];
> > +
> > +			if (r->parent || !r->start || !r->flags)
> > +				continue;
> > +
> > +			if (pci_has_flag(PCI_PROBE_ONLY) ||
> > +			    (r->flags & IORESOURCE_PCI_FIXED)) {
> > +				if (pci_claim_resource(pdev, i) == 0)
> > +					continue;
> > +
> > +				pci_claim_bridge_resource(pdev, i);
> > +			}
> > +		}
> > +	}
> > +
> > +	list_for_each_entry(child_bus, &b->children, node) {
> > +		pci_claim_one_bus(child_bus);
> > +	}
> > +}
> > +EXPORT_SYMBOL(pci_claim_one_bus);
> 
> I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
> claiming resources is a per-device thing, and I don't want to encourage
> people to do it on a per-bus level.
> 
> I'd rather claim them somewhere in the pci_device_add() path, as s390 does
> in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
> we read each BAR, so we could identify invalid or unassigned BARs
> immediately.

You mean claiming the resources in __pci_read_base (and unset the resource
if claiming it fails ?) regardless of PCI_PROBE_ONLY ?

I will give it a go, I fear it might trigger regressions on other archs
though.

We could claim the resources in pcibios_add_device on arm64, but this
means arm code should be patched too since I am not happy at all to let
arm and arm64 diverge even more.

Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
Date: Tue, 12 May 2015 17:34:12 +0100	[thread overview]
Message-ID: <20150512163412.GD16079@red-moon> (raw)
In-Reply-To: <20150512133431.GA2898@google.com>

On Tue, May 12, 2015 at 02:34:31PM +0100, Bjorn Helgaas wrote:

[...]

> > +void pci_claim_one_bus(struct pci_bus *b)
> > +{
> > +	struct pci_dev *pdev;
> > +	struct pci_bus *child_bus;
> > +
> > +	list_for_each_entry(pdev, &b->devices, bus_list) {
> > +		int i;
> > +
> > +		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> > +			struct resource *r = &pdev->resource[i];
> > +
> > +			if (r->parent || !r->start || !r->flags)
> > +				continue;
> > +
> > +			if (pci_has_flag(PCI_PROBE_ONLY) ||
> > +			    (r->flags & IORESOURCE_PCI_FIXED)) {
> > +				if (pci_claim_resource(pdev, i) == 0)
> > +					continue;
> > +
> > +				pci_claim_bridge_resource(pdev, i);
> > +			}
> > +		}
> > +	}
> > +
> > +	list_for_each_entry(child_bus, &b->children, node) {
> > +		pci_claim_one_bus(child_bus);
> > +	}
> > +}
> > +EXPORT_SYMBOL(pci_claim_one_bus);
> 
> I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
> claiming resources is a per-device thing, and I don't want to encourage
> people to do it on a per-bus level.
> 
> I'd rather claim them somewhere in the pci_device_add() path, as s390 does
> in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
> we read each BAR, so we could identify invalid or unassigned BARs
> immediately.

You mean claiming the resources in __pci_read_base (and unset the resource
if claiming it fails ?) regardless of PCI_PROBE_ONLY ?

I will give it a go, I fear it might trigger regressions on other archs
though.

We could claim the resources in pcibios_add_device on arm64, but this
means arm code should be patched too since I am not happy at all to let
arm and arm64 diverge even more.

Lorenzo

  reply	other threads:[~2015-05-12 16:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-05  2:02 [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci Jayachandran C
2015-05-05  2:02 ` Jayachandran C
2015-05-05  2:02 ` [PATCH v2 2/2] PCI: generic: add arm64 support Jayachandran C
2015-05-05  2:02   ` Jayachandran C
2015-05-05 15:53 ` [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci Will Deacon
2015-05-05 15:53   ` Will Deacon
2015-05-05 15:58   ` Arnd Bergmann
2015-05-05 15:58     ` Arnd Bergmann
2015-05-05 16:03   ` Lorenzo Pieralisi
2015-05-05 16:03     ` Lorenzo Pieralisi
2015-05-06 14:18   ` Lorenzo Pieralisi
2015-05-06 14:18     ` Lorenzo Pieralisi
2015-05-06 15:18     ` Bjorn Helgaas
2015-05-06 15:18       ` Bjorn Helgaas
2015-05-07  3:32       ` Suravee Suthikulanit
2015-05-07  3:32         ` Suravee Suthikulanit
2015-05-12 13:34         ` Bjorn Helgaas
2015-05-12 13:34           ` Bjorn Helgaas
2015-05-12 16:34           ` Lorenzo Pieralisi [this message]
2015-05-12 16:34             ` Lorenzo Pieralisi
2015-05-12 19:20             ` Bjorn Helgaas
2015-05-12 19:20               ` Bjorn Helgaas
2015-05-13 12:47         ` Suravee Suthikulanit
2015-05-13 12:47           ` Suravee Suthikulanit
2015-05-13 13:54           ` Bjorn Helgaas
2015-05-13 13:54             ` Bjorn Helgaas
2015-05-13 15:05             ` Suravee Suthikulanit
2015-05-13 15:05               ` Suravee Suthikulanit
2015-05-13 15:11               ` Bjorn Helgaas
2015-05-13 15:11                 ` Bjorn Helgaas
2015-05-12  0:07   ` Jayachandran C.
2015-05-19 23:09     ` Bjorn Helgaas
2015-05-19 23:09       ` Bjorn Helgaas
2015-05-20 17:29       ` Will Deacon
2015-05-20 17:29         ` Will Deacon
2015-05-20 20:46         ` Bjorn Helgaas
2015-05-20 20:46           ` Bjorn Helgaas
2015-05-21  6:37         ` Jayachandran C.
2015-05-26  9:59           ` Will Deacon
2015-05-26  9:59             ` Will Deacon
2015-05-26 10:38             ` Arnd Bergmann
2015-05-26 10:38               ` Arnd Bergmann

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=20150512163412.GD16079@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=jchandra@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=suravee.suthikulpanit@amd.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.