On 2020-07-02 12:37, Jan Behrens wrote:
On Thu, 2 Jul 2020 12:18:02 +0200
Hans Petter Selasky <[email protected]> wrote:
Hi Jan,
I experienced that /dev/usb/2.2.0 and /dev/usb/2.2.1, 2.2.2, 2.2.3,
etc. get treated differently when I reset the LimeSDR Mini with
"usbconfig -u 2 -a 2 reset". The devices 2.2.1 and up are supposingly
re-created (and have their access rights reset), while the device 2.2.0
maintains any manually changed access rights.
Let me explain, now you are getting me into dirty details :-)
This device is used for all of LibUSB interfaces and gives access to all
endpoints:
/dev/usb/X.Y.0
These devices are legacy devices, which allow direct access to the
endpoint via the shell. They are there to support the old user-space
model FreeBSD had. And they are re-created when you reset/reconfigure a
USB device. Actually you can "echo > /dev/usb/X.Y.N" to write directly
to an endpoint from user-space. But don't do that unless it is a modem
endpoint which support AT commands for example.
/dev/usb/X.Y.[1..15]
Are these devices there only for legacy reasons?
Yes, and we have one or two firmware loading utilities in base still
using them.
Or also for granting
access to devices via chown/chmod (or devfs.rules)? I see
that /dev/ugenX.Y are symlinks to /dev/usb/X.Y.0
For LibUSB you only need to chown/chmod /dev/ugenX.Y or /dev/usb/X.Y.0
The other utilities are usually run as root via devd scripts in base
(See /etc/devd) .
I used chown user /dev/usb/2.2.* to get access through libusb (before I
set up devfs.rules).
Technically that is fine too, but you actually only need .0 for LibUSB.
Is it correct that 2.2.0 identifies the device as a whole?
Yes, this is correct.
Then I suppose if you have access to /dev/ugenX.Y (i.e. /dev/usb/X.Y.
0), you should be allowed to reset a device.
Yes, but opening /dev/ugenX.Y doesn't mean that kernel device drivers
are detached from this device.
What do you think?
I'm not sure if this is (from a semantic point of view) the best thing
to do. I would say you should only be able to reset a device if you
have been granted access to the device as a whole (including all
interfaces/subdevices/whatever), as the reset seems to affect all of
those.
In FreeBSD and LibUSB there is no such concept. Everything is oriented
around interfaces. There is a function to claim an interface, but not
the device itself. (man libusb_claim_interface)
That means in order to reset the device itself, I need to claim an
interface, e.g. interface 0? But above you said, 2.2.0 identifies the
device as a whole (and I noted it is symlinked by /dev/ugen2.2). So I'm
a bit confused now. Is /dev/usb/2.2.0 the whole device? Or the
interface 0 of the device? Or both... haha
I think the following will clear your confusion:
FreeBSD allows multiple drivers and user-space (LibUSB) to access the
same device and USB interface, using same endpoints, at the same time!
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 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.
Was that clear?
--HPS
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
