[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15F501D1A78BD343BE8F4D8DB854566B1FD7D6B5@hkemmail01.nvidia.com>
Date: Mon, 7 Jan 2008 13:32:28 +0800
From: "Peer Chen" <pchen@...dia.com>
To: "Peer Chen" <pchen@...dia.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Cc: "peerchen" <peerchen@...il.com>,
"linux-kernel" <linux-kernel@...r.kernel.org>,
"akpm" <akpm@...ux-foundation.org>,
"Andy Currid" <ACurrid@...dia.com>
Subject: RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability
Eric,
Any decision for this patch, if not, currently we prefer to add all our
code to quirks.c.
BRs
Peer Chen
-----Original Message-----
From: Peer Chen
Sent: Wednesday, January 02, 2008 5:58 PM
To: 'Eric W. Biederman'
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability
I think it's more reasonable to only apply this rule onto AMD platform.
BRs
Peer Chen
-----Original Message-----
From: Eric W. Biederman [mailto:ebiederm@...ssion.com]
Sent: Monday, December 24, 2007 7:49 PM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability
"Peer Chen" <pchen@...dia.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
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists