Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: USB drivers

2 views
Skip to first unread message

ti...@cicely12.cicely.de

unread,
Aug 4, 2004, 11:08:51 AM8/4/04
to
On Wed, Aug 04, 2004 at 10:41:50AM -0400, Chris wrote:
> The last time I programed was over 15 years ago and I was thinking of
> looking into the USB drivers for FreeBSD concerning multifunction
> devices. If I ask stupid questions forgive me because I am seeing this
> as a user.
>
> First I would like to know if there is a technical reason why two
> different divers cannot attach to the same device. If each driver works
> well independently, what is the reason to prevent the second one from
> attaching? I would assume that if you attempted to use both drivers at
> the same time you would get a device busy error.

USB devices can be designed to have multiple interfaces at which you
can have different drivers - e.g. you can have a ulpt/umass combo
and both drivers just clain the according interface from the same
device.
Therefor also drivers can be programmed for whole USB devices and for
USB subdevices.
This works perfectly with FreeBSD.

> Am I misunderstanding something here? I see ulpt: and unlpt: attaching
> to the same device and the choice of which one to use is up to the user
> and the hardware they have. If we have two drivers attach in one case
> why, and where, do we prevent other drivers from attaching if they meet
> the minimum requirements?

unlpt and ulpt are just different representations from the same driver.
There is absolutely no sense in having two clients printing at the same
time on the same printer, so blocking each other is absolutely reasonable.
Scheduling multiple requests is up to software like lpd.
See ulpt(4) for details about the functional difference in ulpt vs. unlpt
device nodes - depending on the printer you will likely end up in always
using the same devicenode.
Why do you think this is wrong?

--
B.Walter BWCT http://www.bwct.de
be...@bwct.de in...@bwct.de

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

ch...@tellme3times.com

unread,
Aug 5, 2004, 10:58:35 AM8/5/04
to
M. Warner Losh wrote:

>
>You misunerstand what's actually happening. There's no case in the
>tree where two drivers are attached, at the same time, to the same
>device node. There's only one set of pointers. However, with USB,
>there can be reasons why multiple things can attach to the same
>driver. The usb code tries to do smart things for devices that have
>multiple configurations.
>
>With USB and multi-function devices, here's the code that we use:
>
> /* First try with device specific drivers. */
> probe and attach driver with a config # of -1 (usegeneric = 0)
> return if successful
> /* Next try with interface drivers. */
> foreach valid configuration
> foreach interface
> probe and attach driver
> /* Finally try the generic driver. */
> probe and attach driver with a config # of -1 (usegeneric = 1)
> return if successful
>
>I'm not familiar with the specific instance of ulpt and unlpt.
>
>


You are right I do not understand. All I know is that when the system
boots, at some point a test is done to see if their are USB devices. If
devices exist then attach drivers.

What I am trying to determine is why my multifunction printer/scanner
receives only one of the two drivers. Is it because the printer does
not respond properly? Is it because the printer is not defined? I have
many questions here.

I looked in the following and just see the code for that specific
device. It does not test for multifunction devices. I do not see any
code that follows the logic above.

src/sys/dev/usb/ulpt.c
src/sys/dev/usb/uscanner.c
src/sys/dev/usb/usbdevs

If you can point me in the right direction, or to some documents on USB
driver writing I will try to figure this out. Any help would be
appreciated. I will get this to work because I need both and the effort
required to switch is just not convenient.

Chris

0 new messages