On 23 August 2016 at 02:18, Tormod Volden <lists.tor...@gmail.com> wrote:
> On Mon, Aug 22, 2016 at 8:19 AM, Jay Aurabind wrote:
>> Hi Tormod and Steve,
>>
>> Thanks for your responses. I tried running the pyocd-gdbserver with
>> LIBUSB_DEBUG=9, and got the following[snipped]:
>>
>> libusb: debug [libusb_open] open 2.1
>> libusb: error [_get_usbfs_fd] libusb couldn't open USB device
>> /dev/bus/usb/002/001: Permission denied
>> libusb: error [_get_usbfs_fd] libusb requires write access to USB device
>> nodes.
>> libusb: debug [libusb_open] open 2.1 returns -3
>> uncaught exception: The device has no langid
>> Traceback (most recent call last):
>>
>> The device 1 on bus 2, is actually the root hub - the output of lsusb
>> -v -s2:1 is:
>
> I am a bit confused here, did you really want to manipulate the root
> hub with pyusb, or did something go wrong here?
>
Absolutely not, only reason I wanted to try giving write permission to
that device, which happens to be the root hub was because that's the
only permission error I see in the LIBUSB debug messages, as you can
see from the logs I showed. If I run pyusb as root, I do not see those
permission errors.
I suspect that pyusb reads certain data commonly for all available
devices, may to figure out whether that is really the device it needs
to work on ?
>>
>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Device Descriptor:
>> bLength 18
>> bDescriptorType 1
>> bcdUSB 2.00
>> bDeviceClass 9 Hub
>> bDeviceSubClass 0
>> bDeviceProtocol 0 Full speed (or root) hub
>> bMaxPacketSize0 64
>> idVendor 0x1d6b Linux Foundation
>> idProduct 0x0002 2.0 root hub
>> bcdDevice 4.06
>> iManufacturer 3 Linux 4.6.6-300.fc24.x86_64 ehci_hcd
>> iProduct 2 EHCI Host Controller
>> iSerial 1 0000:00:1d.0
>> bNumConfigurations 1
>
> (Obviously the underlying hardware was not made by the Linux
> Foundation, the kernel usb stack just presents the root hub like it
> would be yet another USB device.)
>
> A "device" like this will be grabbed by the kernel (ehci_hcd driver).
> More generally it can happen per USB interface of the device and each
> can be claimed by its own driver.
>
> The same would be the case for e.g. a USB mass storage device. The
> relevant kernel driver will grab it exclusively, and you won't get
> permissions to write to it, whatever the file permissions on the
> corresponding USB device node.
>
> Some devices can be released from the kernel, and then be available
> for you to manipulate it through the device node (and thus via e.g
> libusb and pyusb). See for instance the libusb_detach_kernel_driver()
> function in libusb. However, in most cases people use libusb and pyusb
> to access devices that have no kernel driver.
In that case, even the root should not be able to write to those
devices, since its exclusively managed by kernel. Then how come I get
no errors when I run pyocd with root permissions ?
>
>> But even after adding the following rule to udev, I am still getting
>> the permission error:
>>
>> ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="1d6b",
>> ATTRS{idProduct}=="0003", MODE="0666", GROUP="plugdev"
>> ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0d28",
>> ATTRS{idProduct}=="0204", MODE="0666", GROUP="plugdev"
>>
>> I tried with both with and without GROUP="plugdev" because the group
>> didnt really exist in my (Fedora 24) distro. Although I created the
>> group and added myself to it, and rebooted.
>
> (You can of course use any group that you are member of.)
>
> Regards,
> Tormod
>
> ------------------------------------------------------------------------------
> _______________________________________________
> pyusb-users mailing list
> pyusb-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
--
Thanks and Regards,
Aurabindo J
------------------------------------------------------------------------------
_______________________________________________
pyusb-users mailing list
pyusb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyusb-users
