Adding new option to limit hub by description.
Existing -s option limits by attached device description,
and new feature -H limits by hub instead.
Thanks to @pendragonsound for submitting patch!
Closes#611.
Fixed all warnings when compiling with `c++ -std=c++11 ...`:
* bzero() appears to be deprecated, replaced with memset()
* fixed few const warnings
* suppressed zero array warnings (emitted by libusb headers)
* No need to check for both __gnu_linux__ and __linux__, latter is enough.
* Require libusb 1.0.13 to build - this makes LIBUSB_API_VERSION always defined.
* Include `<libusb.h>` not `<libusb-1.0/libusb.h>` - this will always work
if `pkg-config` is detected. For backwards compatibility still try building
without `pkg-config` present, but it is much less reliable and will not work on Mac.
* Bump copyright year.
* Add --sysdev/-u option for direct device node access
Only the device specified by the given device path will be accessed,
instead of scanning the USB bus.
Most useful if you use udev rules to create stable device node aliases for hubs,
independent of bus topology.
For instance, if your matching udev rules include SYMLINK+="MYSMARTHUB1"
you can call uhubctl with --sysdev /dev/MYSMARTHUB1 instead of using -l
and a non-stable bus location to specify it.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
* Detect if we are running on Raspberry 4B or 5
* Add RPi 4B and 5 conditionals for RPi hacks
* Relax some conditions which may vary depending on RPi hardware and/or OS
(in particular Ubuntu hub numbering differs from Raspbian).
* For RPi5, changed README to suggest using busses 2 and 4 instead of 1 and 3.
This makes the same recipe work on both Raspbian and Ubuntu.
This fixes#587.
Before:
```
Current status for hub 3 [6b1d:0200 Linux 6.1.98 xhci-hcd xHCI Host Controller 0000:01:00.0, USB 0.02, 2 ports, ppps]
Port 1: 0305 power lowspeed suspend connect [9911:c068 Sierra Wireless, Incorporated MC7304-CP]
Port 2: 0301 power lowspeed connect [0304:0160 FTDI FT232R USB UART A10OEDEW]
```
After:
```
Current status for hub 1 [1d6b:0002 Linux 6.1.98 ehci_hcd EHCI Host Controller 16f0000000000.ehci, USB 2.00, 2 ports, nops]
Port 1: 0503 power highspeed enable connect [0424:2240 Generic Ultra Fast Media 000000225001]
Port 2: 0100 power
Current status for hub 3 [1d6b:0002 Linux 6.1.98 xhci-hcd xHCI Host Controller 0000:01:00.0, USB 2.00, 2 ports, ppps]
Port 1: 0503 power highspeed enable connect [1199:68c0 Sierra Wireless, Incorporated MC7304-CP]
Port 2: 0103 power enable connect [0403:6001 FTDI FT232R USB UART A10OEDEW]
```
Tested on both x86-64 and MIPS64.
Signed-off-by: Christian Svensson <blue@cmd.nu>
Recent libusb seems to have removed extra symlink `libusb-1.0/libusb.h`,
which breaks build on Mac.
TODO: consider always using `<libusb.h>`, but that would
put hard dependency on `pkg-config` usage.
Starting with Linux kernel 6.0[1] there will be a sysfs interface to power USB
ports off/on from userspace.
Try to use this interface before falling back to the usual libusb based
power switching (e.g. when running on a kernel <6.0 or if file permissions do
not allow using the sysfs interface).
The main benefit of using the sysfs interface is that the kernel does not get
confused about the state of a port, so retrying should no longer be required.
[1]: https://lore.kernel.org/all/20220607114522.3359148-1-m.grzeschik@pengutronix.de/
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Split out current libusb based power on/off logic into a separate function
in anticipation of a other power switching implementations.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Sometimes target devices may become unresponsive for control messages to read string descriptors.
Option --nodesc (-N) allows to still reset such devices.
Also, as preventative measure, check if libusb_get_string_descriptor_ascii returns any error,
then stop querying any other string descriptor from the same device.
* Simplified code that powers on/off.
* Fixed minor bug for repeat counter (always once to power off, and opt_repeat times to power on).
* Only warn about USB permissions if no compatible hubs are detected.
Old behavior would always warn, even if permissions were missing for any hub (even unsupported ones).
Add switch --search (-s) to limit hubs by attached device description.
It is recommended to specify search string that is as unique as possible, e.g. device serial number.
It should work for "off" and "cycle" actions, but not for "on" because device would not be visible on USB.
Closes#209.
Show power switching type supported by a hub:
* ppps - per-port power switching
* ganged - ganged power switching
* nops - no power switching
Add --force (-f) switch to allow operation on non-ppps hubs.
Use `-f` at your own risk, this most likely will not work to actually switch power.
For ganged hubs, you may need to turn power off for all hub ports to get any effect.
For nops hubs, it is not likely to work at all, but might be useful for informational purposes.
Also, instead of printing recipe on how to fix USB permissions on Linux,
forward user to web page with detailed explanations.
Closes#260, #280.
Use priority based duality matching.
* Support Raspberry Pi 4B better (as it has USB2 hub one level deeper than its USB3 counterpart).
* Support M1 Macs (as they seem to place all USB devices to bus 2).
* Support Apple mini-dock (it advertises 2 USB2 ports but only 1 USB3 port).
* Should support multiple identical hubs (with the same container id) on Linux.
Hack to support Raspberry Pi 4:
* Override ganged power switching reported by USB2 hub as per-port. This is not necessarily true,
but is consistent with per-port power switching returned by dual USB3 root hub.
Proper fix is for Raspberry Pi 4 USB firmware to return consistent descriptor information.
* When root USB3 hub is detected on RPi4 without ContainerID, it is assumed to have
ContainerID of dual USB2 hub, so USB2/3 duality is still working as expected.
Proper fix would be for USB3 root hub to report correct ContainerID.
Some devices (notably Raspberry 4B) have USB3 hub that advertises
its USB2 compatibility partner at different depth level.
Raspberry 4B onboard hub doesn't yet support uhubctl directly
(but it should once https://github.com/raspberrypi/linux/issues/3079 is fixed),
but this breaks level check restriction for any external USB3 hub attached to RPi4B
- so this check has been removed.
This adds support to be able to build and use uhubctl on NetBSD by using pkg-config to get proper CFLAGS and LDFLAGS.
Perhaps we should use pkg-config universally across all platforms,
but I don't want to potentially break support for existing plaftorms
because pkg-config does not seem to be unconditionally available everywhere.
I have observed a hub which had serial number present for USB2 compatibility hub,
but not for USB3, which broke USB2/3 duality handling:
Current status for hub 4-4 [0451:8140, USB 3.00, 4 ports]
Port 1: 06a0 power Rx.Detect
Port 2: 06a0 power Rx.Detect
Port 3: 06a0 power Rx.Detect
Port 4: 06a0 power Rx.Detect
Current status for hub 3-13 [0451:8142 210C08692601, USB 2.10, 4 ports]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power
This fix will only compare serial numbers if they are both present.
Per USB 3.0 spec, chapter 11.2:
> Within a USB 3.0 hub, both the SuperSpeed and USB 2.0 hub devices shall implement in the hub framework
> a common standardized ContainerID to enable software to identify the physical relationship of the hub devices.
> The ContainerID descriptor is a part of the BOS descriptor set.
* Read ContainerID from BOS descriptor.
* get_device_description() now returns struct with vendor, product, serial number as well as full description.
* Use ContainerID to improve finding dual hubs. This seems to work very well on any OS.
However, this may still fail if two or more identical hubs use the same hardcoded ContainerID
In this case, we still try to look for other clues like serial number match if possible.
This fixes issue #161.
