From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Arjan van de Ven <arjan@infradead.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: Sat, 22 Dec 2007 21:18:25 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.0.9999.0712222109560.21557@woody.linux-foundation.org> (raw)
In-Reply-To: <476DEC66.9050701@garzik.org>
On Sun, 23 Dec 2007, Jeff Garzik wrote:
>
> Then let's do it right: disable mmconfig by default on x86, and enable it
> when passed "pci=mmconfig".
I'm certainly ok with that, but then you say:
> > And yes, if you want the capability following to notice automatically when
> > capabilities really do go into the 0x100+ range, that's fine. I suspect
>
> Yes, we /must/ do this checking, if we don't already.
Hell no. If the user asked for mmconfig to be disabled, it needs to be
disabled, because it may well be broken and non-working. It's better to
not see some capabilities than to lock up the machine.
So what is it? Is it "some machines do it automatically when needed" or is
it "always disabled"?
You seem to now say that "always disabled by default" isn't good either.
What do I need to do to convince you that the *right* thing to do is:
- disabled by default, unless user *explicitly* asks for it with
"pci=mmconfig"
- but certain events will enable it automatically, unless the user
*explicitly* said (or we had a quirk that explicitly disabled it)
something like pci=mmconfig
See what I'm saying? You don't really seem to be disagreeing. It seems to
be, in fact, exactly what you want.
I'm saying that yes, the PCI capability code might be one such "enable
mmconfig if not explicitly disabled" user.
But I also suspect that some drivers might want to do it, and I'm almost
certain that some DMI quirks will want to do it (ie "I recognize this
machine, and this machine is from 2011, and wants MMCONFIG"). So we need
to have an interface for those quirks or other events to also do it, it
cannot be just a "PCI capabilities do it".
Quite frankly, the fewer drivers that do it, the happier I am. Maybe *no*
drivers will do it. If so, "Hallelujah, brother, give me an Amen!". But we
clearly want an interface for _some_ things to say "we might want to have
mmconfig". Maybe it's only PCI capabilities.
Regardless. Even if *no* driver ever does it, the logical interface will
clearly be "pci_enable_mmio(pdev)".
You can then argue all you want against individual drivers actually ever
using it, and I'll support you on that. I think MMCONFIG was/is a total
waste of everybodys time.
Linus
next prev parent reply other threads:[~2007-12-23 5:19 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
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 [this message]
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=alpine.LFD.0.9999.0712222109560.21557@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=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 \
/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®