Date: Mon, 25 Dec 2006 23:52:00 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: amistry@am-productions.biz, freebsd-usb@freebsd.org Subject: Re: Attaching ugen to all usb devices Message-ID: <200612252352.01377.hselasky@c2i.net> In-Reply-To: <20061225.133821.-1605839720.imp@bsdimp.com> References: <200612251456.42770.amistry@am-productions.biz> <20061225.133821.-1605839720.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 25 December 2006 21:38, M. Warner Losh wrote: > In message: <200612251456.42770.amistry@am-productions.biz> > > Anish Mistry <amistry@am-productions.biz> writes: > : Many usb devices can be attached as different devices along with > : being functional with some libusb app that requires ugen. > : eg. HP PSC Printers will attach as ulpt, if ulpt isn't loaded umass > : can attach to access the card slot, if neither of these are loaded > : ugen will attach which is required to run the hplip vendor software > : so that the printer, scanner, and fax machine can be accessed. > > You should review how the device presents itself to the system. If > both umass and ulpt attach to it, it should be possible to make them > both attach at the same time. > > As for ugen, one could easily hack uhub to allow this kind of access. > ugen really shouldn't be attaching to any device at all, but instead > the usb bus (aka uhub) should allow ugen-like acess to each of the > devices. Right. Here are some pointers: The core of your problem is "usbd_set_config()". Whenever you set a new config value, you need to "device_delete_child()" all attached devices, and re-probe the "struct usbd_device *" in question. Maybe you can extend the already existing "usbd_remove_detached_devices()"? Try making a system where the USB device config value is always set from "usbd_probe_and_attach()", hence this function is always called from only one thread at a time! To force the system to re-call "usbd_probe_and_attach()", simply set "up->last_refcount = 0", then call "usb_needs_explore()". "up" is of type "struct usbd_port *". Maybe you should add a new field: udev->current_config_value. When "udev->probed == USBD_PROBED_SPECIFIC_AND_FOUND" disallow "/dev/ugenX" from setting the config value. Incorporate parts of ugen into "struct usbd_device": 1) Split ugen into two parts, /dev/ugenX and /dev/ugenX.X . 2) /dev/ugenX is created by "usbd_new_device()". 3) /dev/ugenX is removed by "usbd_free_device()". 4) /dev/ugenX.X is a regular device that attaches when "uaa.iface != NULL" and "uaa.usegeneric == 1". Maybe you have to remove "USBD_PROBED_GENERIC_AND_FOUND". There should be no problems in the USB stack regarding duplicate device attachment. If two devices start a transfer on the same interrupt endpoint, they will be served alternately, for example. > > : It would be very helpful to allow ulpt, umass, and ugen to all attach > : to the device. This would allow full functionality. Simultaneous > : access isn't necessary, but might be nice in the future. > > That would be a nightmare. Trust me. I've looked into it in the past > it was scary. Better switch the config value, so that the devices show up one by one. > > : The closest thing I can think of that allows similar behavior is > : vgapci that allow acpi_video and a drm driver to both access the > : video card. > > Well, it doesn't really. newbus has a very strong notion of each node > in the tree has one and only one (or zero) devices attached. When do you think that you will have some patches ready? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612252352.01377.hselasky>