On 10/10/13 09:38, Daniel O'Connor wrote:

On 10/10/2013, at 16:59, Hans Petter Selasky <h...@bitfrost.no> wrote:
It might under some circumstances but not directly.

It has 3 sub interfaces, if there is an error on one the the DAQ program will 
call abort() which would result in FDs being closed.

However that sub interface does not use read/poll only ioctl.

How do these IOCTLs work?

They get turned into UT_READ_VENDOR_DEVICE requests in the driver.

Do you wakeup any sleepers at "surprise" detach?

Hi,

If you use synchronous USB control requests, then those should always error out.

The usb_fifo_* code handles all wakeups so I am not sure.

The usb_fifo code only will only do refcounting. If you do USB control requests, you should use the f_ioctl_post, callback, because the f_ioctl callback does not protect against attach and detach or the enumeration thread running.

        err = (f->methods->f_ioctl) (f, cmd, addr, fflags);

        DPRINTFN(2, "f_ioctl cmd 0x%lx = %d\n", cmd, err);

        if (err != ENOIOCTL)
                goto done;

        if (usb_usb_ref_device(cpd, &refs)) {
                err = ENXIO;
                goto done;
        }

        err = (f->methods->f_ioctl_post) (f, cmd, addr, fflags);

        DPRINTFN(2, "f_ioctl_post cmd 0x%lx = %d\n", cmd, err);

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

Reply via email to