Amit Blay | 3 Jul 2011 16:29

[PATCH 0/3] usb:gadget: Add SuperSpeed Function Power Management

This patch series adds Function Power Management to the Gadget Framework for
SuperSpeed USB.

To test the new code, g_zero gadget was updated to support SuperSpeed, and
f_sourcesink function was updated to support SuperSpeed specific handlers.

We used dummy_hcd to emulate UDC & HCD that support SuperSpeed.
We tested the development with our unittest environment which is based on
libusb & GoogleTest. This environment is submitted seperately by
tlinder <at> codeaurora.org.

Amit Blay (3):
  usb: Add SuperSpeed support to g_zero gadget
  usb:gadget: Add SuperSpeed function power management
  usb:gadget: SuperSpeed function power management testing support

 drivers/usb/gadget/dummy_hcd.c    |    3 +-
 drivers/usb/gadget/f_loopback.c   |   57 ++++++++++-
 drivers/usb/gadget/f_sourcesink.c |  217 ++++++++++++++++++++++++++++++++++++-
 drivers/usb/gadget/udc-core.c     |    2 +-
 drivers/usb/gadget/zero.c         |    8 +-
 include/linux/usb/ch9.h           |    8 ++
 include/linux/usb/gadget.h        |   35 +++++--
 7 files changed, 315 insertions(+), 15 deletions(-)

--

-- 
1.7.3.3

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
(Continue reading)

Amit Blay | 3 Jul 2011 16:29

[RFC/PATCH 2/3] usb:gadget: Add SuperSpeed function power management

1. Add missing definitions in ch9.h for requests tarageted to an
Interface: GET_STATUS & SET_FEATURE(FUNC_SUSPEND).

2. Add func_wakeup api to usb_gadget_ops.
Super-Speed device must provide interface number to the UDC when
it triggers remote wakeup (function wake).
The func_wakeup api is used instead of the wakeup api, when the
gadget is connected in Super-Speed. The wakeup api is left as is,
and it is used when the gadget is connected in High-Speed. Therefore,
no change is required in non Super-Speed UDCs.

Signed-off-by: Amit Blay <ablay <at> codeaurora.org>

---
 drivers/usb/gadget/udc-core.c |    2 +-
 drivers/usb/gadget/zero.c     |    6 +++++-
 include/linux/usb/ch9.h       |    8 ++++++++
 include/linux/usb/gadget.h    |   35 +++++++++++++++++++++++++++--------
 4 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 05ba472..beb7e89 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
 <at>  <at>  -347,7 +347,7  <at>  <at>  static ssize_t usb_udc_srp_store(struct device *dev,
 	struct usb_udc		*udc = dev_get_drvdata(dev);

 	if (sysfs_streq(buf, "1"))
-		usb_gadget_wakeup(udc->gadget);
+		usb_gadget_wakeup(udc->gadget, 0);
(Continue reading)

Amit Blay | 3 Jul 2011 16:29

[RFC/PATCH 3/3] usb:gadget: SuperSpeed function power management testing support

1. Fix dummy_hcd to let the function handle GET_STATUS(Interface) request.
2. Fix a bug in f_loopback Gadget which updated the bmAttribute of
f_sourcesink instead of f_loopback.
3. Update f_sourcesink Gadget to support function suspend & wakeup.
This is done by adding get_status() & func_suspend() handlers.
The current status of the function is controlable via debug FS:
(wakeup capable, wakeup enabled, suspended).

Signed-off-by: Amit Blay <ablay <at> codeaurora.org>

---
 drivers/usb/gadget/dummy_hcd.c    |    3 +-
 drivers/usb/gadget/f_loopback.c   |    2 +-
 drivers/usb/gadget/f_sourcesink.c |  162 +++++++++++++++++++++++++++++++++++++
 3 files changed, 165 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index e755a9d..7f6a2d8 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
 <at>  <at>  -1496,7 +1496,8  <at>  <at>  static int handle_control_request(struct dummy_hcd *dum_hcd, struct urb *urb,
 					   Dev_InRequest) {
 					buf[0] = (u8)dum->devstatus;
 				} else
-					buf[0] = 0;
+					/* Let the function handle this */
+					break;
 			}
 			if (urb->transfer_buffer_length > 1)
 				buf[1] = 0;
(Continue reading)

Jeff Ohlstein | 5 Jul 2011 21:15

Re: [stable] [PATCH v2] msm: timer: compensate for timer shift in msm_read_timer_count

Greg KH wrote:
> On Mon, Jun 20, 2011 at 04:27:16PM -0700, David Brown wrote:
>> I don't think this patch was intended for stable in the first place.
>> Jeff, this is a fix for 3.0-rcx, right?
> 
> Then why was it sent to stable <at> kernel.org?
> 
> confused,
> 
> greg k-h
> 

Sorry, this was indeed intended for stable. I will include the Cc: tag
in future patches stable. However, since this was already picked up in
Linus's tree, how should I proceed to get it into stable?

Jeff

--

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
Greg KH | 8 Jul 2011 16:57
Picon

Re: [Qualcomm PM8921 MFD 4/6] mfd: pm8xxx-mpp: Add pm8xxx MPP driver

On Wed, Mar 02, 2011 at 02:13:19PM -0800, adharmap <at> codeaurora.org wrote:
> From: David Collins <collinsd <at> codeaurora.org>
> 
> Add support for multi-purpose pins (MPPs) on Qualcomm PM8xxx
> PMIC chips.
> 
> PM8xxx MPPs can be configured as digital or analog inputs or
> outputs, current sinks, or buffers.
> 
> Change-Id: Iab39b2f7c2ba3f35ef6ac74d37ee7add8c70681f

What is this line for?  It makes no sense for a patch that is being
submitted to the kernel tree, please remove it.

> Signed-off-by: David Collins <collinsd <at> codeaurora.org>

Why have you sent this patch from a different email address than this
one?

greg k-h
Greg KH | 8 Jul 2011 17:44
Picon

Re: [Qualcomm PM8921 MFD 3/6] gpio: pm8xxx-gpio: Add pm8xxx gpio driver

On Wed, Mar 02, 2011 at 02:13:18PM -0800, adharmap <at> codeaurora.org wrote:
> From: Abhijeet Dharmapurikar <adharmap <at> codeaurora.org>
> 
> Add support for GPIO on Qualcomm PM8xxx PMIC chips.
> 
> Change-Id: I5c00baeedc6c40ed40065d15c83577051e6ac9c6

What is this line for?
Abhijeet Dharmapurikar | 8 Jul 2011 19:23

Re: [Qualcomm PM8921 MFD 3/6] gpio: pm8xxx-gpio: Add pm8xxx gpio driver

On 07/08/2011 08:44 AM, Greg KH wrote:
> On Wed, Mar 02, 2011 at 02:13:18PM -0800, adharmap <at> codeaurora.org wrote:
>> From: Abhijeet Dharmapurikar<adharmap <at> codeaurora.org>
>>
>> Add support for GPIO on Qualcomm PM8xxx PMIC chips.
>>
>> Change-Id: I5c00baeedc6c40ed40065d15c83577051e6ac9c6
>
> What is this line for?

That commit text artifact is for our internal review tool (gerrit). I 
cleaned it up in the later revision of the patch series.
The latest can be found here

https://lkml.org/lkml/2011/4/5/427

Thanks for looking,
Abhijeet

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Paul Mundt | 13 Jul 2011 10:13
Gravatar

Re: [PATCH 5/5] drivers/video/msm/mdp.c: adjust error handling code

On Mon, Jul 04, 2011 at 04:11:45PM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia <at> diku.dk>
> 
> Use the error handling code at the end of the function, rather than
> returning directly.
> 
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // <smpl>
>  <at> r <at> 
> identifier x;
>  <at>  <at> 
> 
> kfree(x)
> 
>  <at>  <at> 
> identifier r.x;
> expression E1!=0,E2,E3,E4;
> statement S;
>  <at>  <at> 
> 
> (
> if (<+...x...+>) S
> |
> if (...) { ... when != kfree(x)
>                when != if (...) { ... kfree(x); ... }
>                when != x = E3
> * return E1;
> }
(Continue reading)

David Brown | 13 Jul 2011 19:49
Gravatar

Re: [PATCH 5/5] drivers/video/msm/mdp.c: adjust error handling code

On Wed, Jul 13 2011, Paul Mundt wrote:

>> I wonder if the error handling code at the end of the function should be
>> calling clk_put as well?  In that case, having a separate label for this
>> case would be useful.  Otherwise, one of error_request_irq and error_get_clk
>> can be deleted
>> 
> The MSM implementation for it is simply a nop, so it's not going to
> really matter one way or the other. In terms of general consistency it
> might be worth implementing.

Today, at least.  Hopefully this will get better, since we can turn off
our clocks.

David

--

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
Oliver Neukum | 19 Jul 2011 11:18
Picon

Re: [PATCH/RFC 5/5] usb: Add support for streams alloc/dealloc to devio.c

Am Dienstag, 19. Juli 2011, 11:12:39 schrieb Amit Blay:

> > So it seems like you also need a way for userspace to specify which
> > endpoints get streams, and which endpoints have streams freed.  I will
> 
> What I have in mind is user space passing a structure holding:
> 
> 1. Interface number [IN]
> 2. Bitmap indicating which EP to allocate streams for [IN]

If this is a bitmap,

> 3. Number of streams to allocate, one number [IN}
> 4. Number of streams actually allocated, one number  [OUT]

how can those be scalars? 

	Regards
		Oliver

Gmane