* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: reinette chatre @ 2010-04-26 16:42 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <k2i2d0a357f1004260931l98ce66d2ia3422958779c64d7@mail.gmail.com>
On Mon, 2010-04-26 at 09:31 -0700, Sedat Dilek wrote:
> I tested both .34-git4 kernels half a day and this was the only
> problem I saw in the my system-logs.
This may indicate a problem in your environment since it just says that
the station cannot communicate with the AP anymore. This occurs very
often in various environments. This does not indicate a bug.
> BTW, the WLAN connection did not crash as described in the initial
> bug-report (logs see [1]).
> At that time, I had to coldstart my machine - this was not the case
> last weekend while testing.
Either this issue is very hard to reproduce or it has been addressed
with a change introduced between the kernels you are testing. Can you
reproduce the issue when going back to earlier kernels? If so, then this
may be a candidate for a bisect for us to find out what fixed it.
Reinette
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: Sedat Dilek @ 2010-04-26 17:04 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <1272300138.4381.8815.camel@rchatre-DESK>
On Mon, Apr 26, 2010 at 6:42 PM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Mon, 2010-04-26 at 09:31 -0700, Sedat Dilek wrote:
>> I tested both .34-git4 kernels half a day and this was the only
>> problem I saw in the my system-logs.
>
> This may indicate a problem in your environment since it just says that
> the station cannot communicate with the AP anymore. This occurs very
> often in various environments. This does not indicate a bug.
>
>> BTW, the WLAN connection did not crash as described in the initial
>> bug-report (logs see [1]).
>> At that time, I had to coldstart my machine - this was not the case
>> last weekend while testing.
>
> Either this issue is very hard to reproduce or it has been addressed
> with a change introduced between the kernels you are testing. Can you
> reproduce the issue when going back to earlier kernels? If so, then this
> may be a candidate for a bisect for us to find out what fixed it.
>
The kernel (with patches) is identical to the one from 20100417, so
what shall I bisect?
With same kernel-config, etc.
But in the meantime I upgraded my system - it could be that some other
package(s) fixed the magic.
Other idea could be some temporarily occured disturbance in WLAN
connection and/or in streaming on the websites I visited.
- Sedat -
^ permalink raw reply
* 802.11n copper bag hack for MIMO
From: Luis R. Rodriguez @ 2010-04-26 17:10 UTC (permalink / raw)
To: linux-wireless
Figured you guys working with 802.11n on close range over the air
environments might enjoy this little hack to test performance with
MIMO:
http://www.youtube.com/watch?v=pCMjKJ7LK_U
Luis
^ permalink raw reply
* Re: [RFC/RFT] ssb: Avoid system hang when SPROM read fails
From: John W. Linville @ 2010-04-26 17:15 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, b43-dev, linux-wireless
In-Reply-To: <4bd4c284.WBohOsmgdwRzw5JC%Larry.Finger@lwfinger.net>
On Sun, Apr 25, 2010 at 05:30:28PM -0500, Larry Finger wrote:
> In kernel Bugzilla #15825, the OP reports a case of intermittent reading
> of the SPROM. If such reads fail, the box hangs. Thanks to careful testing
> by bugzillakernelorg@lez.ath.cx has shown that the first read of the
> SPROM returns 0xFFFF with the hang happening on the next read.
>
> The source of the read failure is still under investigation; however,
> this patch does avoid the system hang.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> Does this patch avoid the system hang on your box?
>
> Larry
> ---
>
> ===================================================================
> --- wireless-testing.orig/drivers/ssb/pci.c
> +++ wireless-testing/drivers/ssb/pci.c
> @@ -253,6 +253,11 @@ static int sprom_do_read(struct ssb_bus
> {
> int i;
>
> + /* Check if SPROM can be read */
> + if (ioread16(bus->mmio + SSB_SPROM_BASE) == 0xFFFF) {
> + ssb_printk(KERN_ERR PFX "Unable to read SPROM\n");
> + return -ENODEV;
> + }
> for (i = 0; i < bus->sprom_size; i++)
> sprom[i] = ioread16(bus->mmio + SSB_SPROM_BASE + (i * 2));
>
Well, the "good" news is that I hit the "Unable to read SPROM" case.
The bad news is that the box still hangs after the -ENODEV. I have
not yet tracked-down the exact location of the current hang.
John
P.S. Sorry about the 'radio silence' -- I've been distracted with
some other things. Also, the box in question originally belonged
to someone else who had configured it in a way that was less than
friendly to kernel development. I finally reinstalled it...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] mac80211: fix handling of 4-address-mode in ieee80211_change_iface
From: Felix Fietkau @ 2010-04-26 17:54 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Johannes Berg
A misplaced interface type check bails out too early if the interface
is not in monitor mode. This patch moves it to the right place, so that
it only covers changes to the monitor flags.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -97,9 +97,6 @@ static int ieee80211_change_iface(struct
params->mesh_id_len,
params->mesh_id);
- if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
- return 0;
-
if (type == NL80211_IFTYPE_AP_VLAN &&
params && params->use_4addr == 0)
rcu_assign_pointer(sdata->u.vlan.sta, NULL);
@@ -107,6 +104,9 @@ static int ieee80211_change_iface(struct
params && params->use_4addr >= 0)
sdata->u.mgd.use_4addr = params->use_4addr;
+ if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
+ return 0;
+
sdata->u.mntr_flags = *flags;
return 0;
}
^ permalink raw reply
* Re: [PATCH V4] ssb: Implement virtual SPROM
From: John W. Linville @ 2010-04-26 17:58 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, bcm43xx-dev, linux-wireless
In-Reply-To: <4bac487c.j3EXBzCzHYNAd+Ky%Larry.Finger@lwfinger.net>
On Fri, Mar 26, 2010 at 12:39:08AM -0500, Larry Finger wrote:
> Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
> from the SPROM could be included in the kernel; however, this presents
> a problem in the generation of a unique, reproducible MAC address. The
> solution is to initialize the address to a known, workable value. Thus,
> the device will work without any further code. For an address that is
> preserved across reloads or reboots, a set of udev routines has been
> prepared that detect the special address and assign a random value that
> is preserved in a second udev rule file. The random address should be
> unique except for the case where a given box has more than one of these
> cards. This case is handles by adding the DEVPATH to the recognition rules.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Do we still want this patch? Or do we think all the cases of a
"missing" SPROM were actually a "relocated" SPROM?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 1/3] ath9k_htc: Remove unnecessary powersave restore
From: Sujith @ 2010-04-26 9:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 9c9f3e0..644776a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -153,7 +153,6 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv,
ath_print(common, ATH_DBG_FATAL,
"Unable to reset channel (%u Mhz) "
"reset status %d\n", channel->center_freq, ret);
- ath9k_htc_ps_restore(priv);
goto err;
}
--
1.7.0.5
^ permalink raw reply related
* [PATCH 3/3] ath9k_htc: Simplify RX IRQ handler
From: Sujith @ 2010-04-26 9:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
A bunch of validation and processing in the RX IRQ handler
can be moved to the RX tasklet. The IRQ handler is
already heavy, with the memory allocation for handling
stream mode. Also, a memcpy of 40 bytes for every packet
can be avoided in the handler.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 44 ++++++++++++------------
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 08bfe5d..28abc7d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -448,10 +448,32 @@ static bool ath9k_rx_prepare(struct ath9k_htc_priv *priv,
struct ieee80211_hw *hw = priv->hw;
struct sk_buff *skb = rxbuf->skb;
struct ath_common *common = ath9k_hw_common(priv->ah);
+ struct ath_htc_rx_status *rxstatus;
int hdrlen, padpos, padsize;
int last_rssi = ATH_RSSI_DUMMY_MARKER;
__le16 fc;
+ if (skb->len <= HTC_RX_FRAME_HEADER_SIZE) {
+ ath_print(common, ATH_DBG_FATAL,
+ "Corrupted RX frame, dropping\n");
+ goto rx_next;
+ }
+
+ rxstatus = (struct ath_htc_rx_status *)skb->data;
+
+ if (be16_to_cpu(rxstatus->rs_datalen) -
+ (skb->len - HTC_RX_FRAME_HEADER_SIZE) != 0) {
+ ath_print(common, ATH_DBG_FATAL,
+ "Corrupted RX data len, dropping "
+ "(dlen: %d, skblen: %d)\n",
+ rxstatus->rs_datalen, skb->len);
+ goto rx_next;
+ }
+
+ /* Get the RX status information */
+ memcpy(&rxbuf->rxstatus, rxstatus, HTC_RX_FRAME_HEADER_SIZE);
+ skb_pull(skb, HTC_RX_FRAME_HEADER_SIZE);
+
hdr = (struct ieee80211_hdr *)skb->data;
fc = hdr->frame_control;
hdrlen = ieee80211_get_hdrlen_from_skb(skb);
@@ -616,8 +638,6 @@ void ath9k_htc_rxep(void *drv_priv, struct sk_buff *skb,
struct ath_hw *ah = priv->ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_rxbuf *rxbuf = NULL, *tmp_buf = NULL;
- struct ath_htc_rx_status *rxstatus;
- u32 len = 0;
spin_lock(&priv->rx.rxbuflock);
list_for_each_entry(tmp_buf, &priv->rx.rxbuf, list) {
@@ -634,27 +654,7 @@ void ath9k_htc_rxep(void *drv_priv, struct sk_buff *skb,
goto err;
}
- len = skb->len;
- if (len <= HTC_RX_FRAME_HEADER_SIZE) {
- ath_print(common, ATH_DBG_FATAL,
- "Corrupted RX frame, dropping\n");
- goto err;
- }
-
- rxstatus = (struct ath_htc_rx_status *)skb->data;
-
- if (be16_to_cpu(rxstatus->rs_datalen) -
- (len - HTC_RX_FRAME_HEADER_SIZE) != 0) {
- ath_print(common, ATH_DBG_FATAL,
- "Corrupted RX data len, dropping "
- "(epid: %d, dlen: %d, skblen: %d)\n",
- ep_id, rxstatus->rs_datalen, len);
- goto err;
- }
-
spin_lock(&priv->rx.rxbuflock);
- memcpy(&rxbuf->rxstatus, rxstatus, HTC_RX_FRAME_HEADER_SIZE);
- skb_pull(skb, HTC_RX_FRAME_HEADER_SIZE);
rxbuf->skb = skb;
rxbuf->in_process = true;
spin_unlock(&priv->rx.rxbuflock);
--
1.7.0.5
^ permalink raw reply related
* [PATCH 2/3] ath9k_htc: Validate TX Endpoint ID
From: Sujith @ 2010-04-26 9:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Check for the endpoint IDs when processing
TX completions and drop the unsupported EPIDs.
We can add other endpoints (UAPSD,..) when support
is added.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 2c3c510..08bfe5d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -244,16 +244,25 @@ void ath9k_htc_txep(void *drv_priv, struct sk_buff *skb,
enum htc_endpoint_id ep_id, bool txok)
{
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) drv_priv;
+ struct ath_common *common = ath9k_hw_common(priv->ah);
struct ieee80211_tx_info *tx_info;
if (!skb)
return;
- if (ep_id == priv->mgmt_ep)
+ if (ep_id == priv->mgmt_ep) {
skb_pull(skb, sizeof(struct tx_mgmt_hdr));
- else
- /* TODO: Check for cab/uapsd/data */
+ } else if ((ep_id == priv->data_bk_ep) ||
+ (ep_id == priv->data_be_ep) ||
+ (ep_id == priv->data_vi_ep) ||
+ (ep_id == priv->data_vo_ep)) {
skb_pull(skb, sizeof(struct tx_frame_hdr));
+ } else {
+ ath_print(common, ATH_DBG_FATAL,
+ "Unsupported TX EPID: %d\n", ep_id);
+ dev_kfree_skb_any(skb);
+ return;
+ }
tx_info = IEEE80211_SKB_CB(skb);
--
1.7.0.5
^ permalink raw reply related
* Re: [RFC/RFT] ssb: Avoid system hang when SPROM read fails
From: Larry Finger @ 2010-04-26 18:04 UTC (permalink / raw)
To: John W. Linville; +Cc: Michael Buesch, b43-dev, linux-wireless
In-Reply-To: <20100426171505.GC2387@tuxdriver.com>
On 04/26/2010 12:15 PM, John W. Linville wrote:
>
> Well, the "good" news is that I hit the "Unable to read SPROM" case.
> The bad news is that the box still hangs after the -ENODEV. I have
> not yet tracked-down the exact location of the current hang.
>
> John
>
> P.S. Sorry about the 'radio silence' -- I've been distracted with
> some other things. Also, the box in question originally belonged
> to someone else who had configured it in a way that was less than
> friendly to kernel development. I finally reinstalled it...
That box is certainly resistant!
I certainly understand your distractions. That has to be a major
understatement.
As the patch makes some improvement in both your system and the one in
Bug #15825, I'll push it as a real patch.
Would your box be available to me as a loaner? I have considered buying
a netbook for debugging purposes, but I cannot quite justify the cost.
In addition, Murphy's law would make whatever one I bought work without
any problems.
Larry
^ permalink raw reply
* Re: [PATCH V4] ssb: Implement virtual SPROM
From: Larry Finger @ 2010-04-26 18:14 UTC (permalink / raw)
To: John W. Linville; +Cc: Michael Buesch, bcm43xx-dev, linux-wireless
In-Reply-To: <20100426175850.GD2387@tuxdriver.com>
On 04/26/2010 12:58 PM, John W. Linville wrote:
> On Fri, Mar 26, 2010 at 12:39:08AM -0500, Larry Finger wrote:
>> Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
>> from the SPROM could be included in the kernel; however, this presents
>> a problem in the generation of a unique, reproducible MAC address. The
>> solution is to initialize the address to a known, workable value. Thus,
>> the device will work without any further code. For an address that is
>> preserved across reloads or reboots, a set of udev routines has been
>> prepared that detect the special address and assign a random value that
>> is preserved in a second udev rule file. The random address should be
>> unique except for the case where a given box has more than one of these
>> cards. This case is handles by adding the DEVPATH to the recognition rules.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>
> Do we still want this patch? Or do we think all the cases of a
> "missing" SPROM were actually a "relocated" SPROM?
I would say to drop it for now. We may never even have found a relocated
SPROM, just some bug that keeps it from being read. I'll keep the patch
for the time when we actually find a device in the wild without an
SPROM. To help us find such a device, you should reinstate commit
fcb54b0bf7d3fe730c2. It didn't fix the problems that we have currently,
but the Broadcom driver does indicate that these tests are needed.
Perhaps the message at
+ if (!ssb_is_sprom_available(bus)) {
+ ssb_printk(KERN_ERR PFX "No SPROM available!\n");
+ return -ENODEV;
+ }
should be enhanced to tell the user to contact us on the ML so that we
know that it is time for the virtual SPROM patch.
Larry
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: John W. Linville @ 2010-04-26 18:26 UTC (permalink / raw)
To: Larry Finger; +Cc: Rafał Miłecki, linux-wireless
In-Reply-To: <4BC88EC4.5000606@lwfinger.net>
On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
> > W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
> > <linville@tuxdriver.com> napisał:
> >> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
> >>> John, I posted some time ago following patches:
> >>>
> >>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
> >>> [PATCH 1/2] ssb: Use relative offsets for SPROM
> >>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
> >>>
> >>> while Michael has some doubts about "ssb: Look for SPROM at different
> >>> offset on higher rev CC" I explained to him that what he does not like
> >>> was fixed in next 2 posted patches.
> >>>
> >>> AFAIR you got some device with this recently-discovered location of
> >>> SPROM. Could you test my set if it makes your card working? If so,
> >>> could you take that patches to your tree?
> >>
> >> Sorry, been busy w/ other things. FWIW, my implementation based on
> >> the RE work from Larry did not work on the box in question, and my
> >> implementation wasn't substantially different from yours. Anyway,
> >> I'll try to confirm this soon w/ your patches and to collect more
> >> information for Larry.
> >
> > Ah, I didn't know you got own implementation. Had to miss it.
> >
> > Larry do you have any ideas what else may we do incorrectly?
>
> No. AFAICT, we have implemented it correctly. Any additional info would
> be welcome.
FWIW, this patch series also still results in a hang on my problematic
netbook. I'm going to merge them anyway, in hopes that they make
things better for someone (or at least get us closer to it). I'll try
to pinpoint this hang as well.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: Rafał Miłecki @ 2010-04-26 18:33 UTC (permalink / raw)
To: John W. Linville; +Cc: Larry Finger, linux-wireless
In-Reply-To: <20100426182655.GE2387@tuxdriver.com>
2010/4/26 John W. Linville <linville@tuxdriver.com>:
> On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
>> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
>> > W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
>> > <linville@tuxdriver.com> napisał:
>> >> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>> >>> John, I posted some time ago following patches:
>> >>>
>> >>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>> >>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>> >>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>> >>>
>> >>> while Michael has some doubts about "ssb: Look for SPROM at different
>> >>> offset on higher rev CC" I explained to him that what he does not like
>> >>> was fixed in next 2 posted patches.
>> >>>
>> >>> AFAIR you got some device with this recently-discovered location of
>> >>> SPROM. Could you test my set if it makes your card working? If so,
>> >>> could you take that patches to your tree?
>> >>
>> >> Sorry, been busy w/ other things. FWIW, my implementation based on
>> >> the RE work from Larry did not work on the box in question, and my
>> >> implementation wasn't substantially different from yours. Anyway,
>> >> I'll try to confirm this soon w/ your patches and to collect more
>> >> information for Larry.
>> >
>> > Ah, I didn't know you got own implementation. Had to miss it.
>> >
>> > Larry do you have any ideas what else may we do incorrectly?
>>
>> No. AFAICT, we have implemented it correctly. Any additional info would
>> be welcome.
>
> FWIW, this patch series also still results in a hang on my problematic
> netbook. I'm going to merge them anyway, in hopes that they make
> things better for someone (or at least get us closer to it). I'll try
> to pinpoint this hang as well.
Did it actually pick another (newly discovered) offset for SPROM
location in your case? Could you add some single printk to check this?
--
Rafał
^ permalink raw reply
* Re: [RFC/RFT] ssb: Avoid system hang when SPROM read fails
From: John W. Linville @ 2010-04-26 18:32 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, b43-dev, linux-wireless
In-Reply-To: <4BD5D5B1.6020906@lwfinger.net>
On Mon, Apr 26, 2010 at 01:04:33PM -0500, Larry Finger wrote:
> On 04/26/2010 12:15 PM, John W. Linville wrote:
> >
> > Well, the "good" news is that I hit the "Unable to read SPROM" case.
> > The bad news is that the box still hangs after the -ENODEV. I have
> > not yet tracked-down the exact location of the current hang.
> >
> > John
> >
> > P.S. Sorry about the 'radio silence' -- I've been distracted with
> > some other things. Also, the box in question originally belonged
> > to someone else who had configured it in a way that was less than
> > friendly to kernel development. I finally reinstalled it...
>
> That box is certainly resistant!
>
> I certainly understand your distractions. That has to be a major
> understatement.
>
> As the patch makes some improvement in both your system and the one in
> Bug #15825, I'll push it as a real patch.
>
> Would your box be available to me as a loaner? I have considered buying
> a netbook for debugging purposes, but I cannot quite justify the cost.
> In addition, Murphy's law would make whatever one I bought work without
> any problems.
I think that can be arranged...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: Larry Finger @ 2010-04-26 19:04 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: John W. Linville, linux-wireless
In-Reply-To: <y2nb170af451004261133qe1e0dfaand43c190b6f7f8d3@mail.gmail.com>
On 04/26/2010 01:33 PM, Rafał Miłecki wrote:
> 2010/4/26 John W. Linville <linville@tuxdriver.com>:
>> On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
>>> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
>>>> W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
>>>> <linville@tuxdriver.com> napisał:
>>>>> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>>>>>> John, I posted some time ago following patches:
>>>>>>
>>>>>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>>>>>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>>>>>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>>>>>
>>>>>> while Michael has some doubts about "ssb: Look for SPROM at different
>>>>>> offset on higher rev CC" I explained to him that what he does not like
>>>>>> was fixed in next 2 posted patches.
>>>>>>
>>>>>> AFAIR you got some device with this recently-discovered location of
>>>>>> SPROM. Could you test my set if it makes your card working? If so,
>>>>>> could you take that patches to your tree?
>>>>>
>>>>> Sorry, been busy w/ other things. FWIW, my implementation based on
>>>>> the RE work from Larry did not work on the box in question, and my
>>>>> implementation wasn't substantially different from yours. Anyway,
>>>>> I'll try to confirm this soon w/ your patches and to collect more
>>>>> information for Larry.
>>>>
>>>> Ah, I didn't know you got own implementation. Had to miss it.
>>>>
>>>> Larry do you have any ideas what else may we do incorrectly?
>>>
>>> No. AFAICT, we have implemented it correctly. Any additional info would
>>> be welcome.
>>
>> FWIW, this patch series also still results in a hang on my problematic
>> netbook. I'm going to merge them anyway, in hopes that they make
>> things better for someone (or at least get us closer to it). I'll try
>> to pinpoint this hang as well.
>
> Did it actually pick another (newly discovered) offset for SPROM
> location in your case? Could you add some single printk to check this?
My suggestion is that for now we only implement John's patch for no
SPROM. I am hoping that we try to fix the failures for boxes with the
SPROM in a normal location. Once we do that, there will be a simpler fix
for testing at the alternate location. The patch will all be contained
in sprom_do_read().
Larry
^ permalink raw reply
* [PATCH 05/13] ath9k_hw: Fix usec to hw clock conversion in 5Ghz for ar9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Vasanthakumar Thiagarajan
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Fast clock operation (44Mhz) is enabled for 5Ghz in ar9003, so
take care of the conversion from usec to hw clock.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 10 ++++++++--
drivers/net/wireless/ath/ath9k/hw.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 9af83e5..ca676cd 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -26,6 +26,7 @@
#define ATH9K_CLOCK_RATE_CCK 22
#define ATH9K_CLOCK_RATE_5GHZ_OFDM 40
#define ATH9K_CLOCK_RATE_2GHZ_OFDM 44
+#define ATH9K_CLOCK_FAST_RATE_5GHZ_OFDM 44
static bool ath9k_hw_set_reset_reg(struct ath_hw *ah, u32 type);
@@ -91,7 +92,11 @@ static u32 ath9k_hw_mac_clks(struct ath_hw *ah, u32 usecs)
return usecs *ATH9K_CLOCK_RATE_CCK;
if (conf->channel->band == IEEE80211_BAND_2GHZ)
return usecs *ATH9K_CLOCK_RATE_2GHZ_OFDM;
- return usecs *ATH9K_CLOCK_RATE_5GHZ_OFDM;
+
+ if (ah->caps.hw_caps & ATH9K_HW_CAP_FASTCLOCK)
+ return usecs * ATH9K_CLOCK_FAST_RATE_5GHZ_OFDM;
+ else
+ return usecs * ATH9K_CLOCK_RATE_5GHZ_OFDM;
}
static u32 ath9k_hw_mac_to_clks(struct ath_hw *ah, u32 usecs)
@@ -2192,7 +2197,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
}
if (AR_SREV_9300_20_OR_LATER(ah)) {
- pCap->hw_caps |= ATH9K_HW_CAP_EDMA | ATH9K_HW_CAP_LDPC;
+ pCap->hw_caps |= ATH9K_HW_CAP_EDMA | ATH9K_HW_CAP_LDPC |
+ ATH9K_HW_CAP_FASTCLOCK;
pCap->rx_hp_qdepth = ATH9K_HW_RX_HP_QDEPTH;
pCap->rx_lp_qdepth = ATH9K_HW_RX_LP_QDEPTH;
pCap->rx_status_len = sizeof(struct ar9003_rxs);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 6c84d31..7a1347b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -198,6 +198,7 @@ enum ath9k_hw_caps {
ATH9K_HW_CAP_EDMA = BIT(17),
ATH9K_HW_CAP_RAC_SUPPORTED = BIT(18),
ATH9K_HW_CAP_LDPC = BIT(19),
+ ATH9K_HW_CAP_FASTCLOCK = BIT(20),
};
enum ath9k_capability_type {
--
1.6.3.3
^ permalink raw reply related
* [PATCH 02/13] ath9k_hw: fix pll clock setting for 5ghz on AR9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 11 +----------
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 137543b..bf8ec68 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -375,16 +375,7 @@ static u32 ar9003_hw_compute_pll_control(struct ath_hw *ah,
else if (chan && IS_CHAN_QUARTER_RATE(chan))
pll |= SM(0x2, AR_RTC_9300_PLL_CLKSEL);
- if (chan && IS_CHAN_5GHZ(chan)) {
- pll |= SM(0x28, AR_RTC_9300_PLL_DIV);
-
- /*
- * When doing fast clock, set PLL to 0x142c
- */
- if (IS_CHAN_A_5MHZ_SPACED(chan))
- pll = 0x142c;
- } else
- pll |= SM(0x2c, AR_RTC_9300_PLL_DIV);
+ pll |= SM(0x2c, AR_RTC_9300_PLL_DIV);
return pll;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 09/13] ath9k_hw: use the configured power limit for AR9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Since the new AR9003 EEPROM code does tune the card for the configured
tx power level, we need to fill in the correct power limits in the TPC
part of the DMA descriptor.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 1 +
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 3 +++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 5d92be4..79b0e28 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -1817,6 +1817,7 @@ static void ath9k_hw_ar9300_set_txpower(struct ath_hw *ah,
u8 twiceMaxRegulatoryPower,
u8 powerLimit)
{
+ ah->txpower_limit = powerLimit;
ar9003_hw_set_target_power_eeprom(ah, chan->channel);
ar9003_hw_calibration_apply(ah, chan->channel);
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 7d111fb..37ba374 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -311,6 +311,9 @@ static void ar9003_hw_set11n_txdesc(struct ath_hw *ah, void *ds,
{
struct ar9003_txc *ads = (struct ar9003_txc *) ds;
+ if (txpower > ah->txpower_limit)
+ txpower = ah->txpower_limit;
+
txpower += ah->txpower_indexoffset;
if (txpower > 63)
txpower = 63;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index bc682da..77245df 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -719,6 +719,7 @@ struct ath_hw {
u32 *addac5416_21;
u32 *bank6Temp;
+ u8 txpower_limit;
int16_t txpower_indexoffset;
int coverage_class;
u32 beacon_interval;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 08/13] ath9k: wake queue after processing edma rx frames
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index b0d345a..3db1917 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2290,6 +2290,8 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
ath_tx_complete_buf(sc, bf, txq, &bf_head,
&txs, txok, 0);
+ ath_wake_mac80211_queue(sc, txq);
+
spin_lock_bh(&txq->axq_lock);
if (!list_empty(&txq->txq_fifo_pending)) {
INIT_LIST_HEAD(&bf_head);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 00/13] ath9k/ath9k_hw: AR9003 fixes for April
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
John, this series contains a few fixes we've made to AR9003 over
the last few weeks. We've tested them considerably. Also included
is a change for AR9280 2.0 to enable fast PLL clock.
Happy Monday.
Felix Fietkau (10):
ath9k_hw: update initvals for AR9003
ath9k_hw: fix pll clock setting for 5ghz on AR9003
ath9k_hw: fix typo in the AR9003 EEPROM data structure definition
ath9k_hw: update EEPROM data structure for AR9280
ath9k_hw: fix fast clock handling for 5GHz channels
ath9k: wake queue after processing edma rx frames
ath9k_hw: use the configured power limit for AR9003
ath9k_hw: Fix typos in tx rate power level parsing for AR9003
ath9k_hw: Fix endian bug in an AR9003 EEPROM field
ath9k_hw: fix noisefloor timeout handling on AR9003
Luis R. Rodriguez (2):
ath9k_hw: disable TX IQ calibration for AR9003
ath9k_hw: Fix TX interrupt mitigation settings
Vasanthakumar Thiagarajan (1):
ath9k_hw: Fix usec to hw clock conversion in 5Ghz for ar9003
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 5 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 16 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 3 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 265 +++++++++++-----------
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 3 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 16 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 3 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 24 ++-
drivers/net/wireless/ath/ath9k/hw.h | 8 +-
drivers/net/wireless/ath/ath9k/mac.c | 10 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +
14 files changed, 189 insertions(+), 178 deletions(-)
^ permalink raw reply
* [PATCH 06/13] ath9k_hw: update EEPROM data structure for AR9280
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Adds read access for the 5 GHz fast clock flag
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/eeprom.h | 3 ++-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index fb9c8c9..21354c1 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -300,7 +300,8 @@ struct base_eep_header {
u32 binBuildNumber;
u8 deviceType;
u8 pwdclkind;
- u8 futureBase_1[2];
+ u8 fastClk5g;
+ u8 divChain;
u8 rxGainType;
u8 dacHiPwrMode_5G;
u8 openLoopPwrCntl;
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index cf59799..e591ad6 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -274,6 +274,8 @@ static u32 ath9k_hw_def_get_eeprom(struct ath_hw *ah,
return pBase->txMask;
case EEP_RX_MASK:
return pBase->rxMask;
+ case EEP_FSTCLK_5G:
+ return pBase->fastClk5g;
case EEP_RXGAIN_TYPE:
return pBase->rxGainType;
case EEP_TXGAIN_TYPE:
--
1.6.3.3
^ permalink raw reply related
* [PATCH 04/13] ath9k_hw: disable TX IQ calibration for AR9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Paul Shaw, Thomas Hammel
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
Disable TX IQ calibration, it was prematurely enabled in
previous versions.
Cc: Paul Shaw <Paul.Shaw@Atheros.com>
Cc: Thomas Hammel <Thomas.Hammel@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 3 ++-
drivers/net/wireless/ath/ath9k/hw.c | 6 ++++++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 5e20b48..5fcafb4 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -755,7 +755,8 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
}
/* Do Tx IQ Calibration */
- ar9003_hw_tx_iq_cal(ah);
+ if (ah->config.tx_iq_calibration)
+ ar9003_hw_tx_iq_cal(ah);
/* Revert chainmasks to their original values before NF cal */
ar9003_hw_set_chain_masks(ah, ah->rxchainmask, ah->txchainmask);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 5a29048..9af83e5 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -387,6 +387,12 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.rx_intr_mitigation = true;
/*
+ * Tx IQ Calibration (ah->config.tx_iq_calibration) is only
+ * used by AR9003, but it is showing reliability issues.
+ * It will take a while to fix so this is currently disabled.
+ */
+
+ /*
* We need this for PCI devices only (Cardbus, PCI, miniPCI)
* _and_ if on non-uniprocessor systems (Multiprocessor/HT).
* This means we use it for all AR5416 devices, and the few
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index a78e09b..6c84d31 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -261,6 +261,7 @@ struct ath9k_ops_config {
#define AR_BASE_FREQ_5GHZ 4900
#define AR_SPUR_FEEQ_BOUND_HT40 19
#define AR_SPUR_FEEQ_BOUND_HT20 10
+ bool tx_iq_calibration; /* Only available for >= AR9003 */
int spurmode;
u16 spurchans[AR_EEPROM_MODAL_SPURS][2];
u8 max_txtrig_level;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 03/13] ath9k_hw: fix typo in the AR9003 EEPROM data structure definition
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
index 5fe335e..d8c0318 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -265,7 +265,7 @@ struct cal_ctl_edge_pwr {
} __packed;
struct cal_ctl_data_2g {
- struct cal_ctl_edge_pwr ctlEdges[AR9300_NUM_BAND_EDGES_5G];
+ struct cal_ctl_edge_pwr ctlEdges[AR9300_NUM_BAND_EDGES_2G];
} __packed;
struct cal_ctl_data_5g {
--
1.6.3.3
^ permalink raw reply related
* [PATCH 07/13] ath9k_hw: fix fast clock handling for 5GHz channels
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Combine multiple checks that were supposed to check for the same
conditions, but didn't. Always enable fast PLL clock on AR9280 2.0
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 5 ++---
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 16 ++++++----------
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 ++--
drivers/net/wireless/ath/ath9k/hw.c | 8 ++++++--
drivers/net/wireless/ath/ath9k/hw.h | 5 ++---
5 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 3395ac4..c594814 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -852,7 +852,7 @@ static int ar5008_hw_process_ini(struct ath_hw *ah,
REG_WRITE_ARRAY(&ah->iniBB_RfGain, freqIndex, regWrites);
- if (AR_SREV_9280_20(ah) && IS_CHAN_A_5MHZ_SPACED(chan)) {
+ if (IS_CHAN_A_FAST_CLOCK(ah, chan)) {
REG_WRITE_ARRAY(&ah->iniModesAdditional, modesIndex,
regWrites);
}
@@ -894,8 +894,7 @@ static void ar5008_hw_set_rfmode(struct ath_hw *ah, struct ath9k_channel *chan)
rfMode |= (IS_CHAN_5GHZ(chan)) ?
AR_PHY_MODE_RF5GHZ : AR_PHY_MODE_RF2GHZ;
- if ((AR_SREV_9280_20(ah) || AR_SREV_9300_20_OR_LATER(ah))
- && IS_CHAN_A_5MHZ_SPACED(chan))
+ if (IS_CHAN_A_FAST_CLOCK(ah, chan))
rfMode |= (AR_PHY_MODE_DYNAMIC | AR_PHY_MODE_DYN_CCK_DISABLE);
REG_WRITE(ah, AR_PHY_MODE, rfMode);
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index 18cfe1a..ed314e8 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -455,16 +455,12 @@ static u32 ar9002_hw_compute_pll_control(struct ath_hw *ah,
pll |= SM(0x2, AR_RTC_9160_PLL_CLKSEL);
if (chan && IS_CHAN_5GHZ(chan)) {
- pll |= SM(0x28, AR_RTC_9160_PLL_DIV);
-
-
- if (AR_SREV_9280_20(ah)) {
- if (((chan->channel % 20) == 0)
- || ((chan->channel % 10) == 0))
- pll = 0x2850;
- else
- pll = 0x142c;
- }
+ if (IS_CHAN_A_FAST_CLOCK(ah, chan))
+ pll = 0x142c;
+ else if (AR_SREV_9280_20(ah))
+ pll = 0x2850;
+ else
+ pll |= SM(0x28, AR_RTC_9160_PLL_DIV);
} else {
pll |= SM(0x2c, AR_RTC_9160_PLL_DIV);
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index bf8ec68..806f4a5 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -583,7 +583,7 @@ static int ar9003_hw_process_ini(struct ath_hw *ah,
* For 5GHz channels requiring Fast Clock, apply
* different modal values.
*/
- if (IS_CHAN_A_5MHZ_SPACED(chan))
+ if (IS_CHAN_A_FAST_CLOCK(ah, chan))
REG_WRITE_ARRAY(&ah->iniModesAdditional,
modesIndex, regWrites);
@@ -613,7 +613,7 @@ static void ar9003_hw_set_rfmode(struct ath_hw *ah,
rfMode |= (IS_CHAN_B(chan) || IS_CHAN_G(chan))
? AR_PHY_MODE_DYNAMIC : AR_PHY_MODE_OFDM;
- if (IS_CHAN_A_5MHZ_SPACED(chan))
+ if (IS_CHAN_A_FAST_CLOCK(ah, chan))
rfMode |= (AR_PHY_MODE_DYNAMIC | AR_PHY_MODE_DYN_CCK_DISABLE);
REG_WRITE(ah, AR_PHY_MODE, rfMode);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index ca676cd..2db3ecd 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1232,8 +1232,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
(chan->channel != ah->curchan->channel) &&
((chan->channelFlags & CHANNEL_ALL) ==
(ah->curchan->channelFlags & CHANNEL_ALL)) &&
- !(AR_SREV_9280(ah) || IS_CHAN_A_5MHZ_SPACED(chan) ||
- IS_CHAN_A_5MHZ_SPACED(ah->curchan))) {
+ !AR_SREV_9280(ah)) {
if (ath9k_hw_channel_change(ah, chan)) {
ath9k_hw_loadnf(ah, ah->curchan);
@@ -2206,6 +2205,11 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
pCap->txs_len = sizeof(struct ar9003_txs);
} else {
pCap->tx_desc_len = sizeof(struct ath_desc);
+ if (AR_SREV_9280_20(ah) &&
+ ((ah->eep_ops->get_eeprom(ah, EEP_MINOR_REV) <=
+ AR5416_EEP_MINOR_VER_16) ||
+ ah->eep_ops->get_eeprom(ah, EEP_FSTCLK_5G)))
+ pCap->hw_caps |= ATH9K_HW_CAP_FASTCLOCK;
}
if (AR_SREV_9300_20_OR_LATER(ah))
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 7a1347b..bc682da 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -369,10 +369,9 @@ struct ath9k_channel {
#define IS_CHAN_2GHZ(_c) (((_c)->channelFlags & CHANNEL_2GHZ) != 0)
#define IS_CHAN_HALF_RATE(_c) (((_c)->channelFlags & CHANNEL_HALF) != 0)
#define IS_CHAN_QUARTER_RATE(_c) (((_c)->channelFlags & CHANNEL_QUARTER) != 0)
-#define IS_CHAN_A_5MHZ_SPACED(_c) \
+#define IS_CHAN_A_FAST_CLOCK(_ah, _c) \
((((_c)->channelFlags & CHANNEL_5GHZ) != 0) && \
- (((_c)->channel % 20) != 0) && \
- (((_c)->channel % 10) != 0))
+ ((_ah)->caps.hw_caps & ATH9K_HW_CAP_FASTCLOCK))
/* These macros check chanmode and not channelFlags */
#define IS_CHAN_B(_c) ((_c)->chanmode == CHANNEL_B)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 10/13] ath9k_hw: Fix typos in tx rate power level parsing for AR9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 79b0e28..25dd44d 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -1200,7 +1200,7 @@ static u8 ar9003_hw_eeprom_get_tgt_pwr(struct ath_hw *ah,
u8 *pFreqBin;
if (is2GHz) {
- numPiers = AR9300_NUM_5G_20_TARGET_POWERS;
+ numPiers = AR9300_NUM_2G_20_TARGET_POWERS;
pEepromTargetPwr = eep->calTargetPower2G;
pFreqBin = eep->calTarget_freqbin_2G;
} else {
@@ -1236,7 +1236,7 @@ static u8 ar9003_hw_eeprom_get_ht20_tgt_pwr(struct ath_hw *ah,
u8 *pFreqBin;
if (is2GHz) {
- numPiers = AR9300_NUM_5G_20_TARGET_POWERS;
+ numPiers = AR9300_NUM_2G_20_TARGET_POWERS;
pEepromTargetPwr = eep->calTargetPower2GHT20;
pFreqBin = eep->calTarget_freqbin_2GHT20;
} else {
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox