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:
.. 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
> 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:
> 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
> I do not longer have access to USB analyzer so my debugging abilities
> is somewhat limited now.
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?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"