On Tuesday 24 March 2009 21:10:21 Luis R. Rodriguez wrote:
> On Tue, Mar 24, 2009 at 1:03 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Mar 24, 2009 at 2:41 PM, Luis R. Rodriguez
> > <lrodriguez@xxxxxxxxxxx> wrote:
> >> Do any of you guys have time to pick it up?
> >
> > Well my patch #2 is pretty similar to what Christian has, and I'd like to
> > upstream the first few patches soon (especially the ath.ko creation, it is a
> > beast to rebase as you saw). That would bring up the first contentious
> > point of the merge: is "ath/ath.ko" ok with everyone?
>
> Yes.
Yes.
> > ath5k/9k specific
> > bits can eventually go in ath/{5k,9k} subdirs... not sure where 9170
> > lives then :)
>
> Wherever Christian wants it. If he finds re-usable bits then great.
maybe ath/9kusb ?
> > I probably can't get to it until the weekend, but if you have more time,
> > Christian, feel free to adopt whatever you want from mine. Otherwise I'll
> > pick up where Luis left off on the weekend.
Done! Patch attached, please add to the tree ;)
> > I didn't push it yet because ath5k was having problems once I turned it
> > on for ath5k,
>
> So this is why I recommend to trim the channel list down of ath5k. The
> other reason is you won't have users spending what may be 3/4 of their
> time scanning on channels that they won't ever find APs in. What can
> be done here is add flag or command as we had reviewed a while back
> to allow the user to enable these channels if he knows what he is
> doing so that way we know we don't mind bothering scanning on the
> gazillion channels. But that is just my advice. My concern first is to
> get users working happily and quickly associated to an AP and I think
> that parallels those goals and puts as secondary the bells and
> whistles of adding every single possible channel.
>
> > and I have no other hardware to test with so wanted to
> > figure out what was broken first.
> > Channel list is a good hint, maybe
> > it's time to fix iw/nl80211 to send back all the channels :)
>
> So that is the other option. I tried looking at that yesterday but
> wasn't able to find a way to do this. I went through the netlink
> documenation and even tried modifying the skb on the kernel side as
> its a dump. Not sure what to do here to fix this.
>
> So yes, both are possible options. Just keep in mind that without
> being able to see the channel list with 'iw list' debugging regulatory
> is a real royal pain in the ass. So I'd try to fix that first either
> through channel reduction (you get another bonus enhancement for
> scanning time for users) or through fixing this through iw/nl80211.
>
> Johannes probably can advise best on the second path.
>
> Luis
---
From: Christian Lamparter <chunkeey@xxxxxx>
Date: Tue, 24 Mar 2009 21:24:14 +0100
Subject: [PATCH] ar9170: use regulatory infrastructure
To: linux-wireless@xxxxxxxxxxxxxxx
Make ar9170 select the ath module and add in the hooks to make the
eeprom regulatory hint and reg notifier take effect.
Signed-off-by: Christian Lamparter <chunkeey@xxxxxx>
---
diff --git a/drivers/net/wireless/ar9170/Kconfig b/drivers/net/wireless/ar9170/Kconfig
index de4281f..b99e326 100644
--- a/drivers/net/wireless/ar9170/Kconfig
+++ b/drivers/net/wireless/ar9170/Kconfig
@@ -2,6 +2,7 @@ config AR9170_USB
tristate "Atheros AR9170 802.11n USB support"
depends on USB && MAC80211 && WLAN_80211 && EXPERIMENTAL
select FW_LOADER
+ select ATH_COMMON
help
This is a driver for the Atheros "otus" 802.11n USB devices.
diff --git a/drivers/net/wireless/ar9170/ar9170.h b/drivers/net/wireless/ar9170/ar9170.h
index f4fb2e9..87c1985 100644
--- a/drivers/net/wireless/ar9170/ar9170.h
+++ b/drivers/net/wireless/ar9170/ar9170.h
@@ -48,6 +48,8 @@
#include "eeprom.h"
#include "hw.h"
+#include "../ath/regd.h"
+
#define PAYLOAD_MAX (AR9170_MAX_CMD_LEN/4 - 1)
enum ar9170_bw {
@@ -151,6 +153,7 @@ struct ar9170 {
/* EEPROM */
struct ar9170_eeprom eeprom;
+ struct ath_regulatory regulatory;
/* global tx status for unregistered Stations. */
struct sk_buff_head global_tx_status;
diff --git a/drivers/net/wireless/ar9170/main.c b/drivers/net/wireless/ar9170/main.c
index 5996ff9..4a251fc 100644
--- a/drivers/net/wireless/ar9170/main.c
+++ b/drivers/net/wireless/ar9170/main.c
@@ -1619,12 +1619,24 @@ static int ar9170_read_eeprom(struct ar9170 *ar)
else
ar->hw->channel_change_time = 80 * 1000;
+ ar->regulatory.current_rd = le16_to_cpu(ar->eeprom.reg_domain[0]);
+ ar->regulatory.current_rd_ext = le16_to_cpu(ar->eeprom.reg_domain[1]);
+
/* second part of wiphy init */
SET_IEEE80211_PERM_ADDR(ar->hw, addr);
return bands ? 0 : -EINVAL;
}
+int ar9170_reg_notifier(struct wiphy *wiphy,
+ struct regulatory_request *request)
+{
+ struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
+ struct ar9170 *ar = hw->priv;
+
+ return ath_reg_notifier_apply(wiphy, request, &ar->regulatory);
+}
+
int ar9170_register(struct ar9170 *ar, struct device *pdev)
{
int err;
@@ -1634,10 +1646,16 @@ int ar9170_register(struct ar9170 *ar, struct device *pdev)
if (err)
goto err_out;
+ err = ath_regd_init(&ar->regulatory, ar->hw->wiphy,
+ ar9170_reg_notifier);
+
err = ieee80211_register_hw(ar->hw);
if (err)
goto err_out;
+ if (!ath_is_world_regd(&ar->regulatory))
+ regulatory_hint(ar->hw->wiphy, ar->regulatory.alpha2);
+
err = ar9170_init_leds(ar);
if (err)
goto err_unreg;
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
