On Fri, 2019-07-05 at 14:28 -0400, Alan Stern wrote:
> On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
>
> > (following our conversation)
> >
> > Here's a completely untested alternative patch (it replaces my previous
> > one) that fixes it a bit differently.
> >
> > This time it should handle
On Fri, 2019-07-05 at 10:30 -0400, Alan Stern wrote:
> I haven't looked at the new patches yet.
>
> Still, what I originally had in mind for this situation was that the
> _last_ event should always take precedence. This goes against the idea
> of having separate FSG_STATE_* levels for disconnec
On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
> (following our conversation)
>
> Here's a completely untested alternative patch (it replaces my previous
> one) that fixes it a bit differently.
>
> This time it should handle the case of a disconnect happening
> before we have dequeued a confi
On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:
> On Fri, 2019-07-05 at 10:49 +, EJ Hsu wrote:
> >
> > Yes, looks like we are facing the same issue.
> >
> > The change of Ben is similar to mine, but the priority of
> > FSG_STATE_CONFIG_CHANGE in his patch is higher than FSG_STATE_CONFIG_C
(following our conversation)
Here's a completely untested alternative patch (it replaces my previous
one) that fixes it a bit differently.
This time it should handle the case of a disconnect happening
before we have dequeued a config change.
This assumes that it's correct to never call
usb_compo
On Fri, 2019-07-05 at 10:49 +, EJ Hsu wrote:
> The change for my previous patch is as follows, and it works well on my local
> test.
>
> Thanks,
> EJ
>
> diff --git a/drivers/usb/gadget/function/f_mass_storage.c
> b/drivers/usb/gadget/function/f_mass_storage.c
> index 982c3e8..b5f1e1e 10064
On Fri, 2019-07-05 at 10:49 +, EJ Hsu wrote:
>
> Yes, looks like we are facing the same issue.
>
> The change of Ben is similar to mine, but the priority of
> FSG_STATE_CONFIG_CHANGE in his patch is higher than FSG_STATE_CONFIG_CLEAR.
> So, it will not hit the USB CV TD 9.13 failure as above
Alan Stern wrote:
> On Thu, 4 Jul 2019, EJ Hsu wrote:
>
> > Based on my initial debugging, USB CV TD 9.13 will consecutively set device
> to configuration #1 by sending "Set Configuration" transfer.
> > So, in set_config() function, it will try to disable each interface first
> > and then
> set u
On Thu, 4 Jul 2019, EJ Hsu wrote:
> Based on my initial debugging, USB CV TD 9.13 will consecutively set device
> to configuration #1 by sending "Set Configuration" transfer.
> So, in set_config() function, it will try to disable each interface first and
> then set up each interface. That is, th
Based on my initial debugging, USB CV TD 9.13 will consecutively set device to
configuration #1 by sending "Set Configuration" transfer.
So, in set_config() function, it will try to disable each interface first and
then set up each interface. That is, the fsg_disable() will be called first and
t
EJ Hsu wrote:
> Thinh Nguyen wrote:
> > Alan Stern wrote:
> >> On Tue, 2 Jul 2019, Thinh Nguyen wrote:
> >>
> >>> Hi,
> >>>
> >>> Alan Stern wrote:
> On Fri, 10 May 2019, EJ Hsu wrote:
>
> > This change is to fix below warning message in following scenario:
> > usb_composite_setup
Thinh Nguyen wrote:
> Alan Stern wrote:
>> On Tue, 2 Jul 2019, Thinh Nguyen wrote:
>>
>>> Hi,
>>>
>>> Alan Stern wrote:
On Fri, 10 May 2019, EJ Hsu wrote:
> This change is to fix below warning message in following scenario:
> usb_composite_setup_continue: Unexpected call
>
>>>
On Tue, 2 Jul 2019, Thinh Nguyen wrote:
> Hi,
>
> Alan Stern wrote:
> > On Fri, 10 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()
Hi,
Alan Stern wrote:
> On Fri, 10 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
On Fri, 10 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, a
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
16 matches
Mail list logo
