1.3.3 Release (February 2023)

This release has a compatibility fix for Linux Kernels 6.5 and later

Fix #1 - Fix to build with Linux version 6.5 and later

• get_user_pages function prototype was changed in the following Linux kernel commit:
  remove unused vmas parameter from get_user_pages() - Commit 54d0206
  torvalds/linux@54d0206

1.3.2 Release (February 2022)

This release has compatibility fixes for newer Linux Kernels and a bug fix regarding u3v request_id overflow.

Fix #1 - Kernel 5.10 compatibility

• With kernel 5.10 and up mmap_sem was removed and intended to be replaced with mmap_lock
• Added logic in our code to check kernel version and use the appropriate locking mechanism

Fix #2 - Request_ID overflow back to 1

• Every write command we send increases the request_id by 1 and in the case were we overflow we go back to 0 which isn't allowed
• Introduced logic to loopback to 1 after the first overflow

No other features or bug fixes were introduced in this release.

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

1.2.0 Release

This release added (experimental) support for segmented transfers, improved handling of user memory, and fixed a few issues. Below is a brief summary of the changes:

* Fixed issue with corruption at the end of an image on ARM when DMA transfer size is 
    not cache aligned

* Fixed issue with IDS cameras at USB 2.0 speeds
    * Set required leader and trailer size to wMaxPacketSize instead of 1024

* Fixed kernel oops when opening camera on Broadwell processors
    * Broadwell has a new security feature called Supervisor Mode Access Prevention (SMAP),
        which prevents directly accessing user memory from the kernel.
    * This update fixes a bug where user memory was being checked and then directly accessed.
    * It also adds code to make it more clear which memory is user memory and which belongs
        to the kernel.

* Added support for segmented transfers:

With this feature enabled, the user can pass in a buffer that is not virtually contiguous. The intended use case for this is an image buffer with a border around the image. The buffer in memory would then have some set amount of padding between each line, but the driver would allow the camera to DMA to this memory directly while accounting for the border.
During development we found issues with both Renesas and Intel host controllers that caused the xHCI driver to get in an unrecoverable state. On Renesas, the problem only occurred with smaller line sizes (stride less than 192 bytes). On Intel, this issue was not characterizable enough to work around. After I contacted Intel support, they informed me that this feature will not be supported until Cannon Lake. For now, this feature is experimental and is disabled by default. It can be enabled by toggling the segmented_xfer_enabled sysfs attribute.

1.1.0 Release

The 1.1.0 release did not add any major features, but improved error handling, memory management, and fixed some known issues. Below is a general list of some changes made:

* Improved error handling and cleanup
* Improved plug and play reference counting and memory management
* Added error checking to handle when device is unplugged during sysfs read
* Fixed sysfs attributes bug where a read could potentially return bad data
* Improved scatterlist construction to handle architectures that don't support chaining

1.0.0 Release

Initial release of high performance USB3 Vision driver that reduces CPU utilization.