On Monday 25 December 2006 17:52, Hans Petter Selasky wrote: > 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? I'm not sure. I'd like to make some headway at least by the first since I don't know how much time I'm going to have after then.
-- Anish Mistry [EMAIL PROTECTED] AM Productions http://am-productions.biz/
pgpYp3DeRUc0c.pgp
Description: PGP signature
