* [PATCH] staging: vt6656: return from workqueues on fMP_DISCONNECTED
From: Malcolm Priestley @ 2013-10-14 18:51 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Return from work queues on flag fMP_DISCONNECTED to prevent
any scheduling threads past closing of device.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/bssdb.c | 3 +++
drivers/staging/vt6656/dpc.c | 6 ++++++
drivers/staging/vt6656/wcmd.c | 3 +++
3 files changed, 12 insertions(+)
diff --git a/drivers/staging/vt6656/bssdb.c b/drivers/staging/vt6656/bssdb.c
index ef654c0..dad3f8c 100644
--- a/drivers/staging/vt6656/bssdb.c
+++ b/drivers/staging/vt6656/bssdb.c
@@ -825,6 +825,9 @@ void BSSvSecondCallBack(struct work_struct *work)
u32 uNonShortSlotSTACnt = 0;
u32 uLongPreambleSTACnt = 0;
+ if (pDevice->Flags & fMP_DISCONNECTED)
+ return;
+
spin_lock_irq(&pDevice->lock);
pDevice->uAssocCount = 0;
diff --git a/drivers/staging/vt6656/dpc.c b/drivers/staging/vt6656/dpc.c
index 82d7c1d..75dc92d 100644
--- a/drivers/staging/vt6656/dpc.c
+++ b/drivers/staging/vt6656/dpc.c
@@ -1339,6 +1339,9 @@ void RXvWorkItem(struct work_struct *work)
int ntStatus;
struct vnt_rcb *pRCB = NULL;
+ if (pDevice->Flags & fMP_DISCONNECTED)
+ return;
+
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"---->Rx Polling Thread\n");
spin_lock_irq(&pDevice->lock);
@@ -1398,6 +1401,9 @@ void RXvMngWorkItem(struct work_struct *work)
struct vnt_rx_mgmt *pRxPacket;
int bReAllocSkb = false;
+ if (pDevice->Flags & fMP_DISCONNECTED)
+ return;
+
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"---->Rx Mng Thread\n");
spin_lock_irq(&pDevice->lock);
diff --git a/drivers/staging/vt6656/wcmd.c b/drivers/staging/vt6656/wcmd.c
index 4f45a7f..2f8e2a8 100644
--- a/drivers/staging/vt6656/wcmd.c
+++ b/drivers/staging/vt6656/wcmd.c
@@ -286,6 +286,9 @@ void vRunCommand(struct work_struct *work)
u8 byMask[8] = {1, 2, 4, 8, 0x10, 0x20, 0x40, 0x80};
u8 byData;
+ if (pDevice->Flags & fMP_DISCONNECTED)
+ return;
+
if (pDevice->dwDiagRefCount != 0)
return;
if (pDevice->bCmdRunning != true)
--
1.8.3.2
^ permalink raw reply related
* [PATCH] staging vt6656: Remove 10 second timer and move to BSSvSecondCallBack
From: Malcolm Priestley @ 2013-10-14 18:46 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Remove sTimerTxData 10 second timer which triggers PSbSendNullPacket
every 40 seconds when bLinkPass == true.
Move the 40 second timer to the existing BSSvSecondCallBack
one second delayed workqueue and trigger every 40 seconds when
bLinkPass == true.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/bssdb.c | 21 +++++++++++++----
drivers/staging/vt6656/device.h | 7 ++----
drivers/staging/vt6656/main_usb.c | 2 --
drivers/staging/vt6656/power.c | 6 ++---
drivers/staging/vt6656/usbpipe.c | 2 --
drivers/staging/vt6656/wcmd.c | 47 ---------------------------------------
drivers/staging/vt6656/wcmd.h | 2 --
drivers/staging/vt6656/wmgr.c | 8 -------
8 files changed, 21 insertions(+), 74 deletions(-)
diff --git a/drivers/staging/vt6656/bssdb.c b/drivers/staging/vt6656/bssdb.c
index ae0438a..ef654c0 100644
--- a/drivers/staging/vt6656/bssdb.c
+++ b/drivers/staging/vt6656/bssdb.c
@@ -57,6 +57,7 @@
#include "control.h"
#include "rndis.h"
#include "iowpa.h"
+#include "power.h"
static int msglevel =MSG_LEVEL_INFO;
//static int msglevel =MSG_LEVEL_DEBUG;
@@ -1121,10 +1122,22 @@ else {
}
}
- if (pDevice->bLinkPass == true) {
- if (netif_queue_stopped(pDevice->dev))
- netif_wake_queue(pDevice->dev);
- }
+ if (pDevice->bLinkPass == true) {
+ if (pMgmt->eAuthenMode < WMAC_AUTH_WPA ||
+ pDevice->fWPA_Authened == true) {
+ if (++pDevice->tx_data_time_out > 40) {
+ pDevice->tx_trigger = true;
+
+ PSbSendNullPacket(pDevice);
+
+ pDevice->tx_trigger = false;
+ pDevice->tx_data_time_out = 0;
+ }
+ }
+
+ if (netif_queue_stopped(pDevice->dev))
+ netif_wake_queue(pDevice->dev);
+ }
spin_unlock_irq(&pDevice->lock);
diff --git a/drivers/staging/vt6656/device.h b/drivers/staging/vt6656/device.h
index fa1cefb..95b181d 100644
--- a/drivers/staging/vt6656/device.h
+++ b/drivers/staging/vt6656/device.h
@@ -711,11 +711,8 @@ struct vnt_private {
/* One second callback */
struct delayed_work second_callback_work;
- struct timer_list sTimerTxData;
- unsigned long nTxDataTimeCout;
- int fTxDataInSleep;
- int IsTxDataTrigger;
-
+ u8 tx_data_time_out;
+ bool tx_trigger;
int fWPA_Authened; /*is WPA/WPA-PSK or WPA2/WPA2-PSK authen?? */
u8 byReAssocCount;
u8 byLinkWaitCount;
diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index 0de2156..412a776 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -1081,8 +1081,6 @@ static int device_close(struct net_device *dev)
cancel_delayed_work_sync(&pDevice->run_command_work);
cancel_delayed_work_sync(&pDevice->second_callback_work);
- del_timer(&pDevice->sTimerTxData);
-
if (pDevice->bDiversityRegCtlON) {
del_timer(&pDevice->TimerSQ3Tmax1);
del_timer(&pDevice->TimerSQ3Tmax2);
diff --git a/drivers/staging/vt6656/power.c b/drivers/staging/vt6656/power.c
index edc8975..6334315 100644
--- a/drivers/staging/vt6656/power.c
+++ b/drivers/staging/vt6656/power.c
@@ -257,10 +257,8 @@ int PSbSendNullPacket(struct vnt_private *pDevice)
if (pDevice->bLinkPass == false)
return false;
- if ((pDevice->bEnablePSMode == false) &&
- (pDevice->fTxDataInSleep == false)) {
- return false;
- }
+ if (pDevice->bEnablePSMode == false && pDevice->tx_trigger == false)
+ return false;
memset(pMgmt->pbyPSPacketPool, 0, sizeof(struct vnt_tx_mgmt)
+ WLAN_NULLDATA_FR_MAXLEN);
diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index 37bcb18..5fc18ad 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -662,8 +662,6 @@ static void s_nsBulkOutIoCompleteWrite(struct urb *urb)
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"Write %d bytes\n",(int)ulBufLen);
pDevice->ulBulkOutBytesWrite += ulBufLen;
pDevice->ulBulkOutContCRCError = 0;
- pDevice->nTxDataTimeCout = 0;
-
} else {
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"BULK Out failed %d\n", status);
pDevice->ulBulkOutError++;
diff --git a/drivers/staging/vt6656/wcmd.c b/drivers/staging/vt6656/wcmd.c
index debb87a..4f45a7f 100644
--- a/drivers/staging/vt6656/wcmd.c
+++ b/drivers/staging/vt6656/wcmd.c
@@ -654,22 +654,6 @@ void vRunCommand(struct work_struct *work)
netif_wake_queue(pDevice->dev);
}
- if(pDevice->IsTxDataTrigger != false) { //TxDataTimer is not triggered at the first time
- // printk("Re-initial TxDataTimer****\n");
- del_timer(&pDevice->sTimerTxData);
- init_timer(&pDevice->sTimerTxData);
- pDevice->sTimerTxData.data = (unsigned long) pDevice;
- pDevice->sTimerTxData.function = (TimerFunction)BSSvSecondTxData;
- pDevice->sTimerTxData.expires = RUN_AT(10*HZ); //10s callback
- pDevice->fTxDataInSleep = false;
- pDevice->nTxDataTimeCout = 0;
- }
- else {
- // printk("mike:-->First time trigger TimerTxData InSleep\n");
- }
- pDevice->IsTxDataTrigger = true;
- add_timer(&pDevice->sTimerTxData);
-
}
else if(pMgmt->eCurrState < WMAC_STATE_ASSOCPENDING) {
printk("WLAN_ASSOCIATE_WAIT:Association Fail???\n");
@@ -681,7 +665,6 @@ void vRunCommand(struct work_struct *work)
vCommandTimerWait((void *) pDevice, ASSOCIATE_TIMEOUT/2);
return;
}
- pDevice->byLinkWaitCount = 0;
s_bCommandComplete(pDevice);
break;
@@ -1159,33 +1142,3 @@ void vResetCommandTimer(struct vnt_private *pDevice)
pDevice->bCmdRunning = false;
pDevice->bCmdClear = false;
}
-
-void BSSvSecondTxData(struct vnt_private *pDevice)
-{
- struct vnt_manager *pMgmt = &pDevice->vnt_mgmt;
-
- pDevice->nTxDataTimeCout++;
-
- if (pDevice->nTxDataTimeCout < 4) { //don't tx data if timer less than 40s
- // printk("mike:%s-->no data Tx not exceed the desired Time as %d\n",__FUNCTION__,
- // (int)pDevice->nTxDataTimeCout);
- pDevice->sTimerTxData.expires = RUN_AT(10 * HZ); //10s callback
- add_timer(&pDevice->sTimerTxData);
- return;
- }
-
- spin_lock_irq(&pDevice->lock);
- //is wap_supplicant running successful OR only open && sharekey mode!
- if (((pDevice->bLinkPass == true) &&
- (pMgmt->eAuthenMode < WMAC_AUTH_WPA)) || //open && sharekey linking
- (pDevice->fWPA_Authened == true)) { //wpa linking
- // printk("mike:%s-->InSleep Tx Data Procedure\n",__FUNCTION__);
- pDevice->fTxDataInSleep = true;
- PSbSendNullPacket(pDevice); //send null packet
- pDevice->fTxDataInSleep = false;
- }
- spin_unlock_irq(&pDevice->lock);
-
- pDevice->sTimerTxData.expires = RUN_AT(10 * HZ); //10s callback
- add_timer(&pDevice->sTimerTxData);
-}
diff --git a/drivers/staging/vt6656/wcmd.h b/drivers/staging/vt6656/wcmd.h
index cd12558..caf2684 100644
--- a/drivers/staging/vt6656/wcmd.h
+++ b/drivers/staging/vt6656/wcmd.h
@@ -107,6 +107,4 @@ int bScheduleCommand(struct vnt_private *, CMD_CODE eCommand, u8 *pbyItem0);
void vRunCommand(struct work_struct *work);
-void BSSvSecondTxData(struct vnt_private *);
-
#endif /* __WCMD_H__ */
diff --git a/drivers/staging/vt6656/wmgr.c b/drivers/staging/vt6656/wmgr.c
index 5a6a5ba..6300a56 100644
--- a/drivers/staging/vt6656/wmgr.c
+++ b/drivers/staging/vt6656/wmgr.c
@@ -213,14 +213,6 @@ void vMgrObjectInit(struct vnt_private *pDevice)
pMgmt->wIBSSBeaconPeriod = DEFAULT_IBSS_BI;
BSSvClearBSSList((void *) pDevice, false);
- init_timer(&pDevice->sTimerTxData);
- pDevice->sTimerTxData.data = (unsigned long)pDevice;
- pDevice->sTimerTxData.function = (TimerFunction)BSSvSecondTxData;
- pDevice->sTimerTxData.expires = RUN_AT(10*HZ); //10s callback
- pDevice->fTxDataInSleep = false;
- pDevice->IsTxDataTrigger = false;
- pDevice->nTxDataTimeCout = 0;
-
pDevice->cbFreeCmdQueue = CMD_Q_SIZE;
pDevice->uCmdDequeueIdx = 0;
pDevice->uCmdEnqueueIdx = 0;
--
1.8.3.2
^ permalink raw reply related
* [PATCH] staging: vt6656: return if pControlURB->hcpriv not NULL
From: Malcolm Priestley @ 2013-10-14 18:44 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Fixes occasional urb submitted while active.
Even thought the fMP_CONTROL_WRITES/fMP_CONTROL_READS flags
are cleared in the return context urb->hcpriv is not NULL.
check for hcpriv and return STATUS_FAILURE if not NULL.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/usbpipe.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index 3a03f1d..37bcb18 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -118,6 +118,9 @@ int PIPEnsControlOut(struct vnt_private *pDevice, u8 byRequest, u16 wValue,
if (pDevice->Flags & fMP_CONTROL_READS)
return STATUS_FAILURE;
+ if (pDevice->pControlURB->hcpriv)
+ return STATUS_FAILURE;
+
MP_SET_FLAG(pDevice, fMP_CONTROL_WRITES);
pDevice->sUsbCtlRequest.bRequestType = 0x40;
@@ -177,6 +180,9 @@ int PIPEnsControlIn(struct vnt_private *pDevice, u8 byRequest, u16 wValue,
if (pDevice->Flags & fMP_CONTROL_WRITES)
return STATUS_FAILURE;
+ if (pDevice->pControlURB->hcpriv)
+ return STATUS_FAILURE;
+
MP_SET_FLAG(pDevice, fMP_CONTROL_READS);
pDevice->sUsbCtlRequest.bRequestType = 0xC0;
--
1.8.3.2
^ permalink raw reply related
* [PATCH] mac80211_hwsim: Add iface comb for DFS
From: Janusz Dziedzic @ 2013-10-14 17:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Janusz Dziedzic
Add iface combination that allow DFS support.
Add also debugfs dfs_simulate_radar file that
can be used to simulate radar event.
This could be usefull for mac80211/cfg80211/
regulatory/hostap code testing without real HW.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/mac80211_hwsim.c | 51 +++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 2cd3f54..1a4eca0 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -370,6 +370,8 @@ struct mac80211_hwsim_data {
s64 bcn_delta;
/* absolute beacon transmission time. Used to cover up "tx" delay. */
u64 abs_bcn_ts;
+
+ struct dentry *debugfs_radar;
};
@@ -1714,6 +1716,7 @@ static void mac80211_hwsim_free(void)
list_for_each_entry_safe(data, tmpdata, &tmplist, list) {
debugfs_remove(data->debugfs_group);
+ debugfs_remove(data->debugfs_radar);
debugfs_remove(data->debugfs_ps);
debugfs_remove(data->debugfs);
ieee80211_unregister_hw(data->hw);
@@ -1872,6 +1875,17 @@ static int hwsim_fops_ps_write(void *dat, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(hwsim_fops_ps, hwsim_fops_ps_read, hwsim_fops_ps_write,
"%llu\n");
+static int hwsim_write_simulate_radar(void *dat, u64 val)
+{
+ struct mac80211_hwsim_data *data = dat;
+
+ ieee80211_radar_detected(data->hw);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(hwsim_simulate_radar, NULL,
+ hwsim_write_simulate_radar, "%llu\n");
static int hwsim_fops_group_read(void *dat, u64 *val)
{
@@ -2173,11 +2187,28 @@ static const struct ieee80211_iface_limit hwsim_if_limits[] = {
{ .max = 1, .types = BIT(NL80211_IFTYPE_P2P_DEVICE) },
};
-static struct ieee80211_iface_combination hwsim_if_comb = {
- .limits = hwsim_if_limits,
- .n_limits = ARRAY_SIZE(hwsim_if_limits),
- .max_interfaces = 2048,
- .num_different_channels = 1,
+static const struct ieee80211_iface_limit hwsim_if_dfs_limits[] = {
+ { .max = 8, .types = BIT(NL80211_IFTYPE_AP) },
+};
+
+static struct ieee80211_iface_combination hwsim_if_comb[] = {
+ {
+ .limits = hwsim_if_limits,
+ .n_limits = ARRAY_SIZE(hwsim_if_limits),
+ .max_interfaces = 2048,
+ .num_different_channels = 1,
+ },
+ {
+ .limits = hwsim_if_dfs_limits,
+ .n_limits = ARRAY_SIZE(hwsim_if_dfs_limits),
+ .max_interfaces = 8,
+ .num_different_channels = 1,
+ .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
+ BIT(NL80211_CHAN_WIDTH_20) |
+ BIT(NL80211_CHAN_WIDTH_40) |
+ BIT(NL80211_CHAN_WIDTH_80) |
+ BIT(NL80211_CHAN_WIDTH_160),
+ }
};
static int __init init_mac80211_hwsim(void)
@@ -2195,7 +2226,7 @@ static int __init init_mac80211_hwsim(void)
return -EINVAL;
if (channels > 1) {
- hwsim_if_comb.num_different_channels = channels;
+ hwsim_if_comb[0].num_different_channels = channels;
mac80211_hwsim_ops.hw_scan = mac80211_hwsim_hw_scan;
mac80211_hwsim_ops.cancel_hw_scan =
mac80211_hwsim_cancel_hw_scan;
@@ -2275,8 +2306,8 @@ static int __init init_mac80211_hwsim(void)
hw->wiphy->n_addresses = 2;
hw->wiphy->addresses = data->addresses;
- hw->wiphy->iface_combinations = &hwsim_if_comb;
- hw->wiphy->n_iface_combinations = 1;
+ hw->wiphy->iface_combinations = hwsim_if_comb;
+ hw->wiphy->n_iface_combinations = ARRAY_SIZE(hwsim_if_comb);
if (channels > 1) {
hw->wiphy->max_scan_ssids = 255;
@@ -2519,6 +2550,10 @@ static int __init init_mac80211_hwsim(void)
data->debugfs_group = debugfs_create_file("group", 0666,
data->debugfs, data,
&hwsim_fops_group);
+ data->debugfs_radar = debugfs_create_file("dfs_simulate_radar",
+ 0222, data->debugfs,
+ data,
+ &hwsim_simulate_radar);
tasklet_hrtimer_init(&data->beacon_timer,
mac80211_hwsim_beacon,
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v4 3/6] mac80211: add the CSA and MCSP elements in mesh beaconing
From: Chun-Yeow Yeoh @ 2013-10-14 17:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <1381772716.13092.21.camel@jlt4.sipsolutions.net>
> It occurs after later patches only though, and this patch introduces an
> RCU warning. I'd suggest to roll this into patch 5 or so since there
> it's really only used?
It make sense. I will do that.
----
Chun-Yeow
^ permalink raw reply
* Re: [PATCH v4 3/6] mac80211: add the CSA and MCSP elements in mesh beaconing
From: Johannes Berg @ 2013-10-14 17:45 UTC (permalink / raw)
To: Chun-Yeow Yeoh
Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <CAHS2MGMONy37xZedzRhx10Mes9MCUMfiEjmWjprVOEQY_brw9Q@mail.gmail.com>
On Tue, 2013-10-15 at 01:15 +0800, Chun-Yeow Yeoh wrote:
> > Does this even make sense here - it can't ever be non-NULL in this
> > patch?
> Actually, the NULL and non-NULL situation should occur here. Whenever
> the node triggers the channel switching period, it will append CSA and
> MCSP elements in the beacon.
It occurs after later patches only though, and this patch introduces an
RCU warning. I'd suggest to roll this into patch 5 or so since there
it's really only used?
johannes
^ permalink raw reply
* Re: pull-request: mac80211 2013-10-14
From: John W. Linville @ 2013-10-14 17:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1381736981.13092.4.camel@jlt4.sipsolutions.net>
On Mon, Oct 14, 2013 at 09:49:45AM +0200, Johannes Berg wrote:
> John,
>
> I know it's getting later in the game (rc5 is out) and my last pull
> request hasn't even made it into Linus's tree, but we still have some
> fixes ...
>
> This time I have two fixes from Emmanuel for RF-kill issues, and fixed
> two issues reported by Evan Huus and Thomas Lindroth respectively.
>
> Let me know if there's any problem.
>
> johannes
>
> The following changes since commit 22c4ceed0184318ec5a6182c6d75d398452c2e39:
>
> mac80211: Run deferred scan if last roc_list item is not started (2013-09-30 12:36:56 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
>
> for you to fetch changes up to d86aa4f8ca58898ec6a94c0635da20b948171ed7:
>
> mac80211: fix crash if bitrate calculation goes wrong (2013-10-14 09:47:08 +0200)
Pulling now...
--
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 v4 5/6] {nl,cfg,mac}80211: finalizing mesh channel switching
From: Chun-Yeow Yeoh @ 2013-10-14 17:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <1381760529.13092.17.camel@jlt4.sipsolutions.net>
> subject should read "finalize" or something I guess? Though it really
> isn't clear to me why you split up the patches as is and didn't just put
> 3/5 together as "implement mesh channel switch userspace API" or so?
I split the patches because I would like the CSA to work without even
the beacon involvement, only CSA action frame. But I will take a look
on this again.
> I don't think this belongs here, it's certainly not needed for the API.
> Maybe you need a wrapper struct or so?
Alright, will do so.
----
Chun-Yeow
^ permalink raw reply
* Re: [PATCH v4 2/6] {nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
From: Chun-Yeow Yeoh @ 2013-10-14 17:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <1381760087.13092.12.camel@jlt4.sipsolutions.net>
> How will userspace know whether or not this is supported? Will it just
> try and fail? Does it really not need to know?
The userspace will only try and fail at the time being. If it is
failed, the initiator will still remain at the current operating
channel.
---
Chun-Yeow
^ permalink raw reply
* Re: [PATCH v4 3/6] mac80211: add the CSA and MCSP elements in mesh beaconing
From: Chun-Yeow Yeoh @ 2013-10-14 17:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <1381760191.13092.13.camel@jlt4.sipsolutions.net>
On Mon, Oct 14, 2013 at 10:16 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2013-10-11 at 11:29 -0700, Chun-Yeow Yeoh wrote:
>
>> /* Channel Switching Support */
>> + struct cfg80211_csa_settings *csa_settings;
>
> That should have an __rcu annotation now, I believe?
>
>> + if (ifmsh->csa_settings) {
>
> In which case this will result in a sparse warning.
>
> Does this even make sense here - it can't ever be non-NULL in this
> patch?
Actually, the NULL and non-NULL situation should occur here. Whenever
the node triggers the channel switching period, it will append CSA and
MCSP elements in the beacon. So in this case, ifmsh->csa_settings
should be non-NULL. Once the channel switching count based on TBTT is
expired, ifmsh->csa_setting should be NULL, and both elements no
longer append to the beacon. Does it make sense?
---
Chun-Yeow
^ permalink raw reply
* Re: [PATCH] ath10k: do not warn about unsupported vdev param
From: Bartosz Markowski @ 2013-10-14 16:06 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless@vger.kernel.org
In-Reply-To: <87fvs3etz6.fsf@kamboji.qca.qualcomm.com>
On 14 October 2013 17:46, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>
>> 10.X firmware does not support WMI_VDEV_PARAM_TX_ENCAP_TYPE.
>> It's a known limitation and we should not warn about this.
>>
>> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index 049eca2..9c800f8 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2085,7 +2085,9 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
>> vdev_param = ar->wmi.vdev_param->tx_encap_type;
>> ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
>> ATH10K_HW_TXRX_NATIVE_WIFI);
>> - if (ret)
>> +
>> + /* 10.X firmware does not support this VDEV parameter. Do not warn */
>> + if (ret && !test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
>> ath10k_warn("Failed to set TX encap: %d\n", ret);
>
> But why call ath10k_wmi_vdev_set_param() even if we know it won't work?
> IMHO it's cleaner not to call it at all when ATH10K_FW_FEATURE_WMI_10X
> is set.
I tend to agree. Intention was to keep things generic and just hide the warning.
> Or if we want to avoid using ATH10K_FW_FEATURE_WMI_10X we could also
> change ath10k_wmi_pdev_set_param() to return -EOPNOTSUPP and check for
> that.
I like the second idea. I will send a v2 patch.
--
Bartosz
^ permalink raw reply
* [PATCH] mac80211: add ieee80211_tx_prepare_skb() helper function
From: Felix Fietkau @ 2013-10-14 16:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
This can be used by a driver to prepare skbs for transmission, which were
obtained via functions such as ieee80211_probereq_get or
ieee80211_nullfunc_get.
This is useful for drivers that want to send those frames directly, but
need rate control information to be prepared first.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
include/net/mac80211.h | 14 ++++++++++++++
net/mac80211/tx.c | 29 +++++++++++++++++++++++++++++
2 files changed, 43 insertions(+)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index f386c48..cf2f32a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4567,4 +4567,18 @@ void ieee80211_report_wowlan_wakeup(struct ieee80211_vif *vif,
struct cfg80211_wowlan_wakeup *wakeup,
gfp_t gfp);
+/**
+ * ieee80211_tx_prepare_skb - prepare an 802.11 skb for transmission
+ * @hw: pointer as obtained from ieee80211_alloc_hw()
+ * @vif: virtual interface
+ * @skb: frame to be sent from within the driver
+ * @band: the band to transmit on
+ * @sta: optional pointer to get the station to send the frame to
+ *
+ * Note: must be called under RCU lock
+ */
+bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, struct sk_buff *skb,
+ int band, struct ieee80211_sta **sta);
+
#endif /* MAC80211_H */
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 9993fcb..4340aa7 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1367,6 +1367,35 @@ static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
return 0;
}
+bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, struct sk_buff *skb,
+ int band, struct ieee80211_sta **sta)
+{
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_tx_data tx;
+
+ if (ieee80211_tx_prepare(sdata, &tx, skb) == TX_DROP)
+ return false;
+
+ info->band = band;
+ info->control.vif = vif;
+ info->hw_queue = vif->hw_queue[skb_get_queue_mapping(skb)];
+
+ if (invoke_tx_handlers(&tx))
+ return false;
+
+ if (sta) {
+ if (tx.sta)
+ *sta = &tx.sta->sta;
+ else
+ *sta = NULL;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(ieee80211_tx_prepare_skb);
+
/*
* Returns false if the frame couldn't be transmitted but was queued instead.
*/
--
1.8.0.2
^ permalink raw reply related
* Re: [PATCH] ath10k: do not warn about unsupported vdev param
From: Kalle Valo @ 2013-10-14 15:46 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1381749381-15459-1-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> 10.X firmware does not support WMI_VDEV_PARAM_TX_ENCAP_TYPE.
> It's a known limitation and we should not warn about this.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 049eca2..9c800f8 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2085,7 +2085,9 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
> vdev_param = ar->wmi.vdev_param->tx_encap_type;
> ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
> ATH10K_HW_TXRX_NATIVE_WIFI);
> - if (ret)
> +
> + /* 10.X firmware does not support this VDEV parameter. Do not warn */
> + if (ret && !test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
> ath10k_warn("Failed to set TX encap: %d\n", ret);
But why call ath10k_wmi_vdev_set_param() even if we know it won't work?
IMHO it's cleaner not to call it at all when ATH10K_FW_FEATURE_WMI_10X
is set.
Or if we want to avoid using ATH10K_FW_FEATURE_WMI_10X we could also
change ath10k_wmi_pdev_set_param() to return -EOPNOTSUPP and check for
that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] cfg80211: fix channel to frequency mapping in 5.9GHz range
From: Johannes Berg @ 2013-10-14 15:06 UTC (permalink / raw)
To: Dennis H Jensen; +Cc: linville, linux-wireless
In-Reply-To: <1381762681.3711.36.camel@djensen-laptop>
On Mon, 2013-10-14 at 16:58 +0200, Dennis H Jensen wrote:
> > > The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
> > > to 4.9 GHz but left a hole in the 5.9 Ghz range.
> >
> > But there was no +/- 15 before, so what gives?
>
> Well no :) but there also wasn't a special case for that particular
> channel set (182 - 196).
Yes, but then before 5910 would have been channel 182. Now you're making
it channel 197. That doesn't really make sense at all.
> So now, when you configure the frequency 5910, it is mapped to channel
> 182 which is mapped back to 4910 and nothing works, at least let the
> functions be the inverse of the other.
>
> In case that doesn't do it. What is needed to get channel 182 to be 5910
> MHz as Annex E defines for the US and Europe? Channel to frequency
> mapping based on operating class?
Annex E is the 802.11 spec, to get something into that ...
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: fix channel to frequency mapping in 5.9GHz range
From: Dennis H Jensen @ 2013-10-14 14:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1381759370.13092.11.camel@jlt4.sipsolutions.net>
On Mon, 2013-10-14 at 16:02 +0200, Johannes Berg wrote:
> On Mon, 2013-10-14 at 14:16 +0200, Dennis H Jensen wrote:
> > On Mon, 2013-10-14 at 14:02 +0200, Johannes Berg wrote:
> > > On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
> > >
> > > > > > + else if (chan > 196)
> > > > > > + return 5000 + (chan - 15) * 5;
> > > > >
> > > > > Where does the +/- 15 come from? I can't find any evidence for this in
> > > > > Annex E.
> > > >
> > > > I didn't double check Annex E. I just wanted to recover the lost
> > > > frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
> > >
> > > "Recover"? When did they work? What broke them?
> >
> > The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
> > to 4.9 GHz but left a hole in the 5.9 Ghz range.
>
> But there was no +/- 15 before, so what gives?
Well no :) but there also wasn't a special case for that particular
channel set (182 - 196).
So now, when you configure the frequency 5910, it is mapped to channel
182 which is mapped back to 4910 and nothing works, at least let the
functions be the inverse of the other.
In case that doesn't do it. What is needed to get channel 182 to be 5910
MHz as Annex E defines for the US and Europe? Channel to frequency
mapping based on operating class?
//Dennis
^ permalink raw reply
* Re: [PATCH v4 5/6] {nl,cfg,mac}80211: finalizing mesh channel switching
From: Johannes Berg @ 2013-10-14 14:22 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381516190-23918-6-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-10-11 at 11:29 -0700, Chun-Yeow Yeoh wrote:
> finalizing
subject should read "finalize" or something I guess? Though it really
isn't clear to me why you split up the patches as is and didn't just put
3/5 together as "implement mesh channel switch userspace API" or so?
> struct cfg80211_csa_settings {
> + struct rcu_head rcu_head;
I don't think this belongs here, it's certainly not needed for the API.
Maybe you need a wrapper struct or so?
johannes
^ permalink raw reply
* Re: [PATCH v4 3/6] mac80211: add the CSA and MCSP elements in mesh beaconing
From: Johannes Berg @ 2013-10-14 14:18 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381516190-23918-4-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-10-11 at 11:29 -0700, Chun-Yeow Yeoh wrote:
> Support the adding of CSA and MCSP elements while building the beacon
> for mesh if necessary. This is defined in the IEEE Std 802.11-2012
> section 10.9.8.4.3 that both CSA and MCSP elements must be included
> in beacon and probe response frames until the intended channel
> switch time.
I also get
net/mac80211/mesh.c:673:42: warning: symbol 'ifmsh' shadows an earlier
one
net/mac80211/mesh.c:606:29: originally declared here
with this patch
^ permalink raw reply
* Re: [PATCH v4 3/6] mac80211: add the CSA and MCSP elements in mesh beaconing
From: Johannes Berg @ 2013-10-14 14:16 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381516190-23918-4-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-10-11 at 11:29 -0700, Chun-Yeow Yeoh wrote:
> /* Channel Switching Support */
> + struct cfg80211_csa_settings *csa_settings;
That should have an __rcu annotation now, I believe?
> + if (ifmsh->csa_settings) {
In which case this will result in a sparse warning.
Does this even make sense here - it can't ever be non-NULL in this
patch?
johannes
^ permalink raw reply
* Re: [PATCH v4 2/6] {nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
From: Johannes Berg @ 2013-10-14 14:14 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381516190-23918-3-git-send-email-yeohchunyeow@cozybit.com>
On Fri, 2013-10-11 at 11:29 -0700, Chun-Yeow Yeoh wrote:
> Allow the triggering of CSA frame using mesh interface. The
> rules are more or less same with IBSS, such as not allowed to
> change between the band and channel width has to be same from
> the previous mode. Also, move the ieee80211_send_action_csa
> to a common space so that it can be re-used by mesh interface.
How will userspace know whether or not this is supported? Will it just
try and fail? Does it really not need to know?
johannes
^ permalink raw reply
* Re: [Ilw] trouble with wireless AC 7260 in ubuntu 13.04
From: Seth Forshee @ 2013-10-14 14:06 UTC (permalink / raw)
To: Grumbach, Emmanuel, Ben Meiselman
Cc: linux-wireless@vger.kernel.org, ilw@linux.intel.com,
Yonah Meiselman
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301DC1C5A@HASMSX103.ger.corp.intel.com>
On Sun, Oct 13, 2013 at 04:49:27AM +0000, Grumbach, Emmanuel wrote:
> Hi,
>
> First, please note that mails in any other format than plaintext won't go through the filters to the mailing list. So please, hit the plain text button in gmail.
>
>
> > Hello supporters,
>
> :)
>
> > I got your email addresses from here: http://wireless.kernel.org/en/users/Drivers/iwlwifi
> > (Also copying my brother on this email.)
>
> > I installed Ubuntu 13.04 on a new machine. It has an Intel Dual Band AC 7260 wireless card. I would like to connect to a wireless network but don't know how.
> > I put iwlwifi-7260-7.ucode into /lib/firmware
>
> I am not sure if Ubuntu 13.04 supports this new device already. I'd ask Seth Forshee (CCed).
> This device is supported starting from kernel 3.10 which AFAIK is not shipped with Ubuntu 13.04. They may very well have added a backport based driver.
Ubuntu 13.04 is using a 3.8 kernel. We'll be using 3.11 in the 13.10
release, which is due out this month. If you don't want to install a
newer kernel yourself you can either update to the 13.10 beta [1] or use
the backports project to get drivers from later kernels [2].
Seth
[1] http://fridge.ubuntu.com/2013/09/27/ubuntu-13-10-saucy-salamander-final-beta-released/
[2] https://backports.wiki.kernel.org
^ permalink raw reply
* Re: [PATCH] cfg80211: fix channel to frequency mapping in 5.9GHz range
From: Johannes Berg @ 2013-10-14 14:02 UTC (permalink / raw)
To: Dennis H Jensen; +Cc: linville, linux-wireless
In-Reply-To: <1381752976.3711.14.camel@djensen-laptop>
On Mon, 2013-10-14 at 14:16 +0200, Dennis H Jensen wrote:
> On Mon, 2013-10-14 at 14:02 +0200, Johannes Berg wrote:
> > On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
> >
> > > > > + else if (chan > 196)
> > > > > + return 5000 + (chan - 15) * 5;
> > > >
> > > > Where does the +/- 15 come from? I can't find any evidence for this in
> > > > Annex E.
> > >
> > > I didn't double check Annex E. I just wanted to recover the lost
> > > frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
> >
> > "Recover"? When did they work? What broke them?
>
> The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
> to 4.9 GHz but left a hole in the 5.9 Ghz range.
But there was no +/- 15 before, so what gives?
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: fix channel to frequency mapping in 5.9GHz range
From: Dennis H Jensen @ 2013-10-14 12:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1381752176.13092.10.camel@jlt4.sipsolutions.net>
On Mon, 2013-10-14 at 14:02 +0200, Johannes Berg wrote:
> On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
>
> > > > + else if (chan > 196)
> > > > + return 5000 + (chan - 15) * 5;
> > >
> > > Where does the +/- 15 come from? I can't find any evidence for this in
> > > Annex E.
> >
> > I didn't double check Annex E. I just wanted to recover the lost
> > frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
>
> "Recover"? When did they work? What broke them?
The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
to 4.9 GHz but left a hole in the 5.9 Ghz range.
//Dennis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix channel to frequency mapping in 5.9GHz range
From: Johannes Berg @ 2013-10-14 12:02 UTC (permalink / raw)
To: Dennis H Jensen; +Cc: linville, linux-wireless
In-Reply-To: <1381506302.3711.10.camel@djensen-laptop>
On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
> > > + else if (chan > 196)
> > > + return 5000 + (chan - 15) * 5;
> >
> > Where does the +/- 15 come from? I can't find any evidence for this in
> > Annex E.
>
> I didn't double check Annex E. I just wanted to recover the lost
> frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
"Recover"? When did they work? What broke them?
johannes
^ permalink raw reply
* [PATCH] ath10k: do not warn about unsupported vdev param
From: Bartosz Markowski @ 2013-10-14 11:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
10.X firmware does not support WMI_VDEV_PARAM_TX_ENCAP_TYPE.
It's a known limitation and we should not warn about this.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 049eca2..9c800f8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2085,7 +2085,9 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
vdev_param = ar->wmi.vdev_param->tx_encap_type;
ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
ATH10K_HW_TXRX_NATIVE_WIFI);
- if (ret)
+
+ /* 10.X firmware does not support this VDEV parameter. Do not warn */
+ if (ret && !test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
ath10k_warn("Failed to set TX encap: %d\n", ret);
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
--
1.7.10
^ permalink raw reply related
* [PATCH 4/4] ath9k/ath: move dfs pattern detector to ath
From: Janusz Dziedzic @ 2013-10-14 9:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Janusz Dziedzic
In-Reply-To: <1381741566-2330-1-git-send-email-janusz.dziedzic@tieto.com>
Move the DFS pattern detector code to the ath module so
the other Atheros drivers can make us of it. This makes
no functional changes.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
drivers/net/wireless/ath/Makefile | 4 +++-
drivers/net/wireless/ath/ath9k/Makefile | 4 +---
drivers/net/wireless/ath/ath9k/dfs.h | 2 +-
drivers/net/wireless/ath/ath9k/dfs_debug.c | 2 +-
.../ath/{ath9k => }/dfs_pattern_detector.c | 2 +-
.../ath/{ath9k => }/dfs_pattern_detector.h | 0
.../wireless/ath/{ath9k => }/dfs_pri_detector.c | 2 +-
.../wireless/ath/{ath9k => }/dfs_pri_detector.h | 0
8 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/net/wireless/ath/{ath9k => }/dfs_pattern_detector.c (99%)
rename drivers/net/wireless/ath/{ath9k => }/dfs_pattern_detector.h (100%)
rename drivers/net/wireless/ath/{ath9k => }/dfs_pri_detector.c (99%)
rename drivers/net/wireless/ath/{ath9k => }/dfs_pri_detector.h (100%)
diff --git a/drivers/net/wireless/ath/Makefile b/drivers/net/wireless/ath/Makefile
index fb05cfd..90b9d75 100644
--- a/drivers/net/wireless/ath/Makefile
+++ b/drivers/net/wireless/ath/Makefile
@@ -11,7 +11,9 @@ obj-$(CONFIG_ATH_COMMON) += ath.o
ath-objs := main.o \
regd.o \
hw.o \
- key.o
+ key.o \
+ dfs_pattern_detector.o \
+ dfs_pri_detector.o
ath-$(CONFIG_ATH_DEBUG) += debug.o
ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index 75ee9e7..6205ef5 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -14,9 +14,7 @@ ath9k-$(CONFIG_ATH9K_AHB) += ahb.o
ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
ath9k-$(CONFIG_ATH9K_DFS_DEBUGFS) += dfs_debug.o
ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += \
- dfs.o \
- dfs_pattern_detector.o \
- dfs_pri_detector.o
+ dfs.o
ath9k-$(CONFIG_PM_SLEEP) += wow.o
obj-$(CONFIG_ATH9K) += ath9k.o
diff --git a/drivers/net/wireless/ath/ath9k/dfs.h b/drivers/net/wireless/ath/ath9k/dfs.h
index 3c839f0..c6fa3d5 100644
--- a/drivers/net/wireless/ath/ath9k/dfs.h
+++ b/drivers/net/wireless/ath/ath9k/dfs.h
@@ -17,7 +17,7 @@
#ifndef ATH9K_DFS_H
#define ATH9K_DFS_H
-#include "dfs_pattern_detector.h"
+#include "../dfs_pattern_detector.h"
#if defined(CONFIG_ATH9K_DFS_CERTIFIED)
/**
diff --git a/drivers/net/wireless/ath/ath9k/dfs_debug.c b/drivers/net/wireless/ath/ath9k/dfs_debug.c
index 990c376..90b8342 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_debug.c
+++ b/drivers/net/wireless/ath/ath9k/dfs_debug.c
@@ -20,7 +20,7 @@
#include "ath9k.h"
#include "dfs_debug.h"
-#include "dfs_pattern_detector.h"
+#include "../dfs_pattern_detector.h"
static struct ath_dfs_pool_stats dfs_pool_stats = { 0 };
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
similarity index 99%
rename from drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
rename to drivers/net/wireless/ath/dfs_pattern_detector.c
index c230ffc..a1a69c5 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -19,7 +19,7 @@
#include "dfs_pattern_detector.h"
#include "dfs_pri_detector.h"
-#include "../ath.h"
+#include "ath.h"
/*
* tolerated deviation of radar time stamp in usecs on both sides
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.h b/drivers/net/wireless/ath/dfs_pattern_detector.h
similarity index 100%
rename from drivers/net/wireless/ath/ath9k/dfs_pattern_detector.h
rename to drivers/net/wireless/ath/dfs_pattern_detector.h
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c b/drivers/net/wireless/ath/dfs_pri_detector.c
similarity index 99%
rename from drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
rename to drivers/net/wireless/ath/dfs_pri_detector.c
index 17b5bf9..43b6081 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/dfs_pri_detector.c
@@ -17,7 +17,7 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
-#include "../ath.h"
+#include "ath.h"
#include "dfs_pattern_detector.h"
#include "dfs_pri_detector.h"
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pri_detector.h b/drivers/net/wireless/ath/dfs_pri_detector.h
similarity index 100%
rename from drivers/net/wireless/ath/ath9k/dfs_pri_detector.h
rename to drivers/net/wireless/ath/dfs_pri_detector.h
--
1.7.9.5
^ 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