Date: Thu, 10 Oct 2013 09:48:01 +0200 From: Hans Petter Selasky <hps@bitfrost.no> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: freebsd-usb@freebsd.org Subject: Re: USB config SX lock deadlock Message-ID: <52565BB1.8070506@bitfrost.no> In-Reply-To: <7610BC59-ED91-4807-B145-7F7DD2C725E9@gsoft.com.au> References: <9783900F-08A1-41FB-81B8-3C9809B82521@gsoft.com.au> <52553000.2010003@bitfrost.no> <A2C6A9D3-1595-41D2-A5C6-B544A3E40058@gsoft.com.au> <52554855.6030404@bitfrost.no> <FFD6BC71-0CAC-41AE-9450-6549F4B0E9C5@gsoft.com.au> <52564953.8080707@bitfrost.no> <7610BC59-ED91-4807-B145-7F7DD2C725E9@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/10/13 09:38, Daniel O'Connor wrote:
>
> On 10/10/2013, at 16:59, Hans Petter Selasky <hps@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52565BB1.8070506>