-
Notifications
You must be signed in to change notification settings - Fork 14
usb: Adapt drivers to events API #546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @adamgreloch, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
This pull request adapts the USB drivers (specifically umass and usbacm) to use the new events API. The changes involve modifying the umass_handleInsertion and usbacm_handleInsertion functions to accept a usb_event_insertion_t argument. The code now sets the deviceCreated flag to true and copies the device path to the devPath field of the event structure. This allows the system to track when a USB device has been successfully created and its corresponding path.
Highlights
- API Adaptation: Adapts the
umassandusbacmdrivers to the new USB events API. - Event Handling: Modifies the insertion handling functions to populate the
usb_event_insertion_tstructure with device creation status and path information. - Device Path: Copies the device path to the event structure, enabling tracking of the device's location in the filesystem.
Changelog
- storage/umass/umass.c
- Modified
umass_handleInsertionto acceptusb_event_insertion_t *event. - Set
event->deviceCreated = trueafter successful device creation. - Copied the device path to
event->devPath.
- Modified
- tty/usbacm/usbacm.c
- Modified
usbacm_handleInsertionto acceptusb_event_insertion_t *event. - Set
event->deviceCreated = trueafter successful device creation. - Copied the device path to
event->devPath.
- Modified
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
A USB's gentle hum,
Events trigger, code becomes,
A digital dance.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request adapts the USB drivers to use the events API, which is a good step towards a more robust and flexible USB subsystem. The changes involve modifying the umass and usbacm drivers to handle device insertion events using the new API. Overall, the changes seem reasonable, but there are a few areas that could be improved.
Summary of Findings
- Missing error handling: The code does not check the return value of
memcpyinumass_handleInsertionandusbacm_handleInsertion. This could lead to unexpected behavior if the copy fails. - Incomplete event handling: The code only sets
deviceCreatedtotrueand copies the device path. It might be beneficial to add more information to the event, such as the device's vendor and product IDs.
Merge Readiness
The pull request introduces a new feature and seems generally well-implemented. However, the missing error handling in memcpy should be addressed before merging. I am unable to directly approve this pull request, and recommend that others review and approve this code before merging. At a minimum, the high severity issues should be addressed before merging.
da8c492 to
60b9bb5
Compare
5f84742 to
83811e6
Compare
c255d65 to
231c560
Compare
231c560 to
1ec06a0
Compare
1ec06a0 to
a02664c
Compare
578cce0 to
f95532c
Compare
JIRA: RTOS-1024
JIRA: RTOS-1024
JIRA: RTOS-1024
f95532c to
104d982
Compare
…e insertion Mutex was still locked when returning after error from umass_handleInsertion JIRA: RTOS-1024
JIRA: RTOS-1024
JIRA: RTOS-1024
104d982 to
8a8db8d
Compare
Description
Motivation and Context
Types of changes
How Has This Been Tested?
Checklist:
Special treatment
usb: Notify apps about usb device insertion phoenix-rtos-usb#36