All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Gemini: Add support for PCI BUS
Date: Sun, 28 Nov 2010 20:56:17 +0100	[thread overview]
Message-ID: <201011282056.17389.arnd@arndb.de> (raw)
In-Reply-To: <1290860675-15453-1-git-send-email-ulli.kroll@googlemail.com>

On Saturday 27 November 2010 13:24:35 Hans Ulli Kroll wrote:
> +#define PCI_IOSIZE_REG         (IO_ADDRESS(GEMINI_PCI_IO_BASE))
> +#define PCI_PROT_REG           (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x04)
> +#define PCI_CTRL_REG           (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x08)
> +#define PCI_SOFTRST_REG                (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x10)
> +#define PCI_CONFIG_REG         (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x28)
> +#define PCI_DATA_REG           (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x2C)

If you use the virtual address of the mapping instead of
GEMINI_PCI_IO_BASE, you don't need to repeat the IO_ADDRESS()
macro everywhere. I have a patch that gets rid of all the
conflicting definitions of this macro because it breaks
a multi-platform build once we get there. 

> +static DEFINE_SPINLOCK(gemini_pci_lock);
> +
> +static struct resource gemini_pci_resource_io = {
> +       .name   = "PCI I/O Space",
> +       .start  = IO_ADDRESS(GEMINI_PCI_IO_BASE),
> +       .end    = IO_ADDRESS(GEMINI_PCI_IO_BASE) + SZ_1M - 1,
> +       .flags  = IORESOURCE_IO,
> +};
> +

This looks wrong in multiple ways:

* resources are physical addresses, not virtual addresses
* GEMINI_PCI_IO_BASE is an address in memory space, so it
  needs to be IORESOURCE_MEM, not IORESOURCE_IO. You can
  also register the IORESOURCE_IO resource, but that would
  be .start=PCIBIOS_MIN_IO, .end=IO_SPACE_LIMIT.
* IO_SPACE_LIMIT is larger than the I/O window, which can
  cause overflows. Setting it to 0xffff is generally enough.

> +       spin_lock_irqsave(&gemini_pci_lock, irq_flags);
> +
> +       __raw_writel(PCI_CONF_BUS(bus->number) |
> +                       PCI_CONF_DEVICE(PCI_SLOT(fn)) |
> +                       PCI_CONF_FUNCTION(PCI_FUNC(fn)) |
> +                       PCI_CONF_WHERE(config) |
> +                       PCI_CONF_ENABLE,
> +                       PCI_CONFIG_REG);
> +
> +       switch (size) {
> +       case 4:
> +               __raw_writel(value, PCI_DATA_REG);
> +               break;
> +       case 2:
> +               __raw_writew(value, PCI_DATA_REG + (config & 3));
> +               break;
> +       case 1:
> +               __raw_writeb(value, PCI_DATA_REG + (config & 3));
> +               break;
> +       default:
> +               ret = PCIBIOS_BAD_REGISTER_NUMBER;
> +       }
> +
> +       spin_unlock_irqrestore(&gemini_pci_lock, irq_flags);

The I/O ordering is probably not what you think it is.
There is no ordering guarantee between __raw_writel and
spin_lock/spin_unlock, so you really should be using
readl/writel.

Note that the pci_ops are called under another spinlock, so
you also don't need to take gemini_pci_lock here.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>,
	Russell King <linux@arm.linux.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: Gemini: Add support for PCI BUS
Date: Sun, 28 Nov 2010 20:56:17 +0100	[thread overview]
Message-ID: <201011282056.17389.arnd@arndb.de> (raw)
In-Reply-To: <1290860675-15453-1-git-send-email-ulli.kroll@googlemail.com>

On Saturday 27 November 2010 13:24:35 Hans Ulli Kroll wrote:
> +#define PCI_IOSIZE_REG         (IO_ADDRESS(GEMINI_PCI_IO_BASE))
> +#define PCI_PROT_REG           (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x04)
> +#define PCI_CTRL_REG           (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x08)
> +#define PCI_SOFTRST_REG                (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x10)
> +#define PCI_CONFIG_REG         (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x28)
> +#define PCI_DATA_REG           (IO_ADDRESS(GEMINI_PCI_IO_BASE) + 0x2C)

If you use the virtual address of the mapping instead of
GEMINI_PCI_IO_BASE, you don't need to repeat the IO_ADDRESS()
macro everywhere. I have a patch that gets rid of all the
conflicting definitions of this macro because it breaks
a multi-platform build once we get there. 

> +static DEFINE_SPINLOCK(gemini_pci_lock);
> +
> +static struct resource gemini_pci_resource_io = {
> +       .name   = "PCI I/O Space",
> +       .start  = IO_ADDRESS(GEMINI_PCI_IO_BASE),
> +       .end    = IO_ADDRESS(GEMINI_PCI_IO_BASE) + SZ_1M - 1,
> +       .flags  = IORESOURCE_IO,
> +};
> +

This looks wrong in multiple ways:

* resources are physical addresses, not virtual addresses
* GEMINI_PCI_IO_BASE is an address in memory space, so it
  needs to be IORESOURCE_MEM, not IORESOURCE_IO. You can
  also register the IORESOURCE_IO resource, but that would
  be .start=PCIBIOS_MIN_IO, .end=IO_SPACE_LIMIT.
* IO_SPACE_LIMIT is larger than the I/O window, which can
  cause overflows. Setting it to 0xffff is generally enough.

> +       spin_lock_irqsave(&gemini_pci_lock, irq_flags);
> +
> +       __raw_writel(PCI_CONF_BUS(bus->number) |
> +                       PCI_CONF_DEVICE(PCI_SLOT(fn)) |
> +                       PCI_CONF_FUNCTION(PCI_FUNC(fn)) |
> +                       PCI_CONF_WHERE(config) |
> +                       PCI_CONF_ENABLE,
> +                       PCI_CONFIG_REG);
> +
> +       switch (size) {
> +       case 4:
> +               __raw_writel(value, PCI_DATA_REG);
> +               break;
> +       case 2:
> +               __raw_writew(value, PCI_DATA_REG + (config & 3));
> +               break;
> +       case 1:
> +               __raw_writeb(value, PCI_DATA_REG + (config & 3));
> +               break;
> +       default:
> +               ret = PCIBIOS_BAD_REGISTER_NUMBER;
> +       }
> +
> +       spin_unlock_irqrestore(&gemini_pci_lock, irq_flags);

The I/O ordering is probably not what you think it is.
There is no ordering guarantee between __raw_writel and
spin_lock/spin_unlock, so you really should be using
readl/writel.

Note that the pci_ops are called under another spinlock, so
you also don't need to take gemini_pci_lock here.

	Arnd

  reply	other threads:[~2010-11-28 19:56 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-27 12:24 [PATCH] ARM: Gemini: Add support for PCI BUS Hans Ulli Kroll
2010-11-27 12:24 ` Hans Ulli Kroll
2010-11-28 19:56 ` Arnd Bergmann [this message]
2010-11-28 19:56   ` Arnd Bergmann
2010-11-29 12:17   ` Hans Ulli Kroll
2010-11-29 12:17     ` Hans Ulli Kroll
2010-11-29 15:02     ` Arnd Bergmann
2010-11-29 15:02       ` Arnd Bergmann
2010-11-29 16:05   ` Paulius Zaleckas
2010-11-29 16:05     ` Paulius Zaleckas
2010-11-29 16:45     ` Arnd Bergmann
2010-11-29 16:45       ` Arnd Bergmann
2010-11-29 18:52       ` Paulius Zaleckas
2010-11-29 18:52         ` Paulius Zaleckas
2010-11-29 20:02         ` Arnd Bergmann
2010-11-29 20:02           ` Arnd Bergmann
2010-11-29 20:19           ` Paulius Zaleckas
2010-11-29 20:19             ` Paulius Zaleckas
2010-11-30  8:15             ` Hans Ulli Kroll
2010-11-30  8:15               ` Hans Ulli Kroll
2010-11-30  9:34               ` Paulius Zaleckas
2010-11-30  9:34                 ` Paulius Zaleckas
2010-12-01 11:52                 ` Hans Ulli Kroll
2010-12-01 11:52                   ` Hans Ulli Kroll
2010-12-01 13:08                   ` Paulius Zaleckas
2010-12-01 13:08                     ` Paulius Zaleckas
2010-12-01 15:02                     ` Hans Ulli Kroll
2010-12-01 15:02                       ` Hans Ulli Kroll
2010-12-06 10:51       ` Sergei Shtylyov
2010-12-06 10:51         ` Sergei Shtylyov
2010-12-06 12:18         ` Arnd Bergmann
2010-12-06 12:18           ` Arnd Bergmann
2010-11-29 19:32     ` Russell King - ARM Linux
2010-11-29 19:32       ` Russell King - ARM Linux
2010-11-29 19:57       ` Paulius Zaleckas
2010-11-29 19:57         ` Paulius Zaleckas
  -- strict thread matches above, loose matches on Subject: below --
2010-11-20 14:27 [PATCH] ARM: Gemini: Add support for PCI Bus Hans Ulli Kroll
2010-11-20 14:27 ` Hans Ulli Kroll
2010-11-20 19:30 ` Paulius Zaleckas
2010-11-20 19:30   ` Paulius Zaleckas
2010-11-26 11:18   ` Russell King - ARM Linux
2010-11-26 11:18     ` Russell King - ARM Linux
2010-11-26 11:57 ` Michał Mirosław
2010-11-26 11:57   ` Michał Mirosław
2010-11-27 12:16   ` Hans Ulli Kroll
2010-11-27 12:16     ` Hans Ulli Kroll
2010-11-27 13:01     ` Michał Mirosław
2010-11-27 13:01       ` Michał Mirosław
2010-11-27 15:39       ` Arnd Bergmann
2010-11-27 15:39         ` Arnd Bergmann
2010-11-29  8:12         ` Hans Ulli Kroll
2010-11-29  8:12           ` Hans Ulli Kroll
2010-11-29 14:22         ` Russell King - ARM Linux
2010-11-29 14:22           ` Russell King - ARM Linux
2010-11-29 14:50           ` Hans Ulli Kroll
2010-11-29 14:50             ` Hans Ulli Kroll
2010-11-29 15:57             ` Arnd Bergmann
2010-11-29 15:57               ` Arnd Bergmann
2010-11-30 15:38               ` Hans Ulli Kroll
2010-11-30 15:38                 ` Hans Ulli Kroll
2010-11-30 16:05               ` Russell King - ARM Linux
2010-11-30 16:05                 ` Russell King - ARM Linux
2010-11-30 16:19                 ` Arnd Bergmann
2010-11-30 16:19                   ` Arnd Bergmann
2010-12-01 15:05                   ` Hans Ulli Kroll
2010-12-01 15:05                     ` Hans Ulli Kroll
2010-11-29 15:50           ` Arnd Bergmann
2010-11-29 15:50             ` 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=201011282056.17389.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.