Conversation
…t classes Add preprocessor guards to allow customization of default line coding parameters. Summary of Changes: - Wrapped default line coding constants (RATE, STOP_BIT, PARITY, DATA_BIT) with #ifndef guards in CDC ACM, GSER, and Prolific host class headers - This allows users to define custom default values before including these headers in (ux_user.h) - Updated Prolific activation code to use DEFAULT constants instead of hardcoded values for consistency and better maintainability Files Modified: - common/usbx_host_classes/inc/ux_host_class_cdc_acm.h - common/usbx_host_classes/inc/ux_host_class_gser.h - common/usbx_host_classes/inc/ux_host_class_prolific.h - common/usbx_host_classes/src/ux_host_class_prolific_activate.c
Added missing uninitialize macro in simulator host header (HOST SIM)
Added default value protection for line coding parameters in serial Host classes
This commit cleans up header declarations by removing API and test prototypes that have no corresponding implementation in the repository. Impact: - No runtime behavior change. - Compile/link surface is cleaner and more accurate for users and tests.
* No longer using request_value to get request type.
* Removal of shift.
* Fix GET/SET_DESCRIPTOR routing for class-defined descriptor types
When a host sends GET_DESCRIPTOR or SET_DESCRIPTOR with bmRequestType
set to STANDARD but requests a class-defined descriptor type (e.g. HID
Report 0x22 or Physical 0x23), the request must be routed to the class
layer rather than handled as a standard USB request.
Per USB HID 1.11 section 7.1.1, HID stacks legitimately issue
GET_DESCRIPTOR with bmRequestType=STANDARD | INTERFACE | IN for class
descriptors. The previous fix (checking request_type != STANDARD) broke
this path: (0x81 & 0x60) == 0x00 was seen as standard and the request
would be stalled.
The new condition explicitly checks:
1. request is GET_DESCRIPTOR or SET_DESCRIPTOR
2. bmRequestType type field is STANDARD
3. bDescriptorType (high byte of wValue) is in the USB-IF class-reserved
range 0x21..0x2F
Requests with bmRequestType already set to CLASS or VENDOR, and standard
descriptors (bDescriptorType < 0x21, e.g. BOS 0x0F) or vendor descriptors
(>= 0x40), are left unchanged and follow their normal dispatch path.
Also fix (UINT) to (ULONG) cast, matching the declared type of request_type.
Suggested-by: ABOUSTM <https://github.com/ABOUSTM>
---------
Co-authored-by: Frédéric Desbiens <frederic.desbiens@eclipse-foundation.org>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…col get/set API (#244) This pull request adds host-side HID API functions to get and set the HID protocol (boot vs. report mode), and introduces an optional device-sidecallback invoked when the protocol changes. New features - Added host-side APIs ux_host_class_hid_protocol_set() and ux_host_class_hid_protocol_get() with error-checking wrappers (_uxe_ variants). - Added optional device-side callback ux_device_class_hid_set_protocol_callback, invoked when the host changes the active protocol. - Added a comprehensive test to verify the new protocol callback functionality. Bug fixes (host-side protocol get/set) 1. DMA buffer safety (protocol_get): The received byte is now written into a cache-safe allocated buffer instead of the caller's USHORT* directly. Stack memory is not DMA-safe on cache-incoherent embedded targets, and writing 1 byte into a USHORT* yields incorrect results on big-endianplatforms. Follows the same pattern as ux_host_class_hid_idle_get. 2. Missing device protection semaphore (both functions): In RTOS mode, ux_device_protection_semaphore is now acquired before submitting the transfer, in addition to the HID instance semaphore. All other HID control transfer functions (idle_get, idle_set) take both semaphores; omitting it allowed concurrent callers to corrupt the shared transfer_request fields. 3. Missing standalone locking (both functions): Added proper UX_HOST_STANDALONE support using UX_DISABLE/UX_RESTORE to atomically check and setUX_HOST_CLASS_HID_FLAG_LOCK and UX_DEVICE_FLAG_LOCK, and set UX_TRANSFER_FLAG_AUTO_DEVICE_UNLOCK + UX_TRANSFER_STATE_RESET on the transfer request before initiating. Follows the idle_get inline standalone pattern. Co-authored-by: Frédéric Desbiens <frederic.desbiens@eclipse-foundation.org> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Two issues discovered while reviewing and fixing thread-safety issues in the new ux_host_class_hid_protocol_get/set functions (PR #244). 1. idle_get.c: wrong operator acquires no lock in standalone mode Line 104 used '&= ~UX_HOST_CLASS_HID_FLAG_LOCK' (the release/clear operation) instead of '|= UX_HOST_CLASS_HID_FLAG_LOCK' (acquire/set). The preceding check correctly returns UX_BUSY when the flag is set, but the follow-on line then immediately clears it instead of setting it. The net effect is that the HID instance is never actually locked in UX_HOST_STANDALONE mode, making the mutual-exclusion check a no-op. 2. idle_set.c: standalone path used a blocking spin-loop The standalone branch called _ux_host_class_hid_idle_set_run() in a do/while loop, blocking the caller until the transfer completed. This is inconsistent with every other inline HID control-transfer function (idle_get, report_get, report_set, protocol_get, protocol_set) which all use the direct UX_DISABLE/UX_RESTORE atomic flag pattern and return UX_BUSY if the instance or device endpoint is already locked. Replaced with the same inline standalone locking pattern used by the other functions: atomic HID FLAG_LOCK acquire, atomic DEVICE_FLAG_LOCK acquire with AUTO_DEVICE_UNLOCK + UX_TRANSFER_STATE_RESET, and an AUTO_WAIT check at completion consistent with idle_get behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix(hid): Store client instance per-device instead of per-class * Address review feedback on per-instance HID client copy Three issues fixed, discovered during maintainer review: 1. Memory leak in standalone activation error path (entry.c): _ux_host_class_hid_client_activate_wait() set hid_client to NULL without freeing the per-instance copy allocated in client_search. The HID_ENUM_ERROR handler destroys the hid struct without freeing hid_client, so the copy was leaked on every standalone activation failure. Fixed by freeing hid_client before clearing it. 2. Variable declared inside if-block (client_search.c): hid_client_instance was declared inside the if (status == UX_SUCCESS) block, which is a C99 feature. USBX targets C89/C90 embedded toolchains. Moved to the top of the function with other locals. 3. Trailing whitespace throughout both changed files: The PR introduced trailing spaces on most comment-block lines. Reverted all affected lines to their original whitespace. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Frédéric Desbiens <frederic.desbiens@eclipse-foundation.org> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…control client lifecycle (#265) PR #262 introduced per-instance UX_HOST_CLASS_HID_CLIENT allocation in client_search.c. However, keyboard/mouse/remote_control activate handlers already embed a UX_HOST_CLASS_HID_CLIENT inside their own combined allocation (e.g. UX_HOST_CLASS_HID_CLIENT_KEYBOARD), override hid->hid_client with the embedded copy, and then free the entire combined struct (as 'keyboard_instance', the first field) during deactivation. This created two bugs: 1. Memory leak: the per-instance copy from client_search was abandoned when activate handlers replaced hid->hid_client with their embedded copy. 2. Double-free / UX_MEMORY_CORRUPTED: deactivate.c freed hid->hid_client after calling the handler, but for keyboard/mouse/remote_control the deactivate handler had already freed the entire combined allocation (which contains the embedded hid_client), causing a second free of a pointer into the middle of a now-freed block. Fix: - keyboard/mouse/remote_control activate: free the per-instance copy from client_search before overriding hid->hid_client with the embedded one. - keyboard/mouse/remote_control deactivate: null hid->hid_client after freeing the combined struct, signalling that cleanup is done. - deactivate.c: re-check hid_client != NULL after calling the handler before freeing; keyboard/mouse/remote_control will have nulled it, simple clients will not. - keyboard/mouse ACTIVATE_WAIT error paths (standalone): null hid->hid_client after freeing the combined struct so that the generic cleanup in entry.c skips the already-freed pointer. - entry.c standalone ACTIVATE_WAIT error: guard the free with a NULL check to safely handle both cases. Discovered while investigating test failures introduced by PR #262. All 430 tests pass after this fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Updated version number constants * Updated port version strings --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Applied the standard MIT license header to all project-owned C, header, assembly, shell, and Python files that were missing a copyright notice. Third-party, toolchain startup, and auto-generated files were excluded. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
No description provided.