Searched hist:"67 b3f129" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/drivers/net/wireless/ath/ath6kl/ |
| H A D | core.h | 67b3f129 Tue May 29 13:12:50 CDT 2012 Kiran Reddy <c_lreddy@qca.qualcomm.com> ath6kl: separate ht cap for each band
In virtual interface structure, for each band separate ht cap
is needed. so that one can disable or enable ht capability band
wise.
This will fix the following issue:
1) Disable 11n from supplicant and start a P2P GO.
2) In beacon frames no HT-CAP IE is seen which is expected.
3) Now remove the P2P GO and kill the supplicant.
4) Beacon stops
5) Now using iw associate to an external AP in 5 GHZ
6) In 5 GHZ no HT IE going in assoc request but
when associated in 2.4 GHZ can see HT IES over the air
in assoc request.
In the code for del_beacon in cfg80211.c,set_ht_cap is being
called first for 2.4 GHZ and then for 5 GHZ. When called
for the first time for 2.4 GHZ the enable flag will be set to true
and so when called for the second time for 5 GHZ it just returns
after checking the flag.
Also using this one can have different HT capabilities
per band (for example one may decide not to use 20/40 in 2.4 GHZ
but use it in 5 GHZ). So maintaining a single context is not ok.
it is true for even the enable/disable flag and other HT
capabilities as well
Signed-off-by: Kiran Reddy <c_lreddy@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
67b3f129 Tue May 29 13:12:50 CDT 2012 Kiran Reddy <c_lreddy@qca.qualcomm.com> ath6kl: separate ht cap for each band
In virtual interface structure, for each band separate ht cap
is needed. so that one can disable or enable ht capability band
wise.
This will fix the following issue:
1) Disable 11n from supplicant and start a P2P GO.
2) In beacon frames no HT-CAP IE is seen which is expected.
3) Now remove the P2P GO and kill the supplicant.
4) Beacon stops
5) Now using iw associate to an external AP in 5 GHZ
6) In 5 GHZ no HT IE going in assoc request but
when associated in 2.4 GHZ can see HT IES over the air
in assoc request.
In the code for del_beacon in cfg80211.c,set_ht_cap is being
called first for 2.4 GHZ and then for 5 GHZ. When called
for the first time for 2.4 GHZ the enable flag will be set to true
and so when called for the second time for 5 GHZ it just returns
after checking the flag.
Also using this one can have different HT capabilities
per band (for example one may decide not to use 20/40 in 2.4 GHZ
but use it in 5 GHZ). So maintaining a single context is not ok.
it is true for even the enable/disable flag and other HT
capabilities as well
Signed-off-by: Kiran Reddy <c_lreddy@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
|
| H A D | cfg80211.c | 67b3f129 Tue May 29 13:12:50 CDT 2012 Kiran Reddy <c_lreddy@qca.qualcomm.com> ath6kl: separate ht cap for each band
In virtual interface structure, for each band separate ht cap
is needed. so that one can disable or enable ht capability band
wise.
This will fix the following issue:
1) Disable 11n from supplicant and start a P2P GO.
2) In beacon frames no HT-CAP IE is seen which is expected.
3) Now remove the P2P GO and kill the supplicant.
4) Beacon stops
5) Now using iw associate to an external AP in 5 GHZ
6) In 5 GHZ no HT IE going in assoc request but
when associated in 2.4 GHZ can see HT IES over the air
in assoc request.
In the code for del_beacon in cfg80211.c,set_ht_cap is being
called first for 2.4 GHZ and then for 5 GHZ. When called
for the first time for 2.4 GHZ the enable flag will be set to true
and so when called for the second time for 5 GHZ it just returns
after checking the flag.
Also using this one can have different HT capabilities
per band (for example one may decide not to use 20/40 in 2.4 GHZ
but use it in 5 GHZ). So maintaining a single context is not ok.
it is true for even the enable/disable flag and other HT
capabilities as well
Signed-off-by: Kiran Reddy <c_lreddy@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
67b3f129 Tue May 29 13:12:50 CDT 2012 Kiran Reddy <c_lreddy@qca.qualcomm.com> ath6kl: separate ht cap for each band
In virtual interface structure, for each band separate ht cap
is needed. so that one can disable or enable ht capability band
wise.
This will fix the following issue:
1) Disable 11n from supplicant and start a P2P GO.
2) In beacon frames no HT-CAP IE is seen which is expected.
3) Now remove the P2P GO and kill the supplicant.
4) Beacon stops
5) Now using iw associate to an external AP in 5 GHZ
6) In 5 GHZ no HT IE going in assoc request but
when associated in 2.4 GHZ can see HT IES over the air
in assoc request.
In the code for del_beacon in cfg80211.c,set_ht_cap is being
called first for 2.4 GHZ and then for 5 GHZ. When called
for the first time for 2.4 GHZ the enable flag will be set to true
and so when called for the second time for 5 GHZ it just returns
after checking the flag.
Also using this one can have different HT capabilities
per band (for example one may decide not to use 20/40 in 2.4 GHZ
but use it in 5 GHZ). So maintaining a single context is not ok.
it is true for even the enable/disable flag and other HT
capabilities as well
Signed-off-by: Kiran Reddy <c_lreddy@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
|