Date: Mon, 04 Dec 2006 16:21:48 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@freebsd.org Cc: perforce@freebsd.org Subject: Re: PERFORCE change 110969 for review Message-ID: <20061204.162148.-300783081.imp@bsdimp.com> In-Reply-To: <200612031915.kB3JFLbh077129@repoman.freebsd.org> References: <200612031915.kB3JFLbh077129@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200612031915.kB3JFLbh077129@repoman.freebsd.org>
Hans Petter Selasky <hselasky@freebsd.org> writes:
: http://perforce.freebsd.org/chv.cgi?CH=110969
:
: Change 110969 by hselasky@hselasky_mini_itx on 2006/12/03 19:14:41
:
: Fix a bug in the uplcom probe routine where a revision of 0xFFFF
: was not treated as a special value. The old version of uplcom.c has
: the check, so probably a misunderstanding happened.
:
: Affected files ...
:
: .. //depot/projects/usb/src/sys/dev/usb/uplcom.c#14 edit
:
: Differences ...
:
: ==== //depot/projects/usb/src/sys/dev/usb/uplcom.c#14 (text+ko) ====
:
: @@ -424,7 +424,8 @@
: while(up->vendor) {
: if ((up->vendor == uaa->vendor) &&
: (up->product == uaa->product) &&
: - (up->release <= uaa->release)) {
: + ((up->release <= uaa->release) ||
: + (up->release == 0xFFFF))) {
: return up;
: }
: up++;
What really needs to happen here is that we probe the plcom chip for
its properties, ala the linux driver rather than having a fixed (and
often wrong) table of hard codings. I looked into this a while ago,
but got distracted...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061204.162148.-300783081.imp>