From d619ee08490ca78c9571dca133cd0d0527a60839 Mon Sep 17 00:00:00 2001 From: Luis Carlos Cobo Date: Wed, 23 Apr 2008 12:34:59 -0700 Subject: mac80211: update mesh EID values This patch updates mesh EID values, some of which where conflicting with already-approved 11h EIDs (pointed out by Tomas Winkler). I wanted to use the values suggested in the last available 802.11 draft (2.0) but it assigns 50 to MESH_CONFIG, the same value than EXT_SUPP_RATES. Using the values proposed in the draft incremented by one. Signed-off-by: Luis Carlos Cobo Signed-off-by: John W. Linville --- include/linux/ieee80211.h | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) (limited to 'include/linux') diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h index f27d11a..529f301 100644 --- a/include/linux/ieee80211.h +++ b/include/linux/ieee80211.h @@ -465,13 +465,19 @@ enum ieee80211_eid { WLAN_EID_TS_DELAY = 43, WLAN_EID_TCLAS_PROCESSING = 44, WLAN_EID_QOS_CAPA = 46, - /* 802.11s */ - WLAN_EID_MESH_CONFIG = 36, /* Pending IEEE 802.11 ANA approval */ - WLAN_EID_MESH_ID = 37, /* Pending IEEE 802.11 ANA approval */ - WLAN_EID_PEER_LINK = 40, /* Pending IEEE 802.11 ANA approval */ - WLAN_EID_PREQ = 53, /* Pending IEEE 802.11 ANA approval */ - WLAN_EID_PREP = 54, /* Pending IEEE 802.11 ANA approval */ - WLAN_EID_PERR = 55, /* Pending IEEE 802.11 ANA approval */ + /* 802.11s + * + * All mesh EID numbers are pending IEEE 802.11 ANA approval. + * The numbers have been incremented from those suggested in + * 802.11s/D2.0 so that MESH_CONFIG does not conflict with + * EXT_SUPP_RATES. + */ + WLAN_EID_MESH_CONFIG = 51, + WLAN_EID_MESH_ID = 52, + WLAN_EID_PEER_LINK = 55, + WLAN_EID_PREQ = 68, + WLAN_EID_PREP = 69, + WLAN_EID_PERR = 70, /* 802.11h */ WLAN_EID_PWR_CONSTRAINT = 32, WLAN_EID_PWR_CAPABILITY = 33, -- cgit v1.1 From c9c1014b2bd014c7ec037bbb6f58818162fdb265 Mon Sep 17 00:00:00 2001 From: Patrick McHardy Date: Wed, 23 Apr 2008 22:10:48 -0700 Subject: [RTNETLINK]: Fix bogus ASSERT_RTNL warning ASSERT_RTNL uses mutex_trylock to test whether the rtnl_mutex is held. This bogus warnings when running in atomic context, which f.e. happens when adding secondary unicast addresses through macvlan or vlan or when synchronizing multicast addresses from wireless devices. Mid-term we might want to consider moving all address updates to process context since the locking seems overly complicated, for now just fix the bogus warning by changing ASSERT_RTNL to use mutex_is_locked(). Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller --- include/linux/rtnetlink.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'include/linux') diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h index b9e1740..44c81c7 100644 --- a/include/linux/rtnetlink.h +++ b/include/linux/rtnetlink.h @@ -740,13 +740,13 @@ extern void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change); extern void rtnl_lock(void); extern void rtnl_unlock(void); extern int rtnl_trylock(void); +extern int rtnl_is_locked(void); extern void rtnetlink_init(void); extern void __rtnl_unlock(void); #define ASSERT_RTNL() do { \ - if (unlikely(rtnl_trylock())) { \ - rtnl_unlock(); \ + if (unlikely(!rtnl_is_locked())) { \ printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \ __FILE__, __LINE__); \ dump_stack(); \ -- cgit v1.1