Thank you for your response. This clears up a few things.

> Currently only root/superuser can alter the enumeration state of USB, like
> attaching/detaching kernel drivers. That's why there is a PRIV_DRIVER check

Duly noted. The privilege check failure is valid, then. To me, it doesn't
seem to align with the devfs rules I mentioned, but I don't know the full
scope of PRIV_DRIVER, so I may be way off. Regarding 'currently', is this
likely to change in 11.0?

>> 2) I've patched the OpenOCD source to first check for an active driver
>> with
>> libusb_kernel_driver_active(), and only on success, attempting to detach
>> the device. Whilst this rectifies the issue -- there is no active driver,
>> ergo, no detach attempt is made and I can use the server as described with
>> su, above -- is it reasonable/necessary to do this?
> Unlike Linux, interface drivers can co-exist in userspace and the kernel
> for the same USB device, given they are not in use at the same time.
> Currently this and other user-space drivers should call
> libusb_kernel_driver_active(), but don't bail out if
> libusb_kernel_driver_active() does not succeed.
Got it. This was my solution to the issue, however, it would still require
superuser privileges to detach the device if an active driver is present,
right? The remaining approach, as far as I can see, is to run openocd with
elevated privileges, as opposed to avoid attempting to detach the device by
checking for an active driver. Not optimal, but unavoidable, I think.

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to