From: Bjorn Helgaas <bhelgaas@google.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 2/2] PCI: Stop clearing bridge Secondary Status when setting up I/O aperture
Date: Mon, 9 Dec 2013 13:15:52 -0700 [thread overview]
Message-ID: <CAErSpo4Q-sjiCUs3UbQWdPhOTdxfJP1ay1MugxTPT1E2=TkpJw@mail.gmail.com> (raw)
In-Reply-To: <20131209193332.GB20199@obsidianresearch.com>
On Mon, Dec 9, 2013 at 12:33 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Thu, Dec 05, 2013 at 05:19:55PM -0700, Bjorn Helgaas wrote:
>> pci_setup_bridge_io() accessed PCI_IO_BASE and PCI_IO_LIMIT using dword
>> (32-bit) reads and writes, which also access the Secondary Status register.
>> Since the Secondary Status register is in the upper 16 bits of the dword,
>> and we preserved those upper 16 bits, this had the effect of clearing any
>> of the write-1-to-clear bits that happened to be set in the Secondary
>> Status register.
>
> This is a good catch!
>
>> - pci_write_config_dword(bridge, PCI_IO_BASE, l);
>> + pci_write_config_word(bridge, PCI_IO_BASE, l);
>
> But this is a problem :(
>
> tegra and mvebu at least do not have HW to do non-32 bit writes, so
> their implementation of pci_write_config_word does the RMW internally
> and will still have this same bug.
>
> I think you have to keep the 32 bit write here, but zero the
> write-one-to-clear bits :(
Is there actually some spec requirement about the access sizes that
must be supported by the hardware? If there is something, I'll gladly
keep the 32-bit access, but if it's only a tegra/mvebu-specific
restriction, then I think it needs to be handled in the PCI config
accessors for that hardware.
This spec statement (PCI (not PCIe) r3.0, sec 3.2.2.3.4) makes it
sound like tegra/mvebu is non-conforming and should deal with this
specially:
"A function must not restrict the size of the access it supports in
Configuration Space. The configuration commands, like other commands,
allow data to be accessed using any combination of bytes (including a
byte, word, DWORD, or non-contiguous bytes) and multiple data phases
in a burst. The target is required to handle any combination of byte
enables."
I think the tegra/mvebu accessors should be able to use the address
and access size to figure out what we're trying to do. If we're doing
a WORD write to PCI_IO_BASE, it can turn that into: 32-bit read, clear
the upper 16 bits (secondary status), insert the PCI_IO_BASE part,
32-bit write. If we're doing a 16-bit write to PCI_SEC_STATUS, it can
turn that into: 32-bit read, insert upper 16 bits (secondary status),
leave lower 16 bits alone, 32-bit write.
Bjorn
next prev parent reply other threads:[~2013-12-09 20:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 0:19 [PATCH 0/2] Bridge window discovery and setup fixes Bjorn Helgaas
2013-12-06 0:19 ` [PATCH 1/2] PCI: Prevent bus conflicts while checking for bridge apertures Bjorn Helgaas
2013-12-09 19:31 ` Jason Gunthorpe
2013-12-09 20:00 ` Bjorn Helgaas
2013-12-09 20:15 ` Jason Gunthorpe
2013-12-06 0:19 ` [PATCH 2/2] PCI: Stop clearing bridge Secondary Status when setting up I/O aperture Bjorn Helgaas
2013-12-09 19:33 ` Jason Gunthorpe
2013-12-09 20:15 ` Bjorn Helgaas [this message]
2013-12-09 21:27 ` Jason Gunthorpe
2013-12-09 21:58 ` Bjorn Helgaas
2013-12-10 0:10 ` Jason Gunthorpe
2013-12-10 0:18 ` Bjorn Helgaas
2013-12-10 1:31 ` Jason Gunthorpe
2013-12-10 18:22 ` Bjorn Helgaas
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='CAErSpo4Q-sjiCUs3UbQWdPhOTdxfJP1ay1MugxTPT1E2=TkpJw@mail.gmail.com' \
--to=bhelgaas@google.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-pci@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).