USB reset fails when using a LimeSDR Mini on FreeBSD

[Hans Petter Selasky]

Hi Jan,

On 2020-07-03 09:51, Jan Behrens wrote:
>>
>> Yes, and we have one or two firmware loading utilities in base still
>> using them.
> 
> Except that /dev/usb/X.Y.0 (which is linked by /dev/ugenX.Y) controls
> access rights to the device through libusb, right?

Yes, that is correct.

>>
>> Yes, but opening /dev/ugenX.Y doesn't mean that kernel device drivers
>> are detached from this device.
> 
> Can/does a kernel device driver restrict what a user can do with the
> device when the kernel driver is active? Or does access to the device
> always enable a user to mess up things badly?

The kernel device driver can not restrict what the user-space driver can 
do. Yes, user-space can mess up the device totally.

>>
>> User-space drivers are requested to create a uniq PID file, to avoid
>> clashes with multiple drivers on the same interface and may use
>> libusb_claim_interface() to tell the kernel to detach any drivers on
>> that specific interface.
> 
> If the kernel refuses to give up control, is the user-space program
> denied access? If yes, I can generally understand why you don't want a
> USB reset to be initiated by a user-space program (at least as long
> there are kernel drivers attached).
The FreeBSD USB stack has no concept of exclusive access to USB 
endpoints. Simply if both kernel and user-space attach to the same 
device, user-space will receive half of the USB packets and the kernel 
the other half.

>> If you for example load the LimeSDR two times for the same ugenX.Y
>> device, then the interface communication might stop working, even though
>> no error is reported.
> 
> Thus the lock of user-space drivers is only advisory and not enforced?

Right, it is not enforced.

> How about if a kernel driver uses the device? Can/does the kernel block
> out a user-space driver that would mess with the kernel's operation on
> the device?

No, it is all transparent. Kernel drivers cannot block user-space, but 
user-space can detach kernel-space. That's all.

> 
> I see three possible approaches currently:
> 
> 1. Allowing a USB reset if the user has access to /dev/ugenX.Y (might
>     allow users to mess with kernel's operation on a device, unless the
>     problem exists anyway, see my questions above).
> 
> 2. Allowing a USB reset if the user has access to /dev/ugenX.Y and
>     there are other prerequirements fulfilled (e.g. a sysctl setting to
>     enable it globally, which might not be fine-graded enough, or the
>     requirement that there is currently no kernel driver attached, or a
>     combination thereof).
> 
> 3. Providing a way to grant "reset permissions" on a per-device basis
>     (might be overkill, and not really needed).
> 

Maybe you're right we should allow this for non-root aswell. I need to 
think about it!

--HPS