mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, gregkh@suse.de,
	linux-pci@atrey.karlin.mff.cuni.cz,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Date: Mon, 24 Dec 2007 04:00:07 -0800	[thread overview]
Message-ID: <20071224040007.1277fddd@laptopd505.fenrus.org> (raw)
In-Reply-To: <476F9DF6.60100@garzik.org>

On Mon, 24 Dec 2007 06:54:30 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> Arjan van de Ven wrote:
> > I can see the point of having a sysfs attribute to enable MMCONF
> > from userspace, so that userland diagnostics tools can turn it on
> > if they really really want to. (I'd make that printk a nice warning
> > "application XYZ is enabling extended config space for devize ABC"
> > so that if the box then crashes and burns, people know who/why and
> > where to direct their emails ;-)
> > 
> > We did something similar for "enable", it's maybe 10 lines of code
> > or so.
> > 
> > I would assume lspci and friends would then only turn that on at
> > explicit admin request
> 
> Absolutely...  I'm not asking to default it on, just asking for it to
> be possible :)
> 

ok so to summarize things a bit (I'll admit bias here but still ;)

1) having a per driver function to say "I'd like extended config space" is ok
   (it's the driver that knows what is needed after all)
2) we need a way for userspace to do the same for a given device
   (which then will print a nice warning who does what to whom)
3) we need to have the "no extended config space unless someone wants it" behavior
4) It's inevitable that this will end up being per device given that we'll end up with
   per device "this one is b0rked" quirks over time (even shortly)
5) architectures that have sane extended config space access should just be able to provide
   it always. This could even be on x86 based on BIOS date (say 2009 :)

the patch I posted does 1) 3) 4) and the first half of 5)
I'll update the patch to do 2) and the rest of 5)

Is there anything I skipped in the summary above?
(and yes I realize this needs lspci to be expanded some to set the flag if the admin really asks for it, 
but such is life)


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  reply	other threads:[~2007-12-24 12:01 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-22 12:31 Arjan van de Ven
2007-12-22 12:35 ` [patch] opt the sky2 driver into using extended config space Arjan van de Ven
2007-12-22 20:28   ` Stephen Hemminger
2007-12-22 14:20 ` [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue 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 [this message]
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
     [not found] <fa.pFsY/52FEkQYqrDPnPMxmcUOsRY@ifi.uio.no>
2007-12-22 16:22 ` Robert Hancock
2007-12-22 19:25   ` Greg KH
2007-12-23  0:56     ` Jeff Garzik

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=20071224040007.1277fddd@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=benh@kernel.crashing.org \
    --cc=gregkh@suse.de \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®