From: "Michael S. Tsirkin" <mst@mellanox.co.il>
To: Roland Dreier <rdreier@cisco.com>
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
jeff@garzik.org, matthew@wil.cx, openib-general@openib.org,
linux-pci@atrey.karlin.mff.cuni.cz,
David Miller <davem@davemloft.net>
Subject: Re: Ordering between PCI config space writes and MMIO reads?
Date: Tue, 31 Oct 2006 19:53:12 +0000 [thread overview]
Message-ID: <20061031195312.GD5950@mellanox.co.il> (raw)
In-Reply-To: <adad588tijq.fsf@cisco.com>
Quoting r. Roland Dreier <rdreier@cisco.com>:
> Subject: Re: Ordering between PCI config space writes and MMIO reads?
>
> The discussion fizzled out without really reaching a definitive
> answer, so I'm going to apply the original patch (below), since I
> pretty much convinced myself that only the driver doing the config
> access has enough information to fix this reliably.
>
> - R.
>
> Author: John Partridge <johnip@sgi.com>
> Date: Tue Oct 31 11:00:04 2006 -0800
>
> IB/mthca: Make sure all PCI config writes reach device before doing MMIO
>
> During initialization, mthca writes some PCI config space registers
> and then does an MMIO read from one of the BARs it just enabled. This
> MMIO read sometimes failed and caused a crash on SGI Altix machines,
> because the PCI-X host bridge (legitimately, according to the PCI
> spec) allowed the MMIO read to start before the config write completed.
>
> To fix this, add a config read after all config writes to make sure
> they are all done before starting the MMIO read.
>
> Signed-off-by: John Partridge <johnip@sgi.com>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
>
> diff --git a/drivers/infiniband/hw/mthca/mthca_reset.c b/drivers/infiniband/hw/mthca/mthca_reset.c
> index 91934f2..578dc7c 100644
> --- a/drivers/infiniband/hw/mthca/mthca_reset.c
> +++ b/drivers/infiniband/hw/mthca/mthca_reset.c
> @@ -281,6 +281,20 @@ good:
> goto out;
> }
>
> + /*
> + * Perform a "flush" of the PCI config writes here by reading
> + * the PCI_COMMAND register. This is needed to make sure that
> + * we don't try to touch other PCI BARs before the config
> + * writes are done -- otherwise an MMIO cycle could start
> + * before the config writes are done and reach the HCA before
> + * the BAR is actually enabled.
> + */
> + if (pci_read_config_dword(mdev->pdev, PCI_COMMAND, hca_header)) {
> + err = -ENODEV;
> + mthca_err(mdev, "Couldn't access HCA memory after restoring, "
> + "aborting.\n");
> + }
> +
> out:
> if (bridge)
> pci_dev_put(bridge);
Here's what I don't understand: according to PCI rules, pci config read
can bypass pci config write (both are non-posted).
So why does doing it help flush the writes as the comment claims?
Isn't this more the case of
/* pci_config_write seems to complete asynchronously on Altix systems.
* This is probably broken but its not clear what's the best
* thing to do is - for now, do pci_read_config_dword which seems to flush
* everything out. */
--
MST
next prev parent reply other threads:[~2006-10-31 19:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-24 19:13 Ordering between PCI config space writes and MMIO reads? Roland Dreier
2006-10-24 19:22 ` Jeff Garzik
2006-10-24 21:47 ` Matthew Wilcox
2006-10-24 21:51 ` Roland Dreier
2006-10-24 22:12 ` John Partridge
2006-10-24 22:36 ` Matthew Wilcox
2006-10-24 22:43 ` David Miller
2006-10-25 14:15 ` Roland Dreier
2006-10-31 19:02 ` Roland Dreier
2006-10-31 19:53 ` Michael S. Tsirkin [this message]
2006-10-31 19:53 ` Roland Dreier
2006-10-31 19:58 ` Matthew Wilcox
2006-10-31 20:28 ` Michael S. Tsirkin
2006-10-31 20:34 ` Richard B. Johnson
2006-10-31 20:47 ` Matthew Wilcox
2006-10-31 22:30 ` Roland Dreier
2006-11-01 16:27 ` John Partridge
2006-11-01 16:46 ` Matthew Wilcox
2006-11-01 17:08 ` John Partridge
2006-11-01 17:14 ` Matthew Wilcox
2006-11-01 23:04 ` David Miller
2006-11-02 1:08 ` John Partridge
2006-10-31 20:50 ` Michael S. Tsirkin
2006-10-24 22:59 ` [openib-general] " Jason Gunthorpe
2006-10-25 14:04 ` Roland Dreier
2006-10-24 23:09 ` Michael S. Tsirkin
2006-10-24 23:27 ` Jack Steiner
2006-10-25 14:05 ` Roland Dreier
2006-11-02 3:05 ` Jeremy Higdon
2006-10-24 21:01 ` [openib-general] " JWM
2006-10-24 21:24 ` Alan Cox
2006-10-24 21:29 ` Roland Dreier
2006-10-24 21:37 ` Jeff Garzik
2006-10-25 6:30 ` Grant Grundler
2006-10-25 14:11 ` Roland Dreier
2006-10-25 14:18 ` Matthew Wilcox
2006-10-25 17:15 ` [openib-general] " Jason Gunthorpe
2006-10-25 18:22 ` Michael S. Tsirkin
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=20061031195312.GD5950@mellanox.co.il \
--to=mst@mellanox.co.il \
--cc=davem@davemloft.net \
--cc=jeff@garzik.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--cc=openib-general@openib.org \
--cc=rdreier@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox