All code to be shared between ath9k and ath9k_htc
is part of a common library. This reduces module
proliferation.
Signed-off-by: Sujith <[email protected]>
---
drivers/net/wireless/ath/ath9k/Kconfig | 3 --
drivers/net/wireless/ath/ath9k/Makefile | 3 --
drivers/net/wireless/ath/ath9k/ath9k.h | 6 ----
drivers/net/wireless/ath/ath9k/common.c | 40 -------------------------------
drivers/net/wireless/ath/ath9k/common.h | 40 -------------------------------
drivers/net/wireless/ath/ath9k/htc.h | 1 -
6 files changed, 0 insertions(+), 93 deletions(-)
delete mode 100644 drivers/net/wireless/ath/ath9k/common.c
delete mode 100644 drivers/net/wireless/ath/ath9k/common.h
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index fd28803..4fc4bc6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -1,7 +1,5 @@
config ATH9K_HW
tristate
-config ATH9K_COMMON
- tristate
config ATH9K
tristate "Atheros 802.11n wireless cards support"
@@ -10,7 +8,6 @@ config ATH9K
select MAC80211_LEDS
select LEDS_CLASS
select NEW_LEDS
- select ATH9K_COMMON
---help---
This module adds support for wireless adapters based on
Atheros IEEE 802.11n AR5008, AR9001 and AR9002 family
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index 518ebb7..afe7e19 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -27,9 +27,6 @@ ath9k_hw-y:= hw.o \
obj-$(CONFIG_ATH9K_HW) += ath9k_hw.o
-obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o
-ath9k_common-y:= common.o
-
ath9k_htc-y += htc_hst.o \
hif_usb.o \
wmi.o \
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index b77aedd..ae369a1 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -22,14 +22,8 @@
#include <linux/leds.h>
#include "debug.h"
-#include "common.h"
#include "lib.h"
-/*
- * Header for the ath9k.ko driver core *only* -- hw code nor any other driver
- * should rely on this file or its contents.
- */
-
struct ath_node;
/* Macro to expand scalars to 64-bit objects */
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
deleted file mode 100644
index 2a3f835..0000000
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright (c) 2009 Atheros Communications Inc.
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-/*
- * Module for common driver code between ath9k and ath9k_htc
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-
-#include "common.h"
-
-MODULE_AUTHOR("Atheros Communications");
-MODULE_DESCRIPTION("Shared library for Atheros wireless 802.11n LAN cards.");
-MODULE_LICENSE("Dual BSD/GPL");
-
-static int __init ath9k_cmn_init(void)
-{
- return 0;
-}
-module_init(ath9k_cmn_init);
-
-static void __exit ath9k_cmn_exit(void)
-{
- return;
-}
-module_exit(ath9k_cmn_exit);
diff --git a/drivers/net/wireless/ath/ath9k/common.h b/drivers/net/wireless/ath/ath9k/common.h
deleted file mode 100644
index 7dcf938..0000000
--- a/drivers/net/wireless/ath/ath9k/common.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright (c) 2009 Atheros Communications Inc.
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-#include <net/mac80211.h>
-
-#include "../ath.h"
-#include "../debug.h"
-
-#include "hw.h"
-
-/* Common header for Atheros 802.11n base driver cores */
-
-#define ATH_RSSI_DUMMY_MARKER 0x127
-#define ATH_RSSI_LPF_LEN 10
-#define RSSI_LPF_THRESHOLD -20
-#define ATH_RSSI_EP_MULTIPLIER (1<<7)
-#define ATH_EP_MUL(x, mul) ((x) * (mul))
-#define ATH_RSSI_IN(x) (ATH_EP_MUL((x), ATH_RSSI_EP_MULTIPLIER))
-#define ATH_LPF_RSSI(x, y, len) \
- ((x != ATH_RSSI_DUMMY_MARKER) ? (((x) * ((len) - 1) + (y)) / (len)) : (y))
-#define ATH_RSSI_LPF(x, y) do { \
- if ((y) >= RSSI_LPF_THRESHOLD) \
- x = ATH_LPF_RSSI((x), ATH_RSSI_IN((y)), ATH_RSSI_LPF_LEN); \
-} while (0)
-#define ATH_EP_RND(x, mul) \
- ((((x)%(mul)) >= ((mul)/2)) ? ((x) + ((mul) - 1)) / (mul) : (x)/(mul))
-
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index ad5ce09..201d149 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -25,7 +25,6 @@
#include <linux/leds.h>
#include <net/mac80211.h>
-#include "common.h"
#include "htc_hst.h"
#include "hif_usb.h"
#include "wmi.h"
--
1.7.0.1
Luis R. Rodriguez wrote:
> So you still don't like a common module approach? I guess I can wait
> to see your patch.
I don't know, Luis.
It seems a bit cleaner to me, just ath.ko, ath9k_hw.ko and ath9k.ko
But I don't really care, anyway - maybe we can just dump this series and
use ath9k_common.ko as such.
I'll send patches removing lib.c from ath9k_htc.
> Year I hear you, so there are two things I think we can do in the long
> run to bring in mac80211 helpers together. The first one is to remove
> the ath9k wiphy. The second is to use a threaded ISR and change our
> bottom halves to use a workqueue instead of a tasklet so we can also
> sleep during our work. I think these two things should enable us to
> start sharing some callbacks. But ath9k virtual wiphy seems to provide
> some functionality we don't yet have in mac80211/cfg80211 centrally
> but we could work on that.
My vote is to keep the drivers separate.
Sujith
Luis R. Rodriguez wrote:
> You would be more familiar with the commonality between ath9k and
> ath9k_htc at this point. Even though the two drivers are separate
> right now, say we did remove the ath9k virtual wiphy, is there a set
> of mac80211 callbacks we can start sharing?
I don't think so, all of the callbacks involve issuing WMI commands
to the target, trying to workaround this would involve a lot of code churn.
Sujith
On Tue, Mar 2, 2010 at 12:11 AM, Sujith <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>> ChromeOs builds everything as built-in so in that case you will have
>> both eventually enabled.
>
> Right, in this case a small fix is needed.
> I'll send a patch to link in the library only once.
So you still don't like a common module approach? I guess I can wait
to see your patch.
>> Although it may be a few common helpers it could grow to share common
>> mac80211 helpers. After all, there are a few calls which could simply
>> be shared.
>
> I wanted to do this too, have a single mac80211 layer - but eventually,
> there were just too many differences between the callbacks.
Year I hear you, so there are two things I think we can do in the long
run to bring in mac80211 helpers together. The first one is to remove
the ath9k wiphy. The second is to use a threaded ISR and change our
bottom halves to use a workqueue instead of a tasklet so we can also
sleep during our work. I think these two things should enable us to
start sharing some callbacks. But ath9k virtual wiphy seems to provide
some functionality we don't yet have in mac80211/cfg80211 centrally
but we could work on that.
Luis
Luis R. Rodriguez wrote:
> Interesting approach, instead of having two modules you linked lib.o
> twice to two separate modules, ath9k.ko and ath9k_htc.ko. While this
> does reduce module proliferation is there any advantage to that over
> the approach of stuffing these into one common module shared between
> both?
>
> The benefit of doing it as a module is if both are built-in you reduce
> the final kernel size. On my box with debugging this is 256 KB.
The built-in case would be mostly useful in embedded systems (SoC etc ..).
And it is likely to be either ath9k or ath9k_htc. I don't think that
both family of chipsets can exist simultaneously.
And since the code that is shared is very minimal (a few general routines and crypto),
it felt reasonable to just stuff into a common library.
Sujith
Luis R. Rodriguez wrote:
> ChromeOs builds everything as built-in so in that case you will have
> both eventually enabled.
Right, in this case a small fix is needed.
I'll send a patch to link in the library only once.
> Although it may be a few common helpers it could grow to share common
> mac80211 helpers. After all, there are a few calls which could simply
> be shared.
I wanted to do this too, have a single mac80211 layer - but eventually,
there were just too many differences between the callbacks.
Sujith
On Mon, Mar 1, 2010 at 1:36 AM, Sujith <[email protected]> wrote:
> All code to be shared between ath9k and ath9k_htc
> is part of a common library. This reduces module
> proliferation.
>
> Signed-off-by: Sujith <[email protected]>
Interesting approach, instead of having two modules you linked lib.o
twice to two separate modules, ath9k.ko and ath9k_htc.ko. While this
does reduce module proliferation is there any advantage to that over
the approach of stuffing these into one common module shared between
both?
The benefit of doing it as a module is if both are built-in you reduce
the final kernel size. On my box with debugging this is 256 KB.
Luis
On Tue, Mar 2, 2010 at 12:28 AM, Sujith <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>> So you still don't like a common module approach? I guess I can wait
>> to see your patch.
>
> I don't know, Luis.
> It seems a bit cleaner to me, just ath.ko, ath9k_hw.ko and ath9k.ko
Well I agree, if some common code exists though it should just go into
a module, and if its real small to some inline helpers but from the
looks of it that is not the case.
> But I don't really care, anyway - maybe we can just dump this series and
> use ath9k_common.ko as such.
>
> I'll send patches removing lib.c from ath9k_htc.
Well so my goal with ath9k_common was to use it as a place holder was
we don't have common mac80211 helpers between both ath9k and ath9k_htc
but with an end goal that we try to merge as much as is possible. I
only got to completing basic legacy RX support on ath9k_htc so did
only get that far to see the extend to what things can be shared as
far as mac80211 callbacks are concerned.
>> Year I hear you, so there are two things I think we can do in the long
>> run to bring in mac80211 helpers together. The first one is to remove
>> the ath9k wiphy. The second is to use a threaded ISR and change our
>> bottom halves to use a workqueue instead of a tasklet so we can also
>> sleep during our work. I think these two things should enable us to
>> start sharing some callbacks. But ath9k virtual wiphy seems to provide
>> some functionality we don't yet have in mac80211/cfg80211 centrally
>> but we could work on that.
>
> My vote is to keep the drivers separate.
You would be more familiar with the commonality between ath9k and
ath9k_htc at this point. Even though the two drivers are separate
right now, say we did remove the ath9k virtual wiphy, is there a set
of mac80211 callbacks we can start sharing?
My motivation for sharing more callbacks comes from the eventual goal
to support multiple virtual interfaces on the same radio each on a
separate channel. The complexity of the drivers increase so it seems
there is value in trying to reach more common ground.
Luis
On Mon, Mar 1, 2010 at 8:17 PM, Sujith <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>> Interesting approach, instead of having two modules you linked lib.o
>> twice to two separate modules, ath9k.ko and ath9k_htc.ko. While this
>> does reduce module proliferation is there any advantage to that over
>> the approach of stuffing these into one common module shared between
>> both?
>>
>> The benefit of doing it as a module is if both are built-in you reduce
>> the final kernel size. On my box with debugging this is 256 KB.
>
> The built-in case would be mostly useful in embedded systems (SoC etc ..).
> And it is likely to be either ath9k or ath9k_htc. I don't think that
> both family of chipsets can exist simultaneously.
ChromeOs builds everything as built-in so in that case you will have
both eventually enabled.
> And since the code that is shared is very minimal (a few general routines and crypto),
> it felt reasonable to just stuff into a common library.
Although it may be a few common helpers it could grow to share common
mac80211 helpers. After all, there are a few calls which could simply
be shared.
Luis