On Monday 25 December 2006 21:38, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > Anish Mistry <[EMAIL PROTECTED]> 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 _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
