[ath9k-devel] Extensive AR9280 Documentation

[ath9k-devel] Extensive AR9280 Documentation

[Galen]

I found an interesting document I thought might prove helpful to anybody working on ath9k at a low level:
http://wenku.baidu.com/view/e0e678d184254b35eefd34ed.html

This is a very, very in-depth document that details everything from the functional blocks of AR9280 to the registers. I do not believe a document with this level of detail exists anywhere else online. It makes the ath9k driver source (particularly for AR9002) immensely more understandable. I post this in the hopes that it helps somebody.

Please note, I found this document while searching with Google. I didn't post it, and I'm not responsible for the contents. 

-Galen

[ath9k-devel] Extensive AR9280 Documentation

[Daniel Halperin]

On Thu, Jan 6, 2011 at 10:39 AM, Galen <galenz@zinkconsulting.com> wrote:
> I found an interesting document I thought might prove helpful to anybody working on ath9k at a low level:

Oh come on, don't be posting pirate Chinese stolen documents on here;
we're trying to NOT propagate the myth that all open source users are
hackers that break laws and steal IP from companies.  Atheros is one
of those taking the lead on open sourcing their products, let's not
give them incentives to make an about-face.  Especially with the new
takeover by historically less-awesome Qualcomm!

Dan

[ath9k-devel] Extensive AR9280 Documentation

[Peter Stuge]

Daniel Halperin wrote:
> > I found an interesting document I thought might prove helpful to
> > anybody working on ath9k at a low level:
> 
> Oh come on, don't be posting pirate Chinese stolen documents on here;

Isn't that a matter to take up with whoever posted it in the first
place, rather than with someone who posts a link?


> the myth that all open source users are hackers that break laws and
> steal IP from companies

No myth. Open source requires open information. Companies that are
more worried about IP than anything else will not be very successful
in doing open source.

Another point is that without selling hardware units it's useless to
have IP, unless your purpose in life is to fight patent battles in
court. Good open source built from open information helps sell
hardware units. IP portfolios do not.

And on and on. I basically just disagree.

As you probably know, leaked datasheets are available consistently
persistently throughout the world on and off the internet, and open
source or not is completely irrelevant.

Incidentally it's often neccessary for open source developers to rely
on such leaked information, because that is all they ever get!!

Give and take. Want sit on IP go ahead, people will route around to
find useful solutions.


//Peter

[ath9k-devel] Extensive AR9280 Documentation

[Daniel Halperin]

On Thu, Jan 6, 2011 at 12:01 PM, Peter Stuge <peter@stuge.se> wrote:
> Daniel Halperin wrote:
>> > I found an interesting document I thought might prove helpful to
>> > anybody working on ath9k at a low level:
>>
>> Oh come on, don't be posting pirate Chinese stolen documents on here;
>
> Isn't that a matter to take up with whoever posted it in the first
> place, rather than with someone who posts a link?
>
>
>> the myth that all open source users are hackers that break laws and
>> steal IP from companies
>
> No myth. Open source requires open information. Companies that are
> more worried about IP than anything else will not be very successful
> in doing open source.
>
> Another point is that without selling hardware units it's useless to
> have IP, unless your purpose in life is to fight patent battles in
> court. Good open source built from open information helps sell
> hardware units. IP portfolios do not.
>
> And on and on. I basically just disagree.
>
> As you probably know, leaked datasheets are available consistently
> persistently throughout the world on and off the internet, and open
> source or not is completely irrelevant.
>
> Incidentally it's often neccessary for open source developers to rely
> on such leaked information, because that is all they ever get!!
>
> Give and take. Want sit on IP go ahead, people will route around to
> find useful solutions.

I'm really not going to start flaming with you, I'm just going to say this:

I think the level of support we have now from Atheros is better than
if they pulled entirely out of Linux and we only got support via
ndiswrapper and leaked datasheets.

Dan

[ath9k-devel] Extensive AR9280 Documentation

[Luis R. Rodriguez]

On Thu, Jan 6, 2011 at 12:57 PM, Daniel Halperin
<dhalperi@cs.washington.edu> wrote:
> On Thu, Jan 6, 2011 at 12:01 PM, Peter Stuge <peter@stuge.se> wrote:
>> Daniel Halperin wrote:
>> Give and take. Want sit on IP go ahead, people will route around to
>> find useful solutions.
>
> I'm really not going to start flaming with you, I'm just going to say this:
>
> I think the level of support we have now from Atheros is better than
> if they pulled entirely out of Linux and we only got support via
> ndiswrapper and leaked datasheets.

It helps if the community acknowledges efforts and tries to work with
companies who are putting good effort on things. Respecting IP is a
small trade off that we do ask for. We do provide docs but when
possible and to those who really do work and need it. We are working
on extending our Documentation releases too, so that we can release
more documentation to the public and make it easier and have a
documented way to release more sensitive docs to active developers,
but that requires a bit of an overhaul and good amount of work, but
we'll get there. It should be up to a company to decide what docs to
release though. For now, I do ask that if you do come across links
like these just report them privately to Atheros and please avoid
posting it to public lists.

 Luis

[ath9k-devel] Extensive AR9280 Documentation

[Peter Stuge]

Luis R. Rodriguez wrote:
> It helps if the community acknowledges efforts and tries to work
> with companies who are putting good effort on things.

I would love to ack effort if I had experienced some. I've touched on
a plethora of indications of significant issues in the driver a few
times volunteering to acquire information and do further debugging,
but since all has fallen absolutely flat, it's very hard to ack.


> Respecting IP is a small trade off that we do ask for.

Yes of course. Especially doing something in spite is bad form
uncalled for and unneccessary.

When there is working efficient communication then there is also
no point at all in leaking whatever is considered private. In other
projects there are NDAs between hardware companies and developers,
which allows the software to develop quickly and work really really
great. Maybe that is going on for ath9k too, but has not helped me. :\


//Peter

[ath9k-devel] Extensive AR9280 Documentation

[Luis R. Rodriguez]

On Thu, Jan 06, 2011 at 01:45:48PM -0800, Peter Stuge wrote:
> Luis R. Rodriguez wrote:
> > It helps if the community acknowledges efforts and tries to work
> > with companies who are putting good effort on things.
> 
> I would love to ack effort if I had experienced some. I've touched on
> a plethora of indications of significant issues in the driver a few
> times volunteering to acquire information and do further debugging,
> but since all has fallen absolutely flat, it's very hard to ack.

Can you provide links to your kernel.org bug reports?

> > Respecting IP is a small trade off that we do ask for.
> 
> Yes of course. Especially doing something in spite is bad form
> uncalled for and unneccessary.
> 
> When there is working efficient communication then there is also
> no point at all in leaking whatever is considered private. In other
> projects there are NDAs between hardware companies and developers,
> which allows the software to develop quickly and work really really
> great. Maybe that is going on for ath9k too, but has not helped me. :\

Active developers do get documentation for ath5k without an NDA but
with a gentelmen's petition to not redistribute. We do this for other
OSes too, like for FreeBSD. For ath9k we have not received permission to
release the same docs publicly but am working on creating a better
review process which will let us reconsider releaseing more docs after
a period of time. This is a company process that needs to be built,
so it takes time. In the meantime we do enable active developers to
work with engineers through our private internal list but since
ath9k is Actively maintained by Atheros engineers if you have issues
they should be clearly reported and Atheros will take care of them.

If you have issues I advise you not only use a mailing list but
the bugzilla on kernel.org and report your issue against the
stable kernel you are having an issue with. If you are using
a bleeding edge release (compat-wireless based on linux-next)
or just wireless-testing then you can just use the linux-wireless
mailing list and provide clear details of your issues there.

I believe you have an AR9280 and AR9280 should be IMHO the best
supported 802.11 card on Linux today for both STA/AP mode of operation.
If you have issues can you please put a list together and report them
with clear details either on bugzilla if on a stable kernel or on
linux-wireless if its on wireless-testing.

  Luis

[ath9k-devel] Extensive AR9280 Documentation

[Ben Greear]

On 01/06/2011 02:17 PM, Luis R. Rodriguez wrote:

> so it takes time. In the meantime we do enable active developers to
> work with engineers through our private internal list but since
> ath9k is Actively maintained by Atheros engineers if you have issues
> they should be clearly reported and Atheros will take care of them.

I'd love it if some of those active developers would ack/nack some
patches I've posted recently.  I'm attempting to track down some
issue with tx queues being stopped and not sending pkts to
the hardware, and instrumenting debugfs as I've been doing
seems a good way to debug it.  If I can get those patches in,
I can better report the way I'm causing the problem and maybe you can
reproduce it...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Extensive AR9280 Documentation

[Luis R. Rodriguez]

On Thu, Jan 6, 2011 at 3:04 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 01/06/2011 02:17 PM, Luis R. Rodriguez wrote:
>
>> so it takes time. In the meantime we do enable active developers to
>> work with engineers through our private internal list but since
>> ath9k is Actively maintained by Atheros engineers if you have issues
>> they should be clearly reported and Atheros will take care of them.
>
> I'd love it if some of those active developers would ack/nack some
> patches I've posted recently. ?I'm attempting to track down some
> issue with tx queues being stopped and not sending pkts to
> the hardware, and instrumenting debugfs as I've been doing
> seems a good way to debug it. ?If I can get those patches in,
> I can better report the way I'm causing the problem and maybe you can
> reproduce it...

Sure, it was the holidays you know, I just got back in to SF
yesterday, for example.

  Luis

[ath9k-devel] Extensive AR9280 Documentation

[Ben Greear]

On 01/06/2011 03:14 PM, Luis R. Rodriguez wrote:
> On Thu, Jan 6, 2011 at 3:04 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 01/06/2011 02:17 PM, Luis R. Rodriguez wrote:
>>
>>> so it takes time. In the meantime we do enable active developers to
>>> work with engineers through our private internal list but since
>>> ath9k is Actively maintained by Atheros engineers if you have issues
>>> they should be clearly reported and Atheros will take care of them.
>>
>> I'd love it if some of those active developers would ack/nack some
>> patches I've posted recently.  I'm attempting to track down some
>> issue with tx queues being stopped and not sending pkts to
>> the hardware, and instrumenting debugfs as I've been doing
>> seems a good way to debug it.  If I can get those patches in,
>> I can better report the way I'm causing the problem and maybe you can
>> reproduce it...
>
> Sure, it was the holidays you know, I just got back in to SF
> yesterday, for example.

Glad to have you back!  Debugging ath9k is quite lonely
by oneself :P

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Extensive AR9280 Documentation

[Luis R. Rodriguez]

On Thu, Jan 6, 2011 at 3:19 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 01/06/2011 03:14 PM, Luis R. Rodriguez wrote:
>> On Thu, Jan 6, 2011 at 3:04 PM, Ben Greear<greearb@candelatech.com> ?wrote:
>>> On 01/06/2011 02:17 PM, Luis R. Rodriguez wrote:
>>>
>>>> so it takes time. In the meantime we do enable active developers to
>>>> work with engineers through our private internal list but since
>>>> ath9k is Actively maintained by Atheros engineers if you have issues
>>>> they should be clearly reported and Atheros will take care of them.
>>>
>>> I'd love it if some of those active developers would ack/nack some
>>> patches I've posted recently. ?I'm attempting to track down some
>>> issue with tx queues being stopped and not sending pkts to
>>> the hardware, and instrumenting debugfs as I've been doing
>>> seems a good way to debug it. ?If I can get those patches in,
>>> I can better report the way I'm causing the problem and maybe you can
>>> reproduce it...
>>
>> Sure, it was the holidays you know, I just got back in to SF
>> yesterday, for example.
>
> Glad to have you back! ?Debugging ath9k is quite lonely
> by oneself :P

BTW I should note that if the patch is obvious we typically do not ACK
the patch, as its implicitly OK, we tend to only proactively NACK crap
patches or if changes are very intrusive.

  Luis

[ath9k-devel] Extensive AR9280 Documentation

[Ben Greear]

On 01/06/2011 03:22 PM, Luis R. Rodriguez wrote:
> On Thu, Jan 6, 2011 at 3:19 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 01/06/2011 03:14 PM, Luis R. Rodriguez wrote:
>>> On Thu, Jan 6, 2011 at 3:04 PM, Ben Greear<greearb@candelatech.com>    wrote:
>>>> On 01/06/2011 02:17 PM, Luis R. Rodriguez wrote:
>>>>
>>>>> so it takes time. In the meantime we do enable active developers to
>>>>> work with engineers through our private internal list but since
>>>>> ath9k is Actively maintained by Atheros engineers if you have issues
>>>>> they should be clearly reported and Atheros will take care of them.
>>>>
>>>> I'd love it if some of those active developers would ack/nack some
>>>> patches I've posted recently.  I'm attempting to track down some
>>>> issue with tx queues being stopped and not sending pkts to
>>>> the hardware, and instrumenting debugfs as I've been doing
>>>> seems a good way to debug it.  If I can get those patches in,
>>>> I can better report the way I'm causing the problem and maybe you can
>>>> reproduce it...
>>>
>>> Sure, it was the holidays you know, I just got back in to SF
>>> yesterday, for example.
>>
>> Glad to have you back!  Debugging ath9k is quite lonely
>> by oneself :P
>
> BTW I should note that if the patch is obvious we typically do not ACK
> the patch, as its implicitly OK, we tend to only proactively NACK crap
> patches or if changes are very intrusive.

Well, that leaves me in limbo.  Hard to tell if the patch
was ignored or was OK, and since it can take a while for
wireless-testing to pull in patches anyway, it's easy to
get a week or two behind....

Thanks,
Ben

>
>    Luis


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Extensive AR9280 Documentation

[Adrian Chadd]

On 7 January 2011 06:17, Luis R. Rodriguez <lrodriguez@atheros.com> wrote:

>> When there is working efficient communication then there is also
>> no point at all in leaking whatever is considered private. In other
>> projects there are NDAs between hardware companies and developers,
>> which allows the software to develop quickly and work really really
>> great. Maybe that is going on for ath9k too, but has not helped me. :\
>
> Active developers do get documentation for ath5k without an NDA but
> with a gentelmen's petition to not redistribute. We do this for other
> OSes too, like for FreeBSD. For ath9k we have not received permission to
> release the same docs publicly but am working on creating a better
> review process which will let us reconsider releaseing more docs after
> a period of time. This is a company process that needs to be built,
> so it takes time. In the meantime we do enable active developers to
> work with engineers through our private internal list but since
> ath9k is Actively maintained by Atheros engineers if you have issues
> they should be clearly reported and Atheros will take care of them.

I'd just like to follow up on that, as I think I'm (the?) one of the
FreeBSD people Luis touched on here.

Yes, trying to develop this stuff without comprehensive documentation
is proving difficult. But I've had nothing but wonderful help from
folks like Luis, Felix and some from the ath5k crowd whose names
currently elude me.

If you delve down deep enough to begin figuring out how things hold
together in the driver, a few well-placed questions tends to be enough
to get a set of very well-placed answers. This is how Felix and I
figured out some of the calibration issues with the AR9160's in the
past.

And yes, I've been gently poking Luis and others from time to time to
get access to AR5008/AR9001/AR9002 documentation so I can bring the
FreeBSD HAL code up to date and implement the missing 11n bits. I
realise that there's a lot going on behind the scenes (and I'm glad I
don't have to deal with the politics involved!) and that these sorts
of things take time and dedication from people like Luis who has been
and will continue to champion getting active developers access to the
right resources.

I just thank them for what they've been able to help me with thus far.

Now, I'm going back to lurking so I can finish off FreeBSD's initial
ath 11n commit. :-)



Adrian

[ath9k-devel] Extensive AR9280 Documentation

[Luca Olivetti]

Al 07/01/11 09:49, En/na Adrian Chadd ha escrit:

> If you delve down deep enough to begin figuring out how things hold
> together in the driver, a few well-placed questions tends to be enough
> to get a set of very well-placed answers.

Then I must royally suck at formulating questions. At least the leaked 
documentation gave me a partial answer to my unanswered questions.

Bye
-- 
Luca

[ath9k-devel] Extensive AR9280 Documentation

[Peter Stuge]

Daniel Halperin wrote:
> I think the level of support we have now from Atheros is better
> than if they pulled entirely out of Linux and we only got support
> via ndiswrapper and leaked datasheets.

If only you knew what a joke your statement is to me.

I feel like an absolute fool for buying hardware simply because of
the existence of the ath9k driver, as it simply does not work right
after more than a year still.

I'm just a highly technical end user, so I'm completely insignificant
of course.

(The internet told me that Atheros felt STA important but oh well.)

My hardware expense of 50 EUR and my time attempting to debug during
the last 15 months or so is also not relevant.

The ath9k hardware I do have tends to work very well in AP mode. But
I believe that is largely thanks to efforts from parties not Atheros.

In parallell I've been following development of several other wifi
drivers in Linux. Today, I would much rather have a particular
broadcom .11n chip in my computer, since then maybe I wouldn't need
to drag around the old cardbus card to have wifi connectivity.
Unfortunately it's only a ref design board not really on market.

And that's not the new .11n chips running with the newest driver code
dump from brcm, but rather an older chip and would use a
re-engineered driver that works reliably though not at full capacity.

Reverse engineering is baroque waste of life and intelligence. I have
done enough to know. But apparently it's required for Linux wifi in
2010, because there sure is no detailed technical discussion in the
open here.


//Peter

[ath9k-devel] Extensive AR9280 Documentation

[Luis R. Rodriguez]

On Thu, Jan 06, 2011 at 01:33:34PM -0800, Peter Stuge wrote:
> Daniel Halperin wrote:
> > I think the level of support we have now from Atheros is better
> > than if they pulled entirely out of Linux and we only got support
> > via ndiswrapper and leaked datasheets.
> 
> If only you knew what a joke your statement is to me.
> 
> I feel like an absolute fool for buying hardware simply because of
> the existence of the ath9k driver, as it simply does not work right
> after more than a year still.

Please read my e-mail.

> I'm just a highly technical end user, so I'm completely insignificant
> of course.

Technical users are appreciated but we need you to report issues properly.

> (The internet told me that Atheros felt STA important but oh well.)

Atheros STA is key, and our commitment is to make it the best.

> The ath9k hardware I do have tends to work very well in AP mode. But
> I believe that is largely thanks to efforts from parties not Atheros.

Atheros AP mode has definitley been implemented mostly by openwrt folks
but Atheros has also enabled openwrt folks with proper documentation.
Atheros' engineers have mostly focused on STA mode of operation and
only sometimes work on AP mode. The community has done wonders in helping
with AP mode and even Mesh.

> In parallell I've been following development of several other wifi
> drivers in Linux. Today, I would much rather have a particular
> broadcom .11n chip in my computer, since then maybe I wouldn't need
> to drag around the old cardbus card to have wifi connectivity.
> Unfortunately it's only a ref design board not really on market.
> 
> And that's not the new .11n chips running with the newest driver code
> dump from brcm, but rather an older chip and would use a
> re-engineered driver that works reliably though not at full capacity.

In my experience b43 and b43legacy and even the proprietary drivers are
terrible and in no way can be realistically compared to what we have with
ath9k.

> Reverse engineering is baroque waste of life and intelligence. I have
> done enough to know. But apparently it's required for Linux wifi in
> 2010, because there sure is no detailed technical discussion in the
> open here.

You're mere pessimism to me indicates more that you likely have not
reported your issues properly, I highly recommend you reconsider your
strategy to work on reporting the issues, I'm possitive they will be
addressed. STA mode of operation is critical for Atheros on ath9k.

  Luis