Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Dec 2004 17:40:17 +0100 (CET)
From:      Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk>
To:        Lennart Augustsson <lennart@augustsson.net>, usb@freebsd.org
Subject:   Re: USB vendore designations..
Message-ID:  <200412241640.iBOGeH079345@Mail.NOSPAM.DynDNS.dK>
References:  <41CB38A7.5020700@vicor.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[had to drop Matt as I can't mail him directly, sorry]

On Thu, 23 Dec 2004 13:29:11 -0800, Julian Elischer wrote:

> On FreeBSD we have added vendor descriptiosn fo teh form
> XYZ electrical corp.
> where on NetBSD the same ID may be described as "XYZ"

And OpenBSD has some vendors of the form `XYZ' that are still
in NetBSD as `XYZ foo corp'...


> I'd rather not be different for no reason, but I'm loath to
> just discard information.

This brings up a question I've wanted to pose:  How do the
entries derived from usbdevs get used?

For example, some USB code refers to specific devices, and my
work on a CDC Ethernet driver was helped by the fact that I had
already merged these from OtherBSDen.  So, the more devices one
has, the less one needs to bring usbdevs up-to-date when adding
code to handle new devices.

On the other hand, my Cabal Modem has neither vendor nor product
in usbdevs, and the code reads the descriptors from the device
itself to announce
cdce0: Cisco Systems, Inc. CVA-12x DOCSIS Cable Modem, rev 1.10/1.00, addr 6
and `usbdevs' command says about this
  port 1 addr 6: full speed, self powered, config 1, CVA-12x DOCSIS Cable Modem(
0x0002), Cisco Systems, Inc.(0x05a6), rev 1.00

On the third hand, two other devices I have are(n't) identified:
  port 3 addr 4: low speed, power 100 mA, config 1, product 0x0000(0x0000), vend
or 0x062a(0x062a), rev 0.00
  port 4 addr 5: full speed, power 500 mA, config 1, USB Audio(0xc000), vendor 0
x06f8(0x06f8), rev 1.00
(cordless mouse, and Guillemot Hercules Pocket Muse 5.1 bla bla)


So I'm not sure how important it is for me to add these vendor and
product IDs, provided I don't need to do anything special to get
the modem working, unlike, say, the Zaurus covered by the same
code...  Whereas other drivers, say, for the Realtek GigE chips
need to have every new manufacturer who jumps on the bandwagon
and adopts that chip, added or the card won't be identified.


Secondly, there are a handful of differences between NetBSD and
DFly/FBSD that Matt has discovered, as have I when building NetBSD
afresh after merging in that patch I created a week or more ago...
My apologies to all for not having properly cleaned up the patch,
again.  Anyway, what I remember most includes
PNY vs PEN, where NetBSD has four additional products, or
SONYERICSSON vs SUSTEEN or something else.  Probably one of them
is better...  Some time I'll decide which one...

If I change any of these, in order to get the different BSD branches
to agree with each other, I'll need to change anywhere in the code
where these references can be found (and spend days building LINT to
make sure I've got it right).

In FreeBSD, src/sys/dev/usb/ seems to contain most if not all the USB
code.  Is there anywhere else I might expect to find usbdevs*.h being
consulted, say, in the CAM source, or elsewhere outside dev/usb?
(I'm too lazy to grep, plus I'd like to hear from others who know)

DragonFly has split dev/usb into several directories like bus and
so on, so a simple `grep' won't be as easy for me, but I suspect
most changes I must make to FreeBSD will apply to DFly.


Like I say, I'm halfway through merging in OpenBSD's additions,
with the hangup that they've changed more descriptions, so I don't
know which way to go, and have set that aside to deal with other
things.


> thoughts?

Seeing `usbdevs(8)' for my mouse and audio knob, I'd go for having
fuller descriptions in usbdevs, if that's where they come from.
For those cases where the device provides the command `usbdevs'
with the strings, perhaps it's not important.  The problem is
knowing what works without, and what needs the long descriptions...

(oops, just looked at the usbdevs(4) source and it does not seem
to consult usbdevs.h/_data.h at all, unlike pciconf.  Might be
nice if it could, no?)



barry bouwsma
will spend hours poring over diffs for no good reason and food



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412241640.iBOGeH079345>