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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ