1.3.0 Release (May 2018)

This release addresses a few open issues with the driver and adds a mitigation for cameras that error when the control endpoints are reset.

• Control channel endpoint stalling behavior change

  • Previously we would always reset the control channel endpoints when initializing the control channel (currently for EHCI only, see note below)
    • While this is explicitly supported by the USB3 Vision specification, I have observed that some cameras (from Pleora, AVT, Basler, SVS-Vistek, and other vendors) sometimes don't respond well to control endpoint stalls.
  • Now we only reset the control channel endpoints when we're in an error case.
    • We use endpoint stalling to stop a device while it's processing or to connect to a device without knowing its state. Once we've stalled and cleared the endpoint, we can guarantee that the device is in a known, good state. In the case of the stream and event channels, there is only a single, unidirectional endpoint. Since we are receiving asynchronous streaming data, stalling allows us to make absolutely certain that we stop things correctly and won't potentially get stale data later.
    • Stalling in the general case seems less necessary on the control channel, since there should always be synchronous 2-way communication which makes it much harder to get in a bad state.
  • Note that this change only currently affects the EHCI driver since endpoint stalling is still broken and therefore disabled for xHCI.

• issue #1 : calculate_sglist_entries bug

  • mretallack discovered a bug in this calculation and provided a patch to resolve the issue.
  • This patch was incorporated.
  • Finer details:
    • Whenever we're creating a scatter-gather list, we want to create an entry for the largest segment of contiguous memory that we can. In the typical ("sg_constraint") case, these entries need to be w_max_packet_size aligned, except for the first and last entry.
    • For this reason, we need to round down to the nearest multiple of w_max_packet_size if we have more than that we're trying to transfer. mretallack identified an issue where we were checking if we should round based on the total bytes remaining instead of the total contiguous bytes that we want to transfer. The "if" logic is wrong, but the rounding part has the right variables, which means that you theoretically could end up having pglist_bytes_remaining > w_max_packet_size but bytes_to_transfer < w_max_packet_size and decide to round down, but then end up rounding bytes to transfer down to 0. This would cause a hang in the kernel since our loop would never be able to terminate.
    • The patch he provides just replaces pglist_bytes_remaining with bytes_to_transfer in the "if" logic, which I agree with. However, we should never be in that case described above unless it's the first segment. If we request a big chunk of memory and are not splitting it into segmented transfers (segmented transfers are disallowed in the sg_constraint case), we should get full pages of memory other than the first and last one. Other than in the first segment, it shouldn't be possible to have a contiguous chunk of memory smaller than w_max_packet, yet have more than w_max_packet bytes left to transfer. Therefore, we get lucky with the bug in the case of the last segment since the bytes_to_transfer and pglist_bytes remaining should be the same. In my specific setup with usermode code, I also get lucky in the case of the first segment since we allocate page-aligned buffers. To clarify these requirements, I also added logic to error out if we ever are in the case where we are not w_max_packet aligned and it's not the first or last segment.

• issue #2 : kernel panic can occur with cameras without an event interface

  • Pasam reported an issue where the driver incorrectly tried to use an uninitialized mutex in the case where an event channel was not present.
  • Even if the optional stream and event channels aren't present, we still need these mutexes to be initialized so we can properly handle ioctl calls and push the error-handling logic down to the interface classes as intended.

• Update driver to compile on kernels at least up to 4.9

  • issue #3 : octal check fails on newer kernels
    • Ensure no attributes are world-writable
  • Ensure xhci host controller is correctly identified by checking against both "xhci_hcd" and the newer "xhci-hcd" strings
  • Update code to support new signature for get_user_pages
    • A new patch changes the way the write and force parameters are passed to get_user_pages in order to make the use of FOLL_FORCE explicit. Since we were passing 1 for write and 0 for force, we now just need to pass the flag for FOLL_WRITE in the flags field instead.

• Miscellaneous minor updates

  • Fix formatting issues in u3v_event.c
  • Remove misleading debug print when verifying ack buffer size