* Re: [ath5k-devel] [PATCH v3] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-07-28 23:48 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, David Quan, Luis R. Rodriguez,
linux-kernel, kernel-team@lists.ubuntu.com, Luis Rodriguez,
Jussi Kivilinna, tim.gardner@canonical.com
In-Reply-To: <AANLkTim1sZ5ZoGcrsdCw8dFSzUj4igZOiq7irKsdbfXR@mail.gmail.com>
On Tue, 2010-07-27 at 08:57 -0700, Luis R. Rodriguez wrote:
> On Tue, Jul 27, 2010 at 2:35 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > On Mon, 2010-07-26 at 23:50 +0100, Matthew Garrett wrote:
> >> On Mon, Jul 26, 2010 at 03:43:04PM -0700, Luis R. Rodriguez wrote:
> >>
> >> > I see.. thanks Mathew... in that case since L1 works on all devices we
> >> > could just force enable L1 for all PCIE devices. What do you think?
> >>
> >> Works for me.
> >>
> >
> > On the second thought, there is no 'pci_enable_link_state' :-)
> > I afraid that if I add it, I might not do that right for all cases, thus
> > do more harm that good...
>
> I'm sorry, can you elaborate?
I mean ASPM code doesn't have a function to undo effects of the
blacklist (due to pre 1.1 pcie device).
Its not that simple to write such function.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v3] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-07-29 0:06 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Matthew Garrett, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, David Quan, Luis R. Rodriguez,
linux-kernel, kernel-team@lists.ubuntu.com, Luis Rodriguez,
Jussi Kivilinna, tim.gardner@canonical.com
In-Reply-To: <1280360895.8891.19.camel@maxim-laptop>
On Wed, Jul 28, 2010 at 4:48 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Tue, 2010-07-27 at 08:57 -0700, Luis R. Rodriguez wrote:
>> On Tue, Jul 27, 2010 at 2:35 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> > On Mon, 2010-07-26 at 23:50 +0100, Matthew Garrett wrote:
>> >> On Mon, Jul 26, 2010 at 03:43:04PM -0700, Luis R. Rodriguez wrote:
>> >>
>> >> > I see.. thanks Mathew... in that case since L1 works on all devices we
>> >> > could just force enable L1 for all PCIE devices. What do you think?
>> >>
>> >> Works for me.
>> >>
>> >
>> > On the second thought, there is no 'pci_enable_link_state' :-)
>> > I afraid that if I add it, I might not do that right for all cases, thus
>> > do more harm that good...
>>
>> I'm sorry, can you elaborate?
>
> I mean ASPM code doesn't have a function to undo effects of the
> blacklist (due to pre 1.1 pcie device).
>
> Its not that simple to write such function.
Ah good catch... pcie_aspm_sanity_check() will actually be used to
adjust the device link capability... So even if we do try to insist it
wouldn't work. I'm happy if we deal with this separately, its a
reasonable compromise to fix issues with existing devices out there.
Luis
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-07-29 0:10 UTC (permalink / raw)
To: Felix Fietkau
Cc: Luis Rodriguez, Bruno Randolf, johannes@sipsolutions.net,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <4C50A9B9.5070708@openwrt.org>
On Wed, Jul 28, 2010 at 03:05:45PM -0700, Felix Fietkau wrote:
> On 2010-07-28 11:39 PM, Luis R. Rodriguez wrote:
> > On Wed, Jul 28, 2010 at 02:26:35PM -0700, Felix Fietkau wrote:
> >> We don't need any special case handling for this at all. Drivers already
> >> calculate their HT capabilities based on the number of available chains.
> >> Once the antenna selection stuff is actually used, they will have some
> >> internal information about which chains have how many antennas.
> >>
> >> The reason why we can ignore *all* of this stuff for the API is simple:
> >> We only need to refactor the code to calculate these settings based on
> >> effective chainmask / antenna mask instead of pure hardware capability.
> >>
> >> The effective chainmask / antenna mask is basically the same as the
> >> hardware settings, except that it gets masked with the values that are
> >> configured through this API. That leaves us with something that's easy
> >> to configure, easy to implement for drivers, and doesn't need special
> >> case stuff for various 802.11n features.
> >
> > Consider the case of an already associated STA in 3x3 mode, and someone
> > uses this API to limit it to a 1 stream 1x1 chaimask setting using
> > only one antenna. How would the AP find out about this RX setting
> > from the STA? Are we going to deny mucking with this prior to association?
> > What about if you're the AP?
> >
> > If you are using STBC and the user tunes the device to 1 stream 1x1 chainmask
> > settings, who deals with the required adaptations?
> I think we should simply not accept runtime modifications of this stuff.
> The user should bring down the interface, change the value, then bring
> it back up again. That allows the driver to recalculate all the HT stuff
> based on the updated chainmask/antenna mask without special cases.
Works with me.
Would we keep two values for some of these settings, an "actual hw"
capablity and then also a "configured" values? Would this be exposed
and visible through iw?
Luis
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-07-29 2:11 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Felix Fietkau, johannes, linville, linux-wireless
In-Reply-To: <AANLkTimBu2=9XhzKwUi1ZpRmGWA+C4GCDgXqp-YJVLxt@mail.gmail.com>
On Thu July 29 2010 02:24:46 Luis R. Rodriguez wrote:
> So if you want to define an API I do believe its best to treat these
> separately, for legacy I think your API can be fine tuned to consider
> FIXED_A, FIXED_B, or DIVERSITY.
hi luis,
i already tried to explain several times why FIXED_A, FIXED_B, or DIVERSITY is
not enough even for "legacy". please re-read the mails and the description of
the first patch - i really don't want to re-iterate it *again*. thanks :)
as felix pointed out, it's best to think of this as the antenna mask, which
can be used to mask out antennas which are not attached or should not be used.
it does not matter if the device is "legacy" or 802.11n or "802.11xyz" - we
can always use this API to inform mac80211 / the driver about the available
antennas if they are in fact different from the default HW settings. based on
this information 802.11n drivers can derive which chainmasks to use, and in
some cases wether diversity should be used; "legacy" drivers can derive wether
to use diversity or not.
actually thinking about it like this, i would like to remove the special
casing of "0" for tx diversity (which means go back to my original proposal):
if an antenna can be used for TX it should be set to one in the mask, and the
driver can enable diversity or mulitple chainmasks as suitable.
> Would we keep two values for some of these settings, an "actual hw"
> capablity and then also a "configured" values? Would this be exposed
> and visible through iw?
the actual HW capability could be exported via the wiphy info as well, but i
think this could be dealt with in a seperate patch, as well as other
improvements. for now let's just define an API for an antenna mask, which can
be used to mask out antennas seperately for RX and TX.
i'll try to make that more clear in the descriptions and re-send my proposal.
bruno
^ permalink raw reply
* Re: [PATCH] cfg80211: fix dev <-> wiphy typo
From: Joe Perches @ 2010-07-29 2:40 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John W. Linville
In-Reply-To: <201007290128.46773.chunkeey@googlemail.com>
On Thu, 2010-07-29 at 01:28 +0200, Christian Lamparter wrote:
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ae80f8f..2fd06c6 100644
> - dynamic_pr_debug("%s: " format, wiphy_name(dev), ##args)
> + dynamic_pr_debug("%s: " format, wiphy_name(wiphy), ##args)
Thanks for noticing that Christian.
^ permalink raw reply
* Re: [PATCH 2/2] iw: Add antenna configuration commands
From: Bruno Randolf @ 2010-07-29 3:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <201007281729.38652.br1@einfach.org>
On Wed July 28 2010 17:29:38 Bruno Randolf wrote:
> On Wed July 28 2010 15:50:48 Johannes Berg wrote:
> > On Wed, 2010-07-28 at 11:07 +0900, Bruno Randolf wrote:
> > > On Tue July 27 2010 19:04:21 Johannes Berg wrote:
> > > > On Tue, 2010-07-27 at 18:49 +0900, Bruno Randolf wrote:
> > > > > + if (tb_msg[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
> > > > > + tb_msg[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
> > > > > + printf("\tAntenna: TX %d RX %d\n",
> > > > > + nla_get_u8(tb_msg[NL80211_ATTR_WIPHY_ANTENNA_TX]),
> > > > > + nla_get_u8(tb_msg[NL80211_ATTR_WIPHY_ANTENNA_RX]));
> > > >
> > > > That's like the worst possible way to show the info.
> > >
> > > which way would you prefer?
> >
> > It occurred to me later that with the normal numbers we have (1 through
> > 7) it won't matter much ... but still, I'd prefer %#x.
>
> ok. changed that...
actually - no. what sense does it make to use a hexadecimal notation and print
0x for values between 0 and 7?
bruno
^ permalink raw reply
* [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-07-29 3:58 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, mcgrof, linux-wireless
Allow setting of TX and RX antenna configuration via nl80211.
The antenna configuration is defined as a bitmap of allowed antennas to use.
This API can be used to mask out antennas which are not attached or should not
be used for other reasons like regulatory concerns or special setups.
Separate bitmaps are used for RX and TX to allow configuring different antennas
for receiving and transmitting. The bitmap is 8 bit long, each bit representing
one antenna, starting with antenna 1 at the first bit. If an antenna bit is
set, this means the driver is allowed to use this antenna for RX or TX
respectively; if the bit is not set the hardware is not allowed to use this
antenna.
Using bitmaps has the benefit of allowing for a flexible configuration
interface which can support many different configurations and which can be used
for 802.11n as well as non-802.11n devices. Instead of relying on some hardware
specific assumptions, drivers can use this information to know which antennas
are actually attached to the system and derive their capabilities based on
that.
802.11n devices should enable or disable chains, based on which antennas are
present (If all antennas belonging to a particular chain are disabled, the
entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
Antenna selection) should be calculated based on the available chains after
applying the antenna masks. Should a 802.11n device have diversity antennas
attached to one of their chains, diversity can be enabled or disabled based on
the antenna information.
Non-802.11n drivers can use the antenna masks to enable or disable antenna
diversity.
While covering chainmasks for 802.11n and the standard "legacy" modes "fixed
antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare,
but useful configurations as follows:
1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
have a low gain antenna for TX in order to keep within the regulatory
constraints and a high gain antenna for RX in order to receive weaker signals
("speak softly, but listen harder"). This can be useful for building long-shot
outdoor links. Another usage of this setup is having a low-noise pre-amplifier
on antenna 1 and a power amplifier on the other antenna. This way transmit
noise is mostly kept out of the low noise receive channel.
(This would be bitmaps: tx 1 rx 2).
2) Another similar setup is: Use RX diversity on both antennas, but always send
on antenna 1. Again that would allow us to benefit from a higher gain RX
antenna, while staying within the legal limits.
(This would be: tx 0 rx 3).
3) And finally there can be special experimental setups in research and
development even with pre 802.11n hardware where more than 2 antennas are
available. It's good to keep the API simple, yet flexible.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
v5: Removed the special casing of "0" for diversity. I hope i made the
descriptions more clear and incorportated all comments concerning 802.11n. If
we can agree on this i will re-send the whole series.
---
include/linux/nl80211.h | 25 +++++++++++++++++++++++++
include/net/cfg80211.h | 3 +++
net/wireless/nl80211.c | 30 +++++++++++++++++++++++++++++-
3 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 2c87016..8a88921 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -731,6 +731,28 @@ enum nl80211_commands {
* This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
* for non-automatic settings.
*
+ * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for transmitting.
+ * This can be used to mask out antennas which are not attached or should
+ * not be used for transmitting. If an antenna is not selected in this
+ * bitmap the hardware is not allowed to transmit on this antenna.
+ *
+ * Each bit represents one antenna, starting with antenna 1 at the first
+ * bit. Depending on which antennas are selected in the bitmap, 802.11n
+ * drivers can derive which chainmasks to use (if all antennas belonging to
+ * a particular chain are disabled this chain should be disabled) and if
+ * a chain has diversity antennas wether diversity should be used or not.
+ * HT capabilities (STBC, TX Beamforming, Antenna selection) can be
+ * derived from the available chains after applying the antenna mask.
+ * Non-802.11n drivers can derive wether to use diversity or not.
+ * Drivers may reject configurations or RX/TX mask combinations they cannot
+ * support by returning -EINVAL.
+ *
+ * @NL80211_ATTR_WIPHY_ANTENNA_RX: Bitmap of allowed antennas for receiving.
+ * This can be used to mask out antennas which are not attached or should
+ * not be used for receiving. If an antenna is not selected in this bitmap
+ * the hardware should not be configured to receive on this antenna.
+ * For a more detailed descripton see @NL80211_ATTR_WIPHY_ANTENNA_TX.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -891,6 +913,9 @@ enum nl80211_attrs {
NL80211_ATTR_WIPHY_TX_POWER_SETTING,
NL80211_ATTR_WIPHY_TX_POWER_LEVEL,
+ NL80211_ATTR_WIPHY_ANTENNA_TX,
+ NL80211_ATTR_WIPHY_ANTENNA_RX,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f68ae54..7dc0e8d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1184,6 +1184,9 @@ struct cfg80211_ops {
int (*set_cqm_rssi_config)(struct wiphy *wiphy,
struct net_device *dev,
s32 rssi_thold, u32 rssi_hyst);
+
+ int (*set_antenna)(struct wiphy *wiphy, u8 tx_ant, u8 rx_ant);
+ int (*get_antenna)(struct wiphy *wiphy, u8 *tx_ant, u8 *rx_ant);
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cea595e..62fc5fe 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -156,6 +156,9 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_WIPHY_TX_POWER_SETTING] = { .type = NLA_U32 },
[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] = { .type = NLA_U32 },
+
+ [NL80211_ATTR_WIPHY_ANTENNA_TX] = { .type = NLA_U8 },
+ [NL80211_ATTR_WIPHY_ANTENNA_RX] = { .type = NLA_U8 },
};
/* policy for the attributes */
@@ -458,7 +461,6 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
dev->wiphy.rts_threshold);
NLA_PUT_U8(msg, NL80211_ATTR_WIPHY_COVERAGE_CLASS,
dev->wiphy.coverage_class);
-
NLA_PUT_U8(msg, NL80211_ATTR_MAX_NUM_SCAN_SSIDS,
dev->wiphy.max_scan_ssids);
NLA_PUT_U16(msg, NL80211_ATTR_MAX_SCAN_IE_LEN,
@@ -471,6 +473,16 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
NLA_PUT_U8(msg, NL80211_ATTR_MAX_NUM_PMKIDS,
dev->wiphy.max_num_pmkids);
+ if (dev->ops->get_antenna) {
+ u8 tx_ant = 0, rx_ant = 0;
+ int res;
+ res = dev->ops->get_antenna(&dev->wiphy, &tx_ant, &rx_ant);
+ if (!res) {
+ NLA_PUT_U8(msg, NL80211_ATTR_WIPHY_ANTENNA_TX, tx_ant);
+ NLA_PUT_U8(msg, NL80211_ATTR_WIPHY_ANTENNA_RX, rx_ant);
+ }
+ }
+
nl_modes = nla_nest_start(msg, NL80211_ATTR_SUPPORTED_IFTYPES);
if (!nl_modes)
goto nla_put_failure;
@@ -900,6 +912,22 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
goto bad_res;
}
+ if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
+ info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
+ u8 tx_ant, rx_ant;
+ if (!rdev->ops->set_antenna) {
+ result = -EOPNOTSUPP;
+ goto bad_res;
+ }
+
+ tx_ant = nla_get_u8(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX]);
+ rx_ant = nla_get_u8(info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]);
+
+ result = rdev->ops->set_antenna(&rdev->wiphy, tx_ant, rx_ant);
+ if (result)
+ goto bad_res;
+ }
+
changed = 0;
if (info->attrs[NL80211_ATTR_WIPHY_RETRY_SHORT]) {
^ permalink raw reply related
* Re: [PATCH] wl1271: add get_survey callback in order to get channel noise
From: Juuso Oikarinen @ 2010-07-29 5:00 UTC (permalink / raw)
To: ext John W. Linville
Cc: linux-wireless@vger.kernel.org,
Coelho Luciano (Nokia-MS/Helsinki)
In-Reply-To: <1280349740-26973-1-git-send-email-linville@tuxdriver.com>
On Wed, 2010-07-28 at 22:42 +0200, ext John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/wl12xx/wl1271.h | 3 +++
> drivers/net/wireless/wl12xx/wl1271_main.c | 17 +++++++++++++++++
> drivers/net/wireless/wl12xx/wl1271_rx.c | 7 +++++++
> 3 files changed, 27 insertions(+), 0 deletions(-)
>
I was thinking about the algorithm to get the noise, but then noticed
Kalle Valo's comment for wl1251. Pretty much the same applies here.
Acked-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
-Juuso
^ permalink raw reply
* Re: [PATCH] wl1271: update hw/fw version info in wiphy struct
From: Juuso Oikarinen @ 2010-07-29 5:01 UTC (permalink / raw)
To: ext John W. Linville
Cc: linux-wireless@vger.kernel.org,
Coelho Luciano (Nokia-MS/Helsinki)
In-Reply-To: <1280351443-28535-1-git-send-email-linville@tuxdriver.com>
On Wed, 2010-07-28 at 23:10 +0200, ext John W. Linville wrote:
> This makes the information available through ethtool...
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/wl12xx/wl1271_main.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
> index 374abf0..9d68f00 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_main.c
> +++ b/drivers/net/wireless/wl12xx/wl1271_main.c
> @@ -839,6 +839,7 @@ static int wl1271_op_add_interface(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif)
> {
> struct wl1271 *wl = hw->priv;
> + struct wiphy *wiphy = hw->wiphy;
> int retries = WL1271_BOOT_RETRIES;
> int ret = 0;
>
> @@ -892,6 +893,12 @@ static int wl1271_op_add_interface(struct ieee80211_hw *hw,
>
> wl->state = WL1271_STATE_ON;
> wl1271_info("firmware booted (%s)", wl->chip.fw_ver);
> +
> + /* update hw/fw version info in wiphy struct */
> + wiphy->hw_version = wl->chip.id;
> + strncpy(wiphy->fw_version, wl->chip.fw_ver,
> + sizeof(wiphy->fw_version));
> +
> goto out;
>
> irq_disable:
Acked-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
-Juuso
^ permalink raw reply
* Re: [PATCH] wl1251: update hw/fw version info in wiphy struct
From: Kalle Valo @ 2010-07-29 5:54 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1280351265-27791-1-git-send-email-linville@tuxdriver.com>
On 07/29/2010 12:07 AM, John W. Linville wrote:
> This makes the information available through ethtool...
Thanks, looks good.
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
^ permalink raw reply
* Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen @ 2010-07-29 6:00 UTC (permalink / raw)
To: Vitaly Wool
Cc: linux-wireless, linux-mmc, linux-omap, Kalle Valo, Pandita Vikram,
linux, Nicolas Pitre, Tony Lindgren, Roger Quadros, San Mehat,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
linux-arm-kernel
In-Reply-To: <AANLkTimzA_JJ-byTDWznbL3YzeJ8LAP4M50onf2_3fBF@mail.gmail.com>
Hi Vitaly,
On Wed, Jul 28, 2010 at 10:47 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> On Wed, Jul 21, 2010 at 7:33 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> Add support to set/get mmc_host private embedded
>> data.
>>
>> This is needed to allow software to dynamically
>> create (and remove) SDIO functions which represents
>> embedded SDIO devices.
>>
> <snip>
>> @@ -209,6 +209,8 @@ struct mmc_host {
>> struct led_trigger *led; /* activity led */
>> #endif
>>
>> + void *embedded_data;
>> +
>
> To my understanding, this data doesn't belong to mmc_host. It's not a
> host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's
> totally unrelated to host.
>
> I think a cleaner way would be to introduce something similar to what
> we have for SPI, e. g. struct sdio_board_info. This board info will
> contain platform-specific stuff and vendor id/chip id for each onboard
> SDIO device. Then the SDIO core will pick up the appropriate data
> basing on vendor id/chip id.
Can you please elaborate some more about your proposal (specifically
where does this sdio_board_info get set and how do function drivers
access it) ?
If I understand you correctly, you suggest to have a global,
board-specific table of sdio_board_info structures, which would be
accessible to the SDIO core (through the host driver ?). When a new
SDIO device is found the core would search this table for the
appropriate sdio_board_info struct and make it accessible to the SDIO
function driver ?
Thanks,
Ohad.
>
> ~Vitaly
>
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-07-29 6:12 UTC (permalink / raw)
To: Bruno Randolf; +Cc: johannes, linville, nbd, linux-wireless
In-Reply-To: <20100729035820.5930.29864.stgit@tt-desk>
On Wed, Jul 28, 2010 at 8:58 PM, Bruno Randolf <br1@einfach.org> wrote:
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index 2c87016..8a88921 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -731,6 +731,28 @@ enum nl80211_commands {
> * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
> * for non-automatic settings.
> *
> + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for transmitting.
> + * This can be used to mask out antennas which are not attached or should
> + * not be used for transmitting. If an antenna is not selected in this
> + * bitmap the hardware is not allowed to transmit on this antenna.
> + *
> + * Each bit represents one antenna, starting with antenna 1 at the first
> + * bit. Depending on which antennas are selected in the bitmap, 802.11n
> + * drivers can derive which chainmasks to use (if all antennas belonging to
> + * a particular chain are disabled this chain should be disabled) and if
> + * a chain has diversity antennas wether diversity should be used or not.
> + * HT capabilities (STBC, TX Beamforming, Antenna selection) can be
> + * derived from the available chains after applying the antenna mask.
I don't want to do any work myself on drivers for this, can we have
cfg80211/mac80211 do this for us?
Luis
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Johannes Berg @ 2010-07-29 7:48 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, linville, nbd, linux-wireless
In-Reply-To: <AANLkTika8nD5oEXt-nHx7BHzZzCK1i8VQ9b-ubmcMze+@mail.gmail.com>
On Wed, 2010-07-28 at 23:12 -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 8:58 PM, Bruno Randolf <br1@einfach.org> wrote:
> > diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> > index 2c87016..8a88921 100644
> > --- a/include/linux/nl80211.h
> > +++ b/include/linux/nl80211.h
> > @@ -731,6 +731,28 @@ enum nl80211_commands {
> > * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
> > * for non-automatic settings.
> > *
> > + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for transmitting.
> > + * This can be used to mask out antennas which are not attached or should
> > + * not be used for transmitting. If an antenna is not selected in this
> > + * bitmap the hardware is not allowed to transmit on this antenna.
> > + *
> > + * Each bit represents one antenna, starting with antenna 1 at the first
> > + * bit. Depending on which antennas are selected in the bitmap, 802.11n
> > + * drivers can derive which chainmasks to use (if all antennas belonging to
> > + * a particular chain are disabled this chain should be disabled) and if
> > + * a chain has diversity antennas wether diversity should be used or not.
> > + * HT capabilities (STBC, TX Beamforming, Antenna selection) can be
> > + * derived from the available chains after applying the antenna mask.
>
> I don't want to do any work myself on drivers for this, can we have
> cfg80211/mac80211 do this for us?
Also, this is a serious issue when you want to support this call -- it
may not be done while you're associated since you cannot change those
things properly then.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] iw: Add antenna configuration commands
From: Johannes Berg @ 2010-07-29 7:49 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, linux-wireless
In-Reply-To: <201007291235.11202.br1@einfach.org>
On Thu, 2010-07-29 at 12:35 +0900, Bruno Randolf wrote:
> actually - no. what sense does it make to use a hexadecimal notation and print
> 0x for values between 0 and 7?
Well ... 11n does define mimo 4x4.
johannes
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-07-29 9:12 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: johannes, linville, nbd, linux-wireless
In-Reply-To: <AANLkTika8nD5oEXt-nHx7BHzZzCK1i8VQ9b-ubmcMze+@mail.gmail.com>
On Thu July 29 2010 15:12:29 you wrote:
> On Wed, Jul 28, 2010 at 8:58 PM, Bruno Randolf <br1@einfach.org> wrote:
> > diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> > index 2c87016..8a88921 100644
> > --- a/include/linux/nl80211.h
> > +++ b/include/linux/nl80211.h
> > @@ -731,6 +731,28 @@ enum nl80211_commands {
> > * This is used in association with
> > @NL80211_ATTR_WIPHY_TX_POWER_SETTING * for non-automatic settings.
> > *
> > + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for
> > transmitting. + * This can be used to mask out antennas which are
> > not attached or should + * not be used for transmitting. If an
> > antenna is not selected in this + * bitmap the hardware is not
> > allowed to transmit on this antenna. + *
> > + * Each bit represents one antenna, starting with antenna 1 at the
> > first + * bit. Depending on which antennas are selected in the
> > bitmap, 802.11n + * drivers can derive which chainmasks to use (if
> > all antennas belonging to + * a particular chain are disabled this
> > chain should be disabled) and if + * a chain has diversity antennas
> > wether diversity should be used or not. + * HT capabilities (STBC,
> > TX Beamforming, Antenna selection) can be + * derived from the
> > available chains after applying the antenna mask.
>
> I don't want to do any work myself on drivers for this, can we have
> cfg80211/mac80211 do this for us?
is this not a separate issue from defining the API? you could have it do this
for you even now, with or without the antenna API, no?
i think this should be dealt with seperately. for now let's just define an API
for an antenna mask.
bruno
^ permalink raw reply
* Re: [PATCH 2/2] iw: Add antenna configuration commands
From: Bruno Randolf @ 2010-07-29 9:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1280389745.3823.1.camel@jlt3.sipsolutions.net>
On Thu July 29 2010 16:49:05 Johannes Berg wrote:
> On Thu, 2010-07-29 at 12:35 +0900, Bruno Randolf wrote:
> > actually - no. what sense does it make to use a hexadecimal notation and
> > print 0x for values between 0 and 7?
>
> Well ... 11n does define mimo 4x4.
oh, yes, true: 0xf
bruno
^ permalink raw reply
* Re: [ath9k-devel] ath9k mesh point not emitting beacons
From: Luis R. Rodriguez @ 2010-07-29 7:50 UTC (permalink / raw)
To: Abhijeet Chandran, linux-wireless, Javier Cardona
Cc: ath9k-devel@lists.ath9k.org, Srivatsan Raghavan, Poonam2 Gupta,
Manish Aggarwal, Nikhil Bhatia, Saurabh8 Jain
In-Reply-To: <CCA4ADC4C95A2D478B0D44E203C7370F136BF13F27@GUREXMB02.ASIAN.AD.ARICENT.COM>
On Wed, Jul 28, 2010 at 11:50 PM, Abhijeet Chandran
<Abhijeet.Chandran@aricent.com> wrote:
>
> Hi Luis
>
> Thanks for the link . But our real problem is that the mesh interface that we are creating using iw is not behaving like a mesh point but rather like a wifi station. I have the following observations:
>
> 1. iw phy phy0 interface add mesh0 type mp mesh_id mymesh
>
> .ieee80211_open is called in mac80211 for interface mesh0 with type NL80211_IFTYPE_MESH_POINT
> .Ath9k driver attaches an interface of type NL80211_IFTYPE_MESH_POINT
> .ieee80211_stop is called in mac80211 for interface mesh0 with type NL80211_IFTYPE_MESH_POINT
> .Ath9k driver detached the interface of type NL80211_IFTYPE_MESH_POINT
> .The sdata for the interface mesh0 is flushed in mac80211.
> .ieee80211_open is called in mac80211 for interface mesh0 with type NL80211_IFTYPE_STATION
> .Ath9k driver attaches an interface of type NL80211_IFTYPE_STATION .
>
> From this point on the interface behaves like a wifi station and not as a mesh point. We have not yet figured out why the mesh interface is removed and reset to an interface of type NL80211_IFTYPE_STATION.
Javier would be the best person to review this.
Luis
> Regards
> Abhijeet
>
> -----Original Message-----
> From: Luis R. Rodriguez [mailto:mcgrof@gmail.com]
> Sent: Wednesday, July 28, 2010 9:23 PM
> To: Abhijeet Chandran
> Cc: ath9k-devel@lists.ath9k.org
> Subject: Re: [ath9k-devel] ath9k mesh point not emitting beacons
>
> On Wed, Jul 28, 2010 at 7:19 AM, Abhijeet Chandran <Abhijeet.Chandran@aricent.com> wrote:
>> Hi
>> We have a problem that we have configured a mesh point for the first
>> time and it does not seem to start emitting beacons as soon as it comes up.
>> The card we are using is ath 9220
>> We brought mesh point up , ex:
>> # iw phy phy0 interface add mesh type mp mesh_id mymesh # ifconfig
>> mesh up
>>
>> Through tracing in the kernel module mac80211 it appears that a
>> callback function ieee80211_open is called with type mesh point as
>> soon as the above commands are executed.
>> However it is immediately followed by the callback function
>> ieee80211_stop (usually called when the mesh point is brought down) ,
>> following which the meshpoint related sdata is flushed .
>> Another question that we have is that do we need to enable scanning
>> for the mesh point to emit beacons/probes?
>>
>> We have used the simulator mac80211_hwsim before in which beacons are
>> emitted as soon as the mesh point comes up.In the simulator don't need
>> to start scanning on the mesh point.
>> We'd really appreciate if somone can help us out here.
>
> Known issue no one has yet looked into:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=14187
>
> It should start beaconing if you issue a scan.
>
> Luis
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
>
^ permalink raw reply
* [PATCH] iwlwifi: fix scan abort
From: Stanislaw Gruszka @ 2010-07-29 9:37 UTC (permalink / raw)
To: Wey-Yi Guy, Reinette Chatre, John W. Linville; +Cc: linux-wireless, stable
Fix possible double priv->mutex lock introduced by commit
a69b03e941abae00380fc6bc1877fb797a1b31e6
"iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
We can not call cancel_delayed_work_sync(&priv->scan_check) with
priv->mutex locked because workqueue function iwl_bg_scan_check()
take that lock internally.
We do not need to synchronize when canceling priv->scan_check work.
We can avoid races (sending double abort command or send no
command at all) using STATUS_SCAN_ABORT bit. Moreover
current iwl_bg_scan_check() code seems to be broken, as
we should not send abort commands when currently aborting.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
CC: stable@kernel.org
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index 2a7c399..b0c6b04 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -429,11 +429,10 @@ void iwl_bg_scan_check(struct work_struct *data)
return;
mutex_lock(&priv->mutex);
- if (test_bit(STATUS_SCANNING, &priv->status) ||
- test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
- IWL_DEBUG_SCAN(priv, "Scan completion watchdog resetting "
- "adapter (%dms)\n",
- jiffies_to_msecs(IWL_SCAN_CHECK_WATCHDOG));
+ if (test_bit(STATUS_SCANNING, &priv->status) &&
+ !test_bit(STATUS_SCAN_ABORTING, &priv->status)) {
+ IWL_DEBUG_SCAN(priv, "Scan completion watchdog (%dms)\n",
+ jiffies_to_msecs(IWL_SCAN_CHECK_WATCHDOG));
if (!test_bit(STATUS_EXIT_PENDING, &priv->status))
iwl_send_scan_abort(priv);
@@ -498,12 +497,11 @@ void iwl_bg_abort_scan(struct work_struct *work)
!test_bit(STATUS_GEO_CONFIGURED, &priv->status))
return;
- mutex_lock(&priv->mutex);
-
- cancel_delayed_work_sync(&priv->scan_check);
- set_bit(STATUS_SCAN_ABORTING, &priv->status);
- iwl_send_scan_abort(priv);
+ cancel_delayed_work(&priv->scan_check);
+ mutex_lock(&priv->mutex);
+ if (test_bit(STATUS_SCAN_ABORTING, &priv->status))
+ iwl_send_scan_abort(priv);
mutex_unlock(&priv->mutex);
}
EXPORT_SYMBOL(iwl_bg_abort_scan);
^ permalink raw reply related
* [RFC] mac80211: remove IEEE80211_HW_SPECTRUM_MGMT
From: Johannes Berg @ 2010-07-29 10:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Tomas Winkler, Assaf Krauss
The IEEE80211_HW_SPECTRUM_MGMT hardware flag is
not really useful, since drivers need to add it
to get CSA support. The documentation states that
drivers should set it when they support 802.11h
measurement, channel switching, quieting and TPC.
Some drivers set the flag without supporting TPC,
for example ath9k_htc. Measurements are not done
at all, and quieting is also not supported. All
this hasn't stopped us from claiming we have the
necessary spectrum management implemented. But
the flag itself is pretty useless, so remove it.
Maybe we should have separate flags for "will honour
power_level" and actually implement quieting/measurement,
but right now I think this patch makes sense?
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 -
drivers/net/wireless/ath/ath9k/init.c | 1 -
drivers/net/wireless/iwlwifi/iwl-agn.c | 3 +--
drivers/net/wireless/iwlwifi/iwl3945-base.c | 3 +--
include/net/mac80211.h | 5 -----
net/mac80211/work.c | 3 +--
6 files changed, 3 insertions(+), 13 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/htc_drv_init.c 2010-07-29 11:57:47.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath/ath9k/htc_drv_init.c 2010-07-29 11:57:50.000000000 +0200
@@ -692,7 +692,6 @@ static void ath9k_set_hw_capab(struct at
hw->flags = IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_AMPDU_AGGREGATION |
- IEEE80211_HW_SPECTRUM_MGMT |
IEEE80211_HW_HAS_RATE_CONTROL |
IEEE80211_HW_RX_INCLUDES_FCS |
IEEE80211_HW_SUPPORTS_PS |
--- wireless-testing.orig/drivers/net/wireless/ath/ath9k/init.c 2010-07-29 11:57:47.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath/ath9k/init.c 2010-07-29 11:57:52.000000000 +0200
@@ -626,7 +626,6 @@ void ath9k_set_hw_capab(struct ath_softc
IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK |
- IEEE80211_HW_SPECTRUM_MGMT |
IEEE80211_HW_REPORTS_TX_ACK_STATUS;
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-agn.c 2010-07-29 11:57:47.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-agn.c 2010-07-29 11:57:57.000000000 +0200
@@ -3184,8 +3184,7 @@ static int iwl_mac_setup_register(struct
/* Tell mac80211 our characteristics */
hw->flags = IEEE80211_HW_SIGNAL_DBM |
- IEEE80211_HW_AMPDU_AGGREGATION |
- IEEE80211_HW_SPECTRUM_MGMT;
+ IEEE80211_HW_AMPDU_AGGREGATION;
if (!priv->cfg->broken_powersave)
hw->flags |= IEEE80211_HW_SUPPORTS_PS |
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl3945-base.c 2010-07-29 11:57:47.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl3945-base.c 2010-07-29 11:58:03.000000000 +0200
@@ -3879,8 +3879,7 @@ static int iwl3945_setup_mac(struct iwl_
hw->vif_data_size = sizeof(struct iwl_vif_priv);
/* Tell mac80211 our characteristics */
- hw->flags = IEEE80211_HW_SIGNAL_DBM |
- IEEE80211_HW_SPECTRUM_MGMT;
+ hw->flags = IEEE80211_HW_SIGNAL_DBM;
if (!priv->cfg->broken_powersave)
hw->flags |= IEEE80211_HW_SUPPORTS_PS |
--- wireless-testing.orig/include/net/mac80211.h 2010-07-29 11:57:47.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-07-29 11:58:27.000000000 +0200
@@ -985,10 +985,6 @@ enum ieee80211_tkip_key_type {
* one milliwatt. This is the preferred method since it is standardized
* between different devices. @max_signal does not need to be set.
*
- * @IEEE80211_HW_SPECTRUM_MGMT:
- * Hardware supports spectrum management defined in 802.11h
- * Measurement, Channel Switch, Quieting, TPC
- *
* @IEEE80211_HW_AMPDU_AGGREGATION:
* Hardware supports 11n A-MPDU aggregation.
*
@@ -1049,7 +1045,6 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SIGNAL_UNSPEC = 1<<5,
IEEE80211_HW_SIGNAL_DBM = 1<<6,
/* use this hole */
- IEEE80211_HW_SPECTRUM_MGMT = 1<<8,
IEEE80211_HW_AMPDU_AGGREGATION = 1<<9,
IEEE80211_HW_SUPPORTS_PS = 1<<10,
IEEE80211_HW_PS_NULLFUNC_STACK = 1<<11,
--- wireless-testing.orig/net/mac80211/work.c 2010-07-29 11:57:47.000000000 +0200
+++ wireless-testing/net/mac80211/work.c 2010-07-29 11:58:35.000000000 +0200
@@ -263,8 +263,7 @@ static void ieee80211_send_assoc(struct
if (wk->assoc.capability & WLAN_CAPABILITY_PRIVACY)
capab |= WLAN_CAPABILITY_PRIVACY;
- if ((wk->assoc.capability & WLAN_CAPABILITY_SPECTRUM_MGMT) &&
- (local->hw.flags & IEEE80211_HW_SPECTRUM_MGMT))
+ if (wk->assoc.capability & WLAN_CAPABILITY_SPECTRUM_MGMT)
capab |= WLAN_CAPABILITY_SPECTRUM_MGMT;
mgmt = (struct ieee80211_mgmt *) skb_put(skb, 24);
^ permalink raw reply
* MX27 libertas_sdio SDIO Interrupts vs available bitrate
From: Andreas Feuersinger @ 2010-07-29 10:46 UTC (permalink / raw)
To: libertas-dev, linux-mmc, linux-wireless
Hi,
I'm trying to improve throughput of the Marvell 8686 sdio wlan module.
Unfortunately I have to stick with kernel 2.6.22.
Everything works except for very bad datarate. So far the mxc_mmc
driver does not handle any SDIO interrupts. Could that be the reason
for the bad performance?
I figured, it does not make any difference wheter I use DMA for data
transfer or not (odd?)
I get only up to 90K/s.
thanks!
Andreas
^ permalink raw reply
* WARNING: at net/wireless/mlme.c:47 cfg80211_send_rx_auth+0x8a/0x130
From: Sitsofe Wheeler @ 2010-07-29 10:51 UTC (permalink / raw)
To: linux-wireless
Hi,
Over the past 6 months or so I sometimes see warn on slowpath in dmesg
if I turn on my EeePC 900 (which uses ath5k) and it immediately connects
to AP. Here's an example of the warning from a recent kernel:
[ 13.010403] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3)
[ 13.016644] wlan0: authenticate with xx:xx:xx:xx:xx:xx (try 1)
[ 13.025436] wlan0: authenticated
[ 13.025445] ------------[ cut here ]------------
[ 13.025458] WARNING: at net/wireless/mlme.c:47 cfg80211_send_rx_auth+0x8a/0x130()
[ 13.025463] Hardware name: 900
[ 13.025469] Pid: 490, comm: phy0 Not tainted 2.6.35-rc6-00150-gd15aa2c #1
[ 13.025474] Call Trace:
[ 13.025485] [<b01247f3>] ? warn_slowpath_common+0x73/0xb0
[ 13.025492] [<b04a2f8a>] ? cfg80211_send_rx_auth+0x8a/0x130
[ 13.025499] [<b04a2f8a>] ? cfg80211_send_rx_auth+0x8a/0x130
[ 13.025506] [<b0124849>] ? warn_slowpath_null+0x19/0x20
[ 13.025512] [<b04a2f8a>] ? cfg80211_send_rx_auth+0x8a/0x130
[ 13.025519] [<b04b65c7>] ? ieee80211_probe_auth_done+0x67/0x90
[ 13.025526] [<b04b7a63>] ? ieee80211_work_work+0x253/0x14e0
[ 13.025534] [<b0120790>] ? dequeue_task_fair+0x20/0x1d0
[ 13.025540] [<b012052a>] ? T.1071+0x2a/0x80
[ 13.025547] [<b04d51e0>] ? schedule+0x130/0x2d0
[ 13.025553] [<b04b7810>] ? ieee80211_work_work+0x0/0x14e0
[ 13.025562] [<b0137f1f>] ? worker_thread+0x10f/0x210
[ 13.025569] [<b013b2d0>] ? autoremove_wake_function+0x0/0x40
[ 13.025576] [<b0137e10>] ? worker_thread+0x0/0x210
[ 13.025582] [<b013af04>] ? kthread+0x74/0x80
[ 13.025587] [<b013ae90>] ? kthread+0x0/0x80
[ 13.025594] [<b01030b6>] ? kernel_thread_helper+0x6/0x10
[ 13.025599] ---[ end trace 84910d510f8a9a59 ]---
After a delay the machine goes on to the connect to the AP anyway so it
seems fairly harmless. Any ideas?
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* Urgente- Help in Broadcom bcm4353 - device 14e4:4353 linux driver monitor mode.
From: Arthur Moreira @ 2010-07-29 11:36 UTC (permalink / raw)
To: linux-wireless
Hi guys
I need a help for to find a especific or modified wl driver for the
device 14e4:4353 Broadcom wireless for work in monitor or promiscuo
mode.
i read a site and see your work about this.
if somebody can help me, tks
my card work normally with the compiled hybrid driver wl of the broadcom site
this site: broadcom linux sta, 32 bits hybrid
my machine is a DELL vostro 3500 with this card
if someone can help me with the webcam driver or the fingerprint
driver for the embedded devices of dell, tks again
off corse, sorry for the bad english.
Arthur Moreira
email to me arthur.morera at gmail dot com
^ permalink raw reply
* Re: MX27 libertas_sdio SDIO Interrupts vs available bitrate
From: Julien Boibessot @ 2010-07-29 12:51 UTC (permalink / raw)
To: Andreas Feuersinger; +Cc: libertas-dev, linux-mmc, linux-wireless
In-Reply-To: <20100729124604.79f88553@speedy>
Hi Andreas,
Andreas Feuersinger a écrit :
> I'm trying to improve throughput of the Marvell 8686 sdio wlan module.
> Unfortunately I have to stick with kernel 2.6.22.
>
> Everything works except for very bad datarate. So far the mxc_mmc
> driver does not handle any SDIO interrupts. Could that be the reason
> for the bad performance?
>
Definitly !
(I had the same "problem" on my i.MX27 platform before using SDIO
interrupts)
Regards,
Julien
http://www.armadeus.com
^ permalink raw reply
* [PATCH 1/3] ath9k_hw: Add capability flag for Antenna diversity and combining feature
From: Vasanthakumar Thiagarajan @ 2010-07-29 12:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
This is enabled only for ar9285.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/eeprom.h | 2 ++
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 4 ++++
drivers/net/wireless/ath/ath9k/hw.c | 9 +++++++++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
4 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index 8750c55..b2223a6 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -265,6 +265,8 @@ enum eeprom_param {
EEP_INTERNAL_REGULATOR,
EEP_SWREG,
EEP_PAPRD,
+ EEP_MODAL_VER,
+ EEP_ANT_DIV_CTL1,
};
enum ar5416_rates {
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 9cccd12..2e1397b 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -213,6 +213,10 @@ static u32 ath9k_hw_4k_get_eeprom(struct ath_hw *ah,
return 0;
case EEP_PWR_TABLE_OFFSET:
return AR5416_PWR_TABLE_OFFSET_DB;
+ case EEP_MODAL_VER:
+ return pModal->version;
+ case EEP_ANT_DIV_CTL1:
+ return pModal->antdiv_ctl1;
default:
return 0;
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 2f83f97..d9e9344 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2052,6 +2052,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
struct ath_btcoex_hw *btcoex_hw = &ah->btcoex_hw;
u16 capField = 0, eeval;
+ u8 ant_div_ctl1;
eeval = ah->eep_ops->get_eeprom(ah, EEP_REG_0);
regulatory->current_rd = eeval;
@@ -2276,6 +2277,14 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9287_10_OR_LATER(ah) || AR_SREV_9271(ah))
pCap->hw_caps |= ATH9K_HW_CAP_SGI_20;
+ if (AR_SREV_9285(ah))
+ if (ah->eep_ops->get_eeprom(ah, EEP_MODAL_VER) >= 3) {
+ ant_div_ctl1 =
+ ah->eep_ops->get_eeprom(ah, EEP_ANT_DIV_CTL1);
+ if ((ant_div_ctl1 & 0x1) && ((ant_div_ctl1 >> 3) & 0x1))
+ pCap->hw_caps |= ATH9K_HW_CAP_ANT_DIV_COMB;
+ }
+
return 0;
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 2d30efc..3f19148 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -204,6 +204,7 @@ enum ath9k_hw_caps {
ATH9K_HW_CAP_FASTCLOCK = BIT(20),
ATH9K_HW_CAP_SGI_20 = BIT(21),
ATH9K_HW_CAP_PAPRD = BIT(22),
+ ATH9K_HW_CAP_ANT_DIV_COMB = BIT(23),
};
struct ath9k_hw_capabilities {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] ath9k_hw: Add functions to get/set antenna diversity configuration
From: Vasanthakumar Thiagarajan @ 2010-07-29 12:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1280408219-5293-1-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 39 +++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 2 +
drivers/net/wireless/ath/ath9k/hw-ops.h | 14 +++++++++
drivers/net/wireless/ath/ath9k/hw.h | 10 +++++++
4 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index 4922b8d..f12aab2 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -513,9 +513,43 @@ static void ar9002_hw_set_nf_limits(struct ath_hw *ah)
}
}
+static void ar9002_hw_ant_div_comb_conf_get(struct ath_hw *ah,
+ struct ath_hw_antcomb_conf *antconf)
+{
+ u32 regval;
+
+ regval = REG_READ(ah, AR_PHY_MULTICHAIN_GAIN_CTL);
+ antconf->main_lna_conf = (regval & AR_PHY_9285_ANT_DIV_MAIN_LNACONF) >>
+ AR_PHY_9285_ANT_DIV_MAIN_LNACONF_S;
+ antconf->alt_lna_conf = (regval & AR_PHY_9285_ANT_DIV_ALT_LNACONF) >>
+ AR_PHY_9285_ANT_DIV_ALT_LNACONF_S;
+ antconf->fast_div_bias = (regval & AR_PHY_9285_FAST_DIV_BIAS) >>
+ AR_PHY_9285_FAST_DIV_BIAS_S;
+}
+
+static void ar9002_hw_ant_div_comb_conf_set(struct ath_hw *ah,
+ struct ath_hw_antcomb_conf *antconf)
+{
+ u32 regval;
+
+ regval = REG_READ(ah, AR_PHY_MULTICHAIN_GAIN_CTL);
+ regval &= ~(AR_PHY_9285_ANT_DIV_MAIN_LNACONF |
+ AR_PHY_9285_ANT_DIV_ALT_LNACONF |
+ AR_PHY_9285_FAST_DIV_BIAS);
+ regval |= ((antconf->main_lna_conf << AR_PHY_9285_ANT_DIV_MAIN_LNACONF_S)
+ & AR_PHY_9285_ANT_DIV_MAIN_LNACONF);
+ regval |= ((antconf->alt_lna_conf << AR_PHY_9285_ANT_DIV_ALT_LNACONF_S)
+ & AR_PHY_9285_ANT_DIV_ALT_LNACONF);
+ regval |= ((antconf->fast_div_bias << AR_PHY_9285_FAST_DIV_BIAS_S)
+ & AR_PHY_9285_FAST_DIV_BIAS);
+
+ REG_WRITE(ah, AR_PHY_MULTICHAIN_GAIN_CTL, regval);
+}
+
void ar9002_hw_attach_phy_ops(struct ath_hw *ah)
{
struct ath_hw_private_ops *priv_ops = ath9k_hw_private_ops(ah);
+ struct ath_hw_ops *ops = ath9k_hw_ops(ah);
priv_ops->set_rf_regs = NULL;
priv_ops->rf_alloc_ext_banks = NULL;
@@ -526,5 +560,10 @@ void ar9002_hw_attach_phy_ops(struct ath_hw *ah)
priv_ops->compute_pll_control = ar9002_hw_compute_pll_control;
priv_ops->do_getnf = ar9002_hw_do_getnf;
+ if (AR_SREV_9285(ah)) {
+ ops->ant_div_comb_conf_get = ar9002_hw_ant_div_comb_conf_get;
+ ops->ant_div_comb_conf_set = ar9002_hw_ant_div_comb_conf_set;
+ }
+
ar9002_hw_set_nf_limits(ah);
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.h b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
index c5151a4..37663db 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.h
@@ -302,6 +302,8 @@
#define AR_PHY_NEW_ADC_DC_OFFSET_CORR_ENABLE 0x80000000
#define AR_PHY_MULTICHAIN_GAIN_CTL 0x99ac
+#define AR_PHY_9285_FAST_DIV_BIAS 0x00007E00
+#define AR_PHY_9285_FAST_DIV_BIAS_S 9
#define AR_PHY_9285_ANT_DIV_CTL_ALL 0x7f000000
#define AR_PHY_9285_ANT_DIV_CTL 0x01000000
#define AR_PHY_9285_ANT_DIV_CTL_S 24
diff --git a/drivers/net/wireless/ath/ath9k/hw-ops.h b/drivers/net/wireless/ath/ath9k/hw-ops.h
index ffecbad..7d84b7f 100644
--- a/drivers/net/wireless/ath/ath9k/hw-ops.h
+++ b/drivers/net/wireless/ath/ath9k/hw-ops.h
@@ -139,6 +139,20 @@ static inline void ath9k_hw_ani_monitor(struct ath_hw *ah,
ath9k_hw_ops(ah)->ani_monitor(ah, chan);
}
+static inline void ath9k_hw_antdiv_comb_conf_get(struct ath_hw *ah,
+ struct ath_hw_antcomb_conf *antconf)
+{
+ if (ath9k_hw_ops(ah)->ant_div_comb_conf_get)
+ ath9k_hw_ops(ah)->ant_div_comb_conf_get(ah, antconf);
+}
+
+static inline void ath9k_hw_antdiv_comb_conf_set(struct ath_hw *ah,
+ struct ath_hw_antcomb_conf *antconf)
+{
+ if (ath9k_hw_ops(ah)->ant_div_comb_conf_set)
+ ath9k_hw_ops(ah)->ant_div_comb_conf_set(ah, antconf);
+}
+
/* Private hardware call ops */
/* PHY ops */
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 3f19148..4663557 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -489,6 +489,12 @@ struct ath_gen_timer_table {
} timer_mask;
};
+struct ath_hw_antcomb_conf {
+ u8 main_lna_conf;
+ u8 alt_lna_conf;
+ u8 fast_div_bias;
+};
+
/**
* struct ath_hw_private_ops - callbacks used internally by hardware code
*
@@ -627,6 +633,10 @@ struct ath_hw_ops {
void (*ani_proc_mib_event)(struct ath_hw *ah);
void (*ani_monitor)(struct ath_hw *ah, struct ath9k_channel *chan);
+ void (*ant_div_comb_conf_get)(struct ath_hw *ah,
+ struct ath_hw_antcomb_conf *antconf);
+ void (*ant_div_comb_conf_set)(struct ath_hw *ah,
+ struct ath_hw_antcomb_conf *antconf);
};
struct ath_nf_limits {
--
1.7.0.4
^ 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