public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Peer Chen" <pchen@nvidia.com>
Cc: "peerchen" <peerchen@gmail.com>,
	"linux-kernel" <linux-kernel@vger.kernel.org>,
	"akpm" <akpm@linux-foundation.org>,
	"Andy Currid" <ACurrid@nvidia.com>
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability
Date: Mon, 24 Dec 2007 04:49:01 -0700	[thread overview]
Message-ID: <m1lk7kl3de.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <15F501D1A78BD343BE8F4D8DB854566B1F571D0F@hkemmail01.nvidia.com> (Peer Chen's message of "Mon, 24 Dec 2007 17:10:29 +0800")

"Peer Chen" <pchen@nvidia.com> writes:

> I feel it's dangerous to set the En bit on Intel platform, If the HT MSI
> En is set, the MSI should be expected to transform to HT INT message
> format. It may cause interrupt lost or hardware internal state machine
> failed depend on the hardware design.

Reasonable.  As long as what the quirk is to avoid errata and
chipset specific issues I don't have a problem with it.

I figure the quirk should be a separate patch though.

My concern is that the general rule that always enabling HT MSI
mapping capabilities is reasonable.  Even if there are some
specific exceptions where we don't want to do that.

I want code that requires the smallest list of chipset
exceptions that we can make. 

Eric

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

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-18 15:00 [PATCH] msi: set 'En' bit of MSI Mapping Capability peerchen
2007-12-18 21:59 ` Eric W. Biederman
2007-12-20 13:43   ` Peer Chen
2007-12-20 22:48     ` Eric W. Biederman
2007-12-24  9:10       ` Peer Chen
2007-12-24 11:49         ` Eric W. Biederman [this message]
2008-01-02  9:57           ` Peer Chen
2008-01-07  5:32           ` Peer Chen
2008-01-07  9:01             ` Eric W. Biederman
2007-12-20  0:41 ` Andrew Morton
2007-12-20  0:45   ` Andrew Morton
2007-12-20 22:54     ` Eric W. Biederman

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=m1lk7kl3de.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ACurrid@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pchen@nvidia.com \
    --cc=peerchen@gmail.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