Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Oct 2007 23:02:25 -0700
From:      Luigi Rizzo <rizzo@icir.org>
To:        "M. Warner Losh" <imp@bsdimp.com>, fabio@gandalf.sssup.it
Cc:        cvs-src@FreeBSD.org, luigi@FreeBSD.org, src-committers@FreeBSD.org, bms@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/usb usbdevs uscanner.c
Message-ID:  <20071022230225.A75447@xorpc.icir.org>
In-Reply-To: <20071022.221749.-1844002269.imp@bsdimp.com>; from imp@bsdimp.com on Mon, Oct 22, 2007 at 10:17:49PM -0600
References:  <200710050726.l957QeMI059383@repoman.freebsd.org> <471D576C.30601@FreeBSD.org> <20071022.221749.-1844002269.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 22, 2007 at 10:17:49PM -0600, M. Warner Losh wrote:
> In message: <471D576C.30601@FreeBSD.org>
>             "Bruce M. Simpson" <bms@FreeBSD.org> writes:
> : Luigi Rizzo wrote:
> : >   Log:
> : >   Add entries for Epson multifunction scanner/printer/card readers,
> : >   with all functions supported.
> : 
> : Thanks for doing this. Any plans to MFC?

asap - in fact i have been running this code on 6.2 since late august.
 
> : I will try to test this change on 6.2 with my Epson CX-3650. Currently I 
> : have to unload uscanner and/or ulpt, and physically replug the usb cable 
> : into a different port, to switch between ulpt and uscanner functions on 
> : the device.
> 
> I've been debating a doing a mass MFC.  I've been using FreeBSD
> current's usb stack, with a couple of hacks, in -stable for a few
> weeks now.

that's also an interesting thing as it would also clean up the
codebase a bit. If re@ agrees this might be a good thing to do,
even though it might require a bit more time for code to stabilize
before 6.3 is released.

One difference that we found (not sure where it was introduced)
between -current and RELENG_6 is with the handling of usb transfers
shorter than expected - these happens e.g. with some webcams supported
by the linux-gspca driver (built using linux-kmod-compat - i know
that one doesn't build as is on -current but we have some local changes
to make it work).

Fabio Checconi (in Cc, fabio@gandalf.sssup.it) should have more details,
but in summary the situation should be as follows:
on RELENG_6, these short transfers are handled same as regular ones,
i.e. data is transfered and the caller gets a success return code;
on -current the usb stack returns an error in case it sees them
(the data phase is correct though).

cheers
luigi



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