On Thu, Oct 8, 2015 at 1:37 PM, Peter Chen wrote:
> On Mon, Oct 05, 2015 at 07:27:23PM +0530, Jayan John wrote:
>> We are developing a custom USB device on a iMX6q platform with a Chipidea
>> HDRC. The device uses a single NCM interface for communication with another
>> OTG device i.e. Chipidea HD
On Fri, Oct 02, 2015 at 11:05:28AM -0500, Felipe Balbi wrote:
> Hi Alan,
>
> here's a question which I hope you can help me understand :-)
>
> Why do we have that kthread for the mass storage gadgets ? I noticed a very
> interesting behavior.
>
> Basically, the MSC class works in a loop like so:
On Thu, Oct 08, 2015 at 05:16:06PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 08, 2015 at 09:52:52AM +, Peter Chen wrote:
> > I can't reproduce it for 5 hours, and will change pinmux (do the same
> > thing with your platform), and do the overnight test.
>
I still not reproduce it.
cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
However, SET_LINE_CTL functions properly. When the driver tries to modify
the register, it reads it, modifies some bits and writes back. Because the
read bytes were swapped, this often results in an invalid value to be written.
Calls to dwc2_core_reset() are currently very slow, taking at least
150ms (possibly more). It behooves us to take as many of these calls
out as possible.
It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
should (as documented in the code) only be needed if we need to do a P
Hi,
On Wed, Oct 7, 2015 at 5:48 PM, Douglas Anderson wrote:
> In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
> extra reset to the probe path for the dwc2 USB controllers. This
> allowed proper detection of parameters even if the firmware had already
> used the USB part.
>
On Thu, Oct 08, 2015 at 07:04:05PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > * This program is free software; you can redistribute it and/or modify
> > > > * it under the terms of the GNU General Public License version 2 as
> > > > * published by the Free Software Foundation.
> > >
> > > Please,
Hi!
> > > * This program is free software; you can redistribute it and/or modify
> > > * it under the terms of the GNU General Public License version 2 as
> > > * published by the Free Software Foundation.
> >
> > Please, keep it V2 or later, if you can. It makes sharing code with U-Boot
> > (fo
On Thu, Oct 08, 2015 at 05:50:31PM +0200, Pavel Machek wrote:
> Hi!
>
> > On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote:
> > > On 14 August 2015 at 23:27, Greg KH wrote:
> > >> On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:
> > >>> + *
> > >>> + * This program is f
On Thu, Oct 08, 2015 at 09:52:52AM +, Peter Chen wrote:
> I can't reproduce it for 5 hours, and will change pinmux (do the same
> thing with your platform), and do the overnight test.
There's definitely something weird going on. Over night last night,
I left the Logitech universal receiver in
Hi!
> > What's the advantage of pushing this to userspace? By the time we
> > provide enough discoverability to enable userspace to configure itself
> > it seems like we'd have enough information to do the job anyway.
>
> you're going to be dealing with a setup where each vendor does one thing
>
Hi!
> On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote:
> > On 14 August 2015 at 23:27, Greg KH wrote:
> >> On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote:
> >>> + *
> >>> + * This program is free software; you can redistribute it and/or modify
> >>> + * it under the t
HI!
> > + int ret;
> > +
> > + mutex_lock(&gadget->lock);
> > + ret = raw_notifier_chain_unregister(&gadget->nh, nb);
>
> Greg, this is the kind of thing I wanted to avoid adding more of.
>
> I was wondering if you would accept subsystems using kdbus for
> this sort of notification. I'm ok
Hi,
it looks to me like
commit 4758dcd19a7d9ba9610b38fecb93f65f56f86346
Author: Reyad Attiyat
Date: Thu Aug 6 19:23:58 2015 +0300
usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers
should go into stable. Is there a special reason it has no CC?
Regards
Hi,
On Thu, 2015-10-08 at 16:05 +0300, Mathias Nyman wrote:
> On 08.10.2015 15:28, Daniel Thompson wrote:
> > On 08/10/15 13:05, chunfeng yun wrote:
> >> Hi,
> >> On Thu, 2015-10-01 at 12:44 +0100, Daniel Thompson wrote:
> >>> On 29/09/15 04:01, Chunfeng Yun wrote:
> There some vendor quirks f
On Thu, 2015-10-08 at 13:28 +0100, Daniel Thompson wrote:
> On 08/10/15 13:05, chunfeng yun wrote:
> > Hi,
> > On Thu, 2015-10-01 at 12:44 +0100, Daniel Thompson wrote:
> >> On 29/09/15 04:01, Chunfeng Yun wrote:
> >>> There some vendor quirks for MTK xhci host controller:
> >>> 1. It defines some
On 08/10/15 17:07, Sergei Shtylyov wrote:
On 10/8/2015 4:50 PM, Sergei Shtylyov wrote:
Implement vbus_status method of musb_platform_ops that allows
musb_core to properly represent the VBUS status of musb_dsps devices in
corresponding sysfs entry
Signed-off-by: Roman Alyautdin
---
drivers/
On 10/8/2015 4:50 PM, Sergei Shtylyov wrote:
Implement vbus_status method of musb_platform_ops that allows
musb_core to properly represent the VBUS status of musb_dsps devices in
corresponding sysfs entry
Signed-off-by: Roman Alyautdin
---
drivers/usb/musb/musb_dsps.c | 13 +
Hello.
On 10/7/2015 5:40 PM, Roman Alyautdin wrote:
Implement vbus_status method of musb_platform_ops that allows
musb_core to properly represent the VBUS status of musb_dsps devices in
corresponding sysfs entry
Signed-off-by: Roman Alyautdin
---
drivers/usb/musb/musb_dsps.c | 13 +++
On 08.10.2015 15:28, Daniel Thompson wrote:
On 08/10/15 13:05, chunfeng yun wrote:
Hi,
On Thu, 2015-10-01 at 12:44 +0100, Daniel Thompson wrote:
On 29/09/15 04:01, Chunfeng Yun wrote:
There some vendor quirks for MTK xhci host controller:
1. It defines some extra SW scheduling parameters for H
On 08/10/15 13:05, chunfeng yun wrote:
Hi,
On Thu, 2015-10-01 at 12:44 +0100, Daniel Thompson wrote:
On 29/09/15 04:01, Chunfeng Yun wrote:
There some vendor quirks for MTK xhci host controller:
1. It defines some extra SW scheduling parameters for HW
to minimize the scheduling effort for s
Hi,
On Thu, 2015-10-01 at 12:44 +0100, Daniel Thompson wrote:
> On 29/09/15 04:01, Chunfeng Yun wrote:
> > There some vendor quirks for MTK xhci host controller:
> > 1. It defines some extra SW scheduling parameters for HW
> >to minimize the scheduling effort for synchronous and
> >interrup
On Tue, Oct 06, 2015 at 07:10:44PM -0700, Liu.Zhao wrote:
> This is intended to add ZTE device PIDs on kernel.
>
> Signed-off-by: Liu.Zhao
This one is already in Linus' tree and should be backported to the
stable trees shortly. No need to resend.
Johan
--
To unsubscribe from this list: send the
Hi,
On Tue, 2015-10-06 at 19:50 +0530, Kishon Vijay Abraham I wrote:
> Hi Chunfeng,
>
> On Tuesday 29 September 2015 08:31 AM, Chunfeng Yun wrote:
> > support usb3.0 phy of mt65xx SoCs
>
> I have merged this driver. Can you also send a patch adding yourself as
> the maintainer of this driver?
>
Hi,
On Tue, 2015-09-29 at 17:49 +0300, Sergei Shtylyov wrote:
> On 09/29/2015 06:01 AM, Chunfeng Yun wrote:
>
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > .../devicetree/bindings/usb/mt8173-xhci.
Hi,
On Tue, 2015-09-29 at 17:43 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 09/29/2015 06:01 AM, Chunfeng Yun wrote:
>
> > add a DT binding documentation of usb3.0 phy for MT65xx
> > SoCs from Mediatek.
> >
> > Acked-by: Rob Herring
> > Signed-off-by: Chunfeng Yun
> > ---
> > .../devicetree
I managed to get the implementation working for us using the following dirty
patch for kernel 3.14,
-
diff -u -r a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
--- a/drivers/usb/gadget/f_fs
Hello,
On 2015-10-08 11:35, Javier Martinez Canillas wrote:
Hello,
On 10/08/2015 08:23 AM, Marek Szyprowski wrote:
Hello,
On 2015-10-08 08:02, Krzysztof Kozlowski wrote:
On 07.10.2015 23:26, Marek Szyprowski wrote:
Hello,
On 2015-10-07 02:30, Krzysztof Kozlowski wrote:
Introduction
==
>
> On Wed, Oct 07, 2015 at 09:22:22AM +0100, Russell King - ARM Linux wrote:
> > This bug is soo obscure, I'm not even sure how to start debugging it.
> > This never used to be a problem, but I'm not sure when it started as
> > USB (in general) is not something I use regularly.
> >
> > In this
Hello,
On 10/08/2015 08:23 AM, Marek Szyprowski wrote:
> Hello,
>
> On 2015-10-08 08:02, Krzysztof Kozlowski wrote:
>> On 07.10.2015 23:26, Marek Szyprowski wrote:
>>> Hello,
>>>
>>> On 2015-10-07 02:30, Krzysztof Kozlowski wrote:
Introduction
This patchset tries to fi
On Tue, Sep 29, 2015 at 1:01 PM, Felipe F. Tonello
wrote:
> Here is the third version of this patch set. It includes memory leakage bug
> fix, improvements and code cleanups.
>
> Felipe F. Tonello (4):
> usb: gadget: f_midi: free usb request when done
> usb: gadget: f_midi: free request when
On Mon, Oct 05, 2015 at 07:27:23PM +0530, Jayan John wrote:
> We are developing a custom USB device on a iMX6q platform with a Chipidea
> HDRC. The device uses a single NCM interface for communication with another
> OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance
> after
Konstantin Shkolnyy writes:
> @@ -343,6 +344,28 @@ static int cp210x_get_config(struct usb_serial_port
> *port, u8 request,
> return result;
> }
>
> + /* Workaround for swapped bytes in 16-bit value from
> CP210X_GET_LINE_CTL */
> + if (spriv->swap_get_line_ctl &&
33 matches
Mail list logo
