remote talking to AR9271

[bruce m beach]

> Do not worry to match about "how". Just create patches on
> your personal branch.  Try to do one patch per issue,
> describe what you do and why in the patch and if you think
> "it's time", then do a pull request.

Well I did the first patch on a branch I have locally, that
was no problem, but with the pull request I'm stumped, I
click on the "new pull request" and just don't get anything
that I'm expecting like some kind of form to fill in. Maybe
my brain has turned to mush from doing reverse engineering
all winter. First trying to get the sound working on the
samsung chromebook, which I acomplished and now working on this
project. My own tree that I'm using is quite a bit different
than the one at:
https://github.com/qca/open-ath9k-htc-firmware.git.
What I have done is remove the whole cmake hierarchy
and replaced it with 1 makefile (120 lines), moved all the
c-files(with merging of some of them) into a single
directory with all the include files in a single
subdirectory. This simplifies things a lot. I still have a
some more things like fix up the include files more,
remove some of the protocol layers and rename a lot of the
variables (I've been making a K2 tree only)  but for a
change of pace for the next while I'm going to work on
getting an independent usb link from userland to some
independent code running in the xtensa, hopefully interupt
driven (no dma) to keep it simple as possible. The two
candidates are

1 endpoint 0
2 endpoints 5 and 6 since they are unused.

I'll already have the userland program running which
currently crashes the firmware, which is okay because what I
wanted to find out is if the kernel would somehow block the
opening of the usb file descriptor but apparently not.

Bruce