>> On Tue, Oct 07 2014, Alan Stern wrote:
>>> If you want to allow for the possibility of orderly shutdown (and maybe
>>> even possible restart) of a userspace handler, the function library
>>> should first tell the kernel explicitly to disconnect.
> On Tue, 7 Oct 2014, Michal Nazarewicz
On Tue, Oct 07 2014, Alan Stern st...@rowland.harvard.edu wrote:
If you want to allow for the possibility of orderly shutdown (and maybe
even possible restart) of a userspace handler, the function library
should first tell the kernel explicitly to disconnect.
On Tue, 7 Oct 2014, Michal
On Tue, 7 Oct 2014, Michal Nazarewicz wrote:
> > On Tue, 7 Oct 2014, Felipe Balbi wrote:
> >> Right, but if we allow this, I can already see folks abusing to
> >> connect to the host early and only when necessary do some trickery to
> >> e.g. start adbd (not saying Android will do this, just
>> -Original Message-
>> From: Mike Nazarewicz [mailto:m...@google.com]
>> I don't really see that happening. For the gadget to start all
>> descriptors need to be known. Functionfs will know the descriptors
>> only once the user space daemon provides them. Therefore, with the
>>
ger.kernel.org; linux-
> ker...@vger.kernel.org; andrze...@samsung.com
> Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
>
> > On Tue, 7 Oct 2014, Felipe Balbi wrote:
> >> Right, but if we allow this, I can already see folks abusing to
> >> conn
...@vger.kernel.org; andrze...@samsung.com
Subject: Re: [PATCH] usb: gadget: f_fs: add zombie mode
On Tue, 7 Oct 2014, Felipe Balbi wrote:
Right, but if we allow this, I can already see folks abusing to
connect to the host early and only when necessary do some
trickery to
e.g. start adbd
-Original Message-
From: Mike Nazarewicz [mailto:m...@google.com]
I don't really see that happening. For the gadget to start all
descriptors need to be known. Functionfs will know the descriptors
only once the user space daemon provides them. Therefore, with the
current features
On Tue, 7 Oct 2014, Michal Nazarewicz wrote:
On Tue, 7 Oct 2014, Felipe Balbi wrote:
Right, but if we allow this, I can already see folks abusing to
connect to the host early and only when necessary do some trickery to
e.g. start adbd (not saying Android will do this, just using it as an
> On Tue, 7 Oct 2014, Felipe Balbi wrote:
>> Right, but if we allow this, I can already see folks abusing to
>> connect to the host early and only when necessary do some trickery to
>> e.g. start adbd (not saying Android will do this, just using it as an
>> easy example).
I don't really see that
On Tue, 7 Oct 2014, Felipe Balbi wrote:
> > If the file handle was closed for abnormal reasons, we can behave like
> > crashed firmware. Which means, in the end, doing the same thing as in
> > the normal-reason case -- i.e., do nothing. In particular, don't
> > disconnect.
> >
> > If you
Hi,
On Tue, Oct 07, 2014 at 02:42:33PM -0400, Alan Stern wrote:
> > > It seems to me that we should imitate what an ordinary USB device would
> > > do. If part of the firmware crashes, generally you would expect none
> > > of the endpoints associated with that function to work. Either they
> >
On Tue, 7 Oct 2014, Felipe Balbi wrote:
> > It seems to me that we should imitate what an ordinary USB device would
> > do. If part of the firmware crashes, generally you would expect none
> > of the endpoints associated with that function to work. Either they
> > refuse to accept output from
Hi,
On Tue, Oct 07, 2014 at 01:15:32PM -0400, Alan Stern wrote:
> > > Here also I agree. Zombie mode should "mock" the function until first
> > > next enumeration or unbind. It should not be possible to bind gadget
> > > with function in zombie mode to UDC. Zombie mode should "pretend" only
> > >
On Tue, 7 Oct 2014, Felipe Balbi wrote:
> > Please believe me that I totally agree with you, but I also see Robert's
> > point. Let's take ADB as example. Before ADB has been ported to
> > FunctionFS it communicated with kernel using dev node provided by ADB
> > function driver. With that
Hi,
On Tue, Oct 07, 2014 at 06:37:26PM +0200, Krzysztof Opasiak wrote:
[snip]
> > yeah, and the way to deal with that is disconnecting from the host
> > because that USB function, can't be functional anymore. I mean,
> > imagine you try to e.g. unload pictures from your nice DSLR and
> > that
..@mina86.com; andrze...@samsung.com
> Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
>
> Hi,
>
> On Tue, Oct 07, 2014 at 05:01:15PM +0200, Krzysztof Opasiak wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Oct 06, 201
Hi,
On Tue, Oct 07, 2014 at 05:01:15PM +0200, Krzysztof Opasiak wrote:
> > > > Hi,
> > > >
> > > > On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
> > > >> Since we can compose gadgets from many functions, there is the
> > > >> problem related to gadget breakage while FunctionFS
andrze...@samsung.com; k.opas...@samsung.com
> Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
>
> Hi,
>
> On Tue, Oct 07, 2014 at 08:33:16AM +0200, Robert Baldyga wrote:
> > On 10/07/2014 04:28 AM, Felipe Balbi wrote:
> > > Hi,
> > >
Hi,
On Tue, Oct 07, 2014 at 08:33:16AM +0200, Robert Baldyga wrote:
> On 10/07/2014 04:28 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
> >> Since we can compose gadgets from many functions, there is the problem
> >> related to gadget
On 10/07/2014 04:28 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
>> Since we can compose gadgets from many functions, there is the problem
>> related to gadget breakage while FunctionFS daemon being closed. In some
>> cases it's strongly
On 10/07/2014 04:28 AM, Felipe Balbi wrote:
Hi,
On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while FunctionFS daemon being closed. In some
cases it's strongly desired to keep
Hi,
On Tue, Oct 07, 2014 at 08:33:16AM +0200, Robert Baldyga wrote:
On 10/07/2014 04:28 AM, Felipe Balbi wrote:
Hi,
On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while
...@samsung.com
Subject: Re: [PATCH] usb: gadget: f_fs: add zombie mode
Hi,
On Tue, Oct 07, 2014 at 08:33:16AM +0200, Robert Baldyga wrote:
On 10/07/2014 04:28 AM, Felipe Balbi wrote:
Hi,
On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
Since we can compose gadgets from
Hi,
On Tue, Oct 07, 2014 at 05:01:15PM +0200, Krzysztof Opasiak wrote:
Hi,
On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
Since we can compose gadgets from many functions, there is the
problem related to gadget breakage while FunctionFS daemon
being
...@samsung.com
Subject: Re: [PATCH] usb: gadget: f_fs: add zombie mode
Hi,
On Tue, Oct 07, 2014 at 05:01:15PM +0200, Krzysztof Opasiak wrote:
Hi,
On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga
wrote:
Since we can compose gadgets from many functions
Hi,
On Tue, Oct 07, 2014 at 06:37:26PM +0200, Krzysztof Opasiak wrote:
[snip]
yeah, and the way to deal with that is disconnecting from the host
because that USB function, can't be functional anymore. I mean,
imagine you try to e.g. unload pictures from your nice DSLR and
that DSLR runs
On Tue, 7 Oct 2014, Felipe Balbi wrote:
Please believe me that I totally agree with you, but I also see Robert's
point. Let's take ADB as example. Before ADB has been ported to
FunctionFS it communicated with kernel using dev node provided by ADB
function driver. With that infrastructure
Hi,
On Tue, Oct 07, 2014 at 01:15:32PM -0400, Alan Stern wrote:
Here also I agree. Zombie mode should mock the function until first
next enumeration or unbind. It should not be possible to bind gadget
with function in zombie mode to UDC. Zombie mode should pretend only
as long as
On Tue, 7 Oct 2014, Felipe Balbi wrote:
It seems to me that we should imitate what an ordinary USB device would
do. If part of the firmware crashes, generally you would expect none
of the endpoints associated with that function to work. Either they
refuse to accept output from the host
Hi,
On Tue, Oct 07, 2014 at 02:42:33PM -0400, Alan Stern wrote:
It seems to me that we should imitate what an ordinary USB device would
do. If part of the firmware crashes, generally you would expect none
of the endpoints associated with that function to work. Either they
refuse to
On Tue, 7 Oct 2014, Felipe Balbi wrote:
If the file handle was closed for abnormal reasons, we can behave like
crashed firmware. Which means, in the end, doing the same thing as in
the normal-reason case -- i.e., do nothing. In particular, don't
disconnect.
If you want to allow
On Tue, 7 Oct 2014, Felipe Balbi wrote:
Right, but if we allow this, I can already see folks abusing to
connect to the host early and only when necessary do some trickery to
e.g. start adbd (not saying Android will do this, just using it as an
easy example).
I don't really see that
Hi,
On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
> Since we can compose gadgets from many functions, there is the problem
> related to gadget breakage while FunctionFS daemon being closed. In some
> cases it's strongly desired to keep gadget alive for a while, despite
>
> On 10/06/2014 02:36 PM, Michal Nazarewicz wrote:
>> However, all the ep# files will still exist on the filesystem. This may
>> be a bit confusing and error-prone, no?
On Mon, Oct 06 2014, Robert Baldyga wrote:
> Shouldn't be error-prone, because opening them will fail with -ENODEV,
> but
On 10/06/2014 02:36 PM, Michal Nazarewicz wrote:
> On Mon, Oct 06 2014, Robert Baldyga wrote:
>> Since we can compose gadgets from many functions, there is the problem
>> related to gadget breakage while FunctionFS daemon being closed. In some
>> cases it's strongly desired to keep gadget alive
On Mon, Oct 06 2014, Robert Baldyga wrote:
> Since we can compose gadgets from many functions, there is the problem
> related to gadget breakage while FunctionFS daemon being closed. In some
> cases it's strongly desired to keep gadget alive for a while, despite
> FunctionFS files are closed, to
On Mon, Oct 06 2014, Robert Baldyga r.bald...@samsung.com wrote:
Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while FunctionFS daemon being closed. In some
cases it's strongly desired to keep gadget alive for a while, despite
FunctionFS
On 10/06/2014 02:36 PM, Michal Nazarewicz wrote:
On Mon, Oct 06 2014, Robert Baldyga r.bald...@samsung.com wrote:
Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while FunctionFS daemon being closed. In some
cases it's strongly desired to keep
On 10/06/2014 02:36 PM, Michal Nazarewicz wrote:
However, all the ep# files will still exist on the filesystem. This may
be a bit confusing and error-prone, no?
On Mon, Oct 06 2014, Robert Baldyga r.bald...@samsung.com wrote:
Shouldn't be error-prone, because opening them will fail with
Hi,
On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while FunctionFS daemon being closed. In some
cases it's strongly desired to keep gadget alive for a while, despite
FunctionFS
40 matches
Mail list logo
