On Thu, 9 May 2019, EJ Hsu wrote:
> > You forgot to change fsg_unbind() to use FSG_STATE_DISCONNECT. And when
> > that's done, it will no longer need to set common->new_fsg to NULL either.
> >
>
> Yes, we should change fsg_unbind() as well.
>
> > This is sort of a band-aid approach. The real
>
> You forgot to change fsg_unbind() to use FSG_STATE_DISCONNECT. And when
> that's done, it will no longer need to set common->new_fsg to NULL either.
>
Yes, we should change fsg_unbind() as well.
> This is sort of a band-aid approach. The real problem is that the original
> design
> of th
On Wed, 8 May 2019, EJ Hsu wrote:
> This change is to fix below warning message in following scenario:
> usb_composite_setup_continue: Unexpected call
>
> When system tried to enter suspend, the fsg_disable() will be called to
> disable fsg driver and send a signal to fsg_main_thread. However, at
This change is to fix below warning message in following scenario:
usb_composite_setup_continue: Unexpected call
When system tried to enter suspend, the fsg_disable() will be called to
disable fsg driver and send a signal to fsg_main_thread. However, at
this point, the fsg_main_thread has already
