public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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

  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