All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v2] PCI: mvebu - Support a bridge with no IO port window
Date: Fri, 1 Nov 2013 10:56:09 -0600	[thread overview]
Message-ID: <20131101165609.GA25978@obsidianresearch.com> (raw)
In-Reply-To: <CAErSpo5Y5TH+iapqzhQAcLY6V0rvK=7QAEStcbzLv4mAuLKPDg@mail.gmail.com>

> I don't know why 0xf0f0.  Anything that's non-zero in the upper four
> bits of each byte should work to determine writability.  It seems like
> it would be safer to write 0x00f0 so the window is disabled, because
> even if we're enumerating the bridge at hot-plug time, nobody else
> should be trying to access a device behind the bridge, and we wouldn't
> inadvertently claim something destined for [io 0xf000-0xffff].

What do you think of this?

>From f1f0d6a5b192a46585c5fefdc7ec06808639be4d Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date: Fri, 1 Nov 2013 10:54:13 -0600
Subject: [PATCH] PCI: Use a safer method to determine if a bridge has IO
 support

We want to avoid disturbing an active an enabled bus during IO detection,
so first check if IO is enabled - if so then we know for sure that
the bridge has IO.

Otherwise we can safely fiddle with the IO window register to detect IO,
as IO is disabled.

This also changes the probe value to 0x00f0, which is intended to be
clearer to the reader that this is just a probe.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
 drivers/pci/setup-bus.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index bc26d79..d63087f 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -665,10 +665,16 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
 
 	pci_read_config_word(bridge, PCI_IO_BASE, &io);
 	if (!io) {
-		pci_write_config_word(bridge, PCI_IO_BASE, 0xf0f0);
-		pci_read_config_word(bridge, PCI_IO_BASE, &io);
- 		pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
- 	}
+		u16 command;
+		pci_read_config_word(bridge, PCI_COMMAND, &command);
+		if (command & PCI_COMMAND_IO)
+			b_res[0].flags |= IORESOURCE_IO;
+		else {
+			pci_write_config_word(bridge, PCI_IO_BASE, 0x00f0);
+			pci_read_config_word(bridge, PCI_IO_BASE, &io);
+			pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
+		}
+	}
  	if (io)
 		b_res[0].flags |= IORESOURCE_IO;
 	/*  DECchip 21050 pass 2 errata: the bridge may miss an address
-- 
1.8.1.2


WARNING: multiple messages have this Message-ID (diff)
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] PCI: mvebu - Support a bridge with no IO port window
Date: Fri, 1 Nov 2013 10:56:09 -0600	[thread overview]
Message-ID: <20131101165609.GA25978@obsidianresearch.com> (raw)
In-Reply-To: <CAErSpo5Y5TH+iapqzhQAcLY6V0rvK=7QAEStcbzLv4mAuLKPDg@mail.gmail.com>

> I don't know why 0xf0f0.  Anything that's non-zero in the upper four
> bits of each byte should work to determine writability.  It seems like
> it would be safer to write 0x00f0 so the window is disabled, because
> even if we're enumerating the bridge at hot-plug time, nobody else
> should be trying to access a device behind the bridge, and we wouldn't
> inadvertently claim something destined for [io 0xf000-0xffff].

What do you think of this?

>From f1f0d6a5b192a46585c5fefdc7ec06808639be4d Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date: Fri, 1 Nov 2013 10:54:13 -0600
Subject: [PATCH] PCI: Use a safer method to determine if a bridge has IO
 support

We want to avoid disturbing an active an enabled bus during IO detection,
so first check if IO is enabled - if so then we know for sure that
the bridge has IO.

Otherwise we can safely fiddle with the IO window register to detect IO,
as IO is disabled.

This also changes the probe value to 0x00f0, which is intended to be
clearer to the reader that this is just a probe.

Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
 drivers/pci/setup-bus.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index bc26d79..d63087f 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -665,10 +665,16 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
 
 	pci_read_config_word(bridge, PCI_IO_BASE, &io);
 	if (!io) {
-		pci_write_config_word(bridge, PCI_IO_BASE, 0xf0f0);
-		pci_read_config_word(bridge, PCI_IO_BASE, &io);
- 		pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
- 	}
+		u16 command;
+		pci_read_config_word(bridge, PCI_COMMAND, &command);
+		if (command & PCI_COMMAND_IO)
+			b_res[0].flags |= IORESOURCE_IO;
+		else {
+			pci_write_config_word(bridge, PCI_IO_BASE, 0x00f0);
+			pci_read_config_word(bridge, PCI_IO_BASE, &io);
+			pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
+		}
+	}
  	if (io)
 		b_res[0].flags |= IORESOURCE_IO;
 	/*  DECchip 21050 pass 2 errata: the bridge may miss an address
-- 
1.8.1.2

  reply	other threads:[~2013-11-01 17:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 20:16 [PATCH v2] PCI: mvebu - Support a bridge with no IO port window Jason Gunthorpe
2013-10-15 20:16 ` Jason Gunthorpe
2013-10-17 13:10 ` Jason Cooper
2013-10-17 13:10   ` Jason Cooper
2013-10-17 14:41   ` Jason Gunthorpe
2013-10-17 14:41     ` Jason Gunthorpe
2013-10-17 14:47     ` Jason Cooper
2013-10-17 14:47       ` Jason Cooper
2013-10-31  9:13 ` Thomas Petazzoni
2013-10-31  9:13   ` Thomas Petazzoni
2013-10-31 16:48   ` Jason Gunthorpe
2013-10-31 16:48     ` Jason Gunthorpe
2013-10-31 17:10     ` Bjorn Helgaas
2013-10-31 17:10       ` Bjorn Helgaas
2013-10-31 23:32       ` Jason Gunthorpe
2013-10-31 23:32         ` Jason Gunthorpe
2013-11-01  2:44         ` Bjorn Helgaas
2013-11-01  2:44           ` Bjorn Helgaas
2013-11-01  5:28           ` Jason Gunthorpe
2013-11-01  5:28             ` Jason Gunthorpe
2013-11-01 13:50             ` Bjorn Helgaas
2013-11-01 13:50               ` Bjorn Helgaas
2013-11-01 16:56               ` Jason Gunthorpe [this message]
2013-11-01 16:56                 ` Jason Gunthorpe

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=20131101165609.GA25978@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=bhelgaas@google.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=thomas.petazzoni@free-electrons.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.