Date: Fri, 24 Dec 2004 15:52:18 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: freebsd-misuser@NOSPAM.dyndns.dk, freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk Cc: lennart@augustsson.net Subject: Re: getting vendor IDs Message-ID: <20041224.155218.123609434.imp@bsdimp.com> In-Reply-To: <200412242236.iBOMaig32845@Mail.NOSPAM.DynDNS.dK> References: <41C78044.2050005@elischer.org> <200412242236.iBOMaig32845@Mail.NOSPAM.DynDNS.dK>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200412242236.iBOMaig32845@Mail.NOSPAM.DynDNS.dK>
Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> writes:
: I may try to bring usbdevs into shape with the USB site vendor
: list, separating the others for later consideration. One of the
: things I noticed in a diff was:
: vendor HP 0x03f0 Hewlett Packard
: vendor HP2 0xf003 Hewlett Packard
: That looks to me more like an endian issue, than a separate vendor
: ID, right? (must dig for references, unless it's a real product
: that HP botched up)
It is, but there's a lot of devices that do this. It is a botch in
the device...
: There seem to be a good number of USB vendors whose products show
: up in other Vendors' products.
That's because the vendors are a little bogus. We have the same
problem with pccard at times. The reason it happens is because people
see "D-Link Gerbil Puncher" and they think that the ID belongs to
D-Link, when really it belongs to Rodent Industries, LLC.
: In such a case, the only thing I can see doing is to provide the
: end-product description as part of the vendor product, for NetBSD.
: Which will be rather a lot of work, but when you have the case of
: some unfamiliar-to-consumer's chip in a well-known camera case,
: I don't see an easy way to keep the descriptions short yet clear.
I don't understand what you are saying at all.
: Yeah, it's nitpicking. It doesn't matter to D/FBSD, but apparently
: does to NetBSD (and OpenBSD? Haven't checked), so I'd rather do this
: in a way agreeable to NetBSD...
You assume that there's more coordination in the file than there
really is.
: Also, in the event that D/FBSD implement a pciconf-like command for
: USB that would search through a database for detailed vendor/product
: descriptions, apparently like NetBSD has in the kernel, to make up
: for the noted deficiency with two of my USB devices, then this info
: would be relevant to FreeBSD and DFly.
That's much less needed for usb because you can get real strings from
the usb device, and you can't from the pci devices...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041224.155218.123609434.imp>