On Tue, Sep 15, 2015 at 01:40:30PM +0800, Barry Song wrote:
> 2015-09-14 15:17 GMT+08:00 Peter Chen :
> > On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
> >> From: Rong Wang
> >>
> >> Chipidea puts ci information to drvdata, but this overwrites the drvdata
> >> placed by EHCI core. EH
2015-09-14 15:17 GMT+08:00 Peter Chen :
> On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
>> From: Rong Wang
>>
>> Chipidea puts ci information to drvdata, but this overwrites the drvdata
>> placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
>> from codes like
Hi,
On Mon, Sep 14, 2015 at 9:54 PM, Hans de Goede wrote:
> Hi,
>
>
> On 09/14/2015 10:25 PM, Maxime Ripard wrote:
>>
>> On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 10-09-15 20:30, Maxime Ripard wrote:
On Thu, Sep 10, 2015 at 08:23:23PM +0200, H
On Thu, Sep 10, 2015 at 6:47 AM, Felipe Tonello wrote:
> Hi,
>
> I have the following setup:
>
> DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB
> MIDI GADGET -> HOST
>
> When the throughput from the DSP is high, thus causing the throughput
> on the USB to be high as well, I get
On Thu, Sep 10, 2015 at 10:47:07AM +0100, Felipe Tonello wrote:
> Hi,
>
> I have the following setup:
>
> DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB
> MIDI GADGET -> HOST
>
> When the throughput from the DSP is high, thus causing the throughput
> on the USB to be high as
> On Mon, Sep 14, 2015 at 10:03 PM, Peter Chen
> wrote:
>
> > Would you try to insert udelay(100) at every clk_prepare_enable at
> > imx_prepare_enable_clks at ci_hdrc_imx.c?
>
> This did not help.
>
> It is getting late here, so I will be able to try more things tomorrow.
>
Thanks,
Peter
Hi,
On 09/14/2015 10:25 PM, Maxime Ripard wrote:
On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote:
Hi,
On 10-09-15 20:30, Maxime Ripard wrote:
On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote:
Hi,
On 04-09-15 08:43, Olliver Schinagl wrote:
Hey Hans,
On 07-08-15 1
On Mon, Sep 14, 2015 at 10:03 PM, Peter Chen wrote:
> Would you try to insert udelay(100) at every clk_prepare_enable at
> imx_prepare_enable_clks at ci_hdrc_imx.c?
This did not help.
It is getting late here, so I will be able to try more things tomorrow.
Regards,
Fabio Estevam
--
To unsubscr
ow one?
>
> Applied the patch and still see the issue:
>
> Booting Linux on physical CPU 0x0
> Linux version 4.3.0-rc1-next-20150914-dirty (fabio@fabio-Latitude-E6410) (gcc
> v5
> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, V
On Mon, Sep 14, 2015 at 9:50 PM, Peter Chen wrote:
>
> Would you try below?
>
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 4decb12..34e9f6e 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -16,4 +16,4 @@ obj-$(CONFIG_U
On Mon, Sep 14, 2015 at 10:59:29PM -0300, Fabio Estevam wrote:
> On Mon, Sep 14, 2015 at 9:19 PM, Peter Chen wrote:
>
> > That's so strange, do we need to enable clk_ahb before than clk_ipg?
> > Would you please try below diff based on my patch?
>
> Same kernel crash with this one applied on top
On Mon, Sep 14, 2015 at 9:19 PM, Peter Chen wrote:
> That's so strange, do we need to enable clk_ahb before than clk_ipg?
> Would you please try below diff based on my patch?
Same kernel crash with this one applied on top of the previous one.
>
> Meanwhile, you may need below changes
>
> http:/
ow one?
>
> Applied the patch and still see the issue:
>
> Booting Linux on physical CPU 0x0
> Linux version 4.3.0-rc1-next-20150914-dirty (fabio@fabio-Latitude-E6410) (gcc
> v5
> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, V
Hi Alan,
> > ehci_halt: premature readl returned 10001
>
> Note: 10001 instead of 1, which is what you saw in the other
> kernel. That could be highly relevant.
Really? And I thought that was the least significant bit...
I had a lucky guess among the 2000+ lines of diff output with
which
Good news! I figured out that I can simply use
udev_device_get_is_initialized(). It does exactly what I want.
I tried using a udev_monitor but it doesn't seem to report
pre-existing devices (devices that were already connected to the
system). It just reports changes.
Thanks for the help.
--Da
Roland,
Roland Weber wrote:
> Assuming that this kernel does freeze, I will start to 'bisect' the
> differences in the kernel configurations
Thank you very much for doing this work. You are one of the many
open source heroes and heroines.
//Peter
--
To unsubscribe from this list: send the line
On Sun, 13 Sep 2015, Alan Stern wrote:
> On Sun, 13 Sep 2015, Roland Weber wrote:
>
> > I compiled a kernel 3.17(.0) with my additional debug lines...
> > and this one does NOT freeze! The output is:
> >
> > (first unbind)
> > ehci-pci :00:1d.0: remove, state 4
> > ehci-pci :00:1d.0: roo
On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote:
> Hi,
>
> On 10-09-15 20:30, Maxime Ripard wrote:
> >On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 04-09-15 08:43, Olliver Schinagl wrote:
> >>>Hey Hans,
> >>>
> >>>On 07-08-15 10:45, Olliver Schina
On Mon, Sep 14, 2015 at 12:04 PM, Greg KH wrote:
> Start your program to listen and handle all devices that way through
> udev iterators, that way will always work (for existing and new
> devices).
If by "existing devices", you mean devices that were connected to the
computer before my program st
On Sun, 13 Sep 2015, Hans-Peter Jansen wrote:
> > > usbmon log attached.
> >
> > It wasn't attached.
>
> Hrmpf. Hopefully now...
This time the trace wasn't so useful. It doesn't show any obvious
reason for the disconnections. It only shows that the port's link
state suddenly changes to INAC
Hi,
On Mon, Sep 14, 2015 at 12:56 PM, Hans de Goede wrote:
> Hi,
>
> On 14-09-15 19:53, Bin Liu wrote:
>
>
>
This is my first time looking at dts handling in drivers, so I might
be completely wrong, but I am thinking that since the controller node
links to the phy node, so the con
On Mon, Sep 14, 2015 at 11:55:17AM -0700, David Grayson wrote:
> Hello, Greg. Thanks for the quick reply, and for all your
> contributions to Linux.
>
> On Fri, Sep 11, 2015 at 6:01 PM, Greg KH wrote:
> > Can't you wait for libudev to notify your application when the usb
> > device is attached?
Hello, Greg. Thanks for the quick reply, and for all your
contributions to Linux.
On Fri, Sep 11, 2015 at 6:01 PM, Greg KH wrote:
> Can't you wait for libudev to notify your application when the usb
> device is attached? That should happen after the normal rules are run.
> Have you tried that?
On Mon, 14 Sep 2015, Igor Kotrasinski wrote:
> transfer() schedules a rescan for transfers larger than
> maxpacket, which is wrong for transfers that are multiples
> of maxpacket.
>
> Rewrite to fix and clarify packet multiple / remainder
> transfer logic.
>
> Signed-off-by: Igor Kotrasinski
>
Hi,
On 14-09-15 19:53, Bin Liu wrote:
This is my first time looking at dts handling in drivers, so I might
be completely wrong, but I am thinking that since the controller node
links to the phy node, so the controller node is the parent of the phy
node, so if there is an of api can look it up
Hi,
On Mon, Sep 14, 2015 at 12:25 PM, Hans de Goede wrote:
> Hi,
>
>
> On 14-09-15 19:14, Bin Liu wrote:
>>
>> Hi,
>>
>> On Mon, Sep 14, 2015 at 12:08 PM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 14-09-15 18:58, Bin Liu wrote:
Hi,
On Mon, Sep 14, 2015 at 9:59 A
On Mon, Sep 14, 2015 at 5:01 PM, Felipe Balbi wrote:
> On Sat, Sep 12, 2015 at 03:14:50PM +0200, Peter Senna Tschudin wrote:
>> >> Should these files be consolidated? And if so how?
>> > if you can find an easy way, that would be a very, very welcome patch.
>>
>> Is the ideal solution to consolida
Hi,
On 14-09-15 19:14, Bin Liu wrote:
Hi,
On Mon, Sep 14, 2015 at 12:08 PM, Hans de Goede wrote:
Hi,
On 14-09-15 18:58, Bin Liu wrote:
Hi,
On Mon, Sep 14, 2015 at 9:59 AM, Hans de Goede
wrote:
Hi,
On 14-09-15 16:44, Bin Liu wrote:
Hi,
On Thu, Sep 10, 2015 at 1:38 PM, Hans de Goe
Hi,
On Mon, Sep 14, 2015 at 12:08 PM, Hans de Goede wrote:
> Hi,
>
>
> On 14-09-15 18:58, Bin Liu wrote:
>>
>> Hi,
>>
>> On Mon, Sep 14, 2015 at 9:59 AM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 14-09-15 16:44, Bin Liu wrote:
Hi,
On Thu, Sep 10, 2015 at 1:38 PM
Hi,
On 14-09-15 18:58, Bin Liu wrote:
Hi,
On Mon, Sep 14, 2015 at 9:59 AM, Hans de Goede wrote:
Hi,
On 14-09-15 16:44, Bin Liu wrote:
Hi,
On Thu, Sep 10, 2015 at 1:38 PM, Hans de Goede
wrote:
Hi,
On 10-09-15 20:30, Maxime Ripard wrote:
On Thu, Sep 10, 2015 at 08:23:23PM +0200, Han
Hi,
On Mon, Sep 14, 2015 at 9:59 AM, Hans de Goede wrote:
> Hi,
>
>
> On 14-09-15 16:44, Bin Liu wrote:
>>
>> Hi,
>>
>> On Thu, Sep 10, 2015 at 1:38 PM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>> On 10-09-15 20:30, Maxime Ripard wrote:
On Thu, Sep 10, 2015 at 08:23:23PM +0200, Ha
Signed-off-by: Igor Kotrasinski
---
drivers/usb/gadget/udc/dummy_hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index df11021..da38475 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/
dummy_timer uses transfer() to update transfer limit. However,
limit passed to dummy_timer changes depending on transfer type,
so the actual limit is overwritten.
This can cause unpredictably slow / fast bulk transfers when
coupled with control / interrupt transfers.
Fix by returning actual amoun
currently, when a zlp flag is set and an urb/usb_request
buffer is filled without a short packet, transfer() leaves
its status at -EINPROGRESS and does not rescan for short
packet.
In a scenario where ep.maxpacket bytes are copied,
URB_ZERO_PACKET is set, urb buffer is filled and usb_request
buffe
transfer() schedules a rescan for transfers larger than
maxpacket, which is wrong for transfers that are multiples
of maxpacket.
Rewrite to fix and clarify packet multiple / remainder
transfer logic.
Signed-off-by: Igor Kotrasinski
---
drivers/usb/gadget/udc/dummy_hcd.c | 16 +++-
1
Use WARN_ON() instead of halting the kernel with BUG_ON().
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/usb/gadget/udc/amd5536udc.c
index 8646f6c..4edcfd
A rewrite of init_dma_pools() with proper error handling.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/usb/gadget/udc/amd5536udc.c
ind
We have actually ioremapped dev->virt_addr and dev->regs is
dev->virt_addr + UDC_DEVCFG_ADDR so while unmapping we should unmap
dev->virt_addr.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/g
This amd5536udc was a complete mess. The major problems that i could
find are:
1) if udc_pci_probe() fails in any stage then it just calls the
udc_pci_remove() to handle error. And udc_pci_remove() works with
struct udc *dev which we get from pci_get_drvdata(pdev). But we do the
pci_set_drvdata(pd
The condition checking for irq_registered, regs, mem_region and active
are not required as this is the remove function. And we are in the
remove means that probe was successful and they can never be NULL at
this point of code.
It was required in the original code as the remove function was part of
Rearrange the udc_probe function to remove the forward declarations.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 133 ++--
1 file changed, 66 insertions(+), 67 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/u
We have the function free_dma_pools() which frees all the dma pools. Use
it instead of calling all the functions separately. The if conditions
for data_requests and stp_requests are also not required here as this is
the remove function and we are here means probe has succeeded and dma
has been succ
A rewrite of udc_pci_probe() with proper error handling. We use here
free_dma_pools() in error handling.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 52 +++--
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/
Remove the forward declarations of udc_pci_probe and udc_pci_remove.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/usb/gadget/udc/amd5536udc.c
index 778a424..789441f 10064
Rearrange udc_create_dma_chain to remove the forward declaration.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 241 ++--
1 file changed, 119 insertions(+), 122 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/us
Rearrange the udc_remote_wakeup function to remove the forward declaration.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 40 ++---
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/dr
Rearrange udc_free_dma_chain to remove the forward declaration.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 53 ++---
1 file changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/usb/ga
checkpatch complains about multiple blank lines.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/usb/gadget/udc/amd5536udc.c
index 3657a66..98b841d 100644
--- a
Rearrange the udc_basic_init function to remove the forward declaration.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 55 ++---
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drive
checkpatch complains that the alignment should match with open
parenthesis.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 156 ++--
1 file changed, 78 insertions(+), 78 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/dr
A NULL comparison can be written as if (var) or if (!var).
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/usb/gadget/udc/amd5536udc.c
index f6d609
dma pools are being created by init_dma_pools() but there was no
function for freeing them. Introduce the function now so that we can use
it later.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/gadget/udc/amd5536udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/
On Sat, Sep 12, 2015 at 03:14:50PM +0200, Peter Senna Tschudin wrote:
> >> Should these files be consolidated? And if so how?
> > if you can find an easy way, that would be a very, very welcome patch.
>
> Is the ideal solution to consolidate both fusbh200-hcd.c and
> fotg210-hcd.c in a single modu
Hi,
On 14-09-15 16:44, Bin Liu wrote:
Hi,
On Thu, Sep 10, 2015 at 1:38 PM, Hans de Goede wrote:
Hi,
On 10-09-15 20:30, Maxime Ripard wrote:
On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote:
Hi,
On 04-09-15 08:43, Olliver Schinagl wrote:
Hey Hans,
On 07-08-15 10:45, Olliv
On Mon, 14 Sep 2015, Igor Kotrasinski wrote:
> dummy_timer uses transfer() to update transfer limit. However,
> limit passed to dummy_timer changes depending on transfer type,
> so the actual limit is overwritten.
>
> This can cause unpredictably slow / fast bulk transfers when
> coupled with con
Hi,
On Thu, Sep 10, 2015 at 1:38 PM, Hans de Goede wrote:
> Hi,
>
> On 10-09-15 20:30, Maxime Ripard wrote:
>>
>> On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 04-09-15 08:43, Olliver Schinagl wrote:
Hey Hans,
On 07-08-15 10:45, Olliver
On Mon, 14 Sep 2015, Igor Kotrasinski wrote:
> transfer() schedules a rescan for transfers larger than
> maxpacket, which is wrong for transfers that are multiples
> of maxpacket.
>
> Rewrite to fix and clarify packet multiple / remainder
> transfer logic.
>
> Signed-off-by: Igor Kotrasinski
>
On Mon, 14 Sep 2015, Igor Kotrasinski wrote:
> When close to transfer limit for a frame, transfer() decreases
> data length to send to limit. This can cause an erroneous short
> packet transfer to be simulated.
I don't see how that could happen.
> Rework transfer logic to decrease data to tranfe
On Mon, 14 Sep 2015, Igor Kotrasinski wrote:
> currently, when a zlp flag is set and an urb/usb_request
> buffer is filled without a short packet, transfer() leaves
> its status at -EINPROGRESS and does not rescan for short
> packet.
>
> In a scenario where ep.maxpacket bytes are copied,
> URB_ZE
On Mon, 14 Sep 2015, Igor Kotrasinski wrote:
> Signed-off-by: Igor Kotrasinski
> ---
> drivers/usb/gadget/udc/dummy_hcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
> b/drivers/usb/gadget/udc/dummy_hcd.c
> index 59be03e..183e368
The change ensures otg is not in a A- state when checking for VBUS in
peripheral mode.
musb_start() where VBUS checking is in can be called in many situations.
One example is in babble recovery routine, in which otg is transitioning
from A-HOST to A-WAIT-BCON, but VBUS discharge takes time, so
mus
On Tue, Jul 21, 2015 at 09:58:19AM +0800, Peter Hung wrote:
> This driver is for Fintek F81532/F81534 USB to Serial Ports IC.
>
> Features:
> 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC
> 2. Support Baudrate from B50 to B150 (excluding B100).
> 3. The RTS signal can be transform
transfer() schedules a rescan for transfers larger than
maxpacket, which is wrong for transfers that are multiples
of maxpacket.
Rewrite to fix and clarify packet multiple / remainder
transfer logic.
Signed-off-by: Igor Kotrasinski
---
drivers/usb/gadget/udc/dummy_hcd.c | 17 -
Hello.
On 9/14/2015 12:45 PM, Igor Kotrasinski wrote:
transfer() schedules a rescan for transfers larger than
maxpacket, which is wrong for transfers that are multiples
of maxpacket.
Rewrite to fix and clarify packet multiple / remainder
transfer logic.
Signed-off-by: Igor Kotrasinski
---
0x0
Linux version 4.3.0-rc1-next-20150914-dirty (fabio@fabio-Latitude-E6410) (gcc v5
CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
Machine model: Freescale i.MX27 Product Development Kit
Memory policy: Data cache writeback
Built 1 zonelist
> Recent commits to kernel/git/torvalds/linux.git have made the following
> functions able to tolerate NULL arguments:
>
> kmem_cache_destroy (commit 3942d29918522)
> mempool_destroy (commit 4e3ca3e033d1)
> dma_pool_destroy (commit 44d7175da6ea)
How do you think about to extend an other SmPL scrip
currently, when a zlp flag is set and an urb/usb_request
buffer is filled without a short packet, transfer() leaves
its status at -EINPROGRESS and does not rescan for short
packet.
In a scenario where ep.maxpacket bytes are copied,
URB_ZERO_PACKET is set, urb buffer is filled and usb_request
buffe
When close to transfer limit for a frame, transfer() decreases
data length to send to limit. This can cause an erroneous short
packet transfer to be simulated.
Rework transfer logic to decrease data to tranfer to multiple of
maxpacket.
Signed-off-by: Igor Kotrasinski
---
drivers/usb/gadget/udc/
Signed-off-by: Igor Kotrasinski
---
drivers/usb/gadget/udc/dummy_hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index 59be03e..183e368 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/
transfer() schedules a rescan for transfers larger than
maxpacket, which is wrong for transfers that are multiples
of maxpacket.
Rewrite to fix and clarify packet multiple / remainder
transfer logic.
Signed-off-by: Igor Kotrasinski
---
drivers/usb/gadget/udc/dummy_hcd.c | 17 -
dummy_timer uses transfer() to update transfer limit. However,
limit passed to dummy_timer changes depending on transfer type,
so the actual limit is overwritten.
This can cause unpredictably slow / fast bulk transfers when
coupled with control / interrupt transfers.
Fix by returning actual amoun
On 09/11/2015 07:20 PM, Alan Stern wrote:
> On Fri, 11 Sep 2015, Igor Kotrasinski wrote:
>
>> currently, when a zlp flag is set and an urb/usb_request
>> buffer is filled without a short packet, transfer() leaves
>> its status at -EINPROGRESS and does not rescan for short
>> packet.
>>
>> In a scen
On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
> From: Rong Wang
>
> Chipidea puts ci information to drvdata, but this overwrites the drvdata
> placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
> from codes like ehci-sysfs.c:
> static ssize_t show_companion(
On 15-09-14 08:05:26, Peter Chen wrote:
>
> > >
> > > root@imx6sxsabresd:~# opkg
> > > opkg-buildopkg-compare-versions.sh opkg-make-index
> > > opkg-buildpackage opkg-diff opkg-show-deps
> > > opkg-compare-indexes opkg-extract-file opkg-unbuil
> >
> > root@imx6sxsabresd:~# opkg
> > opkg-buildopkg-compare-versions.sh opkg-make-index
> > opkg-buildpackage opkg-diff opkg-show-deps
> > opkg-compare-indexes opkg-extract-file opkg-unbuild
> > opkg-compare-versions opkg-list-fields
On Mon, Aug 31, 2015 at 02:16:10PM -0400, David Ward wrote:
> Other Sierra Wireless MC73xx devices exist, with different USB IDs.
You should mention that you're just fixing a comment somewhere. And the
patch summary (Subject) should mention that too rather than rely on
"->".
> Cc: Bjørn Mork
> S
On Mon, Aug 24, 2015 at 08:36:12AM -0700, Liu.Zhao wrote:
> This is intended to add ZTE device PIDs on kernel.
>
> Signed-off-by: Liu.Zhao
Now applied, thanks.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
Mor
On 12.09.2015 00:56, Andrew Gillis wrote:
I get an error when trying to play music through USB DACs under Linux. This
only happens with a few high end DACs and only when using a NEC uPD72020x
chipset USB 3.0 port.
The people at RedHat think it may be the NEC uPD72020x chipset is reporting
it's c
On Sat, Sep 12, 2015 at 04:28:33PM +0200, Bjørn Mork wrote:
> David Ward writes:
>
> > An earlier e-mail from Reinhard contained a patch that did this for the
> > MC7304. That patch could be modified as shown below so that the control
> > request is enabled or disabled from qcprobe() instead. Thi
Andrew Gillis wrote:
> I get an error when trying to play music through USB DACs under Linux.
> This only happens with a few high end DACs and only when using a NEC
> uPD72020x chipset USB 3.0 port.
>
> The people at RedHat think it may be the NEC uPD72020x chipset is
> reporting it's capabilities
On 15-09-14 13:50:22, Peter Chen wrote:
> On Mon, Sep 14, 2015 at 12:01:04PM +0530, maitysancha...@gmail.com wrote:
> > On 15-09-14 13:11:16, Peter Chen wrote:
> > > On Fri, Sep 11, 2015 at 04:51:22PM +0530, maitysancha...@gmail.com wrote:
> > > > On 15-09-11 15:56:17, maitysancha...@gmail.com wrot
I wrote:
> Felipe Tonello wrote:
>> DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB
>> MIDI GADGET -> HOST
>>
>> When the throughput from the DSP is high, thus causing the throughput
>> on the USB to be high as well, I get a Kernel Panic saying to increase
>> the coherent_pool. I
On Mon, Sep 14, 2015 at 12:01:04PM +0530, maitysancha...@gmail.com wrote:
> On 15-09-14 13:11:16, Peter Chen wrote:
> > On Fri, Sep 11, 2015 at 04:51:22PM +0530, maitysancha...@gmail.com wrote:
> > > On 15-09-11 15:56:17, maitysancha...@gmail.com wrote:
> > > > Hello Peter,
> > > >
> > > > On 15-0
83 matches
Mail list logo
