gt; (default_idle_call+0x30/0x44)
> [ 4588.312623] [] (default_idle_call) from []
> (cpu_startup_entry+0x30c/0x370)
> [ 4588.321292] [] (cpu_startup_entry) from []
> (rest_init+0x94/0x98)
> [ 4588.329082] [] (rest_init) from []
> (start_kernel+0x404/0x410)
> [ 4588.336606] Code:
03:00 Bin Liu :
> Hi,
>
> On Fri, May 20, 2016 at 04:32:06PM +0300, Matwey V. Kornilov wrote:
>> 2016-05-20 16:19 GMT+03:00 :
>> > Hello,
>> >
>> > I am running 4.6-rc3 on BealgeBone Black and when I try to interract
>> > with pwc webcam attached t
maxburst = 0,
address = 0 '\000', desc = 0x0, comp_desc = 0x0}, name = '\000'
, hw_ep = 0x0, musb = 0x0,
current_epnum = 0 '\000', type = 0 '\000', is_in = 0 '\000',
packet_sz = 0, desc = 0x0, dma = 0x0, req_list = {next = 0x0,
prev = 0x0},
By the way, is it ok that function musb_rx_dma_iso_cppi41 uses
hw_ep->tx_channel? I would suppose that it should use rx_channel
instead.
2016-05-20 23:58 GMT+03:00 Matwey V. Kornilov :
> (gdb) frame 3
> #3 musb_host_rx (musb=0xdb3e0010, epnum=) at
> ../drivers/usb/musb/musb_host.c
2016-05-21 0:12 GMT+03:00 Bin Liu :
> Hi,
>
> On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote:
>> By the way, is it ok that function musb_rx_dma_iso_cppi41 uses
>> hw_ep->tx_channel? I would suppose that it should use rx_channel
>> instead.
>
&g
2016-05-21 6:13 GMT+03:00 Bin Liu :
> Hi,
>
> On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov wrote:
>> 2016-05-21 0:12 GMT+03:00 Bin Liu :
>>> Hi,
>>>
>>> On Sat, May 21, 2016 at 12:05:06AM +0300, Matwey V. Kornilov wrote:
>>>> By the w
2016-05-21 20:50 GMT+03:00 Matwey V. Kornilov :
> 2016-05-21 6:13 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov
>> wrote:
>>> 2016-05-21 0:12 GMT+03:00 Bin Liu :
>>>> Hi,
>>>>
>>>> On S
2016-05-23 16:35 GMT+03:00 Bin Liu :
> Hi,
>
> On Sat, May 21, 2016 at 08:50:32PM +0300, Matwey V. Kornilov wrote:
>> 2016-05-21 6:13 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Fri, May 20, 2016 at 4:20 PM, Matwey V. Kornilov
>> > wrote:
2016-05-23 16:36 GMT+03:00 Bin Liu :
> Hi,
>
> On Sat, May 21, 2016 at 10:04:48PM +0300, Matwey V. Kornilov wrote:
>> 2016-05-21 20:50 GMT+03:00 Matwey V. Kornilov :
>> > 2016-05-21 6:13 GMT+03:00 Bin Liu :
>> >> Hi,
>> >>
>> >> On Fr
2016-05-23 16:36 GMT+03:00 Bin Liu :
> Hi,
>
> On Sat, May 21, 2016 at 10:04:48PM +0300, Matwey V. Kornilov wrote:
>> 2016-05-21 20:50 GMT+03:00 Matwey V. Kornilov :
>> > 2016-05-21 6:13 GMT+03:00 Bin Liu :
>> >> Hi,
>> >>
>> >> On Fr
2016-09-12 6:28 GMT+03:00 Bin Liu :
> Hi,
>
> On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>> 2016-08-30 21:30 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> >
2016-09-12 21:57 GMT+03:00 Bin Liu :
> Hi,
>
> On Mon, Sep 12, 2016 at 11:52:46AM +0300, Matwey V. Kornilov wrote:
>> 2016-09-12 6:28 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Tue, Aug 30, 2016 at 11:44:33PM +0300, Matwey V. Kornilov wrote:
>> &g
2016-09-12 22:38 GMT+03:00 Matwey V. Kornilov :
> 2016-09-12 21:57 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Mon, Sep 12, 2016 at 11:52:46AM +0300, Matwey V. Kornilov wrote:
>>> 2016-09-12 6:28 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> >
pplied in hardware before ftdi_set_termios returns?
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at htt
it, if you think that it could provide more information. I am
>> also ready to perform additional tests (use usbmon maybe?).
>>
>> How could this issue be resolved?
>>
>> Thank you.
>
> Do you have CPPI DMA enabled? If so I think you might hit on a known
> issu
2016-07-20 0:34 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >
2016-07-20 9:09 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> >
2016-07-20 17:13 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> &g
2016-07-20 18:06 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 17:13 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> &
2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 18:06 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-20 17:13 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> >
yet, if it was intentionnaly fixed.
2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
>> 2016-07-20 18:06 GMT+03:00 Bin Liu :
>>> Hi,
>>>
>>> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
ag to handle urb
> return in bottom half"
>
> I have not checked yet, if it was intentionnaly fixed.
>
> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov :
>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
>>> 2016-07-20 18:06 GMT+03:00 Bin Liu :
>>>> Hi,
&
tform
device now, reuse that and remove similar code from platform code.
2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov :
> Hello,
>
> I've just bisected commit, which fixed the issue in v4.7
>
> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
> Merge: f55532a febce40
> Au
MT+03:00 Matwey V. Kornilov :
> Hello,
>
> I've found that the following commit fixes the issue:
>
> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
> Author: Viresh Kumar
> Date: Fri Apr 22 16:58:42 2016 +0530
>
> cpufreq: omap: Use generic platdev driver
2016-08-01 19:50 GMT+03:00 Viresh Kumar :
> On 31-07-16, 23:31, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only
bytes); discarded.
[ 31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
[ 31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.
2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov :
> Hello,
>
> I've also just found that the same commit breaks cpufreq on BeagleBon
2016-08-01 20:06 GMT+03:00 Viresh Kumar :
> On 01-08-16, 20:01, Matwey V. Kornilov wrote:
>> With this patch, there is no cpufreq directory here.
>>
>> Without this patch, the output is the following:
>>
>> nohostname:~ # uname -a
>> Linux nohostname 4.6.4-3.
if (pdev->fill_buf) {
pdev->fill_buf->filled = 0;
pdev->vsync = 1;
}
}
2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
> pwc module output with trace=511 is the following:
>
> [ 24.793109] usbcore:
xt_fill_buf(pdev);
> if (pdev->fill_buf) {
> pdev->fill_buf->filled = 0;
> pdev->vsync = 1;
> }
> }
>
> 2016-08-01 21:16 GMT+03:00 Matwey V. Kornilov :
&g
y ideas why?
>
> 2016-08-04 19:57 GMT+03:00 Matwey V. Kornilov :
>> I've just found that many packages in URBs have zero actual_length (It
>> is a question why).
>> Then the following end of frame criteria leads to `frame underflow&
latency.
2016-08-04 22:58 GMT+03:00 Matwey V. Kornilov :
> I've just found that in such cases, when DMA actual length is zero,
> both cppi41_channel->prog_len and txstate.residue equal 960 at
> musb_cppi41 line 225:
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linu
Any ideas?
2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov :
> When DMA is not used, I see the same behavior: lots of zero-length
> packages received.
>
> Can It be related to some kind of USB overflow due to long input data
> processing with disabled IRQ?
> When HCD_BC is
I've just checked 4.8-rc2 - same behaviour.
2016-08-18 16:31 GMT+03:00 Matwey V. Kornilov :
> Any ideas?
>
> 2016-08-04 23:08 GMT+03:00 Matwey V. Kornilov :
>> When DMA is not used, I see the same behavior: lots of zero-length
>> packages received.
>>
>>
I've just measured that
it takes 150 us in average for pwc_isoc_handler to run
350 us - __usb_hcd_giveback_urb
So, it takes either 50 us (with HCD_BH) or 400 us (without) for
usb_hcd_giveback_urb to run.
2016-08-20 21:09 GMT+03:00 Matwey V. Kornilov :
> I've just checked 4
In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
every 0.01 sec. It is not clear why behavior is so different.
2016-08-21 17:02 GMT+03:00 Matwey V. Kornilov :
> I've just measured that
>
> it takes 150 us in average for pwc_isoc_handler t
2016-08-22 1:00 GMT+03:00 Alan Stern :
> On Sun, 21 Aug 2016, Matwey V. Kornilov wrote:
>
>> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
>> every 0.01 sec. It is not clear why behavior is so different.
>
> What behavior are you asking about?
2016-08-22 11:32 GMT+03:00 Matwey V. Kornilov :
> 2016-08-22 1:00 GMT+03:00 Alan Stern :
>> On Sun, 21 Aug 2016, Matwey V. Kornilov wrote:
>>
>>> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
>>> every 0.01 sec. It is not clear why beh
ated every 1 ms by
hardware and should be followed by IN immediately?
If so, it is not clear to me how they should be aligned when the time
difference between to subsequent INs is greater than 1ms.
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow S
2016-08-30 21:30 GMT+03:00 Bin Liu :
> Hi,
>
> On Sun, Aug 28, 2016 at 01:13:55PM +0300, Matwey V. Kornilov wrote:
>> Hello Bin,
>>
>> I would like to start new thread on my issue. Let me recall where the issue
>> is:
>> There is 100% frame lost in pwc webc
2016-11-01 23:33 GMT+03:00 Bin Liu :
> On Sat, Oct 15, 2016 at 10:25:42PM +0300, Matwey V. Kornilov wrote:
>
> [snip]
>
>> >>> > Which means without this commit your camera has been working without
>> >>> > issues, and this is a regression with
From: Matwey V. Kornilov
This patch adds support for the Lake Shore Cryotronics devices to
the CP210x driver.
Signed-off-by: Matwey V. Kornilov
---
These lines are ported from cp210x driver distributed by Lake Shore web site:
http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0
Hi,
With the following configure options, musb_hdrc and tusb6010 make
dependency loop:
CONFIG_USB_MUSB_HDRC=m
CONFIG_USB_MUSB_TUSB6010=m
CONFIG_USB_TUSB_OMAP_DMA=y
tusb6010.ko provides function `tusb_get_revision` which is used by
tusb6010_omap.o which is a part of musb_hdrc.ko
In its tur
01.05.2014 23:40, Felipe Balbi пишет:
Hi,
On Thu, May 01, 2014 at 11:13:19PM +0400, Matwey V. Kornilov wrote:
Hi,
With the following configure options, musb_hdrc and tusb6010 make dependency
loop:
CONFIG_USB_MUSB_HDRC=m
CONFIG_USB_MUSB_TUSB6010=m
CONFIG_USB_TUSB_OMAP_DMA=y
tusb6010.ko
01.05.2014 23:51, Felipe Balbi пишет:
I don't think you need that. Have tusb_get_revision() run only one
during tusb6010 probe/init function and cache the returned value inside
musb->revision or something like that, then remove all other calls to
tusb_get_revision() and have tusb6010_omap.c check
From: "Matwey V. Kornilov"
Subject: [PATCH 0/2] Fix dependency loop in tusb6010
With the following configure options, musb_hdrc and tusb6010 make dependency
loop:
CONFIG_USB_MUSB_HDRC=m
CONFIG_USB_MUSB_TUSB6010=m
CONFIG_USB_TUSB_OMAP_DMA=y
tusb6010.ko provides function `tusb_ge
From e24375ea6aefe2ad1ee72b8facab91abd1be190a Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Fri, 9 May 2014 16:10:16 +0400
Subject: [PATCH 2/2] Use musb->tusb_revision instead of tusb_get_revision call.
The value of the revision is stored in musb->tusb_revision,
so
From 0bd8c14855eeb049f49685f36386750a999078a3 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Fri, 9 May 2014 15:52:00 +0400
Subject: [PATCH 1/2] Add tusb_revision to struct musb to store the revision.
Add field to store tusb6010 revision value. Read the revision at
the s
Hi,
Running 3.16.1 on beaglebone black, I have the following issue with
musb_hdrc on boot:
[ 11.151063] Unable to handle kernel paging request at virtual
address e09bb05c
[ 11.158774] pgd = de5d8000
[ 11.161613] [e09bb05c] *pgd=9e02d811, *pte=, *ppte=
[ 11.168247] Interna
Hi George,
Many thanks for the hint. Am I right that we can not have multiple
MUSB DMA modes within the same kernel? It is a pity.
2014-09-09 12:40 GMT+04:00 George Cherian :
> Hi Matwey,
>
>
> On 09/09/2014 01:58 PM, Matwey V. Kornilov wrote:
>>
>> Hi,
>>
>>
twey V. Kornilov :
> Hi George,
>
> Many thanks for the hint. Am I right that we can not have multiple
> MUSB DMA modes within the same kernel? It is a pity.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@jabb
--
To unsubscribe from this list: send the
2014-09-09 18:45 GMT+04:00 Felipe Balbi :
> On Tue, Sep 09, 2014 at 01:28:55PM +0400, Matwey V. Kornilov wrote:
>> Hi George,
>>
>> Why dma_controller_create can not be set in struct musb_platform_ops?
>> Then each module would be able to set dma_control
ey aren't.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2014-09-09 20:09 GMT+04:00 Felipe Balbi :
> On Tue, Sep 09, 2014 at 07:52:59PM +0400, Matwey V. Kornilov wrote:
>> 2014-09-09 19:11 GMT+04:00 Felipe Balbi :
>> > the proper way would be to move everything to dma_engine. OMAP already
>> > has support for DMA engine
2014-09-09 21:49 GMT+04:00 Felipe Balbi :
> Hi,
>
> On Tue, Sep 09, 2014 at 09:16:50PM +0400, Matwey V. Kornilov wrote:
>> I am still running 3.16.1 no BeagleBone Black and after I sorted out
>> the configuration nothing oopses, but there is another problem.
>> I can
sourcing 5.046V when I attach a device
> which draws 25 ~ 45 mA.
Angstrom gives me the same 4.7V
On the power input jack, there is 4.8V. I found no voltage regulators
for 5V line on the board, so I think I just need to find other power
supply.
--
With best regards,
Matwey V. Kornilov
http://blog.
2014-09-10 17:52 GMT+04:00 Felipe Balbi :
> Hi,
>
> On Wed, Sep 10, 2014 at 11:06:05AM +0400, Matwey V. Kornilov wrote:
>> 2014-09-09 22:20 GMT+04:00 Felipe Balbi :
>> > oh, so it's not really a BBB. I have never seen an EMBEST RevB3. Do you
>> > have access t
-hdrc.1.auto: complete de3b7880
usb_api_blocking_completion+0x0/0x1c [usbcore] (-71), dev0 ep0in, 0/64
This is similar to
http://www.spinics.net/lists/linux-omap/msg106299.html (no explanation
is given)
However, I don't yet have an idea what is csr0 register for, and what
is going on. :)
--
With b
2014-09-11 0:32 GMT+04:00 Alan Stern :
> If all else fails, git bisect might pinpoint the cause of the problem.
>
> Alan Stern
>
I would have need config bisect.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
To unsubscribe from this li
FFSET(epnum)(0x20 + ((epnum) * 4))
-#endif
I am still testing, and suspect that musb_readb/musb_writeb stuff in
musb_io.h is also the subject.
The question is how to fix all this in correct way.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
To
s has to be introduced?
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
traction.
I see also that void* private is required both by struct musb_hw_ep
and struct musb.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majo
Ok. What is about musb_io.h? What does it mean "TUSB6010 doesn't allow
8-bit access; 16-bit access is the minimum."?
I think __raw_readb is kind of return *(u8_t*)(addr), but this is CPU
stuff as far as I understand.
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.
2014-09-16 22:39 GMT+04:00 Felipe Balbi :
> Hi,
>
> (man, talk about trimming... leave some context ;-)
>
> On Tue, Sep 16, 2014 at 10:06:33PM +0400, Matwey V. Kornilov wrote:
>> Ok. What is about musb_io.h? What does it mean "TUSB6010 doesn't allow
>> 8-bit
2014-09-17 19:25 GMT+04:00 Felipe Balbi :
> On Wed, Sep 17, 2014 at 10:46:57AM +0400, Matwey V. Kornilov wrote:
>> 2014-09-16 22:39 GMT+04:00 Felipe Balbi :
>> > Hi,
>> >
>> > (man, talk about trimming... leave some context ;-)
>> >
>> > On Tue
2014-09-17 19:46 GMT+04:00 Felipe Balbi :
> On Wed, Sep 17, 2014 at 07:35:14PM +0400, Matwey V. Kornilov wrote:
>> 2014-09-17 19:25 GMT+04:00 Felipe Balbi :
>> > On Wed, Sep 17, 2014 at 10:46:57AM +0400, Matwey V. Kornilov wrote:
>> >> 2014-09-16 22:39 GMT+0
On 23.10.2014 12:52, russ.d...@gmail.com
wrote:
From: Russ Dill
This patch provides the FTDI genuine product verification steps
as contained within the new 2.12.00 official release. It ensures
that counterfeiters don't exploit engineering investment made
by FTDI. Counterfeit ICs are destroying
Hi,
I am facing the following issue, when running 3.19-rc6 on my beaglebone black:
[9.638571] Unable to handle kernel paging request at virtual address
69646b89
[9.646309] pgd = db6dc000
[9.649168] [69646b89] *pgd=
[9.652929] Internal error: Oops: 5 [#1] SMP ARM
[9.65
Hi,
I was able to use some gdb to touch the issue:
(gdb) monitor lsmod
Module Size modstruct Used by
musb_am335x 1431 0xbf0002781 (Loading) 0xbf00 [ ]
(gdb) bt
#0 0x73256020 in ?? ()
#1 0xc07a68f8 in driver_match_device (dev=, drv=) at ../drivers/base
The issue is still there for 3.19.0-rc7
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
05.02.2015 19:30, Matwey V. Kornilov пишет:
>
> The issue is still there for 3.19.0-rc7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kerne
2018-03-22 20:11 GMT+03:00 Bin Liu :
> On Thu, Mar 22, 2018 at 07:31:59PM +0300, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I am running 4.16-rc6 and see the following issue with ASIX
>> usb-ethernet dongle running on BeagleBoneBlack (TI AM335x).
>
> Does the i
2018-03-22 20:11 GMT+03:00 Bin Liu :
> On Thu, Mar 22, 2018 at 07:31:59PM +0300, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I am running 4.16-rc6 and see the following issue with ASIX
>> usb-ethernet dongle running on BeagleBoneBlack (TI AM335x).
>
> Does the i
Hi Bin,
I've just checked that the issue is still present in 4.13.10.
2017-04-27 13:20 GMT+03:00 Matwey V. Kornilov :
> This commit changes the order of actions undertaken in
> musb_advance_schedule() in order to overcome issue with broken
> isochronous transfer [1].
>
>
The issue is also present in 4.9.60-ti-r75
2017-11-04 17:05 GMT+03:00 Matwey V. Kornilov :
> Hi Bin,
>
> I've just checked that the issue is still present in 4.13.10.
>
> 2017-04-27 13:20 GMT+03:00 Matwey V. Kornilov :
>> This commit changes the orde
2017-11-16 19:32 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Nov 15, 2017 at 06:19:08PM +0300, Matwey V. Kornilov wrote:
>> The issue is also present in 4.9.60-ti-r75
>>
>> 2017-11-04 17:05 GMT+03:00 Matwey V. Kornilov :
>> > Hi Bin,
>> >
>> > I'
6.html
[2] https://www.spinics.net/lists/linux-usb/msg145747.html
[3] http://openvizsla.org/
[4] https://www.spinics.net/lists/linux-usb/msg156107.html
[5] https://www.spinics.net/lists/linux-usb/msg156486.html
[6]
https://github.com/matwey/linux/commit/2b36e1add5aaf552923c8c1340e50bd7c2050fde
--
With best regard
2018-02-16 19:27 GMT+03:00 Tony Lindgren :
> * Matwey V. Kornilov [180215 17:55]:
>> [] 7.219456 d= 0.000997 [181.0 + 3.667] [ 3] IN : 4.5
>> [T ] 7.219459 d= 0.03 [181.0 + 7.083] [800] DATA0: 53 da
>> ...
>> []
187.0 + 3.667] [ 3] IN : 4.5
[] 7.225459 d= 0.03 [187.0 + 7.000] [ 3] DATA0: 00 00
Here, I believe that IN request is missed at 7.221 and this leads to
the issues with missed data.
2016-08-28 13:13 GMT+03:00 Matwey V. Kornilov :
> Hello Bin,
>
> I would like to start
ng
urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
next urb if there is the next urb pending in queue.
[1] https://www.spinics.net/lists/linux-usb/msg145747.html
Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
handle urb return in bottom half"&q
2017-04-27 18:35 GMT+03:00 Bin Liu :
> Hi Matwey,
>
> On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote:
>> This commit changes the order of actions undertaken in
>> musb_advance_schedule() in order to overcome issue with broken
>> isochronous transfer
2017-04-27 20:13 GMT+03:00 Bin Liu :
> On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>> 2017-04-27 18:35 GMT+03:00 Bin Liu :
>> > Hi Matwey,
>> >
>> > On Thu, Apr 27, 2017 at 01:20:33PM +0300, Matwey V. Kornilov wrote:
>> >> Thi
which i
2017-04-28 14:58 GMT+03:00 Bin Liu :
> On Fri, Apr 28, 2017 at 10:04:30AM +0300, Matwey V. Kornilov wrote:
>> 2017-04-27 20:13 GMT+03:00 Bin Liu :
>> > On Thu, Apr 27, 2017 at 07:26:31PM +0300, Matwey V. Kornilov wrote:
>> >> 2017-04-27 18:35 GMT+03:
2017-04-28 15:43 GMT+03:00 Bin Liu :
> On Fri, Apr 28, 2017 at 03:13:55PM +0300, Matwey V. Kornilov wrote:
>> which i
>>
>> 2017-04-28 14:58 GMT+03:00 Bin Liu :
>> > On Fri, Apr 28, 2017 at 10:04:30AM +0300, Matwey V. Kornilov wrote:
>> >> 2017-04-27 20:
2017-04-28 16:30 GMT+03:00 Bin Liu :
> On Fri, Apr 28, 2017 at 04:15:09PM +0300, Matwey V. Kornilov wrote:
>> 2017-04-28 15:43 GMT+03:00 Bin Liu :
>> > On Fri, Apr 28, 2017 at 03:13:55PM +0300, Matwey V. Kornilov wrote:
>> >> which i
>> >>
>> >&g
2017-04-29 11:16 GMT+03:00 Matwey V. Kornilov :
> 2017-04-28 16:30 GMT+03:00 Bin Liu :
>> On Fri, Apr 28, 2017 at 04:15:09PM +0300, Matwey V. Kornilov wrote:
>>> 2017-04-28 15:43 GMT+03:00 Bin Liu :
>>> > On Fri, Apr 28, 2017 at 03:13:55PM +0300, Matwey V. K
2017-04-29 17:24 GMT+03:00 Matwey V. Kornilov :
> 2017-04-29 11:16 GMT+03:00 Matwey V. Kornilov :
>> 2017-04-28 16:30 GMT+03:00 Bin Liu :
>>> On Fri, Apr 28, 2017 at 04:15:09PM +0300, Matwey V. Kornilov wrote:
>>>> 2017-04-28 15:43 GMT+03:00 Bin Liu :
>>>
an be checked internally in the
driver.
--
With best regards,
Matwey V. Kornilov
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2017-08-28 11:49 GMT+03:00 Greg KH :
> On Mon, Aug 28, 2017 at 11:22:48AM +0300, Matwey V. Kornilov wrote:
>> Hi all,
>>
>> I have an issue with the following patch:
>> c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting")
>>
>>
2017-08-28 11:22 GMT+03:00 Matwey V. Kornilov :
> Hi all,
>
> I have an issue with the following patch:
> c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting")
>
> I really need sub 16-ms latency for my peripheral and while I have no
>
with timeout due to missed input. It must be handled
inside the driver.
2017-08-28 12:32 GMT+03:00 Matwey V. Kornilov :
> 2017-08-28 11:22 GMT+03:00 Matwey V. Kornilov :
>> Hi all,
>>
>> I have an issue with the following patch:
>> c6dce2626606 ("USB: serial: ftdi
We assign "urb->hcpriv = qh;" a few lines down. The valid qh for the urb is
hep->hcpriv in this code path.
Fixes: 714bc5ef3eda ("musb: potential use after free")
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_host.c | 2 +-
1 file changed, 1 insertion(+),
By the way, why do we need to store the qh in urb->hcpriv?
qh can always be accessible through urb->ep->hcpriv
Wouldn't it be better to drop entire urb->hcpriv usage?
ср, 23 янв. 2019 г. в 20:52, Matwey V. Kornilov :
>
> We assign "urb->hcpriv = qh;" a few lin
сб, 26 янв. 2019 г. в 00:37, Alan Stern :
>
> On Fri, 25 Jan 2019, Bin Liu wrote:
>
> > On Thu, Jan 24, 2019 at 09:47:02PM +0300, Matwey V. Kornilov wrote:
> > > By the way, why do we need to store the qh in urb->hcpriv?
> > > qh can always be accessible throu
("musb: potential use after free")
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index b59ce9ad14ce..a60d52c7e112 100644
--- a/drivers/usb/musb/m
94 matches
Mail list logo
