console=ttymxc0,115200n8 earlyprintk root=/dev/mtdblock3 ro
booting kernel with devicetree
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.15.0-rc1-next-20140415-dirty (s...@shc.zet) (gcc version 4.7.3
(GCC) ) #11 PREEMPT Wed Apr 16 09:40:14 MSK 2014
> On Wed, Apr 16, 2014 at 12:23 AM, Peter Chen
> wrote:
> > Please check if below patch is existed
> >
> > commit 3b5d3e6845bfe68777d069886b0d1cd5f23b9d58
> > Author: Chris Ruehl
> > Date: Fri Jan 10 13:51:29 2014 +0800
> >
> > usb: chipidea: Fix Internal error: : 808 [#1] ARM related to
Hi,
On Tue, Apr 15, 2014 at 01:55:38PM -0400, Alan Stern wrote:
> On Tue, 15 Apr 2014, Felipe Balbi wrote:
>
> > > 2. Does device need to know OUT transactions before hand so that OUT
> > > requests are queued for endpoint before packets are received
> > > from host?
> >
> > well, no. Gadget dri
On Tue, Apr 15, 2014 at 08:08:32PM +0200, Paul Bolle wrote:
> On Tue, 2014-04-15 at 12:23 -0500, Felipe Balbi wrote:
> > so this means that drivers/usb/gadget/mv_u3d_core.c isn't used either ?
>
> Why should it? There's no dependency on CPU_MMP3 for USB_MV_U3D anymore,
> is there?
no, but the UDC
Hi,
On Wed, Apr 16, 2014 at 10:13:38AM +0800, Wang, Yu wrote:
> >> >how did you test it ? According to [1] Merrifield won't work for more
> >> >than 20s or so with v3.14 and, since there is no resolution on the
> >> >thread, I assume today's mainline won't work either.
> >> >
> >> >Anyway, if you
On Wed, Apr 16, 2014 at 12:23 AM, Peter Chen wrote:
> Please check if below patch is existed
>
> commit 3b5d3e6845bfe68777d069886b0d1cd5f23b9d58
> Author: Chris Ruehl
> Date: Fri Jan 10 13:51:29 2014 +0800
>
> usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
>
> * i
> Hi,
>
> I am trying to add USBOTG support to mx27pdk with the following dts patch:
>
> --- a/arch/arm/boot/dts/imx27-pdk.dts
> +++ b/arch/arm/boot/dts/imx27-pdk.dts
> @@ -78,6 +78,14 @@
> status = "okay";
> };
>
> +&usbotg {
> + pinctrl-names = "default";
> + pinctrl-0
On Tue, Apr 15, 2014 at 09:53:49AM -0500, Felipe Balbi wrote:
>Hi,
>
>On Tue, Apr 15, 2014 at 06:29:20PM +0800, Wang, Yu wrote:
>> On Fri, Apr 11, 2014 at 06:19:57PM -0500, Felipe Balbi wrote:
>> >Hi,
>> >
>> >On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote:
>> >> Hi Balbi,
>> >>
>> >> At
Allows the driver to turn off the clock during suspend for additional power
savings.
Signed-off-by: Michael Welling
---
drivers/usb/host/ehci-atmel.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehc
On 04/15/2014 05:34 PM, Johan Hovold wrote:
On Tue, Apr 15, 2014 at 04:06:11PM +0200, Johan Hovold wrote:
Specifically, I asked if you are able to make sense of the values of
register 0x2518. The reason I ask is that your patch changes the value
of that register from 0x50 (set in ch341_config
Hi Alan,
On Tuesday 15 April 2014 14:05:14 Alan Stern wrote:
> On Tue, 15 Apr 2014, Laurent Pinchart wrote:
> > > I'm open to the idea of exporting the hub functions. In the end, it
> > > doesn't make all that much difference (it would save a little object
> > > code).
> >
> > I would have agreed
Hi Alan,
On Tuesday 15 April 2014 14:01:54 Alan Stern wrote:
> On Tue, 15 Apr 2014, Laurent Pinchart wrote:
> > Platform drivers sometimes need to perform specific handling of hub
> > control requests. Make this possible by exporting the ohci_hub_control()
> > function which can then be called fro
Hi!
> > From: Felipe Balbi
>
> This patch, which is present in 3.14-rc4 as 30a70b026 ("usb: musb: fix
> obex in g_nokia.ko causing kernel panic"), breaks USB gadget support
> on my Pandaboard. Bisecting points to this commit, reverting it makes
> USB gadget support work again. The problem is t
Yes, we tried with 3.14 and after less than 24hrs.
What could we do to fix the issue?
Thank you,
Matteo
Here's dmesg output:
[103200.145660] INFO: task :2341 blocked for more than 120 seconds.
[103200.145774] Not tainted 3.14.0-+ #3
[103200.145844] "echo 0 > /proc/sys/kern
Hi,
On 04/15/2014 09:42 PM, Julius Werner wrote:
+hdegoede
I tried to apply this patch on top of 3.15-rc1, but it fails because of the
streams support added to xhci_find_new_dequeue_state()
After some manual editing the interesting parts of
xhci_find_new_dequeue_state() looks like this:
@@ -
On 04/14/2014 12:08 PM, Laurent Pinchart wrote:
Hello,
I've noticed two issues with teh ohci-jz4740 driver while reading the source
code. Here are two patches to fix them. Both are untested as I don't have
access to the hardware.
I unfortunately don't have the hardware handy for testing at the
+hdegoede
> I tried to apply this patch on top of 3.15-rc1, but it fails because of the
> streams support added to xhci_find_new_dequeue_state()
>
> After some manual editing the interesting parts of
> xhci_find_new_dequeue_state() looks like this:
>
> @@ -577,46 +568,57 @@ void xhci_find_new_dequ
Estimado cliente,
Su antigua contraseña será cambiada si usted no responde a esta advertencia de
seguridad inmediatamente.
Rellene aquí => https://667jnbv.typeform.com/to/N2B2Fq
Tenga en cuenta que la página expirará cinco horas después fue enviado este
correo electrónico.
--
To unsubscribe from
On Tue, 15 Apr 2014, Stefani Seibold wrote:
> > So two devices failed to initialize after the drivers were rebound: 3-4
> > and 2-2. We know that 3-4 was the mass-storage device, but I can't
> > tell from this log what 2-2 was.
> >
>
> 2-2 is a custom HID device which handles the front pane
Am Dienstag, den 15.04.2014, 15:14 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
>
> > > > usbcore: registered new interface driver USB-SATA-storage
> > > > USB SATA Mass Storage support registered.
> > > > usb 1-4: new high-speed USB device number 4 using ehci-pci
> > >
Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
>
> > I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
> > the following dmesg log:
> >
> > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> > ehci-pci: EHC
On Tue, 15 Apr 2014, Stefani Seibold wrote:
> > > usbcore: registered new interface driver USB-SATA-storage
> > > USB SATA Mass Storage support registered.
> > > usb 1-4: new high-speed USB device number 4 using ehci-pci
> > > : ports detected
> >
> > What driver is this? I've never heard of
Am Dienstag, den 15.04.2014, 15:05 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
>
> > > One other thing you can try is to increase the reset timeout in
> > > drivers/usb/host/ehci-hub.c. This is under the USB_PORT_FEAT_RESET
> > > case in ehci_hub_control(), around li
Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
>
> > I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
> > the following dmesg log:
> >
> > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> > ehci-pci: EHC
On Tue, 15 Apr 2014, Stefani Seibold wrote:
> > One other thing you can try is to increase the reset timeout in
> > drivers/usb/host/ehci-hub.c. This is under the USB_PORT_FEAT_RESET
> > case in ehci_hub_control(), around line 1225:
> >
> > /*
> >
On Tue, 15 Apr 2014, Stefani Seibold wrote:
> I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
> the following dmesg log:
>
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-pci: EHCI PCI platform driver
> ehci-pci :00:17.2: EHCI Host Controller
> ehci-
Am Dienstag, den 15.04.2014, 15:49 -0300 schrieb Thadeu Lima de Souza
Cascardo:
> On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote:
> > Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
> > Cascardo:
> > > On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.
On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote:
> Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
> Cascardo:
> > On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
> > >
> > > Zitat von Thadeu Lima de Souza Cascardo :
> > >
> > > >On Tue,
Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
Cascardo:
> On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
> >
> > Zitat von Thadeu Lima de Souza Cascardo :
> >
> > >On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
> > >>
> > >>Zitat
On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
>
> Zitat von Thadeu Lima de Souza Cascardo :
>
> >On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
> >>
> >>Zitat von Thadeu Lima de Souza Cascardo :
> >>
> >>>On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef.
Am Montag, den 14.04.2014, 13:58 -0400 schrieb Alan Stern:
> On Mon, 14 Apr 2014, Stefani Seibold wrote:
>
> > > > An other PowerPC device which is nearly eactly the same HW but without
> > > > this USB HUB works perfectly.
> > >
> > > Maybe you should replace that hub with a different brand.
>
Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern:
> On Mon, 14 Apr 2014 stef...@seibold.net wrote:
>
> > Zitat von Alan Stern :
> >
> >
> > >> <6>[ 167.936921] usb 2-2.1: new full-speed USB device number 3
> > >> using ohci-pci
> > >> <6>[ 168.067890] usb 2-2.1: New USB device foun
On Tue, 2014-04-15 at 12:23 -0500, Felipe Balbi wrote:
> so this means that drivers/usb/gadget/mv_u3d_core.c isn't used either ?
Why should it? There's no dependency on CPU_MMP3 for USB_MV_U3D anymore,
is there?
> Instead of deleting this and introducing a new driver, why don't you
> just help fi
On Tue, 15 Apr 2014, Laurent Pinchart wrote:
> > I'm open to the idea of exporting the hub functions. In the end, it doesn't
> > make all that much difference (it would save a little object code).
>
> I would have agreed to keep the code as it is today if you had thought that
> exporting the hub
On Tue, 15 Apr 2014, Laurent Pinchart wrote:
> Platform drivers sometimes need to perform specific handling of hub
> control requests. Make this possible by exporting the ohci_hub_control()
> function which can then be called from a custom hub control handler in
> the default case.
You should als
On Tue, 15 Apr 2014, Stephen Warren wrote:
> On 04/15/2014 10:06 AM, Laurent Pinchart wrote:
> > Platform drivers sometimes need to perform specific handling of hub
> > control requests. Make this possible by exporting the ehci_hub_control()
> > function which can then be called from a custom hub
On Tue, 15 Apr 2014, Felipe Balbi wrote:
> > 2. Does device need to know OUT transactions before hand so that OUT
> > requests are queued for endpoint before packets are received
> > from host?
>
> well, no. Gadget driver shouldn't depend on that. That's UDC driver's
> responsability to manage th
On Tue, Apr 15, 2014 at 04:06:11PM +0200, Johan Hovold wrote:
> On Mon, Apr 14, 2014 at 07:54:17PM +, Karl Palsson wrote:
> > + if (C_PARENB(tty)) {
> > + if (C_PARODD(tty)) {
> > + if (C_CMSPAR(tty)) {
>
> Thanks for fixing the C_CMSPAR macro, but you didn't add
On Tue, Apr 15, 2014 at 01:36:23PM +0200, Paul Bolle wrote:
> The usb phy driver for mv_u3d got added in v3.7 through commit
> a67e76ac904c ("usb: phy: mv_u3d: Add usb phy driver for mv_u3d"). It
> then depended on USB_MV_U3D. And that symbol depended
> on CPU_MMP3 at that time. But CPU_MMP3 has ne
On Wed, Apr 02, 2014 at 03:21:44PM +0200, Daniel Mack wrote:
> On 04/02/2014 02:12 PM, Sergei Shtylyov wrote:
> > On 02-04-2014 15:58, Daniel Mack wrote:
> >> +static inline void musb_platform_reset(struct musb *musb)
> >> +{
> >> + if (musb->ops->reset)
> >> + musb->ops->reset(musb);
> >
Hi,
On Wed, Mar 26, 2014 at 03:37:52PM +0530, sundeep subbaraya wrote:
> >> + INIT_LIST_HEAD(&req->queue);
> >
> > remove this INIT_LIST_HEAD();
> >
> > also, before returning, I suppose you probably want to link the request
> > to the endpoint somehow. Usually people save the endpoint pointer
On 04/15/2014 10:06 AM, Laurent Pinchart wrote:
> Platform drivers sometimes need to perform specific handling of hub
> control requests. Make this possible by exporting the ehci_hub_control()
> function which can then be called from a custom hub control handler in
> the default case.
I recall try
On Sun, Apr 13, 2014 at 05:53:10PM -0700, Benjamin West wrote:
> On Tue, Apr 8, 2014 at 12:52 AM, Johan Hovold wrote:
> > On Mon, Apr 07, 2014 at 07:26:01PM +0300, Mathias Nyman wrote:
> >> On 04/03/2014 07:32 PM, Johan Hovold wrote:
> >> > Hi Mathias and Benjamin,
> >> >
> >> > Mathias, I underst
On Sun, Apr 13, 2014 at 05:04:50PM -0700, Benjamin West wrote:
> On Thu, Apr 3, 2014 at 9:32 AM, Johan Hovold wrote:
> >> Ok, looks like the same error as with usb-next. Could you provide a log
> >> with debugging enabled when enumeration fails on v3.14-rc7? Perhaps
> >> someone who knows more ab
Platform drivers sometimes need to perform specific handling of hub
control requests. Make this possible by exporting the ehci_hub_control()
function which can then be called from a custom hub control handler in
the default case.
Signed-off-by: Laurent Pinchart
---
drivers/usb/host/ehci-hub.c
Platform drivers sometimes need to perform specific handling of hub
control requests. Make this possible by exporting the ohci_hub_control()
function which can then be called from a custom hub control handler in
the default case.
Signed-off-by: Laurent Pinchart
---
drivers/usb/host/ohci-at91.c
Override the hub control operation to enable and disable external
regulators for the ports vbus power supply in response to clear/set
USB_PORT_FEAT_POWER requests.
Signed-off-by: Laurent Pinchart
---
drivers/usb/host/ohci-pxa27x.c | 67 ++
1 file changed,
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-pxa/zeus.c | 89 ++--
1 file changed, 48 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index b19d1c3..205f9bf 100644
--- a/arch/arm/mach-pxa/zeus.c
+++
Hello,
The PXA27x OHCI implementation doesn't perform automatic control of port power
supplies for all ports. While the PPS and LSDA bits of the HcRhPortStatus
register are implemented, only a subset of ports have an external power enable
pin controlled by the port status register. Other ports nee
Hi Alan,
Thank you for your comments.
On Monday 14 April 2014 10:35:43 Alan Stern wrote:
> On Mon, 14 Apr 2014, Laurent Pinchart wrote:
> > Hello,
> >
> > The PXA27x OHCI implementation doesn't perform automatic control of port
> > power supplies for all ports. While the PPS and LSDA bits of the
Zitat von Thadeu Lima de Souza Cascardo :
On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
Zitat von Thadeu Lima de Souza Cascardo :
>On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
>>
>>Zitat von Benjamin Herrenschmidt :
>>
>>>I don't know about EHCI
Hi,
On Tue, Apr 15, 2014 at 06:29:20PM +0800, Wang, Yu wrote:
> On Fri, Apr 11, 2014 at 06:19:57PM -0500, Felipe Balbi wrote:
> >Hi,
> >
> >On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote:
> >> Hi Balbi,
> >>
> >> At first, thank you to help give the response in patience.
> >>
> >> > Hi
On Mon, Apr 14, 2014 at 07:54:17PM +, Karl Palsson wrote:
> Based on wireshark packet traces from a windows machine.
>
> ch340 and ch341 both seem to support all parity modes, but only the ch341
> appears to support variable data bits and variable stop bits, so those are
> left
> unimplemente
On Mon, 14 Apr 2014, Stephen Warren wrote:
> From: Stephen Warren
>
> To avoid memory fetch underflows with larger USB transfers, Tegra SoCs
> need txfill_tuning's txfifothresh register field set to a non-default
> value. Add a custom reset override in order to set this up.
>
> These values are
On Tue, 15 Apr 2014, Pratyush Anand wrote:
> > How about just creating a normal USB device instead of a platform
> > device? I think all you have to do is make usb_new_device() avoid
> > calling usb_enumerate_device() when the new flag is set.
>
> I had thought of this. But, I had found that e
Hi,
On Monday 14 April 2014 07:19 PM, Tomasz Figa wrote:
> On 14.04.2014 15:40, Vivek Gautam wrote:
>> On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I
>> wrote:
>>>
>>>
>>> On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I
Hi Heikki,
On Tue, Dec 10, 2013 at 7:25 PM, Heikki Krogerus
wrote:
Giving life to this thread after long time.
> Hi,
>
> On Tue, Dec 10, 2013 at 04:25:25PM +0530, Vivek Gautam wrote:
>> @@ -170,6 +189,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
>> }
>>
>> /*
>> +
On 04/03/2014 12:29 AM, Julius Werner wrote:
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this up fo
On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
>
> Zitat von Thadeu Lima de Souza Cascardo :
>
> >On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
> >>
> >>Zitat von Benjamin Herrenschmidt :
> >>
> >>>I don't know about EHCI specifically but this is a kno
On Tue, Apr 15, 2014 at 11:13:17AM +0200, Johan Hovold wrote:
> On Tue, Apr 15, 2014 at 10:35:19AM +0200, Oliver Neukum wrote:
> > On Mon, 2014-04-14 at 21:58 +0200, Johan Hovold wrote:
> >
> > > Fix this by implementing a delayed-write queue using urb anchors and
> > > making sure to discard the
The usb phy driver for mv_u3d got added in v3.7 through commit
a67e76ac904c ("usb: phy: mv_u3d: Add usb phy driver for mv_u3d"). It
then depended on USB_MV_U3D. And that symbol depended
on CPU_MMP3 at that time. But CPU_MMP3 has never been part of the tree.
This means that this drive was unbuildabl
On 2014-03-27 16:15, Andreas Larsson wrote:
This patchset:
- Adds some OF related improvements suggested by Mark
Rutland.
- Adds ep.maxpacket_limit to the debugfs file and adds a check if
gr_ep_enable is called with a maxpacket value greater than
ep.maxpacket_limit.
- Fixes a bu
On Tue, Apr 15, 2014 at 02:20:13AM +0800, Alan Stern wrote:
> On Mon, 14 Apr 2014, Pratyush Anand wrote:
>
> > Hi Alan,
> >
> > On Fri, Apr 11, 2014 at 06:56:37PM +0800, Pratyush ANAND wrote:
> > > Lecroy's USB Compliance suites provide option to test Link Layer Tests
> > > for Super Speed device
On Fri, Apr 11, 2014 at 06:19:57PM -0500, Felipe Balbi wrote:
>Hi,
>
>On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote:
>> Hi Balbi,
>>
>> At first, thank you to help give the response in patience.
>>
>> > Hi,
>> >
>> > On Wed, Apr 09, 2014 at 02:08:32PM +0800, Wang, Yu wrote:
>> > > Glad
Zitat von Thadeu Lima de Souza Cascardo :
On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
Zitat von Benjamin Herrenschmidt :
>I don't know about EHCI specifically but this is a known issue with
>XHCI, I observe similar issues on other powerpc platforms (servers)
>and thi
On Tue, Apr 15, 2014 at 10:35:19AM +0200, Oliver Neukum wrote:
> On Mon, 2014-04-14 at 21:58 +0200, Johan Hovold wrote:
>
> > Fix this by implementing a delayed-write queue using urb anchors and
> > making sure to discard the queue properly at shutdown.
>
> Looks very good, with one exception: ac
On 04/14/2014 08:12 PM, Christoph Lameter wrote:
n Mon, 14 Apr 2014, Grygorii Strashko wrote:
Hi All,
I'm observing a huge number of warnings produced during the boot of my Keystone
2 board
when USB is enabled.
[2.496460] BUG: using __this_cpu_read() in preemptible [] code:
khub
On Tue, Apr 15, 2014 at 01:48:00AM +0800, Paul Zimmerman wrote:
> > From: linux-usb-ow...@vger.kernel.org
> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Pratyush Anand
> > Sent: Monday, April 14, 2014 1:48 AM
> >
> > On Mon, Apr 14, 2014 at 09:42:25AM +0530, Pratyush Anand wrote:
> > >
On Tue, Apr 15, 2014 at 04:24:10PM +0800, Xiao Jin wrote:
> On 04/15/2014 03:58 AM, Johan Hovold wrote:
> > Jin, did you check what closing_wait setting your application is using?
>
> I check the closing_wait is 30s by default. Below is the trace we get
> when reproduced problem.
>
>
On Mon, Apr 14, 2014 at 11:24:18PM +0800, Mathias Nyman wrote:
> Hi
>
> On 04/11/2014 01:20 PM, Pratyush Anand wrote:
> > As best case, a host controller should support U0 to U1 switching for
> > the devices connected below any tier of hub level supported by usb
> > specification. Therefore xhci_c
On Mon, 2014-04-14 at 21:58 +0200, Johan Hovold wrote:
> Fix this by implementing a delayed-write queue using urb anchors and
> making sure to discard the queue properly at shutdown.
Looks very good, with one exception: acm_tty_close() must
synchronously resume the device so that the anchor is em
Hi, Johan,
On 04/15/2014 03:58 AM, Johan Hovold wrote:
The current ACM runtime-suspend implementation is broken in several
ways:
Firstly, it buffers only the first write request being made while
suspended -- any further writes are silently dropped.
Secondly, writes being dropped also leak writ
Hi Felipe,
> >> On 04/02/2014 10:47 AM, Peter Chen wrote:
> >>> We have historic problem that the gadget will not work if the gadget
> >>> is build-in and the udc driver is defered probe due to some
> >>> resources are not ready. Below links are related to this problem.
> >>>
> >>> http://marc.inf
This patch reduce unecessary NETTX softirq call caused by
free skb header. You will see this softirq comes twice while
there is only one TX packet to be transmitted.
So using dev_kfree_skb() instead of dev_kfree_skb_any() to
avoid this problem.
Signed-off-by: Macpaul Lin
Cc: David S. Miller
Cc:
On Tue, Apr 15, 2014 at 09:43:04AM +0800, Li Jun wrote:
> On Mon, Apr 14, 2014 at 08:45:13PM +0800, Peter Chen wrote:
> > On Mon, Apr 14, 2014 at 10:22:32AM +0800, Li Jun wrote:
> > > On Mon, Apr 14, 2014 at 09:37:50AM +0800, Li Jun wrote:
> > > > From: Li Jun
> > > >
> > > > This patchset adds U
75 matches
Mail list logo
