Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> Hi Oleksij,
>
> On Tue, 2016-07-05 at 19:23 +0200, Oleksij Rempel wrote:
>> Hi,
>>
>> Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
>>>
>>> Hello,
>>>
>>> Looks like this is an
Hi,
Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
> Hello,
>
> Looks like this is another manifestation of already seen problem with
> ath9k-htc
> and OHCI controller.
>
> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
> development board (this is Synopsys AXS103)
Am 13.03.2016 um 16:30 schrieb Alan Stern:
> On Sun, 13 Mar 2016, Oleksij Rempel wrote:
>
>> Hallo all,
>>
>> i need to sync device clock with host clock, since device will return
>> SOF counter for each packet i need to use it as reference. Are there any
>>
Hallo all,
i need to sync device clock with host clock, since device will return
SOF counter for each packet i need to use it as reference. Are there any
proper way to convert SOF to a host timestamp?
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
Am 26.11.2014 um 01:28 schrieb David Lechner:
On 7 July 2014 17:08, Oleksij Rempel linux@ wrote:
/ Am 07.07.2014 15:40, schrieb Anders Darander:/
/ On 4 July 2014 18:54, Oleksij Rempel linux@ wrote:/
/ Am 04.07.2014 18:30, schrieb Alan Stern:/
/ On Fri, 4 Jul
Am 07.07.2014 15:40, schrieb Anders Darander:
On 4 July 2014 18:54, Oleksij Rempel li...@rempel-privat.de wrote:
Am 04.07.2014 18:30, schrieb Alan Stern:
On Fri, 4 Jul 2014, Anders Darander wrote:
~# usb 1-1: new full-speed USB device number 3 using at91_ohci
usb 1-1: ath9k_htc: Firmware
Am 07.07.2014 17:08, schrieb Oleksij Rempel:
Am 07.07.2014 15:40, schrieb Anders Darander:
On 4 July 2014 18:54, Oleksij Rempel li...@rempel-privat.de wrote:
Am 04.07.2014 18:30, schrieb Alan Stern:
On Fri, 4 Jul 2014, Anders Darander wrote:
~# usb 1-1: new full-speed USB device number 3
Am 04.07.2014 18:30, schrieb Alan Stern:
On Fri, 4 Jul 2014, Anders Darander wrote:
Hi,
While porting an internal BSP (a design based on a at91sam9g20 SoC)
from 3.10 to 3.14, I got flooded with messages like:
~# usb 1-1: new full-speed USB device number 3 using at91_ohci
usb 1-1:
Hi Arokux,
Am 29.09.2013 23:16, schrieb Arokux X:
Hi Oleksij,
On Sun, Sep 29, 2013 at 10:01 PM, Oleksij Rempel li...@rempel-privat.de
wrote:
Hi Arokux,
Allan already pointed on timing issue. If you compare bad and working
logs you will see that interval on bad log is match more shorter
Hi Arokux,
Allan already pointed on timing issue. If you compare bad and working
logs you will see that interval on bad log is match more shorter. On my
expiriance with other wifi adapter it is critical. Beside, it has
nothing todo with wifi at all.
In many cases usb controller insight of adapter
Am 28.09.2013 20:08, schrieb Marc MERLIN:
On Mon, Sep 23, 2013 at 10:21:23AM +0200, Oleksij Rempel wrote:
Understood, just making sure this was still potentially useful considering
what I found out since my last message.
Which version of powertop are you actually using? None of current
Am 22.09.2013 22:36, schrieb Marc MERLIN:
On Sun, Sep 22, 2013 at 04:32:08PM -0400, Alan Stern wrote:
I'm somehow thinking there is a driver or hardware problem when the device
does get stuck in a mode where it won't sleep properly again until the next
reboot (just unloading/loading the driver
Am 07.09.2013 03:38, schrieb Alan Stern:
On Fri, 6 Sep 2013, Oleksij Rempel wrote:
Am 06.09.2013 23:09, schrieb Alan Stern:
On Fri, 6 Sep 2013, Oleksij Rempel wrote:
Hi Alan,
i need more help.
We have more test results now. Initial patch was probably fixing
fallowing issue - bad
Am 06.09.2013 23:09, schrieb Alan Stern:
On Fri, 6 Sep 2013, Oleksij Rempel wrote:
Hi Alan,
i need more help.
We have more test results now. Initial patch was probably fixing
fallowing issue - bad performance on EP4/EP3 if Intr transfer is used.
It is reproducible only on EHCI
Am 10.08.2013 13:57, schrieb Alan Stern:
On Sat, 10 Aug 2013, Oleksij Rempel wrote:
usb reset do not affect behaviour of firmware. At least after i remove
all attempts to reboot FW from driver.
If adapter will got reset signal, FW will be notified about it. Then FW
will remove reset flag
and EP4 bulk. FIFO for this endpoints
stay not reconfigured, so under the hood it is still Int EP.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 36 ++--
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git
Am 13.08.2013 10:09, schrieb Oleksij Rempel:
If usb auto suspend is enabled or system run in to suspend/resume
cycle ath9k-htc adapter will stop to response. It is reproducible on xhci HCs.
Host part of problem:
XHCI do timing calculation based on Transfer Type and bInterval,
immediately after
Am 10.08.2013 13:57, schrieb Alan Stern:
On Sat, 10 Aug 2013, Oleksij Rempel wrote:
usb reset do not affect behaviour of firmware. At least after i remove
all attempts to reboot FW from driver.
If adapter will got reset signal, FW will be notified about it. Then FW
will remove reset flag
Am 09.08.2013 21:32, schrieb Alan Stern:
On Fri, 9 Aug 2013, Oleksij Rempel wrote:
Is there any way to prevent the device from losing its firmware during
a USB reset or suspend?
For suspend - yes. It is possible to ignore suspend command or put the
SoC in low power mode - but is it probably
Am 09.08.2013 16:13, schrieb Alan Stern:
On Fri, 9 Aug 2013, Christian Lamparter wrote:
After loading firmware, a reset generally is necessary. Some devices
will do it themselves; others require you to call usb_reset_device().
This makes things complicated. Because, as far as I remember,
Am 09.08.2013 19:16, schrieb Alan Stern:
On Fri, 9 Aug 2013, Oleksij Rempel wrote:
Am 09.08.2013 16:52, schrieb Alan Stern:
On Fri, 9 Aug 2013, Oleksij Rempel wrote:
What about a get firmware version sort of thing? There really should
be a way for the driver to tell whether the firmware
Am 31.07.2013 08:52, schrieb Oleksij Rempel:
Am 28.07.2013 22:41, schrieb Christian Lamparter:
On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
Am 28.07.2013 14:12, schrieb Oleksij Rempel:
Am 28.07.2013 13:38, schrieb Christian Lamparter:
before rmmod.
Oh, I
Just in case,
i tested ar5523 based adapter on two different xhci controllers. No
visible problems.
Am 07.08.2013 05:39, schrieb Sarah Sharp:
Please recompile your kernel with CONFIG_USB_DEBUG and
CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and email dmesg from when you
first plug in the
Am 28.07.2013 22:41, schrieb Christian Lamparter:
On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
Am 28.07.2013 14:12, schrieb Oleksij Rempel:
Am 28.07.2013 13:38, schrieb Christian Lamparter:
Anyway, I tried the -next branch.
commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
Am 28.07.2013 13:38, schrieb Christian Lamparter:
Anyway, I tried the -next branch.
commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
Author: Oleksij Rempel li...@rempel-privat.de
Date: Wed Jul 24 10:26:18 2013 +0200
k2_fw_usb_api: workaround for EP4 bug.
but still, the device won't
Am 28.07.2013 14:12, schrieb Oleksij Rempel:
Am 28.07.2013 13:38, schrieb Christian Lamparter:
Anyway, I tried the -next branch.
commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
Author: Oleksij Rempel li...@rempel-privat.de
Date: Wed Jul 24 10:26:18 2013 +0200
k2_fw_usb_api
not know what i miss.
-Mathias
On 07/09/2013 08:08 PM, Oleksij Rempel wrote:
You have right.
this problem didn't disappear, it just masked and have other side effect.
I get corrupt buffers after reloading of ath9k_htc(wifi usb adapter) ...
some times laptop will crash in same way like the bug i
Hi Sarah,
Are there any news on this issue?
suddenly i don't have usb analyser to find what actually happening (That
is way too expensive for Hobbyist). But probably thinkpenguin.com can
provide you some sample to track it down (CC them).
Am 22.07.2013 20:54, schrieb Oleksij Rempel:
Am
Am 23.07.2013 20:26, schrieb Christian Lamparter:
On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
Am 22.07.2013 23:23, schrieb Christian Lamparter:
On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
Am 22.07.2013 21:54, schrieb Christian Lamparter:
Hello!
On Monday, July
Am 22.07.2013 19:33, schrieb Sarah Sharp:
On Mon, Jul 22, 2013 at 11:43:53AM +0200, Oleksij Rempel wrote:
Hello all,
i'm working on ath9k_htc's suspend/resume issue and need your help.
This devices has problems with suspend mode. After it resume,
USB_PHY stay misconfigured. Only way to bring
Am 22.07.2013 23:23, schrieb Christian Lamparter:
On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
Am 22.07.2013 21:54, schrieb Christian Lamparter:
Hello!
On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
i'm one of ath9k_htc devs. Currently i'm working on usb_suspend
in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/usb
same root.
Am 08.07.2013 18:37, schrieb Sarah Sharp:
On Sat, Jul 06, 2013 at 11:13:15AM +0200, Oleksij Rempel wrote:
Hi Sarah,
thanks you or who ever fixed this issue. With latest wireless-testing
i can't reproduce my crash any more. Instead i get this messages:
What kernel is your wireless
Hallo Sarah,
looks like my adventure with this controller are not finished.
Short story:
After reloading ath9k_htc module i get some corrupt urbs on adapter
side. It was possible to confirm it by debuging ath9k_htc firmware. On
the host side i tried to use Wireshark, but at this stage all
Am 11.06.2013 19:34, schrieb Sarah Sharp:
On Mon, Jun 10, 2013 at 08:55:56AM +0200, Oleksij Rempel wrote:
Hello all,
i'm working on usb_autosuspend for ath9k_htc and triggered this
oops. Currently i do not know if real bug is in ath9k_htc or in
xhci. Same adapter with same kernel and my
Am 11.06.2013 19:34, schrieb Sarah Sharp:
On Mon, Jun 10, 2013 at 08:55:56AM +0200, Oleksij Rempel wrote:
Hello all,
i'm working on usb_autosuspend for ath9k_htc and triggered this
oops. Currently i do not know if real bug is in ath9k_htc or in
xhci. Same adapter with same kernel and my
Hello all,
i'm working on usb_autosuspend for ath9k_htc and triggered this oops.
Currently i do not know if real bug is in ath9k_htc or in xhci. Same
adapter with same kernel and my patches work fine on ehci host... so may
be it is xhci.
i get oops on this line:
426 static void
Thank you, this patch fixes this issue.
Am 28.05.2013 16:23, schrieb Alan Stern:
On Mon, 27 May 2013, Oleksij Rempel wrote:
Hmmm. Maybe we can narrow this down. What happens if you apply only
parts of the commit?
For example, on top of c97041a, try applying only the hunks that change
ehci
Am 27.05.2013 17:59, schrieb Alan Stern:
On Mon, 27 May 2013, Oleksij Rempel wrote:
Am 27.05.2013 17:24, schrieb Alan Stern:
On Mon, 27 May 2013, Oleksij Rempel wrote:
Hello Alan,
i have regression with this patch:
commit c1fdb68e3d73741630ca16695cf9176c233be7ed
Author: Alan Stern st
Am 12.07.2012 10:05, schrieb Eric Ding:
On 07/09/2012 10:17 PM, Alan Stern wrote:
On Sun, 8 Jul 2012, Jonathan Nieder wrote:
Eric Ding wrote:
So it looks like you'd have to both look for USB_CLASS_VIDEO and check
uvc_ids[] too... which becomes somewhat hairy, since I assume you don't
realy
On 08.07.2012 07:37, Eric Ding wrote:
On 07/08/2012 09:52 AM, Alan Stern wrote:
On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:
Well, the quirk does make sense. What doesn't make sense is why moving
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change
On 08.07.2012 17:18, Alan Stern wrote:
On Sun, 8 Jul 2012, Eric Ding wrote:
I think the reason was the way rpm_suspend() worked at the time of that
commit (it works a bit differently now, but not as much as to avoid the
problem).
Namely, before commit
On 07.07.2012 11:20, Eric Ding wrote:
On 07/06/2012 11:47 PM, Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes, but we still need to know the reason why. Neither Rafael nor I
has been able to figure out why that commit messed things up.
Was the driver doing any dynamic
On 07.07.2012 13:38, Eric Ding wrote:
On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
On 07.07.2012 11:20, Eric Ding wrote:
On 07/06/2012 11:47 PM, Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes, but we still need to know the reason why. Neither Rafael nor I
has been able
On 07.07.2012 15:55, Eric Ding wrote:
On 07/07/2012 09:11 PM, Oleksij Rempel wrote:
On 07.07.2012 13:38, Eric Ding wrote:
On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
On 07.07.2012 11:20, Eric Ding wrote:
On 07/06/2012 11:47 PM, Alan Stern wrote:
On Fri, 6 Jul 2012, Alan Cox wrote:
Yes
45 matches
Mail list logo
