public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Andi Kleen <ak@suse.de>
Cc: Grant Grundler <grundler@parisc-linux.org>,
	Michael Chan <mchan@broadcom.com>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	akpm@osdl.org, greg@kroah.com, "Durairaj,
	Sundarapandian" <sundarapandian.durairaj@intel.com>
Subject: Re: [PATCH] pci-mmconfig fix for 2.6.9
Date: Sun, 14 Nov 2004 23:00:21 -0700	[thread overview]
Message-ID: <20041115060021.GA3302@colo.lackof.org> (raw)
In-Reply-To: <20041114085831.GF16795@wotan.suse.de>

On Sun, Nov 14, 2004 at 09:58:31AM +0100, Andi Kleen wrote:
> > Other chipsets can implement postable config space. To be compliant
> > with the ECN, the architecture must define a method to guarantee
> > the posted writes have reached the target device. I think the
> > ECN we've been talking about assumes that method will be implemented
> > in firmware somehow and NOT as a direct access method in the OS.
> 
> Hmm, but there is no way for the chipset to tell us that this 
> is needed. 

Why not?
Can't we just "know" if specific chipsets implement posted
mmconfig writes or not?

Intel folks have confirmed their chipsets to date implement
non-postable mmconfig writes.


> Perhaps we really need to special case this and add posted pci config
> writes to handle Michael's power management issue properly. 
> That would be definitely the safer approach.

hrm...are you suggesting another entry point in the struct raw_pci_ops?

There are two tests in arch/i386/pci/mmconfig.c:pci_mmcfg_init() before
the raw_pci_ops is set to &pci_mmcfg. Perhaps some additional crude tests
could select a different set of pci_raw_ops to deal with posted writes
to mmconfig space. Someone more familiar with those chipsets might
find a more elegant solution.

> > That means someone has to introduce a new method to access
> > mmconfig if they implement postable writes.
> 
> 
> Problem is that it adds silently a very subtle bug and there
> is no way I know of for ACPI to tell the firmware it shouldn't use
> posting.

Uhm, ACPI needs to tell the firmware?
I would expect firmware to be platform/chip specific and "just know".

If you meant OS, we already embed knowledge about specific chipsets
for bug workarounds (e.g. tg3 driver). I think that's an option here too.
I mean tweaking mmconfig.c to install a (possibly) chip specific
method (raw_pci_ops) to flush posted mmconfig writes.

>  The driver should know when the read is forbidden though.

Yeah, I would expect it to also. But I certainly don't expect
it to know how to flush a posted write with anything but a
config read.

If the chipset that implemented posted mmconfig writes is compliant
with the ECN we've been talking about, then there must be some other
method to guarantee the writes reaches the device. I would expect
another raw_pci_ops method to be able to deal with it but can't
promise that's true for every chipset out there.

grant

  reply	other threads:[~2004-11-15  6:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-13 16:22 [PATCH] pci-mmconfig fix for 2.6.9 Michael Chan
2004-11-13 19:46 ` Grant Grundler
2004-11-14  8:58   ` Andi Kleen
2004-11-15  6:00     ` Grant Grundler [this message]
2004-11-15  8:33       ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2004-11-15  7:07 Michael Chan
2004-11-15  8:01 ` Grant Grundler
2004-11-12 23:56 Michael Chan
2004-11-13  9:22 ` Andi Kleen
2004-11-12 21:49 Michael Chan
2004-11-12 22:31 ` Grant Grundler
2004-11-12 19:23 Michael Chan
2004-11-12 20:55 ` Grant Grundler
2004-11-12 17:52 Michael Chan
2004-11-12 18:35 ` Grant Grundler
2004-11-11 16:33 Nguyen, Tom L
2004-11-10 22:20 long
2004-11-11  1:30 ` Greg KH
2004-11-11  7:57 ` Andi Kleen
2004-11-10 19:38 long
2004-11-10 19:35 ` Greg KH
2004-11-10 17:26 Durairaj, Sundarapandian
2004-11-10 17:35 ` Greg KH

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=20041115060021.GA3302@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=mchan@broadcom.com \
    --cc=sundarapandian.durairaj@intel.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