Skip to content

usb: device_next: allow to pass maximum possible MPS value to drivers #92831

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jfischer-no
Copy link
Collaborator

Allow the stack to pass the maximum possible MPS value within alternate
settings.

Add helper function to enable/disable control endpoint.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
The wMaxPacketSize (MPS) value of an endpoint may vary depending on the
interface's alternate settings. Device controller, which uses dedicated
memory for the endpoint FIFO, may end up in a locked state during
endpoint reconfiguration if the allocated memory is too small but the
higher memory window is still used. Although the driver could allocate a
new, larger memory window, the last used window would likely remain
unused, wasting a bit of dedicated RAM.

Allow the stack to pass the maximum possible MPS value within alternate
settings. For a controller with endpoint FIFOs and dedicated RAM, the
driver should use this value for the FIFO configuration.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
To ensure that the alternate endpoint setting does not result in a
memory window that is too small being allocated and locked because a
higher FIFO is still in use, use the maximum MPS value for FIFO memory
allocation.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Copy link

sonarqubecloud bot commented Jul 8, 2025

*
* @return 0 on success, all other values should be treated as error.
* @retval -ENODEV endpoint is not assigned or no configuration found
* @retval -EALREADY endpoint is already enabled
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This -EALRADY description seems wrong. It is disable function.

@AlessandroLuo AlessandroLuo removed the request for review from aaronyegx July 9, 2025 07:29
err1 = udc_ep_disable_internal(dev, USB_CONTROL_EP_IN);
err2 = udc_ep_disable_internal(dev, USB_CONTROL_EP_OUT);

return err1 ? err1 : err2;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This modifies the sequence that is performed on endpoint disable. Now the disable function will be called on both IN and OUT (before it was called first on OUT and then on IN) regardless of the returned error. Before first OUT endpoint was disabled and then IN endpoint was disabled only if OUT endpoint disable succeeded.

*
* @return 0 on success, all other values should be treated as error.
* @retval -ENODEV endpoint is not assigned or no configuration found
* @retval -EALREADY endpoint is already enabled
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like copy&paste error, if endpoint is "already enabled" then disable should succeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: USB Universal Serial Bus Experimental Experimental features not enabled by default platform: Ambiq Ambiq platform: ITE ITE platform: NXP Drivers NXP Semiconductors, drivers platform: STM32 ST Micro STM32
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants