From: Bjørn Mork
Date: Thu, 14 Mar 2013 12:05:13 +0100
> commit bd329e1 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
> introduced a new policy, preferring MBIM for dual NCM/MBIM functions if
> the cdc_mbim driver was enabled. This caused a regression for users
> wanting to use NC
On 16.03.2013 18:39, Alan Stern wrote:
On Sat, 16 Mar 2013, Soeren Moch wrote:
I implemented the counter. The max value is sampled at the beginning of
end_free_itds(), the current counter value is sampled at the end of this
function. Counter values w/o a max number are from the error path in
it
* Felipe Balbi | 2013-01-25 11:12:41 [+0200]:
>diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
>index 40b1d88..8a1eeb2 100644
>--- a/drivers/usb/gadget/udc-core.c
>+++ b/drivers/usb/gadget/udc-core.c
>@@ -197,6 +207,8 @@ int usb_add_gadget_udc(struct device *parent, stru
On Sun, 17 Mar 2013, Soeren Moch wrote:
> For each device only one isochronous endpoint is used (EP IN4, 1x 940
> Bytes, Interval 1).
> When the ENOMEM error occurs, a huge number of iTDs is in the free_list
> of one stream. This number is much higher than the 2*M entries, which
> should be the
On Sun, 17 Mar 2013, Alan Stern wrote:
> On Sun, 17 Mar 2013, Soeren Moch wrote:
>
> > For each device only one isochronous endpoint is used (EP IN4, 1x 940
> > Bytes, Interval 1).
> > When the ENOMEM error occurs, a huge number of iTDs is in the free_list
> > of one stream. This number is much
On Saturday 16 March 2013 01:30:32 Alexey Khoroshilov wrote:
> acm_probe() ignores errors in tty_port_register_device()
> and leaves intfdata pointing to freed memory on alloc_fail7
> error path. The patch fixes the both issues.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
I have a pandora board which has similar musb setup to beagleboard
(OMAP3530 + TWL4030) and musb never worked well on it for me in mainline.
Well it usually works if you plug the cable once, but as soon as you start
replugging cables and mixing host adapter into the game it totally breaks
and reboo
There is no need to do it, otg.set_suspend(false) (which itself
comes from runtime_pm OMAP glue calls) will enable it later anyway.
This used to be the place where things were enabled if booted with
cable connected before runtime_pm conversion, but now can be dropped.
Signed-off-by: Grazvydas Igno
In some rare cases we may get multiple interrupts that will generate
duplicate omap_musb_mailbox() calls. This is a problem because each
VBUS/ID event generates runtime_pm call in OMAP glue code, causing
unbalanced gets or puts and breaking PM.
The same goes for initial state, glue already default
With runtime_pm in place there is no longer need to turn the phy
on/off in OTG layer on cable connect/disconnect, OMAP glue does
this through otg.set_suspend() callback after it's called through
omap_musb_mailbox() on VBUS/ID interrupt. Not doing this will save
power when cable is connected but no
On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
is updated correctly. It does work fine when PHY is powered down though.
To work around that we have to poll.
This patch also moves twl->linkstat upda
On USB_EVENT_ID event the musb glue enables VBUS by calling
omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
USB_EVENT_NONE reverse action is never made, and that breaks PM.
Disable VBUS on USB_EVENT_NONE to be sure musb session is ended
on cable unplug so that PM works.
Signed-o
On some platform configurations (like OMAP3+twl4030) it's the platform
code that enables VBUS, not OTG transceiver, so call vbus platform
callback instead, it will then call the transceiver if needed.
This fixes a use case where USB cable is plugged first and gadget
driver is loaded later after th
At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.
Signed-off-by: Grazvydas Ignotas
---
drivers/usb/phy/ph
Userspace applications need to know the maximum supported message
size.
The cdc-wdm driver translates between a character device stream
and a message based protocol. Each message is transported as a
usb control message with no further encapsulation or syncronization.
Each read or write on the cha
On Saturday 16 March 2013 23:47:19 Du Xing wrote:
> On Friday, March 15, 2013 12:53 AM, Oliver Neukum wrote:
>
> > The problem is that I needed to work around the counting nature of
> > completions.
> > If you go to a waitqueue the need is removed. Your original patch together
> > with
> > the c
On Fri, Mar 15, 2013 at 10:47:50AM -0400, Alan Stern wrote:
> On Fri, 15 Mar 2013, Peter Chen wrote:
>
> > On Thu, Mar 14, 2013 at 10:59:45AM -0400, Alan Stern wrote:
> > > On Thu, 14 Mar 2013, Peter Chen wrote:
> > >
> > > > /home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c
On Fri, Mar 15, 2013 at 10:18:57AM -0700, Sarah Sharp wrote:
> On Fri, Mar 15, 2013 at 10:47:50AM -0400, Alan Stern wrote:
> > On Fri, 15 Mar 2013, Peter Chen wrote:
> >
> > > On Thu, Mar 14, 2013 at 10:59:45AM -0400, Alan Stern wrote:
> > > > On Thu, 14 Mar 2013, Peter Chen wrote:
> > > >
> > >
On Fri, Mar 15, 2013 at 11:04:47PM +0200, Svetoslav Neykov wrote:
> Hi Peter,
>
> >> There is a core on mips which doesn't support otg. From my point of
> >> view, support for dual_role should be a separate patch, ideally by
> >> Svetoslav (Cc'ed) who has this hardware, after we've cleaned up all
On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote:
>
> > Eg, for tablet or phone, the dr_mode may be "gadget", but the
> > otg_capable = 1.
>
> No, because dr_mode indicates controller's capability, and not the
> "current" mode of operation. Why would anyone want to put *that* in
On Fri, Mar 15, 2013 at 01:42:36PM +0100, Matthieu CASTET wrote:
> Peter Chen a écrit :
> > On Fri, Mar 15, 2013 at 12:38:07PM +0200, Alexander Shishkin wrote:
> Do you see any problems with this?
> >>> How to know vbus status if dr_mode == gadget, we need to indicate
> >>> connection
> >>> a
On Fri, Mar 15, 2013 at 12:37:01PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Fri, Mar 15, 2013 at 06:04:08PM +0800, Peter Chen wrote:
> > On Fri, Mar 15, 2013 at 09:51:29AM +0200, Felipe Balbi wrote:
> > >
> > > that's all wrong and needs to be fixed. UDC-core has to be the central
> > > point for
22 matches
Mail list logo
