Merge refined libusb-1.0+0.1 branch into NUT master #1254
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Starting with the configure checks, to detect if libusb 1.0 if available, and otherwise fall back to the libusb 0.1 backend
The port to libusb 1.0 is now complete for usbhid-ups. Other USB drivers (bcmxcp_usb, blazer_usb, nutdrv_atcl_usb, richcomm_usb, riello_usb, tripplite_usb, nutdrv_qx) have still to be addressed
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
NUT internal header "libusb.h" was renamed, since it collides with the libusb 1.0 header, which has the same name. A few occurences of reference and documentation were however missing
libusb 1.0 provide its own routine for detaching kernel driver
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
usb_strerror was not remapped for libusb 0.1 implementation
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
The port to libusb 1.0 is complete, at least from a build perspective. This now needs to be tested with devices
A few symbols from libusb 1.0 were wrongly used directly, instead of being looked up and loaded at init time
libusb 1.0 has its own set of return codes, and error interface. Rework the common HID core (shared between usbhid-ups and mge-shut) so that error handling can work with both, and using either libusb 0.1 or 1.0 for usbhid-ups
bus publication was wrongly listing both the bus and the portname, instead of the bus only. This may have caused some issue when trying to match the port
For libusb 0.1 implementation, we had to workaround a libusb API goofs, by wrapping the base function usb_control_msg(), and casting the variables to the right type. This is not needed for libusb 1.0 implementation, but was wrongly left in the code (reported by Charles Lepple)
libusb 1.0 has introduced a new function (libusb_set_auto_detach_kernel_driver), beside from the explicit kernel driver detachment request (libusb_detach_kernel_driver). However, the former is not available on all systems. As an example, FreeBSD 10.1-10.3 does not have this. The detachment and interface claiming has been reworked to handle this case (reported by Charles Lepple) Reference: #300
Following the recent modification for the kernel driver detachment, and the related functions availability depending on the platforms, nutdrv_atcl_usb and richcomm_usb were using the wrong macro for libusb_set_auto_detach_kernel_driver and were missing the libusb 1.0 code for explicit kernel driver detachment Reference: #300
usb_set_altinterface allows to force the USB code to call `libusb_set_interface_alt_setting (0, 0)` (equivalent to `libusb_set_altinterface(0)` in libusb 0.1), as was done in NUT 2.7.2 and earlier. However, the libusb 1.0 implementation was still missing the related code Reference: #300
With the port to libusb 1.0, a sanity check was done on the available number of USB devices to try. This however caused a behavior regression, since the only device that NUT may have access to can be the only UPS connected. In this case, the driver may exit upon trying to reconnect if the device is transiently not available Reference: #300
libusb 1.0 returns on success, the number of bytes actually transferred or otherwise an error code, except for interrupt transfers, where the actual transfer size is stored in a separate variable. The libusb 1.0 implementation in NUT thus needed to be fixed to behave the same way than the libusb 0.1 implementation Reference: #300
Per <http://libusb.sf.net/api-1.0/group__dev.html#ga8163100afdf933fabed0db7fa81c89d1>, the handle is only populated when the return code is 0. This fixes a crash during device detection where more than one HID UPS is available, and the driver needs to skip the first one.
…g uses of (lib)usb_strerror with nut_usb_strerror()
…atible-pointer-types-discards-qualifiers
…_detach_kernel_driver_np (0.1)
…omm_usb.c: honor that libusb-1.0 may HAVE_LIBUSB_DETACH_KERNEL_DRIVER_NP
…chcomm_usb.c: only apply usb_detach_kernel_driver_np to libusb-0.1 builds (no alias tricks)
… int types to backend API dependent "usb_ctrl_*" and "usb_dev_handle" typedefs, then range-check and cast the numbers, and avoid build warnings
…on.h due to lack of WITH_LIBUSB_x_y)
jimklimov
added
USB
refactor/fightwarn
This was referenced Jan 7, 2022
|
This pull request introduces 20 alerts when merging e3cc3e6 into 92ecace - view on LGTM.com new alerts:
|
jimklimov
force-pushed
the
libusb-1.0+0.1
branch
from
9436974
to
22aca84
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses part of issue #300 by merging the evolution of "libusb-1.0+0.1" branch (after #1241) proposed as one of solutions to that issue. Another acceptable solution is in "libusb-1.0" branch which is now a sub-set of this one, posted in PR #1253 to retain all the relevant histories involved, and a further PR #1255 to clean up the remaining warnings and bump the default required baseline for code quality.
Refinements generally concern use of
xstrdup()(error-checked) instead ofstrdup(), and conversely back tomalloc()and situation-aware handling (e.g. libusb resource freeing before exiting) instead of defaultxmalloc()error-handling.Codebases have been tested in practice over X-Mas/New-Year 2021 vacations on a multitude of platforms, as discussed in the mailing lists.