Hi,
I have been looking at an issue where a phone that is the Function FS
host sometimes locks up and causes the function:
static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data
*io_data) in drivers/usb/gadget/function/f_fs.c to timeout after
MAX_SCHEDULE_TIMEOUT jiffies.
We are openi
>
> FunctionFS is very specific, because read/write operations are directly
> translated into USB requests, which are asynchronous, so you cannot use
> O_NONBLOCK.
>
> If you need non-blocking API you can use Asynchronous I/O (AIO). You can
> find some examples in kernel sources (tools/usb/ffs-ai
> On Wed, Apr 01, 2015 at 06:29:05PM +0100, Baxter, Jim wrote:
>>>
>>> FunctionFS is very specific, because read/write operations are directly
>>> translated into USB requests, which are asynchronous, so you cannot use
>>> O_NONBLOCK.
>>>
>>&
>
> FunctionFS is very specific, because read/write operations are
> directly translated into USB requests, which are asynchronous, so
> you cannot use O_NONBLOCK.
>
> If you need non-blocking API you can use Asynchronous I/O (AIO). You
> can find some examples in kernel
Bjørn Mork writes:
>
> Ouch! Thanks for finding this. This should go to the stable queue as
> well.
>
> Reviewed-by: Bjørn Mork
>
Do I need to submit this to the stable queue myself?
-- Jim
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to
Bjørn Mork writes:
> "Baxter, Jim" writes:
>
>>
>> Do I need to submit this to the stable queue myself?
>
> No, davem will handle that.
>
> That is, assuming that you had posted this to netdev in the first
> place... Sorry, I just assumed you did
From: Oliver Neukum (oneu...@suse.com) Sent: Wed, 17 May 2017 09:44:20 +0200
> Am Dienstag, den 16.05.2017, 20:24 +0200 schrieb Bjørn Mork:
>>
>> I must say that I don't like the additional complexity added here. If
>> there are memory issues and you can reduce the buffer size to
>> USB_CDC_NCM_
From: David S. Miller (da...@davemloft.net)
Sent: Wed, 17 May 2017 14:18:19 -0400
>
> When there isn't memory pressure this will hurt performance of
> course.
>
> It is a quite common paradigm to back down to 0 order memory requests
> when higher order ones fail, so this isn't such a bad change
From: David S. Miller (da...@davemloft.net)
Sent: Tue, 23 May 2017 11:26:25 -0400
> From: Oliver Neukum
> Date: Tue, 23 May 2017 10:42:48 +0200
>
>>
>> We could use a counter. After the first failure, do it once, after the
>> second twice and so on. And reset the counter as a higher order
>> all
From: Oliver Neukum (oneu...@suse.com) Sent: Mon, 12 Jun 2017 12:24:07 +0200
> Am Dienstag, den 23.05.2017, 20:06 +0100 schrieb Jim Baxter:
>> From: David S. Miller (da...@davemloft.net)
>> Sent: Tue, 23 May 2017 11:26:25 -0400
>>>
>>> From: Oliver Neukum
>>> Date: Tue, 23 May 2017 10:42:48 +020
From: David S. Miller (da...@davemloft.net)
Sent: Fri, 30 Jun 2017 12:59:53 -0400
To: jim_bax...@mentor.com
Cc: linux-usb@vger.kernel.org, net...@vger.kernel.org,
linux-ker...@vger.kernel.org, oli...@neukum.org, bj..
> Jim Baxter writes:
>
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented.
>>
>> This especially affects embedded systems that have constrained
>> resources but wish to maximise the throughput of CDC-NCM with
12 matches
Mail list logo
