public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Date: Sat, 22 Dec 2007 11:25:32 -0800	[thread overview]
Message-ID: <20071222192532.GA5282@suse.de> (raw)
In-Reply-To: <476D39C5.9080409@shaw.ca>

On Sat, Dec 22, 2007 at 10:22:29AM -0600, Robert Hancock wrote:
> Arjan van de Ven wrote:
>> Hi,
>> Linus really wants the extended (4Kb) PCI configuration space (using MCFG 
>> acpi table etc) to be opt-in, since there's many issues with it and most 
>> drivers don't even use/need it. The idea behind opt-in is that if you 
>> don't use it, you don't get to suffer the bugs...
>> Booted on my 64 bit test machine; sadly it has a defunct BIOS that doesn't 
>> have a working MCFG.
>> From: Arjan van de Ven <arjan@linux.intel.com>
>> Subject: Make MMCONFIG space a driver opt-in
>> There are many issues with using the extended PCI configuration space 
>> (CPU, Chipset and most of all BIOS bugs). This while the vast majority of 
>> drivers
>> and devices don't even use/need to use the memory mapped access methods 
>> since they
>> don't use the config space beyond the traditional 256 bytes.
>> This patch makes accessing the extended config space a driver choice, via 
>> the
>> pci_enable_ext_config(pdev)
>> API function; drivers that want/need the extended configuration space 
>> should call this.
>> (a separate patch will be posted to add this function call to the driver 
>> that uses this)
>
> I don't really like this approach. Whether MMCONFIG works or not has 
> nothing to do with the device itself, it's an attribute of the machine, and 
> possibly the bus it's been plugged into. This patch might prevent problems 
> in some cases, but it's equally likely to just delay problems until 
> somebody plugs in a device that tries to use extended config space.

But it is that device, and the driver that controls this device that
cares about the extended config space.  So it's fair to push this onto
the driver if needed, instead of forcing the pci core to just blindly
guess for all devices, and getting it wrong...

thanks,

greg k-h

  reply	other threads:[~2007-12-22 19:23 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.pFsY/52FEkQYqrDPnPMxmcUOsRY@ifi.uio.no>
2007-12-22 16:22 ` [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue Robert Hancock
2007-12-22 19:25   ` Greg KH [this message]
2007-12-23  0:56     ` Jeff Garzik
2007-12-22 12:31 Arjan van de Ven
2007-12-22 14:20 ` Jeff Garzik
2007-12-22 14:47   ` Arjan van de Ven
2007-12-22 15:54     ` Matthew Wilcox
2007-12-22 16:02       ` Arjan van de Ven
2007-12-22 21:10         ` Matthew Wilcox
2007-12-23 23:33           ` Benjamin Herrenschmidt
2007-12-22 18:06     ` Linus Torvalds
2007-12-22 19:30       ` Martin Mares
2007-12-22 20:15         ` Arjan van de Ven
2007-12-22 20:36           ` Martin Mares
2007-12-23  1:29           ` Jeff Garzik
2007-12-23  1:26       ` Jeff Garzik
2007-12-23  3:46         ` Linus Torvalds
2007-12-23  4:11           ` Jeff Garzik
2007-12-23  4:35             ` Linus Torvalds
2007-12-23  4:52               ` Jeff Garzik
2007-12-23  5:00                 ` Linus Torvalds
2007-12-23  5:09                   ` Jeff Garzik
2007-12-23 21:09                   ` Benjamin Herrenschmidt
2007-12-23 21:15                     ` Martin Mares
2007-12-23 22:32                       ` Ivan Kokshaysky
2007-12-23 23:06                       ` Benjamin Herrenschmidt
2007-12-23 23:19                         ` Benjamin Herrenschmidt
2007-12-23  5:27                 ` Loic Prylli
2007-12-23  5:44                   ` Jeff Garzik
2007-12-23  8:33                     ` Loic Prylli
2007-12-23 11:03                     ` Ivan Kokshaysky
2007-12-23 17:32                       ` Linus Torvalds
2007-12-24  7:31                         ` Jeff Garzik
2007-12-24 18:51                           ` Linus Torvalds
2007-12-24 21:22                             ` Matthew Wilcox
2007-12-27 11:46                             ` Jeff Garzik
2007-12-27 14:09                               ` Arjan van de Ven
2007-12-24  7:22                       ` Jeff Garzik
2007-12-24 15:47                         ` Ivan Kokshaysky
2007-12-23 21:13                     ` Benjamin Herrenschmidt
2007-12-23 10:33                 ` Arjan van de Ven
2007-12-24  7:04                   ` Jeff Garzik
2007-12-24 11:49                     ` Arjan van de Ven
2007-12-24 11:54                       ` Jeff Garzik
2007-12-24 12:00                         ` Arjan van de Ven
2007-12-25  9:22                           ` Martin Mares
2007-12-25  9:40                             ` Martin Mares
2007-12-23  4:13           ` Jeff Garzik
2007-12-23  4:18             ` Jeff Garzik
2007-12-23  4:44               ` Linus Torvalds
2007-12-23  5:04                 ` Jeff Garzik
2007-12-23  5:18                   ` Linus Torvalds
2007-12-23  5:22                     ` Jeff Garzik
2007-12-23  4:40             ` Linus Torvalds
2007-12-23 10:18               ` Martin Mares
2007-12-23  5:09             ` Loic Prylli
2007-12-23  5:57             ` H. Peter Anvin
2007-12-23  1:34     ` Jeff Garzik
2007-12-22 20:43 ` Benjamin Herrenschmidt

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=20071222192532.GA5282@suse.de \
    --to=gregkh@suse.de \
    --cc=arjan@infradead.org \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    /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