[ath9k-devel] general question about AR7010 arch.
Hi all, do i understand correctly - AR7010 is generally a MIPS CPU? AR5523 is R4000 MIPS. How about AR9170 and other usb controllers? If it is true, are there any good reason to develop separate firmware for each of them? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM
On Sat, Mar 30, 2013 at 06:27:53AM -0700, Adrian Chadd wrote: >IIRC, there's ETSI requirements that tones are generated to test centre >frequency accuracies. I thought that the FCC had those too? >Adrian I'd asked the RF boys. Nobody can recall exactly, they do it more than two years ago, but they did it with MXA Signal Analyzer which measures frequency error. They do not spent too much time on it beacuse if you have 5ppm quartz generator then the precision of carrier frequencies is guaranteed by design. Most problems in ETSI is out-of-band radiation pattern which it defines in absolute values in contradistinction to FCC. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [Question] About WoW in ath9k
On Thu, Mar 28, 2013 at 4:41 PM, Ryo Matsuura wrote: > Hello > > I'm using Atheros 9280 device. > I find interesting mailing list message about WoW. > > - > Title:[PATCH v4 00/10] Add support for WOW in ath9k > Mohammed Shafi Shajakhan Tue, 10 Jul 2012 02:23:08 -0700 > - > > I would like to try a WoW function. > Is there any information on Chipset which checked WoW by ath9k? AR9462, your chip needs to be wow enabled in the hardware. > > Regards > > Matsuura > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- thanks, shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
On Wed, Mar 27, 2013 at 7:04 PM, Peter Stuge wrote: > Adrian Chadd wrote: > > the "quick" fix is to re-reset the PCI slot or the PCI bus. > > Read the quote from Daniel's email again. It explains how that caused > the problem. > > In his bad case there was a reset at time 1 and another reset at time 2. > > Removing the reset at time 1 and keeping an unchanged reset at time 2 > made the problem disappear. > > It seems that the hardware could not handle the reset at time 1, > presumably because the reset was incorrect per the specification. > It wasn't that it could not handle the reset a time 1 but that the reset at time 2 was causing the issue that Michael explained with hanging the EEPROM. So it is not that either reset was more appropriate than the other but that for this BIOS implementation it was better to remove time 1 and keep time 2 since one reset really was needed. > The reset at time 2 is presumably correct, since things work with it. > > If something (the reset at time 1) is able to screw up hardware so > badly that even a correct reset (time 2) does not *actually* reset > the hardware then I would consider that a very serious bus IP > problem in the hardware. > > It would be interesting to know if this is *really* the problem. I'm > not at all sure. > > > > PCI device resource allocation and enumeration; which the Linux > > kernel may or may not do. > > It does not. > > > > The real fix is to smack the heck out of BIOS writers who do > > strange and wonderful crap in their BIOS when resetting > > Enumeration comes much later. The only two possibilities are a. the > reset at time 1 violated the specification and b. the hardware > doesn't handle multiple resets reliably. > The vendor never mentioned whether this was out of spec or if the card was not compliant but I can say that this was not the first issue we had run into with a BIOS. Another instance was making assumptions that no one would ever have more than 20 PCIe devices connected to the bus. This was an artificial limit imposed by the BIOS writter that did technically violate the spec. It would be good to get more detail about what exactly makes the > hardware fail to initialize registers from the EEPROM. > > I don't think there's such a thing as "best practise" on a bus. > Either the spec is followed (by everyone) or it isn't. :) > > > //Peter > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure
Re-enable interrupts after a channel change failure, since
ath_complete_reset will not be called. Also schedule a reset as a
best effort method to recover the chip from whatever state caused the
channel change failure.
Signed-off-by: Robert Shade
---
drivers/net/wireless/ath/ath9k/main.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 24650fd..0567ac9 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -280,6 +280,12 @@ static int ath_reset_internal(struct ath_softc
*sc, struct ath9k_channel *hchan)
if (r) {
ath_err(common,
"Unable to reset channel, reset status %d\n", r);
+
+ ath9k_hw_set_interrupts(ah);
+ ath9k_hw_enable_interrupts(ah);
+
+ ath9k_queue_reset(sc, RESET_TYPE_BB_HANG);
+
goto out;
}
--
1.7.1
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] general question about AR7010 arch.
On 1 April 2013 00:40, Oleksij Rempel wrote: > Hi all, > > do i understand correctly - AR7010 is generally a MIPS CPU? > AR5523 is R4000 MIPS. How about AR9170 and other usb controllers? > If it is true, are there any good reason to develop separate firmware for > each of them? So! * AR5523 is a mips 4kp or 4kc, I forget * AR9170 is some SH core (SH4?); * AR7010/AR9271 is a Tensilica core. It'd be nice if there were some shared code between them! However a lot of code gets stuffed into ROM. So it's not necessarily easy to have a shared firmware between each. That said, it'd be nice if we could unify things over time if it were possible. There's not much code in each of these. Anyway - I'm trying to get the AR5523 firmware open sourced. I'll post updates when this has finished. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure
You filed a bug against this, right? Can you mention the bug report in there?
(What's the "blessed" way to mention a bugzilla.kernel.org bug in a
linux git commit?)
adrian
On 1 April 2013 07:22, Robert Shade wrote:
> Re-enable interrupts after a channel change failure, since
> ath_complete_reset will not be called. Also schedule a reset as a
> best effort method to recover the chip from whatever state caused the
> channel change failure.
>
> Signed-off-by: Robert Shade
> ---
> drivers/net/wireless/ath/ath9k/main.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c
> b/drivers/net/wireless/ath/ath9k/main.c
> index 24650fd..0567ac9 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -280,6 +280,12 @@ static int ath_reset_internal(struct ath_softc
> *sc, struct ath9k_channel *hchan)
> if (r) {
> ath_err(common,
> "Unable to reset channel, reset status %d\n", r);
> +
> + ath9k_hw_set_interrupts(ah);
> + ath9k_hw_enable_interrupts(ah);
> +
> + ath9k_queue_reset(sc, RESET_TYPE_BB_HANG);
> +
> goto out;
> }
>
> --
> 1.7.1
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] general question about AR7010 arch.
Am 01.04.2013 18:24, schrieb Adrian Chadd: > On 1 April 2013 00:40, Oleksij Rempel wrote: >> Hi all, >> >> do i understand correctly - AR7010 is generally a MIPS CPU? >> AR5523 is R4000 MIPS. How about AR9170 and other usb controllers? >> If it is true, are there any good reason to develop separate firmware for >> each of them? > > So! > > * AR5523 is a mips 4kp or 4kc, I forget > * AR9170 is some SH core (SH4?); > * AR7010/AR9271 is a Tensilica core. > > It'd be nice if there were some shared code between them! However a > lot of code gets stuffed into ROM. So it's not necessarily easy to > have a shared firmware between each. > > That said, it'd be nice if we could unify things over time if it were > possible. There's not much code in each of these. > > Anyway - I'm trying to get the AR5523 firmware open sourced. I'll post > updates when this has finished. Sounds great. I have AR5523+AR2112 and AR5523+AR5112.. so, some testing can be done :) -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure
Yes, https://bugzilla.kernel.org/show_bug.cgi?id=55771
It was actually at the bottom of my commit message, but now I see that it
was cut off by git format-patch
On Mon, Apr 1, 2013 at 12:25 PM, Adrian Chadd wrote:
> You filed a bug against this, right? Can you mention the bug report in
> there?
>
> (What's the "blessed" way to mention a bugzilla.kernel.org bug in a
> linux git commit?)
>
>
>
> adrian
>
>
> On 1 April 2013 07:22, Robert Shade wrote:
> > Re-enable interrupts after a channel change failure, since
> > ath_complete_reset will not be called. Also schedule a reset as a
> > best effort method to recover the chip from whatever state caused the
> > channel change failure.
> >
> > Signed-off-by: Robert Shade
> > ---
> > drivers/net/wireless/ath/ath9k/main.c |6 ++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/main.c
> > b/drivers/net/wireless/ath/ath9k/main.c
> > index 24650fd..0567ac9 100644
> > --- a/drivers/net/wireless/ath/ath9k/main.c
> > +++ b/drivers/net/wireless/ath/ath9k/main.c
> > @@ -280,6 +280,12 @@ static int ath_reset_internal(struct ath_softc
> > *sc, struct ath9k_channel *hchan)
> > if (r) {
> > ath_err(common,
> > "Unable to reset channel, reset status %d\n", r);
> > +
> > + ath9k_hw_set_interrupts(ah);
> > + ath9k_hw_enable_interrupts(ah);
> > +
> > + ath9k_queue_reset(sc, RESET_TYPE_BB_HANG);
> > +
> > goto out;
> > }
> >
> > --
> > 1.7.1
>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure
On 2013-04-01 4:22 PM, Robert Shade wrote:
> Re-enable interrupts after a channel change failure, since
> ath_complete_reset will not be called. Also schedule a reset as a
> best effort method to recover the chip from whatever state caused the
> channel change failure.
>
> Signed-off-by: Robert Shade
Your patch is badly whitespace damaged.
> ---
> drivers/net/wireless/ath/ath9k/main.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c
> b/drivers/net/wireless/ath/ath9k/main.c
> index 24650fd..0567ac9 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -280,6 +280,12 @@ static int ath_reset_internal(struct ath_softc
> *sc, struct ath9k_channel *hchan)
> if (r) {
> ath_err(common,
> "Unable to reset channel, reset status %d\n", r);
> +
> + ath9k_hw_set_interrupts(ah);
Why the call to ath9k_hw_set_interrupts here?
> + ath9k_hw_enable_interrupts(ah);
> +
> + ath9k_queue_reset(sc, RESET_TYPE_BB_HANG);
> +
> goto out;
> }
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Re-enable interrupts after a channel change failure
On Mon, Apr 01, 2013 at 09:25:43AM -0700, Adrian Chadd wrote: > You filed a bug against this, right? Can you mention the bug report in there? > > (What's the "blessed" way to mention a bugzilla.kernel.org bug in a > linux git commit?) I usually just include the URL. "Fixes Bug #12345" would suffice as well. -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] general question about AR7010 arch.
Hi, On 1 April 2013 10:05, Christopher Waid wrote: > I'd like to see the ath3k firmware for the AR3011/AR3012 released more > than the firmware for the AR5523 chipset. The ath3k supports USB bluetooth > and there are no mini pcie combo cards with a free wireless/bluetooth > chipset combination at the moment. This chipset is a USB chipset that > shows up as a USB device on the mini pcie card. I forget what its called > although newer systems USB support through the mini pcie slot. The AR5523 firmware is (somewhat) easier as a concept to open up because it really is an already-opensourced CPU core with an already-opensourced wifi chip (AR5212) and some USB device which I _think_ is related to what's in subsequent SoCs. The bluetooth firmware is a completely different business unit. I'd have to go digging to find out all the relevant software/documentation and see what concerns people have before I even attempt that. So, maybe after I've finished opening up the last couple things I'm doing at the moment. Especially the older bluetooth chipset that we stopped shipping firmware for for some odd reason. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM
On 1 April 2013 01:14, Alex Hacker wrote: > I'd asked the RF boys. Nobody can recall exactly, they do it more than two > years ago, but they did it with MXA Signal Analyzer which measures frequency > error. They do not spent too much time on it beacuse if you have 5ppm quartz > generator then the precision of carrier frequencies is guaranteed by design. > Most problems in ETSI is out-of-band radiation pattern which it defines in > absolute values in contradistinction to FCC. Right. I _think_ the tx continuous tone operation does transmit carriers of various widths, up to 20/40mhz, with the TX spectral mask being met (ie, it doesn't just blurt crap everywhere.) I believe that's what is used when doing compliance testing. Anyway, I'm back in the office in a couple days; I'll dig into this further and try to come up with a plan moving forward. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath: Let user know which keycache method is complaining.
From: Ben Greear
Should make the warning messages more useful.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/key.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/key.c b/drivers/net/wireless/ath/key.c
index 5c54aa4..1816b4e 100644
--- a/drivers/net/wireless/ath/key.c
+++ b/drivers/net/wireless/ath/key.c
@@ -45,7 +45,8 @@ bool ath_hw_keyreset(struct ath_common *common, u16 entry)
void *ah = common->ah;
if (entry >= common->keymax) {
- ath_err(common, "keycache entry %u out of range\n", entry);
+ ath_err(common, "keyreset: keycache entry %u out of range\n",
+ entry);
return false;
}
@@ -91,7 +92,8 @@ static bool ath_hw_keysetmac(struct ath_common *common,
void *ah = common->ah;
if (entry >= common->keymax) {
- ath_err(common, "keycache entry %u out of range\n", entry);
+ ath_err(common, "keysetmac: keycache entry %u out of range\n",
+ entry);
return false;
}
@@ -133,7 +135,8 @@ static bool ath_hw_set_keycache_entry(struct ath_common
*common, u16 entry,
u32 keyType;
if (entry >= common->keymax) {
- ath_err(common, "keycache entry %u out of range\n", entry);
+ ath_err(common, "set-entry: keycache entry %u out of range\n",
+ entry);
return false;
}
--
1.7.3.4
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Announcement: open source AR9380 and later HAL
On Fri Mar 15 02:10:50 2013, Adrian Chadd wrote: > Hi, > > I just realised I forgot to announce this here! > > I've been working on open sourcing the QCA 10.x mainline AR9380 HAL. > It's passed legal approval (well, last week!) and you can now find it > online: > > https://github.com/qca/qcamain_open_hal_public > > Now, the 30 second FAQ: > > * It's from Nov 27, 2012 - which means there are a few things that > have changed since then - so don't use it as an authoritative > reference compared to ath9k without doing much more digging! ; > * It's missing certain things - including but not limited to > EEPROM/OTP write, TX beamforming, spectral scan (but this will change > later), fast channel change, various calibration and debug modes which > are used for manufacturing; > * It (mostly) compiles and runs as-is, if you're a FreeBSD user and > have a HAL framework to compile it against. > > I've done this so open source developers can see a known good and > working version of the chipset support for the AR9380 and later. > > If you check out my personal git fork: > > https://github.com/erikarn/qcamain_open_hal_public > > You'll see that I have a branch (local/freebsd) which contains the > (mostly mechanical!) changes to FreeBSD in order to use it. And yes, > this branch does compile and run in FreeBSD, giving me AR9380 and > later chipset support. > > I have an update underway to bring it up to the latest code (well, as > of March 13, 2013) and I'll send out another announcement once that's > done. > > I'll also work with legal and engineering teams to get further > features opened up. > > Thanks and enjoy! > > > > Adrian > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks a lot Adrian ! Keep it up :-) ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Source code for Bluetooth AR3012 drivers
Hello all, Under the link, git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ar3k/ there is only .dfu file and could not get the source code. Where can I find and download the source code base for this driver? Thanks & regards Sandeep Suresh ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Source code for Bluetooth AR3012 drivers
The source code is not available for the AR3xxx series hardware, I'm sorry. The devices run firmware, either in RAM, ROM or flash. Thanks, Adrian On 1 April 2013 20:00, sandeep suresh wrote: > Hello all, > Under the link, > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ar3k/ > > there is only .dfu file and could not get the source code. Where can I find > and download the source code base for this driver? > > Thanks & regards > Sandeep Suresh > > > > > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Source code for Bluetooth AR3012 drivers
Thanks Mr.Adrian for the quick response. Regards Sandeep. From: Adrian Chadd To: sandeep suresh Cc: ath9k-devel ; "linux-wirel...@vger.kernel.org" Sent: Tuesday, 2 April 2013 8:37 AM Subject: Re: [ath9k-devel] Source code for Bluetooth AR3012 drivers The source code is not available for the AR3xxx series hardware, I'm sorry. The devices run firmware, either in RAM, ROM or flash. Thanks, Adrian On 1 April 2013 20:00, sandeep suresh wrote: > Hello all, > Under the link, > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ar3k/ > > there is only .dfu file and could not get the source code. Where can I find > and download the source code base for this driver? > > Thanks & regards > Sandeep Suresh > > > > > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Cyclic throughput at a distance
Hi Björn Smedman, Have you resolved the issue? I encountered the same problem on AR9580 (atheros official driver), but still no clue so far. Looking forward to your response, thx! ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
