On Wed, May 11 2016, Felipe Balbi wrote:
> Also, returning -EOVERFLOW is not exactly correct here, because you'd
> violate POSIX specification of read(), right ?
Maybe we could piggyback on:
EINVAL fd was created via a call to timerfd_create(2) and the
wrong size buffer was g
On Fri, May 13 2016, Alan Stern wrote:
> The point is that you don't know whether the host sent more data than
> expected. All you know is that the host sent more data than the user
> asked the kernel for -- but maybe the user didn't ask for all the data
> that he expected. Maybe the user wanted
> Alan Stern writes:
>> The point is that you don't know whether the host sent more data than
>> expected. All you know is that the host sent more data than the user
>> asked the kernel for -- but maybe the user didn't ask for all the
>> data that he expected. Maybe the user wanted to retrieve t
So I’ve been looking at AIO handling in f_fs and either I’m stupid or
the code is broken. Here’s part of ffs_user_copy_worker:
int ret = io_data->req->status ? io_data->req->status :
io_data->req->actual;
if (io_data->read && ret > 0) {
> On 05/16/2016 06:05 PM, Michal Nazarewicz wrote:
>> So I’ve been looking at AIO handling in f_fs and either I’m stupid or
>> the code is broken.
On Mon, May 16 2016, Lars-Peter Clausen wrote:
> The code was broken. Fixed in commit 332a5b446b791 ("usb: gadget:
> f_fs:
On Mon, May 16 2016, Felipe Balbi wrote:
> Michal Nazarewicz writes:
>
>>> Alan Stern writes:
>>>> The point is that you don't know whether the host sent more data than
>>>> expected. All you know is that the host sent more data than the user
>
On Tue, May 17 2016, Changbin Du wrote:
>> There appears to be no kfifo support for iov_iter though, so I just went
>> with a simple buffer.
>>
>> I haven’t looked at the patch too carefully so this is an RFC rather
>> than an actual patch at this point. It does compile at least.
>>
>> Regardles
On Wed, May 18 2016, Felipe Balbi wrote:
> we've been through this before. This needs to be done at the gadget
> layer. Gadget driver can over-allocate ahead of time if
> gadget->quirk_ep_out_aligned_size is true, then we avoid memcpy() at
> the UDC driver level.
Right, all right, so let’s look at
On Thu, May 19 2016, Changbin Du wrote:
>> On Wed, May 18 2016, Felipe Balbi wrote:
>> > we've been through this before. This needs to be done at the gadget
>> > layer. Gadget driver can over-allocate ahead of time if
>> > gadget->quirk_ep_out_aligned_size is true, then we avoid memcpy() at
>> > th
Add a pr_err when host sent more data then the size of the buffer user
space gave us. This may happen on UDCs which require OUT requests to
be aligned to max packet size. The patch includes a description of the
situation.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c
ignored.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 130 +++--
1 file changed, 109 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index e26a6b4..08a1ac2 100644
UDC does and
* breaks one read -> one request model which has been true so far.
Michal Nazarewicz (2):
usb: gadget: f_fs: printk error when excess data is dropped on read
usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests
drivers/usb/gadget/function/f_fs.c |
Fixes all of the unused-but-set-variable warnings enabled when
building with W=1. As described in the first patch, some warnings are
left off. See said patch for more description.
Michal Nazarewicz (4):
usb: gadget: fix unused-but-set-variale warnings
usb: gadget: m66592: fix unused-but-set
needed.
Signed-off-by: Michal Nazarewicz
Cc: Yoshihiro Shimoda
---
drivers/usb/gadget/udc/m66592-udc.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/udc/m66592-udc.c
b/drivers/usb/gadget/udc/m66592-udc.c
index b1cfa96..6e977dc
that
are needed.
Signed-off-by: Michal Nazarewicz
Cc: Yoshihiro Shimoda
---
drivers/usb/gadget/udc/r8a66597-udc.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/udc/r8a66597-udc.c
b/drivers/usb/gadget/udc/r8a66597-udc.c
index
);
^
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 3 +-
drivers/usb/gadget/function/u_serial.c | 3 +-
drivers/usb/gadget/legacy/g_ffs.c | 15 --
drivers/usb/gadget/udc/amd5536udc.c| 9 +-
drivers/usb/gadget/udc/bdc/bdc_cmd.c | 3 --
doing so, it removes calls to ioread32 function which does I/O with
the device, but I hope the reads don’t have any side effects that are
needed.
Signed-off-by: Michal Nazarewicz
Cc: Yu Xu
---
drivers/usb/gadget/udc/mv_u3d_core.c | 23 +++
1 file changed, 3 insertions(+), 20
is the wrong variable to use for an iterator.
>
> Fixes: ddf8abd25994 ('USB: f_fs: the FunctionFS driver')
> Signed-off-by: Dan Carpenter
Acked-by: Michal Nazarewicz
How on Earth could I have made that mistake is beyond my
comprehension. O_o On second thought, things being
On Sat, May 28 2016, Dan Carpenter wrote:
> Also in the kernel we have to declare variables at the start of the
> block.
/me shrugs
I looked at this out of curiosity and there are precedents:
$ git grep 'for (\(int\|unsigned\|signed\|long\|char\)[[:space:]]' |wc -l
19
(albeit mostly in
: ddf8abd25994 ('USB: f_fs: the FunctionFS driver')
> Signed-off-by: Dan Carpenter
Acked-by: Michal Nazarewicz
> ---
> v2: move the eps_ptr assignment outside the loop.
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index 7351
On Sat, May 28 2016, Dan Carpenter wrote:
> Try compiling the code you suggested.
I find this amusing to be perfectly honest.
Kernel uses designated initialisers, flexible array members, stdint.h,
compound literals and variadic macros, yet still for some reason sticks
to -std=gnu89.
No matter, t
Those are enabled with W=1 make option.
The patch leaves of some type-limits warnings which are caused by
generic macros used in a way where they produce always-false
conditions.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 3 +--
drivers/usb/gadget/function
On Tue, May 31 2016, Felipe Balbi wrote:
> This series doesn't seem to apply to v4.7-rc1. Care to rebase on
> testing/fixes?
Sure. Only the first patch needs fixing (by skipping failed hunks).
Michal Nazarewicz (4):
usb: gadget: fix unused-but-set-variale warnings
usb: gadget:
doing so, it removes calls to ioread32 function which does I/O with
the device, but I hope the reads don’t have any side effects that are
needed.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/udc/mv_u3d_core.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions
that
are needed.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/udc/r8a66597-udc.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/udc/r8a66597-udc.c
b/drivers/usb/gadget/udc/r8a66597-udc.c
index 8b300e6..f2c8862 100644
--- a
needed.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/udc/m66592-udc.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/udc/m66592-udc.c
b/drivers/usb/gadget/udc/m66592-udc.c
index b1cfa96..6e977dc 100644
--- a/drivers/usb
On Fri, Jun 24 2016, Dan Carpenter wrote:
> Return -ENOMEM if kmalloc() fails.
>
> Fixes: 9353afbbfa7b ('usb: gadget: f_fs: buffer data from ‘oversized’ OUT
> requests')
> Signed-off-by: Dan Carpenter
>
Acked-by: Michal Nazarewicz
> diff --git a/drivers/usb/gadg
On Wed, Nov 21 2012, Sebastian Andrzej Siewior wrote:
> So you say "keep the patch as it with this module-parameter
> compatibility"?
I'm saying that in my opinion external behaviour of the gadgets should
not change until a configfs solution is ready and final.
As for the patch, I had some concer
> * Andrzej Pietrasiewicz | 2012-11-22 13:06:54 [+0100]:
>>During its lifetime, the mass storage can require creating
>>lunX directories for its luns. And again, with usbf_option
On Thu, Nov 22 2012, Sebastian Andrzej Siewior wrote:
> You have first to detach the gadget because you can't update wh
> * Andrzej Pietrasiewicz | 2012-11-22 13:06:56 [+0100]:
>> echo .img >
>> /cfg/usb-function-gadget/G1/C1/F1/MassStorage/lun0/file
>>
>> Do the similar thing to other functions, then
>>
>> echo 1 > /cfg/usb-function-gadget/G1/ready
On Thu, Nov 22 2012, Sebastian Andrzej Siewior wrote:
> One thing
On Thu, Nov 22 2012, Andrzej Pietrasiewicz wrote:
> pre_eject and post_eject are not used by anyone. Removing them.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Signed-off-by: Kyungmin Park
Acked-by: Michal Nazarewicz
As far as I'm concerned, this can get merged regardless of
> * Andrzej Pietrasiewicz | 2012-11-22 13:06:55 [+0100]:
>> Using configfs to create/configure a usb gadget requires
>> providing a method to create config group for a usb function
>> and a wrapper for usb_add_function.
>>
>> Signed-off-by: Andrzej Pietrasiewicz
>> Signed-off-by: Kyungmin Park
O
On Thu, Nov 22 2012, Andrzej Pietrasiewicz wrote:
> mount -t configfs none /cfg
> mkdir -p /cfg/usb-function-gadget/G1/C1/F1
> echo 0x > /cfg/usb-function-gadget/G1/idVendor
> echo 0x > /cfg/usb-function-gadget/G1/idProduct
> echo 0x > /cfg/usb-function-gadget/G1/bcdDevice
> echo > /cfg/usb-functi
On Thu, Nov 22 2012, Andrzej Pietrasiewicz wrote:
> Signed-off-by: Andrzej Pietrasiewicz
> Signed-off-by: Kyungmin Park
> ---
> drivers/usb/gadget/f_mass_storage.c | 225
> +++
> 1 files changed, 225 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/gad
On Thu, Nov 22 2012, Andrzej Pietrasiewicz wrote:
> @@ -45,10 +46,9 @@
> #define VLDBG(lun, fmt, args...) do { } while (0)
> #endif /* VERBOSE_DEBUG */
>
> -#define LDBG(lun, fmt, args...) dev_dbg (&(lun)->dev, fmt, ## args)
> -#define LERROR(lun, fmt, args...) dev_err (&(lun)->dev, fmt, ## a
On Thu, Nov 22 2012, Andrzej Pietrasiewicz wrote:
> +static void fsg_free(struct usb_function *f)
> +{
> + struct fsg_dev *fsg = fsg_from_func(f);
> +
> kfree(fsg);
> }
kfree(fsg_from_func(f));
if you ask me, but feel free to ignore me.
>
> @@ -2970,22 +2981,65 @@ a
On Thu, Nov 22 2012, Andrzej Pietrasiewicz wrote:
> +#define _FSG_MODULE_PARAM_ARRAY(prefix, params, name, type, desc)\
> + module_param_array_named(prefix ## name, params.name, type, \
> + &prefix ## params.name ## _count, \
> +
On Mon, Nov 26 2012, Andrzej Pietrasiewicz wrote:
> In some parts of the kernel (e.g. planned configfs integration into usb
> gadget) there is a need to programmatically create config groups
> (directories) but it would be preferable to disallow creating them by
> the user. This is more or less wh
> On 11/26/2012 09:35 AM, Andrzej Pietrasiewicz wrote:
>> In some parts of the kernel (e.g. planned configfs integration into usb
>> gadget) there is a need to programmatically create config groups
>> (directories) but it would be preferable to disallow creating them by
>> the user. This is more or
On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
> Wouldn't say that. It may adds complexity on another level. The target
> subsystem has the same problem with adding luns and there seems nothing
> wrong with having lun3 and 4 and leaving 0 and 1 unsued.
That's not what Wikipedia claims thoug
> On Mon, 26 Nov 2012, Sebastian Andrzej Siewior wrote:
>> Step two is a folder where we setup individual configuration of a function.
>>
>> /functions/ttyS0
>> /functions/ttyS1
>> /functions/storage
>>
>> each one of the function folder has the file called "name". So for the
>> folder ttyS0 the
On Mon, Nov 26 2012, Alan Stern wrote:
> In your example, what files would appear under under
> /functions/storage? I gather that the "storage" part is just a
> placeholder name with no real meaning. The meaning is conveyed
> when the user writes "mass_storage" to /functions/storage/name.
>
> Whe
On Tue, Nov 27 2012, Andrzej Pietrasiewicz wrote:
> I think we _still_ need a way to programmatically create/remove configfs
> directories. Without it, this: "After name is written it will request
> the module and special configuration related files pop up."
> (http://www.spinics.net/lists/linux-u
On Tue, Nov 27 2012, Sebastian Andrzej Siewior wrote:
> I don't want to push python on anyone but the removal magic is simply
> straight forward: unlink the disk ports, rmdir luns, tpgt,…
How should a generic tool know what kind of actions are needed for given
function to be removed? If you ask m
> On 11/27/2012 05:23 PM, Michal Nazarewicz wrote:
>> How should a generic tool know what kind of actions are needed for given
>> function to be removed? If you ask me, there should be a way to unbind
>> gadget and unload all modules without any specific knowledge of the
&g
On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
> -
> /functions/acm-function/
>
> instead of
>
> /functions/function1/
> +name
> with attribute file named "name" which contains the name of the
> function (i.e. acm). My point is to keep "name" in
Looks nice. :]
On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
> |# modprobe dummy_hcd num=2
>
> |# find /sys/kernel/config/ -ls
> | 65470 drwxr-xr-x 5 root root0 Nov 28 19:39
> /sys/kernel/config/
> | 5320 drwxr-xr-x 2 root root0 Nov 28 19:39
On Thu, Nov 29 2012, Sebastian Andrzej Siewior wrote:
> |# modprobe dummy_hcd num=2
>
> |# find /sys/kernel/config/ -ls
>
> | 5570 drwxr-xr-x 3 root root0 Nov 29 17:26
> /sys/kernel/config/
> | 5580 drwxr-xr-x 5 root root0 Nov 29 17:26
> /sys/kerne
On Fri, Nov 30 2012, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 29, 2012 at 05:43:21PM +0100, Sebastian Andrzej Siewior wrote:
>> |# modprobe dummy_hcd num=2
>>
>> |# find /sys/kernel/config/ -ls
>>
>> | 5570 drwxr-xr-x 3 root root0 Nov 29 17:26
>> /sys/kernel/config/
>> |
On Fri, Nov 30 2012, Sebastian Andrzej Siewior wrote:
> That won't work. You can only symlink an instance to one UDC. It is an
> instance after all. If you want two ACM ports you need two ACM folder
> in your functions folder:
>
> acm.ttyS0
> acm.ttyS1
Yeah, but what Felipe just made me realise i
On Fri, Nov 30 2012, Felipe Balbi wrote:
> why would you load a function before it's actually needed ? We could
> end up with users who will just load the function and never actually
> need them which will consume memory for no reason.
IMO that's actually mute argument since it can be done regardl
; common->lun < common->nluns)
> | ~~~ ^ ~
>
> common->lun is defined as "unsigned int" so its value is always >= 0.
> It is assigned via cbw->Lun which is defined as u8 so it is also not
> abused as -1.
>
> Signed-off-by: Sebasti
> On 11/30/2012 07:39 PM, Michal Nazarewicz wrote:
>> Yeah, but what Felipe just made me realise is that if that's the case,
>> than it makes no sense to have the functions directory outside of the
>> gadget. Instead we should have something like:
On Mon, Dec 03 2012,
> On Fri, Nov 30, 2012 at 07:40:31PM +0100, Michal Nazarewicz wrote:
>> IMO that's actually mute argument since it can be done regardless. You
>> can modprobe the module anyway.
On Fri, Nov 30 2012, Felipe Balbi wrote:
> fair enough, I just want to avoid doing any me
as -1.
>
>> [min...@mina86.com: make lun unsigned int and use %u in DBG() macro for it]
>> Acked-by: Michal Nazarewicz
On Tue, Dec 04 2012, Sergei Shtylyov wrote:
> Michal, shouldn't you rather sign off on the patch if it includes a chunk
> from you anyway?
Makes s
On Fri, Dec 07 2012, victor wrote:
> I can build linux USB mass storage gadget. When I want to insmod it, the
> following errors are reported. I have the file g_mass_storage.ko, why can't
> I insmod the file?
>
> # ls /lib/modules/3.4.4\+/kernel/drivers/usb/gadget/
> g_mass_storage.ko
> # insmod /
On Mon, Dec 10 2012, Golmer Palmer wrote:
> This message is for request to support CD-ROM boot support in the USB Gadget
> driver.
>
> Specifically, I ask for improve "g_mass_storage" driver with:
>
> * 2048 byte/sector support in CD mode.
Unless I'm missing something, g_mass_storage is using 20
On Sun, Dec 09 2012, victor wrote:
> Yes, I am running the USB mass storage gadget on a new chip. Which
> UDC code supports the mass storage gadget? I intend to write UDC for
> the new chip based on the existing UDC code.
Mass storage gadget should work with any UDC, but if there is none it
won'
On Sat, Dec 29 2012, chetan cr123 wrote:
> I am facing some build errors when i am trying to build my gadget
> driver as module
> /media/work/rev_295/kernel/drivers/usb/gadget/composite.c:1406:
> undefined reference to `usb_gadget_unregister_driver'
>
> drivers/built-in.o: In function `usb_compos
On Sat, Dec 29 2012, chetan cr123 wrote:
> usb_gadget_unregister_driver and usb_gadget_probe_driver functions are
> exported (EXPORT_SYMBOL)from my gadget driver ((its in path
> kernel/drivers/staging...))
Ah, missed this remark in my previous response.
This is not correct. usb_gadget_unregister_
d/kgid where appropriate) in 3.7.
>
> Signed-off-by: Benoit Goby
Acked-by: Michal Nazarewicz
Cc: sta...@kernel.org
> ---
> drivers/usb/gadget/f_fs.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/f_fs.c b/drivers/
From: Michal Nazarewicz
kstrtoul() checks for overflow which simple_strtoul() does not pluss
it has “*end == 0” check in it as well. As a side effect, a new
line character is now accepted, but this should not be an issue.
Signed-off-by: Michal Nazarewicz
---
Patch on top of v3.5 with Benoit
From: Michal Nazarewicz
The use of memcmp() is clever and all and maybe even it makes parsing a
bit faster (since only options with given length need to be checked) but
option parsing is hardly a critical path and the additional code
complexity is not worth it.
Signed-off-by: Michal Nazarewicz
On Thu, Jan 24 2013, Greg KH wrote:
> gadgetfs is a userspace api that I don't think we can just drop all
> that easily. Does f_fs do everything that gadgetfs does?
gadgetfs and functionfs have a different API so f_fs cannot be used as
a drop-in replacement for gadgetfs.
--
Best regards,
On Thu, Jan 24 2013, Felipe Balbi wrote:
> Hmm, looks like there's no easy way out. Can we (easily) make
> a compatibility layer between the two ? What are the biggest
> differences?
The biggest difference is that gadgetfs application handles all setup
requests whereas with functionfs most of them
fput+0xb0/0x1f4
> [ 52.642633] c1 [] fput+0x20/0x2c
> [ 52.642636] c1 [] task_work_run+0xb4/0xe8
> [ 52.642640] c1 [] do_exit+0x360/0xb9c
> [ 52.642644] c1 [] do_group_exit+0x4c/0xb0
> [ 52.642647] c1 [] get_signal+0x380/0x89c
> [ 52.642651] c1 [] do_signal+0x154/0
callbacks ever return NULL, a null pointer dereference will
happen.
Be defensive about it and check in those functions whether the callbacks
(incorrectly) returned NULL and interpret it as ENOMEM error pointer
instead.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/functions.c |
; Signed-off-by: Daniel Wagner
> Cc: Felipe Balbi
> Cc: Michal Nazarewicz
Acked-by: Michal Nazarewicz
> Cc: Greg Kroah-Hartman
> Cc: linux-usb@vger.kernel.org
> ---
> drivers/usb/gadget/function/f_fs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
bug in the code and we need to do this:
--- >8 -
>From 0ce6cc5e2440800243eff06c6952cba0f976da2f Mon Sep 17 00:00:00 2001
From: Michal Nazarewicz
Date: Wed, 28 Sep 2016 18:10:42 +0200
Subject: [PATCH] usb: gadget: f_fs: edit
On Wed, Sep 28 2016, Michal Nazarewicz wrote:
> With that done, the only thing which needs a mutex is
> epfile->read_buffer.
Perhaps this would do:
>8 -- -
>From 6416a1065203a39328311f6c58083089efe169aa Mon Sep 1
On Mon, Oct 03 2016, John Stultz wrote:
> On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote:
>> On Wed, Sep 28 2016, Michal Nazarewicz wrote:
>>> With that done, the only thing which needs a mutex is
>>> epfile->read_buffer.
>>
>
ffs_func_eps_disable is called from atomic context so it cannot sleep
thus cannot grab a mutex. Change the handling of epfile->read_buffer
to use non-sleeping synchronisation method.
Reported-by: Chen Yu
Signed-off-by: Michał Nazarewicz
Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT req
epfile->ep is protected by ffs->eps_lock (not epfile->mutex) so clear it
while holding the spin lock.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
n the given ep. HW know the
>actual transfer status.
> 2) after hw stop transfer, driver scan if there are any completed one.
> 3) if found, process it with real status. if no, the request can
>canceled.
>
> Signed-off-by: Du, Changbin
Acked-by: Michal Nazarewicz
While
: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index d1a4a86..1384220 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget
Eliminate one of the return paths by using a ‘goto error_mutex’ and
rearrange some if-bodies which results in reduction of the indention level
and thus hopefully makes the function easier to read and reason about.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 127
ter if-else-if-else chain) and returns ret. Noticeably,
this does not include freeing of the data buffer.
Fix by introducing a goto which moves control flow to the the end of the
function where spin_unlock_irq, mutex_unlock and kfree are all called.
Signed-off-by: Michal Nazarewicz
---
drivers/
...@mina86.com: rebased on top of refactoring patches]
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_fs.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 63fe693..8c
In ffs_epfile_io error label points to a return path which includes
a kfree(data) call. However, at the beginning of the function data is
always NULL so some of the early ‘goto error’ can safely be replaced
with a trivial return statement.
Signed-off-by: Michal Nazarewicz
---
drivers/usb
On Tue, Jan 05 2016, Peter Chen wrote:
> Why -EINTR, the kernel-doc said it should return -ECONNRESET for
> active request, see include/linux/usb/gadget.h.
Because EINTR is what read returns to the user if the operation has been
interrupted by a signal, see ‘man 2 read’:
EINTR The call was
On Tue, Jan 05 2016, Dan Carpenter wrote:
> We added a new error path to this function and we forgot to drop the
> lock.
>
> Fixes: e1e3d7ec5da3 ('usb: gadget: f_midi: pre-allocate IN requests')
> Signed-off-by: Dan Carpenter
Acked-by: Michal Nazarewicz
> ---
>
On Wed, Jan 06 2016, Dan Carpenter wrote:
> On Tue, Jan 05, 2016 at 08:51:18PM +, Felipe Ferreri Tonello wrote:
>> This case is not a matter of been pretty but a matter of been less error
>> prone.
>>
>> What would you suggest?
>
> Normally it's better to unwind in the reverse order from how w
: f_midi: remove useless midi reference from port struct
Michal Nazarewicz (8):
usb: f_fs: fix memory leak when ep changes during transfer
usb: f_fs: fix ffs_epfile_io returning success on req alloc failure
usb: f_fs: replace unnecessary goto with a return
usb: f_fs: refactor ffs_epfile_io
usb
On Fri, Feb 05 2016, weiyj...@163.com wrote:
> From: Wei Yongjun
>
> Add the missing unlock before return from function f_midi_alloc()
> when kfifo_alloc() failed.
There already is a patchset addressing this:
http://comments.gmane.org/gmane.linux.kernel/2135768
>
> Signed-off-by: Wei Yongjun
>
> Michal Nazarewicz writes:
>> Resending my previous two sets for f_fs and f_midi. This time rebased
>> on top of Felipe’s next branch.
>>
>> Dan Carpenter (1):
>> usb: gadget: f_midi: missing unlock on error path
>>
>> Du, Changbin (
it is need to align
> the request buffer's size to an ep's maxpacketsize.
>
> Signed-off-by: Baolin Wang
Acked-by: Michal Nazarewicz
> ---
> drivers/usb/gadget/function/f_midi.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
On Fri, Jul 08 2016, Baolin Wang wrote:
> On 7 July 2016 at 20:51, Michal Nazarewicz wrote:
>> On Thu, Jul 07 2016, Baolin Wang wrote:
>>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>>> attribute, which means it need to align the reque
> Baolin Wang writes:
>> @@ -359,10 +361,12 @@ static int f_midi_set_alt(struct usb_function *f,
>> unsigned intf, unsigned alt)
>>
>> /* allocate a bunch of read buffers and queue them all at once. */
>> for (i = 0; i < midi->qlen && err == 0; i++) {
>> -struct usb_reques
[NAK]
> ...
> HOST: [PING]
> DEVICE: [NAK]
>
> This patch fixes this problem by setting the minimum usb_request's buffer
> size
> for the OUT endpoint as its wMaxPacketSize.
>
> Acked-by: Michal Nazarewicz
> Signed-off-by
it is need to align
> the request buffer's size to an ep's maxpacketsize.
>
> Signed-off-by: Baolin Wang
> Acked-by: Michal Nazarewicz
> ---
> Changelog since v1:
> - Remove the in_ep modification.
> - Remove max_t() function.
>
> drivers/usb/gadget/func
ich does always returns the
> aligned buffer size for an endpoint. This is useful to be used by USB requests
> allocator functions.
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Michal Nazarewicz
> ---
> include/linux/usb/gadget.h | 17 ++---
> 1 file ch
On Tue, Jul 26 2016, Felipe F. Tonello wrote:
> 512 is the value used by wMaxPacketSize, as specified by the USB Spec. This
> makes sure this driver uses, by default, the most optimal value for IN and OUT
> endpoint requests.
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Mi
On Tue, Jul 26 2016, Felipe F. Tonello wrote:
> Using usb_ep_align() makes sure that the buffer size for OUT endpoints is
> always aligned with wMaxPacketSize (512 usually). This makes sure
> that no buffer has the wrong size, which can cause nasty bugs.
>
> Signed-off-by: Felipe F. Tonello
> ---
me.
> create an inline function to pass the same value to len and default_len.
>
> So this patch also removes duplicate code from few drivers.
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Michal Nazarewicz
> ---
> drivers/usb/gadget/function/f_hid.c| 10 ++--
On Tue, Jul 26 2016, Felipe F. Tonello wrote:
> We should always use free_ep_req() when allocating requests with
> alloc_ep_req().
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Michal Nazarewicz
> ---
> drivers/usb/gadget/function/f_hid.c | 10 +++---
> 1 file change
On Tue, Jul 26 2016, Felipe F. Tonello wrote:
> Use gadget's framework allocation function instead of directly calling
> usb_ep_alloc_request().
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Michal Nazarewicz
> ---
> drivers/usb/gadget/function/f_hid.c | 6 +---
On Wed, Aug 03 2016, Oliver Neukum wrote:
> Before we think about that, the basic question whether
>
> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH
>
> is clearer and easier to read than
>
> 0644
>
> must be decided. I would saz no, it is not.
I was about to write the same thing.
I dislike magic numbers
ich does always returns the
> aligned buffer size for an endpoint. This is useful to be used by USB requests
> allocator functions.
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Michal Nazarewicz
> ---
> include/linux/usb/gadget.h | 17 ++---
> 1 file ch
On Fri, Aug 05 2016, Felipe F. Tonello wrote:
> 512 is the value used by wMaxPacketSize, as specified by the USB Spec. This
> makes sure this driver uses, by default, the most optimal value for IN and OUT
> endpoint requests.
>
> Signed-off-by: Felipe F. Tonello
Acked-by: Mi
On Wed, Mar 02 2016, Felipe F. Tonello wrote:
> Signed-off-by: Felipe F. Tonello
> ---
> drivers/usb/gadget/function/f_midi.c | 77
> +++-
> 1 file changed, 40 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c
> b/drivers/usb/ga
1 - 100 of 552 matches
Mail list logo
