linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [rfc] Implement ath9k mesh point operation
@ 2009-03-16 22:36 Pat Erley
  2009-03-16 22:57 ` Andrey Yurovsky
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Pat Erley @ 2009-03-16 22:36 UTC (permalink / raw)
  To: linux-wireless
  Cc: ath9k-devel, andrey@cozybit.com >> Andrey Yurovsky, brian,
	javier, colin

This patch enables mesh point operation for ath9k.  Tested with b43
and ath5k as peers. 

Signed-off-by: Pat Erley <pat-lkml@erley.org>
---
Currently, you need to trigger a scan on the mesh point interface to
enable beaconing.  This is the same behavior the ath5k, rt2500usb and 
rt61pci drivers exhibit.  Is this a mac80211 design flaw, or something
in all of these drivers?

diff --git a/drivers/net/wireless/ath9k/beacon.c b/drivers/net/wireless/ath9k/beacon.c
index 039c781..68e05ed 100644
--- a/drivers/net/wireless/ath9k/beacon.c
+++ b/drivers/net/wireless/ath9k/beacon.c
@@ -70,7 +70,8 @@ static void ath_beacon_setup(struct ath_softc *sc, struct ath_vif *avp,
 	ds = bf->bf_desc;
 	flags = ATH9K_TXDESC_NOACK;
 
-	if (sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC &&
+	if (((sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC) ||
+	     (sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT)) &&
 	    (ah->caps.hw_caps & ATH9K_HW_CAP_VEOL)) {
 		ds->ds_link = bf->bf_daddr; /* self-linked */
 		flags |= ATH9K_TXDESC_VEOL;
@@ -728,6 +729,7 @@ void ath_beacon_config(struct ath_softc *sc, struct ieee80211_vif *vif)
 			ath_beacon_config_ap(sc, &conf, avp);
 			break;
 		case NL80211_IFTYPE_ADHOC:
+		case NL80211_IFTYPE_MESH_POINT:
 			ath_beacon_config_adhoc(sc, &conf, avp, vif);
 			break;
 		case NL80211_IFTYPE_STATION:
diff --git a/drivers/net/wireless/ath9k/hw.c b/drivers/net/wireless/ath9k/hw.c
index ea550cc..a69328e 100644
--- a/drivers/net/wireless/ath9k/hw.c
+++ b/drivers/net/wireless/ath9k/hw.c
@@ -1424,6 +1424,7 @@ static void ath9k_hw_set_operating_mode(struct ath_hw *ah, int opmode)
 		REG_CLR_BIT(ah, AR_CFG, AR_CFG_AP_ADHOC_INDICATION);
 		break;
 	case NL80211_IFTYPE_ADHOC:
+	case NL80211_IFTYPE_MESH_POINT:
 		REG_WRITE(ah, AR_STA_ID1, val | AR_STA_ID1_ADHOC
 			  | AR_STA_ID1_KSRCH_MODE);
 		REG_SET_BIT(ah, AR_CFG, AR_CFG_AP_ADHOC_INDICATION);
@@ -3129,6 +3130,7 @@ void ath9k_hw_beaconinit(struct ath_hw *ah, u32 next_beacon, u32 beacon_period)
 		flags |= AR_TBTT_TIMER_EN;
 		break;
 	case NL80211_IFTYPE_ADHOC:
+	case NL80211_IFTYPE_MESH_POINT:
 		REG_SET_BIT(ah, AR_TXCFG,
 			    AR_TXCFG_ADHOC_BEACON_ATIM_TX_POLICY);
 		REG_WRITE(ah, AR_NEXT_NDP_TIMER,
diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k/main.c
index a2f5af6..0f9f6ca 100644
--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -1591,7 +1591,8 @@ void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
 	hw->wiphy->interface_modes =
 		BIT(NL80211_IFTYPE_AP) |
 		BIT(NL80211_IFTYPE_STATION) |
-		BIT(NL80211_IFTYPE_ADHOC);
+		BIT(NL80211_IFTYPE_ADHOC) |
+		BIT(NL80211_IFTYPE_MESH_POINT);
 
 	hw->wiphy->reg_notifier = ath9k_reg_notifier;
 	hw->wiphy->strict_regulatory = true;
@@ -2199,18 +2200,13 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
 		ic_opmode = NL80211_IFTYPE_STATION;
 		break;
 	case NL80211_IFTYPE_ADHOC:
-		if (sc->nbcnvifs >= ATH_BCBUF) {
-			ret = -ENOBUFS;
-			goto out;
-		}
-		ic_opmode = NL80211_IFTYPE_ADHOC;
-		break;
 	case NL80211_IFTYPE_AP:
+	case NL80211_IFTYPE_MESH_POINT:
 		if (sc->nbcnvifs >= ATH_BCBUF) {
 			ret = -ENOBUFS;
 			goto out;
 		}
-		ic_opmode = NL80211_IFTYPE_AP;
+		ic_opmode = conf->type;
 		break;
 	default:
 		DPRINTF(sc, ATH_DBG_FATAL,
@@ -2246,7 +2242,8 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
 	 * Note we only do this (at the moment) for station mode.
 	 */
 	if ((conf->type == NL80211_IFTYPE_STATION) ||
-	    (conf->type == NL80211_IFTYPE_ADHOC)) {
+	    (conf->type == NL80211_IFTYPE_ADHOC) ||
+	    (conf->type == NL80211_IFTYPE_MESH_POINT)) {
 		if (ath9k_hw_phycounters(sc->sc_ah))
 			sc->imask |= ATH9K_INT_MIB;
 		sc->imask |= ATH9K_INT_TSFOOR;
@@ -2293,8 +2290,9 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
 	del_timer_sync(&sc->ani.timer);
 
 	/* Reclaim beacon resources */
-	if (sc->sc_ah->opmode == NL80211_IFTYPE_AP ||
-	    sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC) {
+	if ((sc->sc_ah->opmode == NL80211_IFTYPE_AP) ||
+	    (sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC) ||
+	    (sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT)) {
 		ath9k_hw_stoptxdma(sc->sc_ah, sc->beacon.beaconq);
 		ath_beacon_return(sc, avp);
 	}
@@ -2427,6 +2425,7 @@ static int ath9k_config_interface(struct ieee80211_hw *hw,
 		switch (vif->type) {
 		case NL80211_IFTYPE_STATION:
 		case NL80211_IFTYPE_ADHOC:
+		case NL80211_IFTYPE_MESH_POINT:
 			/* Set BSSID */
 			memcpy(sc->curbssid, conf->bssid, ETH_ALEN);
 			memcpy(avp->bssid, conf->bssid, ETH_ALEN);
@@ -2450,7 +2449,8 @@ static int ath9k_config_interface(struct ieee80211_hw *hw,
 	}
 
 	if ((vif->type == NL80211_IFTYPE_ADHOC) ||
-	    (vif->type == NL80211_IFTYPE_AP)) {
+	    (vif->type == NL80211_IFTYPE_AP) ||
+	    (vif->type == NL80211_IFTYPE_MESH_POINT)) {
 		if ((conf->changed & IEEE80211_IFCC_BEACON) ||
 		    (conf->changed & IEEE80211_IFCC_BEACON_ENABLED &&
 		     conf->enable_beacon)) {
diff --git a/drivers/net/wireless/ath9k/rc.c b/drivers/net/wireless/ath9k/rc.c
index 8327356..31a6a2a 100644
--- a/drivers/net/wireless/ath9k/rc.c
+++ b/drivers/net/wireless/ath9k/rc.c
@@ -1615,6 +1615,7 @@ static void ath_rate_init(void *priv, struct ieee80211_supported_band *sband,
 	/* Choose rate table first */
 
 	if ((sc->sc_ah->opmode == NL80211_IFTYPE_STATION) ||
+	    (sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT) ||
 	    (sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC)) {
 		rate_table = ath_choose_rate_table(sc, sband->band,
 						   sta->ht_cap.ht_supported,

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [rfc] Implement ath9k mesh point operation
  2009-03-16 22:36 [rfc] Implement ath9k mesh point operation Pat Erley
@ 2009-03-16 22:57 ` Andrey Yurovsky
  2009-03-16 23:03   ` Pat Erley
  2009-03-17  4:45 ` Pat Erley
  2009-03-17  7:46 ` Johannes Berg
  2 siblings, 1 reply; 7+ messages in thread
From: Andrey Yurovsky @ 2009-03-16 22:57 UTC (permalink / raw)
  To: Pat Erley; +Cc: linux-wireless

Hi Pat,

On Mon, Mar 16, 2009 at 3:36 PM, Pat Erley <pat-lkml@erley.org> wrote:
> Currently, you need to trigger a scan on the mesh point interface to
> enable beaconing. =A0This is the same behavior the ath5k, rt2500usb a=
nd
> rt61pci drivers exhibit. =A0Is this a mac80211 design flaw, or someth=
ing
> in all of these drivers?

Are you really seeing this behavior on ath5k?  I have never seen that
happen, if it's new then it's a regression.  rt2x00 does have this
problem at this time.

  -Andrey
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc] Implement ath9k mesh point operation
  2009-03-16 22:57 ` Andrey Yurovsky
@ 2009-03-16 23:03   ` Pat Erley
  0 siblings, 0 replies; 7+ messages in thread
From: Pat Erley @ 2009-03-16 23:03 UTC (permalink / raw)
  To: Andrey Yurovsky; +Cc: linux-wireless

Andrey Yurovsky wrote:
> Hi Pat,
> 
> On Mon, Mar 16, 2009 at 3:36 PM, Pat Erley <pat-lkml@erley.org> wrote:
>> Currently, you need to trigger a scan on the mesh point interface to
>> enable beaconing.  This is the same behavior the ath5k, rt2500usb and
>> rt61pci drivers exhibit.  Is this a mac80211 design flaw, or something
>> in all of these drivers?
> 
> Are you really seeing this behavior on ath5k?  I have never seen that
> happen, if it's new then it's a regression.  rt2x00 does have this
> problem at this time.
> 
>   -Andrey

Yep, here's my lspci output and relevant dmesg messages when I load ath5k:

Atheros Communications Inc. AR5212/AR5213 Multiprotocol MAC/baseband processor (rev 01)

ath5k 0000:02:0a.0: PCI INT A -> Link[APC3] -> GSI 18 (level, low) -> IRQ 18
ath5k 0000:02:0a.0: registered as 'phy5'
phy5: Selected rate control algorithm 'minstrel'
ath5k phy5: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy5: RF5112B multiband radio found (0x36)
udev: renamed network interface wlan1 to wlan3

(yes, phy5, I have a ton of wireless stuff plugged into this dev system)

and here's the procedure I use:

iw dev wlan3 del
iw phy phy5 interface add mp0 type mp mesh_id FooBarMesh
ifconfig mp0 10.0.0.5 netmask 255.255.255.0 up
(tshark on rtl8187 shows no beaconing)
iw dev mp0 scan trigger
(tshark on rtl8187 now shows beaconing)

Out of all the devices I have, only b43 seems to beacon before a scan.  Is
there a chance I need to wait like 45 seconds for beaconing to start on ath5k
like how ibss mode tries to find a peer already broadcasting before it enables
beacons?

Pat Erley

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc] Implement ath9k mesh point operation
  2009-03-16 22:36 [rfc] Implement ath9k mesh point operation Pat Erley
  2009-03-16 22:57 ` Andrey Yurovsky
@ 2009-03-17  4:45 ` Pat Erley
  2009-03-17  7:44   ` Johannes Berg
  2009-03-17  7:46 ` Johannes Berg
  2 siblings, 1 reply; 7+ messages in thread
From: Pat Erley @ 2009-03-17  4:45 UTC (permalink / raw)
  To: linux-wireless

Also, I was able to do the development of this thanks to hardware 
donated by Johannes Berg (b43 card that was used as a baseline known
working device) and an ath9k card donated by Oxford TEC[1].  What's 
the best way to add this 'credit' to the commit, or is it not 
appropriate?

Pat Erley

[1] http://www.oxfordtec.com/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc] Implement ath9k mesh point operation
  2009-03-17  4:45 ` Pat Erley
@ 2009-03-17  7:44   ` Johannes Berg
  0 siblings, 0 replies; 7+ messages in thread
From: Johannes Berg @ 2009-03-17  7:44 UTC (permalink / raw)
  To: Pat Erley; +Cc: linux-wireless

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Tue, 2009-03-17 at 00:45 -0400, Pat Erley wrote:
> Also, I was able to do the development of this thanks to hardware 
> donated by Johannes Berg (b43 card that was used as a baseline known
> working device) and an ath9k card donated by Oxford TEC[1].  What's 
> the best way to add this 'credit' to the commit, or is it not 
> appropriate?

For all I'm personally concerned, it doesn't matter at all.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc] Implement ath9k mesh point operation
  2009-03-16 22:36 [rfc] Implement ath9k mesh point operation Pat Erley
  2009-03-16 22:57 ` Andrey Yurovsky
  2009-03-17  4:45 ` Pat Erley
@ 2009-03-17  7:46 ` Johannes Berg
  2009-03-17 21:05   ` Andrey Yurovsky
  2 siblings, 1 reply; 7+ messages in thread
From: Johannes Berg @ 2009-03-17  7:46 UTC (permalink / raw)
  To: Pat Erley
  Cc: linux-wireless, ath9k-devel, andrey, Andrey Yurovsky, brian,
	javier, colin

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

On Mon, 2009-03-16 at 18:36 -0400, Pat Erley wrote:

> Currently, you need to trigger a scan on the mesh point interface to
> enable beaconing.  This is the same behavior the ath5k, rt2500usb and 
> rt61pci drivers exhibit.  Is this a mac80211 design flaw, or something
> in all of these drivers?

It's mac80211. We never call ieee80211_if_config() when we enable a mesh
interface, and thus conf.enable_beacon with
IEEE80211_IFCC_BEACON_ENABLED isn't ever set correctly.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [rfc] Implement ath9k mesh point operation
  2009-03-17  7:46 ` Johannes Berg
@ 2009-03-17 21:05   ` Andrey Yurovsky
  0 siblings, 0 replies; 7+ messages in thread
From: Andrey Yurovsky @ 2009-03-17 21:05 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Pat Erley, linux-wireless

ieee80211_start_mesh() does this:

ieee80211_if_config(sdata, IEEE80211_IFCC_BEACON |
                                   IEEE80211_IFCC_BEACON_ENABLED);

and it's called by ieee80211_open()

On Tue, Mar 17, 2009 at 12:46 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2009-03-16 at 18:36 -0400, Pat Erley wrote:
>
>> Currently, you need to trigger a scan on the mesh point interface to
>> enable beaconing. =A0This is the same behavior the ath5k, rt2500usb =
and
>> rt61pci drivers exhibit. =A0Is this a mac80211 design flaw, or somet=
hing
>> in all of these drivers?
>
> It's mac80211. We never call ieee80211_if_config() when we enable a m=
esh
> interface, and thus conf.enable_beacon with
> IEEE80211_IFCC_BEACON_ENABLED isn't ever set correctly.
>
> johannes
>



--=20
Andrey Yurovsky
cozybit Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2009-03-17 21:05 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-16 22:36 [rfc] Implement ath9k mesh point operation Pat Erley
2009-03-16 22:57 ` Andrey Yurovsky
2009-03-16 23:03   ` Pat Erley
2009-03-17  4:45 ` Pat Erley
2009-03-17  7:44   ` Johannes Berg
2009-03-17  7:46 ` Johannes Berg
2009-03-17 21:05   ` Andrey Yurovsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).