netdev - RE: [PATCH] e1000e: test MSI interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Mar 2008 15:55:34 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	"David Miller" <davem@...emloft.net>, <jeff@...zik.org>
Cc:	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	<e1000-devel@...ts.sourceforge.net>, <netdev@...r.kernel.org>
Subject: RE: [PATCH] e1000e: test MSI interrupts

David Miller wrote:
> From: Jeff Garzik <jeff@...zik.org>
> Date: Thu, 27 Mar 2008 15:43:42 -0400
> 
>> But that seems like a quick id test, with no need for all that
>> generic MSI test code.
> 
> Yes, that is the way to do it.

I get your point, but this seems a maintainance problem due to not being
able to "future proof" the solution.  I know what is (IDs) available
now, but I don't know how many systems in the future IBM will release
with a similar bridge but a different device ID that causes the same
issue.  Should we take on the maintenance of continually having to add
every new bridge device that has this issue to our driver?  Users just
want this stuff to work when they plug it in.

tg3.c has exactly this kind of test and workaround (in fact its where I
got the code) to work around the same kind of issues.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html