linux-kernel - Re: [PATCH] PCI: nVidia's MCP61 ethernet card needs quirk for wrong class

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]

Message-ID: <47010A34.9000709@pobox.com>
Date:	Mon, 01 Oct 2007 10:54:44 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Jiri Kosina <jkosina@...e.cz>
CC:	Greg KH <greg@...ah.com>, Ayaz Abdulla <aabdulla@...dia.com>,
	linux-pci@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: nVidia's MCP61 ethernet card needs quirk for wrong
 class

Jiri Kosina wrote:
> On Mon, 1 Oct 2007, Jeff Garzik wrote:
> 
>>> PCI: nVidia's MCP61 ethernet card needs quirk for wrong class
>>> The MCP61 ethernet controller from nVidia (NVENET_19) contains wrong
>>> PCI class:
>>>  00:07.0 Bridge [0680]: nVidia Corporation MCP61 Ethernet [10de:03ef] (rev
>>>  a2)
>>> i.e. it identifies itself as a bridge. Fix this.
>>> Signed-off-by: Jiri Kosina <jkosina@...e.cz>
>> What is the problem that is present without this patch?
> 
> Userspace tools that are used to configure network are probable not to 
> detect this device as a network card and therefore not provide means to 
> configure the device (this is a case at least with yast, I don't know what 
> is the situation with other configurators).
> 
> There might be also other situations, I don't know. Userspace really 
> should know the proper class of the device, shouldn't it?

There are other network devices that do not claim 
PCI_CLASS_NETWORK_ETHERNET either.  Since this is a purely cosmetic 
issue -- said userland tools would need to support weird cases _anyway_ 
  -- I am not inclined to apply the patch.

The kernel could do a lot to make things "prettier," but that would lead 
to lots of additional code bloat.  It's easier to export the world as it 
is, and let the chips fall where they may.

	Jeff



-
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/