No subject

[<bogus@does.not.exist.com>]

The lower you go on the level of abstraction, the more data any kind of
debugging approach generates, meaning way more effort to analyze the
data and make sense of it.
I don't typically start with the part that's hardest to analyze. High
level states are easier to look into and make sense of, so they're also
easier to rule out.
Code review is also a very good starting point. I actually found and
fixed more user visible bugs through code review than any other
debugging method.

>> > but hardware development information in the community is not
>> > really available.
>> 
>> I found that people that have shown enough interest in improving ath9k
>> and have proven to be experienced in working on such drivers tend to get
>> access to documentation.
> 
> Well, let's say that in my experience the threshold for "approval"
> was set too high. As I said, and as you may remember, I was
> repeatedly shot down or ignored, offering to try to get to the bottom
> of the issues. I understand now that it may not really be legally
> possible for Atheros to provide the information that is actually
> required to get to the bottom of the issues, but that makes working
> on the driver too inefficient.
Most issues can be fixed with a good understanding of the code alone,
detailed hardware knowledge is often not as important.
This isn't unique to ath9k. I've fixed bugs in other drivers as well
without having any form of hardware documentation, because I'm able to
read and understand code and my brain can handle a bit of complexity.

>> > Being told to try to reverse engineer the hardware using the
>> > driver source code or any other source code does not qualify.
>> 
>> Your definition of 'reverse engineering' is quite funny.
> 
> There's not just one type of reverse engineering.
> 
> Suggesting hardware reverse engineering in an open source driver
> development effort is, well, not what I expect.
> 
> 
>> To me it looks somewhat ridiculous that you claim to know better what's
>> required to debug this issue than people working with the hardware on a
>> daily basis (Adrian, Mohammed, me).
> 
> I've developed both hardware and software for more than 20 years, and
> neither problems nor solutions have changed much, so I think I still
> have a clue.
OK, so let me get this straight: You can't imagine how the test result
from disabling PS could be useful for tracking down the problem, so you
automatically assume that it *must* be a lame workaround suggestion?
That seems rather narrow-minded of you.

Of course I can see multiple ways in which this information would be
useful, but I guess that may not matter to you.

- Felix