public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Jay Cliburn <jacliburn@bellsouth.net>,
	Grzegorz Krzystek <ninex@NineX.eu.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@suse.de>,
	ninex@o2.pl, linux-kernel@vger.kernel.org,
	linux-pci@atrey.karlin.mff.cuni.cz,
	Michael Ellerman <michael@ellerman.id.au>,
	David Miller <davem@davemloft.net>,
	Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
Date: Fri, 25 May 2007 13:35:01 -0700	[thread overview]
Message-ID: <20070525203501.GD5413@suse.de> (raw)
In-Reply-To: <m1myztaq5s.fsf@ebiederm.dsl.xmission.com>

On Fri, May 25, 2007 at 09:17:35AM -0600, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
> 
> > Originally I would have thought this would be a good idea, but now that
> > Vista is out, which supports MSI, I don't think we are going to need
> > this in the future.  All new chipsets should support MSI fine and this
> > table will only grow in the future, while the blacklist should not need
> > to have many new entries added to it.
> >
> > So I don't think this is a good idea, sorry.
> 
> - The current situation is broken
> - In spec hardware does not require MSI to generate interrupts
>   Which leaves enabling MSI optional.
> 
> Do you have a better idea to solve the current brokenness?
> 
> MSI appears to have enough problems that enabling it in a kernel
> that is supposed to run lots of different hardware (like a distro
> kernel) is a recipe for disaster.

Oh, I agree it's a major pain in the ass at times...

But I'm real hesitant to change things this way.  We'll get reports of
people who used to have MSI working, and now it will not (like all AMD
chipsets).  That's a regression...

Perhaps we can trigger off of the same flag that Vista uses like Andi
suggested?  That's one way to "know" that the hardware works, right?

For non-x86 arches, they all seem to want to always enable MSI as they
don't have to deal with as many broken chipsets, if any at all.  So for
them, we'd have to just whitelist the whole arch.  Does that really make
sense?

And again, over time, like years, this list is going to grow way beyond
a managable thing, especially as any new chipset that comes out in 2009
is going to have working MSI, right?  I think our blacklist is easier to
manage over time, while causing a problem for some users in trying to
determine their broken hardware that they currently have.

It's a trade off, and I'd like to choose the one that over the long
term, causes the least ammount of work and maintaiblity.  I think the
current blacklist meets that goal.

thanks,

greg k-h

  parent reply	other threads:[~2007-05-25 20:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200705122146.l4CLkH6q012322@fire-2.osdl.org>
     [not found] ` <m1mz09p1t7.fsf@ebiederm.dsl.xmission.com>
     [not found]   ` <20070513014622.c5702928.akpm@linux-foundation.org>
     [not found]     ` <46470209.9000502@bellsouth.net>
     [not found]       ` <46470515.50000@NineX.eu.org>
     [not found]         ` <464707F7.6080600@bellsouth.net>
     [not found]           ` <m1irawpwy2.fsf@ebiederm.dsl.xmission.com>
     [not found]             ` <20070513204407.7ba35010@osprey.hogchain.net>
     [not found]               ` <4647FA38.3090108@NineX.eu.org>
     [not found]                 ` <46480EA5.40400@NineX.eu.org>
     [not found]                   ` <20070514053406.478bf93f@osprey.hogchain.net>
     [not found]                     ` <m1d513oddj.fsf@ebiederm.dsl.xmission.com>
     [not found]                       ` <20070514093829.377e04bc@osprey.hogchain.net>
     [not found]                         ` <m18xbrnyxi.fsf@ebiederm.dsl.xmission.com>
     [not found]                           ` <20070514160005.627435e3@osprey.hogchain.net>
     [not found]                             ` <m1odkmmft4.fsf@ebiederm.dsl.xmission.com>
     [not found]                               ` <20070515212200.517fcba2@osprey.hogchain.net>
     [not found]                                 ` <m14pmcmz8r.fsf@ebiederm.dsl.xmission.com>
     [not found]                                   ` <20070516185225.3f3ac082@osprey.hogchain.net>
     [not found]                                     ` <m1sl9wl28m.fsf@ebiederm.dsl.xmission.com>
     [not found]                                       ` <20070522204103.134bf5a2@osprey.hogchain.net>
2007-05-25  4:19                                         ` [PATCH 1/2] msi: Invert the sense of the MSI enables Eric W. Biederman
2007-05-25  4:26                                           ` [PATCH 2/2] msi: Add support for the Intel chipsets that support MSI Eric W. Biederman
2007-05-25  5:38                                             ` Andi Kleen
2007-05-25  6:10                                               ` Eric W. Biederman
2007-05-25 14:42                                                 ` Chuck Ebbert
2007-05-25 16:52                                                   ` Eric W. Biederman
2007-05-25  4:31                                           ` [PATCH 1/2] msi: Invert the sense of the MSI enables Andrew Morton
2007-05-25  5:20                                             ` Eric W. Biederman
2007-05-25  5:44                                             ` Grant Grundler
2007-05-25  5:51                                             ` Andi Kleen
2007-05-25 20:16                                               ` Jonathan Lundell
2007-05-26  6:52                                                 ` Grant Grundler
2007-05-25  5:14                                           ` Michael Ellerman
2007-05-25  5:59                                             ` Eric W. Biederman
2007-05-25  6:40                                             ` David Miller
2007-05-25  5:20                                           ` Greg KH
2007-05-25  5:57                                             ` Eric W. Biederman
2007-05-25 15:17                                             ` Eric W. Biederman
2007-05-25 15:28                                               ` Chuck Ebbert
2007-05-25 15:40                                               ` Roland Dreier
2007-05-25 15:42                                                 ` Roland Dreier
2007-05-25 16:10                                                   ` Eric W. Biederman
2007-05-25 20:09                                                     ` David Schwartz
2007-05-25 20:25                                                     ` Roland Dreier
2007-05-25 20:35                                               ` Greg KH [this message]
2007-05-25 21:06                                                 ` Eric W. Biederman
2007-05-25 21:17                                                   ` Roland Dreier
2007-05-25 21:31                                                   ` Greg KH
2007-05-26  6:43                                                 ` Grant Grundler
2007-05-25 21:47                                           ` Brice Goglin

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=20070525203501.GD5413@suse.de \
    --to=gregkh@suse.de \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=jacliburn@bellsouth.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=michael@ellerman.id.au \
    --cc=ninex@NineX.eu.org \
    --cc=ninex@o2.pl \
    --cc=tony.luck@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