On 2013-07-01, at 9:48 PM, Oleksandr Tymoshenko <go...@bluezbox.com> wrote:

> On 2013-06-26, at 11:47 PM, Hans Petter Selasky <h...@bitfrost.no> wrote:
>> On 06/27/13 02:53, Oleksandr Tymoshenko wrote:
>>> On 2013-04-07, at 12:04 AM, Hans Petter Selasky <h...@bitfrost.no> wrote:
>>>> On 04/06/13 22:50, Oleksandr Tymoshenko wrote:
>>>>> Hello,

.. skipped ..

> Writing 127 to FADDR breaks driver. It can't even attach device properly. 
> I do not completely understand the scenario behind this requirement. My 
> recollection is: when we cancel IN transaction somehow we should ensure 
> that function that currently handles it does not stuck forever. From what 
> I see it's just impossible. There is internal NAK timer that fails the 
> transaction
> once it reached configured value (or 3 by default AFAIR). Isn't it enough?
> I tried unloading active uwrtn driver - it unloads with some delay but as 
> far as I can see from logs delay is not due to USB internal transactions code
> it must be upper layer. 
> Could you, please, elaborate  on the matter?
> Here is updated version of the patch: 
> http://people.freebsd.org/~gonzo/arm/patches/beaglebone-usb-20130701.diff
> Besides cosmetic fixes I also synced dev/usb/controller/musb_otg_atmelarm.c
> to the latest changes of core logic: added required wrappers and some 
> initializations. 
> I do not longer have access to USB analyzer so my debugging abilities
> is somewhat limited now.

Hi Hans,

The driver seems to be fairly stable judging from my tests. I'd like to commit 
as-is, get more test coverage  from users and tighten up loose ends then. 

What do you think?

freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to