From: Bjorn Helgaas <bhelgaas@google.com>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, arnd@arndb.de,
Liviu.Dudau@arm.com, linux-pci@vger.kernel.org,
mohit.kumar@st.com
Subject: Re: [PATCH 1/3] ARM: bios32: use pci_enable_resource to enable PCI resources
Date: Tue, 11 Feb 2014 18:06:50 -0700 [thread overview]
Message-ID: <20140212010650.GI21057@google.com> (raw)
In-Reply-To: <1391532784-1953-2-git-send-email-will.deacon@arm.com>
On Tue, Feb 04, 2014 at 04:53:02PM +0000, Will Deacon wrote:
> This patch moves bios32 over to using the generic code for enabling PCI
> resources. All that's left to take care of is the case of PCI bridges,
> which need to be enabled for both IO and MEMORY, regardless of the
> resource types.
>
> A side-effect of this change is that we no longer explicitly enable
> devices when running in PCI_PROBE_ONLY mode. This stays closer to the
> meaning of the option and prevents us from trying to enable devices
> without any assigned resources (the core code refuses to enable
> resources without parents).
Heh, I've been looking at this, too :) I have a similar patch for ARM and
other architectures with their own versions of pcibios_enable_device().
Several of them (arm m68k tile tegra unicore32) have this special code that
enables IO and MEMORY for bridges unconditionally. But from a PCI
perspective, I don't know why we should do this unconditionally. If a
bridge doesn't have an enabled MEM window or MEM BAR, I don't think we
should have to enable PCI_COMMAND_MEMORY for it.
The architectures that do this only check for valid MEM BARs, i.e., they
only look at resources 0-5, and they don't look at the window resources.
The architectures that don't enable IO and MEMORY for bridges
unconditionally check *all* the resources up to PCI_NUM_RESOURCES, which
includes the BARs, bridge windows, and any IOV resources.
The generic pci_enable_resources() does check all the resources, so I
*think* it should be safe for all architectures to use that and just drop
the check for bridges. What do you think?
Bjorn
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/kernel/bios32.c | 35 ++++++++++-------------------------
> 1 file changed, 10 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 317da88ae65b..9f3c76638689 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -608,40 +608,25 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> */
> int pcibios_enable_device(struct pci_dev *dev, int mask)
> {
> - u16 cmd, old_cmd;
> - int idx;
> - struct resource *r;
> + int err;
> + u16 cmd;
>
> - pci_read_config_word(dev, PCI_COMMAND, &cmd);
> - old_cmd = cmd;
> - for (idx = 0; idx < 6; idx++) {
> - /* Only set up the requested stuff */
> - if (!(mask & (1 << idx)))
> - continue;
> + if (pci_has_flag(PCI_PROBE_ONLY))
> + return 0;
>
> - r = dev->resource + idx;
> - if (!r->start && r->end) {
> - printk(KERN_ERR "PCI: Device %s not available because"
> - " of resource collisions\n", pci_name(dev));
> - return -EINVAL;
> - }
> - if (r->flags & IORESOURCE_IO)
> - cmd |= PCI_COMMAND_IO;
> - if (r->flags & IORESOURCE_MEM)
> - cmd |= PCI_COMMAND_MEMORY;
> - }
> + err = pci_enable_resources(dev, mask);
> + if (err)
> + return err;
>
> /*
> * Bridges (eg, cardbus bridges) need to be fully enabled
> */
> - if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE)
> + if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE) {
> + pci_read_config_word(dev, PCI_COMMAND, &cmd);
> cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
> -
> - if (cmd != old_cmd) {
> - printk("PCI: enabling device %s (%04x -> %04x)\n",
> - pci_name(dev), old_cmd, cmd);
> pci_write_config_word(dev, PCI_COMMAND, cmd);
> }
> +
> return 0;
> }
>
> --
> 1.8.2.2
>
WARNING: multiple messages have this Message-ID (diff)
From: bhelgaas@google.com (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] ARM: bios32: use pci_enable_resource to enable PCI resources
Date: Tue, 11 Feb 2014 18:06:50 -0700 [thread overview]
Message-ID: <20140212010650.GI21057@google.com> (raw)
In-Reply-To: <1391532784-1953-2-git-send-email-will.deacon@arm.com>
On Tue, Feb 04, 2014 at 04:53:02PM +0000, Will Deacon wrote:
> This patch moves bios32 over to using the generic code for enabling PCI
> resources. All that's left to take care of is the case of PCI bridges,
> which need to be enabled for both IO and MEMORY, regardless of the
> resource types.
>
> A side-effect of this change is that we no longer explicitly enable
> devices when running in PCI_PROBE_ONLY mode. This stays closer to the
> meaning of the option and prevents us from trying to enable devices
> without any assigned resources (the core code refuses to enable
> resources without parents).
Heh, I've been looking at this, too :) I have a similar patch for ARM and
other architectures with their own versions of pcibios_enable_device().
Several of them (arm m68k tile tegra unicore32) have this special code that
enables IO and MEMORY for bridges unconditionally. But from a PCI
perspective, I don't know why we should do this unconditionally. If a
bridge doesn't have an enabled MEM window or MEM BAR, I don't think we
should have to enable PCI_COMMAND_MEMORY for it.
The architectures that do this only check for valid MEM BARs, i.e., they
only look at resources 0-5, and they don't look at the window resources.
The architectures that don't enable IO and MEMORY for bridges
unconditionally check *all* the resources up to PCI_NUM_RESOURCES, which
includes the BARs, bridge windows, and any IOV resources.
The generic pci_enable_resources() does check all the resources, so I
*think* it should be safe for all architectures to use that and just drop
the check for bridges. What do you think?
Bjorn
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/kernel/bios32.c | 35 ++++++++++-------------------------
> 1 file changed, 10 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 317da88ae65b..9f3c76638689 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -608,40 +608,25 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> */
> int pcibios_enable_device(struct pci_dev *dev, int mask)
> {
> - u16 cmd, old_cmd;
> - int idx;
> - struct resource *r;
> + int err;
> + u16 cmd;
>
> - pci_read_config_word(dev, PCI_COMMAND, &cmd);
> - old_cmd = cmd;
> - for (idx = 0; idx < 6; idx++) {
> - /* Only set up the requested stuff */
> - if (!(mask & (1 << idx)))
> - continue;
> + if (pci_has_flag(PCI_PROBE_ONLY))
> + return 0;
>
> - r = dev->resource + idx;
> - if (!r->start && r->end) {
> - printk(KERN_ERR "PCI: Device %s not available because"
> - " of resource collisions\n", pci_name(dev));
> - return -EINVAL;
> - }
> - if (r->flags & IORESOURCE_IO)
> - cmd |= PCI_COMMAND_IO;
> - if (r->flags & IORESOURCE_MEM)
> - cmd |= PCI_COMMAND_MEMORY;
> - }
> + err = pci_enable_resources(dev, mask);
> + if (err)
> + return err;
>
> /*
> * Bridges (eg, cardbus bridges) need to be fully enabled
> */
> - if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE)
> + if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE) {
> + pci_read_config_word(dev, PCI_COMMAND, &cmd);
> cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
> -
> - if (cmd != old_cmd) {
> - printk("PCI: enabling device %s (%04x -> %04x)\n",
> - pci_name(dev), old_cmd, cmd);
> pci_write_config_word(dev, PCI_COMMAND, cmd);
> }
> +
> return 0;
> }
>
> --
> 1.8.2.2
>
next prev parent reply other threads:[~2014-02-12 1:06 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 16:53 [PATCH 0/3] ARM: PCI: implement virtual PCI host controller Will Deacon
2014-02-04 16:53 ` Will Deacon
2014-02-04 16:53 ` [PATCH 1/3] ARM: bios32: use pci_enable_resource to enable PCI resources Will Deacon
2014-02-04 16:53 ` Will Deacon
2014-02-12 1:06 ` Bjorn Helgaas [this message]
2014-02-12 1:06 ` Bjorn Helgaas
2014-02-12 16:18 ` Will Deacon
2014-02-12 16:18 ` Will Deacon
2014-02-04 16:53 ` [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller Will Deacon
2014-02-04 16:53 ` Will Deacon
2014-02-04 19:13 ` Arnd Bergmann
2014-02-04 19:13 ` Arnd Bergmann
2014-02-05 19:09 ` Will Deacon
2014-02-05 19:09 ` Will Deacon
2014-02-05 19:27 ` Jason Gunthorpe
2014-02-05 19:27 ` Jason Gunthorpe
2014-02-05 19:41 ` Peter Maydell
2014-02-05 19:41 ` Peter Maydell
2014-02-05 20:26 ` Arnd Bergmann
2014-02-05 20:26 ` Arnd Bergmann
2014-02-05 20:53 ` Jason Gunthorpe
2014-02-05 20:53 ` Jason Gunthorpe
2014-02-06 8:28 ` Arnd Bergmann
2014-02-06 8:28 ` Arnd Bergmann
2014-02-06 20:31 ` Russell King - ARM Linux
2014-02-06 20:31 ` Russell King - ARM Linux
2014-02-09 20:18 ` Arnd Bergmann
2014-02-09 20:18 ` Arnd Bergmann
2014-02-09 20:34 ` Russell King - ARM Linux
2014-02-09 20:34 ` Russell King - ARM Linux
2014-02-11 19:15 ` Arnd Bergmann
2014-02-11 19:15 ` Arnd Bergmann
2014-02-07 11:46 ` Will Deacon
2014-02-07 11:46 ` Will Deacon
2014-02-07 17:54 ` Jason Gunthorpe
2014-02-07 17:54 ` Jason Gunthorpe
2014-02-12 18:10 ` Will Deacon
2014-02-12 18:10 ` Will Deacon
2014-02-12 18:19 ` Jason Gunthorpe
2014-02-12 18:19 ` Jason Gunthorpe
2014-02-12 18:21 ` Will Deacon
2014-02-12 18:21 ` Will Deacon
2014-02-09 20:30 ` Arnd Bergmann
2014-02-09 20:30 ` Arnd Bergmann
2014-02-10 17:34 ` Jason Gunthorpe
2014-02-10 17:34 ` Jason Gunthorpe
2014-02-11 10:42 ` Arnd Bergmann
2014-02-11 10:42 ` Arnd Bergmann
2014-02-12 19:43 ` Jason Gunthorpe
2014-02-12 19:43 ` Jason Gunthorpe
2014-02-12 20:07 ` Arnd Bergmann
2014-02-12 20:07 ` Arnd Bergmann
2014-02-12 20:33 ` Bjorn Helgaas
2014-02-12 20:33 ` Bjorn Helgaas
2014-02-12 21:15 ` Thomas Petazzoni
2014-02-12 21:15 ` Thomas Petazzoni
2014-02-12 22:24 ` Jason Gunthorpe
2014-02-12 22:24 ` Jason Gunthorpe
2014-02-12 19:49 ` Will Deacon
2014-02-12 19:49 ` Will Deacon
2014-02-06 8:54 ` Anup Patel
2014-02-06 8:54 ` Anup Patel
2014-02-06 10:26 ` Arnd Bergmann
2014-02-06 10:26 ` Arnd Bergmann
2014-02-06 10:52 ` Anup Patel
2014-02-06 10:52 ` Anup Patel
2014-02-06 10:54 ` Liviu Dudau
2014-02-06 10:54 ` Liviu Dudau
2014-02-06 11:00 ` Will Deacon
2014-02-06 11:00 ` Will Deacon
2014-02-06 11:28 ` Arnd Bergmann
2014-02-06 11:28 ` Arnd Bergmann
2014-02-04 16:53 ` [PATCH 3/3] ARM: mach-virt: allow PCI support to be selected Will Deacon
2014-02-04 16:53 ` Will Deacon
2014-04-03 22:07 ` [PATCH 0/3] ARM: PCI: implement virtual PCI host controller Bjorn Helgaas
2014-04-03 22:07 ` Bjorn Helgaas
2014-04-14 17:13 ` Will Deacon
2014-04-14 17:13 ` Will Deacon
2014-04-14 18:48 ` Arnd Bergmann
2014-04-14 18:48 ` Arnd Bergmann
2014-04-15 14:47 ` Will Deacon
2014-04-15 14:47 ` Will Deacon
2014-04-15 15:26 ` Arnd Bergmann
2014-04-15 15:26 ` Arnd Bergmann
2014-04-16 13:58 ` Will Deacon
2014-04-16 13:58 ` Will Deacon
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=20140212010650.GI21057@google.com \
--to=bhelgaas@google.com \
--cc=Liviu.Dudau@arm.com \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=mohit.kumar@st.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.