Date:	Mon, 04 May 2015 14:55:10 +0200
From:	Robert Baldyga <r.baldyga@...sung.com>
To:	balbi@...com
Cc:	gregkh@...uxfoundation.org, m.szyprowski@...sung.com,
	andrzej.p@...sung.com, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Robert Baldyga <r.baldyga@...sung.com>
Subject: [PATCH v2 0/5] usb: gadget: Fix gadget deactivaton feature

Hi,

This patch set introduces two functions usb_gadget_deactivate() and
usb_gadget_activate(), designed to prevent udc-core from showing binded
gadget to host until it will be ready to work. It also makes
usb_function_deactivate()/activate() using these functions.

So far gadget deactivation was made by calling usb_gadget_disconnect(),
but since we have usb_gadget_connect() called after gadget->bind()
(in udc_bind_to_driver()) this method doesn't provide expected result.
Calling function usb_gadget_disconnect() before gadget connection doesn't
prevent udc-core from connecting gadget to driver - usb_gadget_disconnect()
call is ignored and gadget is connected regardless to it. This usually
results with errors, for example because we binded gadget with 0
configurations.

This patch set fixes this problem adding functions allowing to perform
effective gadget deactivation from gadget->bind().

According to Felipe's suggestion, in v2 there is one new patch adding
'bind_deactivated' flag, which should be used by functions which want
to be binded as deactivated (for example because they need to wait for
userspace daemon). Functions using this flag have to call
usb_function_activate() to tell composite core they are ready to work.
I have also converted functions which are using deactivation feature
to make them using 'bind_deactivated' flag. Patches are also attached
to this patch set.

I was considering removing usb_function_deactivate() function since we
have this flag, but I see that some of USB functions use it not only
in bind() but also e.g. when userspace daemon disconnects. This is also
the reason why I haven't named this flag 'controls_pullup', because this
name doesn't describe precisely what does it mean.

We also need to consider what to do when deactivation fails (which can
happen if our UDC driver doesn't support the pullup callback). So far,
when usb_function_deactivate() was called in bind(), we have had ability
to decide what to do, when it fails. Now we preform function deactivation
before its bind(), and when deactivation fails we fail to add the function
to gadget. Maybe we should to allow it to continue despite deactivation
failure and inform function (somehow) about this situation. If only it
makes any sense, because in this form it looks more complicated that
it was, and moreover it actually doesn't add any new features.

Best regards,
Robert Baldyga

Changelog:

v2:
- add 'bind_deactivated' flag

v1: https://lkml.org/lkml/2015/4/7/92

Robert Baldyga (5):
  usb: gadget: add usb_gadget_activate/deactivate functions
  usb: composite: fix usb_function_activate/deactivate functions
  usb: composite: add bind_deactivated flag to usb_function
  usb: gadget: f_uvc: use bind_deactivated flag
  usb: gadget: f_obex: use bind_deactivated flag

 drivers/usb/gadget/composite.c       |  10 +++-
 drivers/usb/gadget/function/f_obex.c |  19 +------
 drivers/usb/gadget/function/f_uvc.c  |   7 +--
 include/linux/usb/composite.h        |   2 +
 include/linux/usb/gadget.h           | 100 ++++++++++++++++++++++++++++++++---
 5 files changed, 106 insertions(+), 32 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists