test suite for ath9k_htc

test suite for ath9k_htc

[bruce m beach]

Hello

 I have been working on cleaning up ath9k_htc firmware build tree for about 3
months now( and looks like I'll be doing this for all eternity) and am looking
for a low-level test-suite that exists or I write myself or a combination of
both, so I invite comment.

Bruce

Re: test suite for ath9k_htc

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 486 bytes --]

Am 25.03.2016 um 18:03 schrieb bruce m beach:
> Hello
> 
>  I have been working on cleaning up ath9k_htc firmware build tree for about 3
> months now( and looks like I'll be doing this for all eternity) and am looking
> for a low-level test-suite that exists or I write myself or a combination of
> both, so I invite comment.

Suddenly I'm not aware of any low-level test-suite.

what are your thoughts about it? What exactly do you wont to test?
-- 
Regards,
Oleksij



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

test suite for ath9k_htc

[bruce m beach]

Hello Oleksij

>> Suddenly I'm not aware of any low-level test-suite.

>> What do you mean by low-level?

I mean either going in via an out of tree module or through user land via
libusb, in both cases bypassing all the protocol stacks, (the out of tree
module would directly access the driver calls), both of which I have bits and
pieces working. From reading Dave Taht's email and yours I have decided on the
USB approach, the only real change to the firmware that I have in mind (other
that cleaning up the mess) The change being that with the FUSB200 can
be setup to
have multiple interaces. The first interface being the existing one that the
driver currently talks to. The second interface being for debugging and
exaustive testing of the firmware. I've bits and pieces in place and was
working on it until I became totally distracted by the never ending saga of the
hideous nightmare of the duplicate include files which I mostly got under
control, one directory for building the rom stuff and one directory for
building the ram stuff. I currently can access the firmware with USB but I have
to detach the driver. It would be nice to get around that and have the driver
running while you are working.

>> What exactly do you want to test?

Well in general everything. There is no test suite for the firmware. What I
want I will do and will become available but the thought occurs to me: How many
tests can you dream up using the proc or sys filesystems to put in scripts? Me:
I only know one: turn off the led and I stole that one from Oleksij. What about
Dave Taht's suggestion for exercising both the driver and firmware. That Stuff
is way up in the stratosphere for me. I never work at that level. Do you have
an interest? How about you Dave? What we are talking about is the AR9271 chip
which is the basis of all sorts WIFI adapters. It comes in 2 flavours usb and
pci. I have a TP-LINK TL-WN722N so inexpensive that I bought 3 of them and very
common but also lots of other manufacturers that Oleksij knows about. I would
like to know if anybody has ever had one of these transmitting at a sustained
rate of 155 mbs for an hour or so. I'm curious about something.(Other than will
it melt)

By the way this is all about making the firmware tree easier to use.  Both the
kernel driver and the firmware work fine with certain things known to be
nonfunctional at this time.

Bruce