All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org, "Kok,
	 Auke-jan H" <auke-jan.h.kok@intel.com>
Subject: Re: [PATCH] e1000e: test MSI interrupts
Date: Thu, 27 Mar 2008 15:43:42 -0400	[thread overview]
Message-ID: <47EBF8EE.1000102@garzik.org> (raw)
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5204BF07F7@orsmsx418.amr.corp.intel.com>

Brandeburg, Jesse wrote:
> Kok, Auke wrote:
>> Jeff Garzik wrote:
>>> Auke Kok wrote:
>>>> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>>>>
>>>> Test the MSI interrupt physically once before assuming that it
>>>> actually works. Several platforms have already come across that
>>>> have non-functional MSI interrupts and this code will attempt
>>>> to detect those safely. Once the test succeeds MSI interrupts
>>>> will be enabled.
>>>>
>>>> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>>>> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> 
>>> Ah, the perennial add-same-test-to-every-driver conundrum.
>>>
>>> I think we are far enough along with MSI to _not_ do this anymore in
>>> drivers. 
> 
> Actually, I'm hoping you'll allow this Jeff, we have a production system
> (see below) we know about that doesn't like the way 82571 formats MSI
> interrupt messages.  All other systems seem to be okay with this format
> of MSI messages, but this system implemented a stricter interpretation
> of the spec, and so even though that system doesn't need a quirk for MSI
> because MSI works in general, we still MUST test the MSI vector to make
> sure it works *for us*  In this case it comes down to being an errata
> workaround.
> 
> Since there is no way to "test" generation of an interrupt from any
> specific hardware device without internal knowledge of said device,
> there isn't a way for us to help the kernel by writing a generic "test
> MSI" routine.
> 
> I would prefer this "generic test" code be in the driver rather than
> having to identify all the chipsets that fail and have the driver do
> *specific chipset* detection ala bnx2.c's 8132 bridge workaround.

Well if it's a problem with the networking chip rather than the 
platform, then absolutely stick it in the driver (unless its so severe 
it needs to be in pci/quirks.c before the driver even loads).

But that seems like a quick id test, with no need for all that generic 
MSI test code.

Certainly the work is scoped based on where the problem lies, either 
platform, device, or platform+device.

	Jeff




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

  reply	other threads:[~2008-03-27 19:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-26 18:36 [PATCH] e1000e: test MSI interrupts Auke Kok
2008-03-26 18:42 ` Jeff Garzik
2008-03-26 20:42   ` [E1000-devel] " Kok, Auke
2008-03-27 17:53     ` Brandeburg, Jesse
2008-03-27 19:43       ` Jeff Garzik [this message]
2008-03-27 22:05         ` David Miller
2008-03-27 22:55           ` Brandeburg, Jesse
2008-03-27 23:06             ` David Miller
2008-03-27 23:38             ` Jeff Garzik
2008-03-27 23:53               ` Kok, Auke
2008-03-28  0:03                 ` David Miller
2008-03-27 21:59       ` David Miller
2008-03-27 22:05       ` Andy Gospodarek
2008-03-27 22:16         ` Kok, Auke
2008-03-27 22:33           ` Andy Gospodarek
2008-03-27 22:47             ` Kok, Auke

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=47EBF8EE.1000102@garzik.org \
    --to=jeff@garzik.org \
    --cc=auke-jan.h.kok@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=jesse.brandeburg@intel.com \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.