On 9/25/26 10:17 AM, Mattijs Korpershoek wrote:

Hello Mattijs,

On Thu, Sep 24, 2026 at 23:14, Marek Vasut <[email protected]> wrote:

On 9/7/26 10:47 AM, Mattijs Korpershoek wrote:

Hello Mattijs,

Thank you for the patch.

On Thu, Sep 03, 2026 at 04:02, Marek Vasut <[email protected]> wrote:

After fsg_unbind() is called on UMS teardown, the fsg_main_thread()
which also invokes handle_exception() is unlikely to run afterward.
Therefore, any exceptions raised in fsg_unbind(), and also exceptions
raised in fsg_common_release() which is called from both fsg_unbind()
and fsg_common_init() fail path, will remain unhandled.

This leads to a problem where FSG_STATE_TERMINATED/EXIT handling is
not performed on UMS exit and the do_set_interface(..., NULL) which
shuts down endpoints is also not performed, leaving the endpoints
enabled.

The CI UDC driver does check for repeated enablement of endpoints and
returns -EBUSY if an endpoint is enabled repeatedly. That prevents
UMS from being started after it was exited once already. That is,
running "ums 0 mmc 0 ; ums 0 mmc 0" on U-Boot command line will lead
to one successful and one failed UMS session. The later session ends
up triggering fsg_is_set() assertion in fsg_setup() and triggers a
panic().

Fix this by synchronously invoking the do_set_interface() from both
fsg_unbind() and fsg_common_release(). That makes the unbind behave
as intended, as if the fsg_main_thread() ran after fsg_unbind() and
handled the outstanding raised exceptions.

Signed-off-by: Marek Vasut <[email protected]>

The change looks fine to me. I hard a hard time understanding why there
was not an equivalent fix in Linux.
I think it's because we have cyclic in U-Boot and real threading in the
kernel.

In any case:

Reviewed-by: Mattijs Korpershoek <[email protected]>
Maybe this could be added into 2026.10 release ?

I'm sorry, this completely dissapeared from my radar (It was not
assigned to me on patchwork).

No worries, thank you !

Reply via email to