* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-23 14:39 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTimsEkff4sMiMB_VyWqkZOjy9PIuJ4AiC95PASOZ@mail.gmail.com>
On Tue, Jun 22, 2010 at 12:38:03PM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 12:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> > On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
> >>
> >> Does CONFIG_PCIEASPM provide a way for the user to modifiy
> >> the settings at runtime?
> >
> > You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
> >
> > http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
> > http://wireless.kernel.org/en/users/Documentation/ASPM
> >
> >> I have a Samsung N130 netbook which has a BIOS setting
> >> called "CPU Power Saving Mode". When enabled it activates
> >> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
> >> and the PCIE bridge (with the BIOS setting off it's just L1).
> >> The result is that the ethernet througput is reduced to 25Mbit/s.
> >
> > L0s is not going to buy you much gains, getting at least L1 will
> > however. L0s is just a further enhancement. I recommend you test by
> > enabling L1 and L0s, check how longer your battery lasts and then test
> > again with just L1. Then test without both L1 and L0s.
>
> So defaults should always be sane and you should not have to play with
> this stuff, unless you're a hacker, or are testing something for
> development purposes. Tweaking ASPM settings is not something a user
> should have to worry about. Period.
OK, let me put the question another way:
If enabling ASPM comes with a performance penalty (which is not unexpected,
there is usually a tradeoff between performance and power consumption),
do you think a boot time option (pcie_aspm=) or compile time option
(CONFIG_PCIEASPM) is the right user interface?
But meanwhile I found that CONFIG_PCIEASPM has a runtime
interface, /sys/module/pcie_aspm/parameters/policy.
http://lwn.net/Articles/266585/
I have not tested it on my N130 yet.
Johannes
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
From: John W. Linville @ 2010-06-23 14:16 UTC (permalink / raw)
To: Justin Mattock; +Cc: linux-wireless, Linux Kernel Mailing List
In-Reply-To: <AANLkTilf41JrFwN1veRDifNA78S2LQ6SO0g3YLOONd2W@mail.gmail.com>
On Tue, Jun 22, 2010 at 04:16:53PM -0700, Justin Mattock wrote:
> I remember ipsec was able to work cleanly on my machines probably
> about 4/6 months ago
> now I get this:
<snip>
Perhaps netdev would be a more appropriate list than linux-wireless
for this?
John
--
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
* [PATCH] ath9k: Fix bug in starting ani
From: Vasanthakumar Thiagarajan @ 2010-06-23 13:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
There are few places where ANI is started without checking
if it is right to start. This might lead to a case where ani
timer would be left undeleted and cause improper memory acccess
during module unload. This bug is clearly exposed with
paprd support where the driver detects tx hang and does a
chip reset. During this reset ani is (re)started without checking
if it needs to be started. This would leave a timer scheduled
even after all the resources are freed and cause a panic.
This patch introduces a bit in sc_flags to indicate if ani
needs to be started in sw_scan_start() and ath_reset().
This would fix the following panic. This issue is easily seen
with ar9003 + paprd.
BUG: unable to handle kernel paging request at 0000000000003f38
[<ffffffff81075391>] ? __queue_work+0x41/0x50
[<ffffffff8106afaa>] run_timer_softirq+0x17a/0x370
[<ffffffff81088be8>] ? tick_dev_program_event+0x48/0x110
[<ffffffff81061f69>] __do_softirq+0xb9/0x1f0
[<ffffffff810ba060>] ? handle_IRQ_event+0x50/0x160
[<ffffffff8100af5c>] call_softirq+0x1c/0x30
[<ffffffff8100c9f5>] do_softirq+0x65/0xa0
[<ffffffff81061e25>] irq_exit+0x85/0x90
[<ffffffff8155e095>] do_IRQ+0x75/0xf0
[<ffffffff815570d3>] ret_from_intr+0x0/0x11
<EOI>
[<ffffffff812fd67b>] ? acpi_idle_enter_simple+0xe4/0x119
[<ffffffff812fd674>] ? acpi_idle_enter_simple+0xdd/0x119
[<ffffffff81441c87>] cpuidle_idle_call+0xa7/0x140
[<ffffffff81008da3>] cpu_idle+0xb3/0x110
[<ffffffff81550722>] start_secondary+0x1ee/0x1f5
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 3a14630..6218890 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -516,6 +516,7 @@ void ath_deinit_leds(struct ath_softc *sc);
#define SC_OP_TSF_RESET BIT(11)
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
+#define SC_OP_ANI_RUN BIT(14)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 5af2596..41a317d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -451,6 +451,10 @@ static void ath_start_ani(struct ath_common *common)
{
struct ath_hw *ah = common->ah;
unsigned long timestamp = jiffies_to_msecs(jiffies);
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
+
+ if (!(sc->sc_flags & SC_OP_ANI_RUN))
+ return;
common->ani.longcal_timer = timestamp;
common->ani.shortcal_timer = timestamp;
@@ -766,11 +770,13 @@ static void ath9k_bss_assoc_info(struct ath_softc *sc,
/* Reset rssi stats */
sc->sc_ah->stats.avgbrssi = ATH_RSSI_DUMMY_MARKER;
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
} else {
ath_print(common, ATH_DBG_CONFIG, "Bss Info DISASSOC\n");
common->curaid = 0;
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
}
}
@@ -1376,8 +1382,10 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
if (vif->type == NL80211_IFTYPE_AP ||
vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MONITOR)
+ vif->type == NL80211_IFTYPE_MONITOR) {
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
+ }
out:
mutex_unlock(&sc->mutex);
@@ -1398,6 +1406,7 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&sc->mutex);
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
/* Reclaim beacon resources */
--
1.7.0.4
^ permalink raw reply related
* Re: Recent results with BCM4312 on Netbook
From: Michael Büsch @ 2010-06-23 12:42 UTC (permalink / raw)
To: Larry Finger; +Cc: Gábor Stefanik, wireless, b43-dev
In-Reply-To: <AANLkTikjzHcT9L472CFJ2LKtOiEUIk2S78_S_s-IxHjl@mail.gmail.com>
Please note that there were some rewrites recently in the kernel
DMA subsystem. b43 does now use the generic DMA interface, which
should work on all busses. I would not rule out an error in
that area, though it's unlikely.
--
Greetings Michael.
^ permalink raw reply
* [PATCH] rt2500usb: fallback to SW encryption for TKIP+AES
From: Ondrej Zary @ 2010-06-23 10:57 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <201006222346.06150.linux@rainbow-software.org>
On Tuesday 22 June 2010, Ondrej Zary wrote:
> On Tuesday 22 June 2010 21:35:18 Gertjan van Wingerde wrote:
> > On 06/22/10 12:38, Ondrej Zary wrote:
> > > Hello,
> > > I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
> > > 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink
> > > RT2500USB]
> > >
> > > The problem only appears when HW encryption is enabled and connecting
> > > to an AP configured as WPA2 TKIP+AES.
> > >
> > > HW encryption works when the AP is configured as TKIP-only or AES-only.
> > > It also works when AP is configured as TKIP+AES but wpa_supplicant is
> > > forced to use TKIP as pairwise cipher (pairwise=TKIP)
> > >
> > > SW encryption works always.
> > >
> > > The problem is that no packets are transmitted. I can't see DHCP
> > > broadcasts on other machine using tcpdump. But when I run tcpdump on
> > > the rt2500usb, I see broadcasts from the other machine, so receive
> > > seems to work fine.
> > >
> > > Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
> > > [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
> > > [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
> > > [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
> > > [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
> > > [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.274533] wlan1: authenticated
> > > [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
> > > [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411
> > > status=0 aid=1) [ 373.277704] wlan1: associated
> > > [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
> > > [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
> > > hw_key_idx = 0 OK [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
> > > [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
> > > hw_key_idx = 1 OK [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
> > > [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 375.160246] rt2x00crypto_tx_overhead=8
> > > [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
> > > [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
> > > [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 381.163507] rt2x00crypto_tx_overhead=8
> > > [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
> > > [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
> > > [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 388.165194] rt2x00crypto_tx_overhead=8
> > > [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
> > > [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
> > > [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 399.169481] rt2x00crypto_tx_overhead=8
> > > [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
> > > [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
> > > [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
> > > [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
> > > [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 410.168850] rt2x00crypto_tx_overhead=8
> > > [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
> > > [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
> > > [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
> > > [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
> > > [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
> > > [ 422.169699] rt2x00crypto_tx_overhead=8
> > > [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
> > > [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
> > >
> > > Seems that it's trying to use CCMP, which is good. I wonder if the keys
> > > are properly handled in rt2500usb_config_key. They seem to be uploaded
> > > to the HW correctly (one at index 0, one at 1) - but can't tell without
> > > any HW docs.
> > >
> > > I did some framedumps before but don't know what to do with them (what
> > > to look for):
> > > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> > > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.tx
> > >t
> > >
> > > Anything else I can try?
> >
> > Hi Ondrej,
> >
> > Did you also test what happens if you configure the AP to be TKIP+AES and
> > force wpa-supplicant to use AES pairwise key?
> > If my analysis below is correct then that may work as well.
>
> That does not work - it's probably the same case as default options (TKIP
> group key + AES pairwise key).
>
> > If my reading of the rt2570 data sheet is correct, then the rt2570 will
> > only support one encryption mechanism at the time. That means that it is
> > not possible to upload 1 TKIP key and 1 AES key at the same time to the
> > hardware. All the configured keys have to be of the same encryption
> > algorithm.
> > Presumably this is why the HW encryption engine fails, as the keys are
> > set with mixed settings.
> > Based on that, I don't think that rt2500usb can support this TKIP+AES
> > setting on wpa-supplicant.
>
> If this is true, then the driver should fall back to SW encryption in this
> case.
HW crypto in rt2500usb does not seem to support keys with different ciphers,
which breaks TKIP+AES mode. Fall back to software encryption to fix it.
This should fix long-standing problems with rt2500usb and WPA, such as:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
https://bugzilla.redhat.com/show_bug.cgi?id=484888
Also tested that it does not break WEP, TKIP-only and AES-only modes.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
diff -urp linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c
--- linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-12 04:14:04.000000000 +0200
+++ linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-23 12:18:43.000000000 +0200
@@ -348,6 +348,7 @@ static int rt2500usb_config_key(struct r
int timeout;
u32 mask;
u16 reg;
+ enum cipher curr_cipher;
if (crypto->cmd == SET_KEY) {
/*
@@ -358,6 +359,7 @@ static int rt2500usb_config_key(struct r
mask = TXRX_CSR0_KEY_ID.bit_mask;
rt2500usb_register_read(rt2x00dev, TXRX_CSR0, ®);
+ curr_cipher = rt2x00_get_field16(reg, TXRX_CSR0_ALGORITHM);
reg &= mask;
if (reg && reg == mask)
@@ -366,6 +368,14 @@ static int rt2500usb_config_key(struct r
reg = rt2x00_get_field16(reg, TXRX_CSR0_KEY_ID);
key->hw_key_idx += reg ? ffz(reg) : 0;
+ /*
+ * Hardware requires that all keys use the same cipher
+ * (e.g. TKIP-only, AES-only, but not TKIP+AES).
+ * If this is not the first key, compare the cipher with the
+ * first one and fall back to SW crypto if not the same.
+ */
+ if (key->hw_key_idx > 0 && crypto->cipher != curr_cipher)
+ return -EOPNOTSUPP;
/*
* The encryption key doesn't fit within the CSR cache,
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 2/2] nl80211: Add option to adjust transmit power
From: Juuso Oikarinen @ 2010-06-23 10:08 UTC (permalink / raw)
To: ext Artem Mygaiev; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <op.veqxtlvunp38ce@conquistador-pc.synapse.com>
Hi Artem,
On Wed, 2010-06-23 at 11:26 +0200, ext Artem Mygaiev wrote:
> Hello Juuso
>
> A very minor comment - why do you need 'idx' here? Can't you just directly
> access array by NL80211_* index without adding an index variable?
The idx is there for pure beautification - there's no way to decently
fit onto one line without it ;)
-Juuso
>
> > + if (info->attrs[NL80211_ATTR_WIPHY_TX_POWER_SETTING]) {
> > + enum nl80211_tx_power_setting type;
> > + int idx, mbm = 0;
> > +
> > + if (!rdev->ops->set_tx_power) {
> > + return -EOPNOTSUPP;
> > + goto bad_res;
> > + }
> > +
> > + idx = NL80211_ATTR_WIPHY_TX_POWER_SETTING;
> > + type = nla_get_u32(info->attrs[idx]);
> > +
> > + if (!info->attrs[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] &&
> > + (type != NL80211_TX_POWER_AUTOMATIC)) {
> > + result = -EINVAL;
> > + goto bad_res;
> > + }
> > +
> > + if (type != NL80211_TX_POWER_AUTOMATIC) {
> > + idx = NL80211_ATTR_WIPHY_TX_POWER_LEVEL;
> > + mbm = nla_get_u32(info->attrs[idx]);
> > + }
> > +
> > + result = rdev->ops->set_tx_power(&rdev->wiphy, type, mbm);
> > + if (result)
> > + goto bad_res;
> > + }
>
^ permalink raw reply
* Re: [PATCH 2/2] nl80211: Add option to adjust transmit power
From: Artem Mygaiev @ 2010-06-23 9:26 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1277284358-11014-2-git-send-email-juuso.oikarinen@nokia.com>
Hello Juuso
A very minor comment - why do you need 'idx' here? Can't you just directly
access array by NL80211_* index without adding an index variable?
> + if (info->attrs[NL80211_ATTR_WIPHY_TX_POWER_SETTING]) {
> + enum nl80211_tx_power_setting type;
> + int idx, mbm = 0;
> +
> + if (!rdev->ops->set_tx_power) {
> + return -EOPNOTSUPP;
> + goto bad_res;
> + }
> +
> + idx = NL80211_ATTR_WIPHY_TX_POWER_SETTING;
> + type = nla_get_u32(info->attrs[idx]);
> +
> + if (!info->attrs[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] &&
> + (type != NL80211_TX_POWER_AUTOMATIC)) {
> + result = -EINVAL;
> + goto bad_res;
> + }
> +
> + if (type != NL80211_TX_POWER_AUTOMATIC) {
> + idx = NL80211_ATTR_WIPHY_TX_POWER_LEVEL;
> + mbm = nla_get_u32(info->attrs[idx]);
> + }
> +
> + result = rdev->ops->set_tx_power(&rdev->wiphy, type, mbm);
> + if (result)
> + goto bad_res;
> + }
--
Best regards,
Artem
^ permalink raw reply
* [PATCH] iw: Add support for setting transmit power level
From: Juuso Oikarinen @ 2010-06-23 9:12 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Add a "set txpower" option to specify the current transmit power level. Modes
supported are automatic, fixed and limited, and the limit may be specified
in signed mBm units.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
nl80211.h | 22 ++++++++++++++++++++++
phy.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/nl80211.h b/nl80211.h
index 64fb32b..2c87016 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -725,6 +725,12 @@ enum nl80211_commands {
* @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
* connected to this BSS.
*
+ * @NL80211_ATTR_WIPHY_TX_POWER_SETTING: Transmit power setting type. See
+ * &enum nl80211_tx_power_setting for possible values.
+ * @NL80211_ATTR_WIPHY_TX_POWER_LEVEL: Transmit power level in signed mBm units.
+ * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
+ * for non-automatic settings.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -882,6 +888,9 @@ enum nl80211_attrs {
NL80211_ATTR_AP_ISOLATE,
+ NL80211_ATTR_WIPHY_TX_POWER_SETTING,
+ NL80211_ATTR_WIPHY_TX_POWER_LEVEL,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -1659,4 +1668,17 @@ enum nl80211_cqm_rssi_threshold_event {
NL80211_CQM_RSSI_THRESHOLD_EVENT_HIGH,
};
+
+/**
+ * enum nl80211_tx_power_setting - TX power adjustment
+ * @NL80211_TX_POWER_AUTOMATIC: automatically determine transmit power
+ * @NL80211_TX_POWER_LIMITED: limit TX power by the mBm parameter
+ * @NL80211_TX_POWER_FIXED: fix TX power to the mBm parameter
+ */
+enum nl80211_tx_power_setting {
+ NL80211_TX_POWER_AUTOMATIC,
+ NL80211_TX_POWER_LIMITED,
+ NL80211_TX_POWER_FIXED,
+};
+
#endif /* __LINUX_NL80211_H */
diff --git a/phy.c b/phy.c
index 8f8d757..f042dc2 100644
--- a/phy.c
+++ b/phy.c
@@ -175,7 +175,7 @@ static int handle_netns(struct nl80211_state *state,
return 1;
NLA_PUT_U32(msg, NL80211_ATTR_PID,
- strtoul(argv[0], &end, 10));
+ strtoul(argv[0], &end, 10));
if (*end != '\0')
return 1;
@@ -258,3 +258,51 @@ COMMAND(set, distance, "<distance>",
NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_distance,
"Set appropriate coverage class for given link distance in meters.\n"
"Valid values: 0 - 114750");
+
+static int handle_txpower(struct nl80211_state *state,
+ struct nl_cb *cb,
+ struct nl_msg *msg,
+ int argc, char **argv)
+{
+ enum nl80211_tx_power_setting type;
+ int ret = -ENOSPC;
+ int mbm;
+
+ /* get the required args */
+ if (argc != 1 && argc != 2)
+ return 1;
+
+ if (!strcmp(argv[0], "auto"))
+ type = NL80211_TX_POWER_AUTOMATIC;
+ else if (!strcmp(argv[0], "fixed"))
+ type = NL80211_TX_POWER_FIXED;
+ else if (!strcmp(argv[0], "limit"))
+ type = NL80211_TX_POWER_LIMITED;
+ else {
+ printf("Invalid parameter: %s\n", argv[0]);
+ return 2;
+ }
+
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_TX_POWER_SETTING, type);
+
+ if (type != NL80211_TX_POWER_AUTOMATIC) {
+ if (argc != 2) {
+ printf("Missing TX power level argument.\n");
+ return 2;
+ }
+
+ mbm = atoi(argv[1]);
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_TX_POWER_LEVEL, mbm);
+ }
+
+ ret = 0;
+
+ nla_put_failure:
+ return ret;
+}
+COMMAND(set, txpower, "<auto|fixed|limit> [<tx power in mBm>]",
+ NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_txpower,
+ "Specify transmit power level and setting type.");
+COMMAND(set, txpower, "<auto|fixed|limit> [<tx power in mBm>]",
+ NL80211_CMD_SET_WIPHY, 0, CIB_NETDEV, handle_txpower,
+ "Specify transmit power level and setting type.");
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] cfg80211/mac80211: Update set_tx_power to use mBm instead of dBm units
From: Juuso Oikarinen @ 2010-06-23 9:12 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In preparation for a TX power setting interface in the nl80211, change the
.set_tx_power function to use mBm units instead of dBm for greater accuracy and
smaller power levels.
Also, already in advance move the tx_power_setting enumeration to nl80211.
This change affects the .tx_set_power function prototype. As a result, the
corresponding changes are needed to modules using it. These are mac80211,
iwmc3200wifi and rndis_wlan.
Cc: Samuel Ortiz <samuel.ortiz@intel.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Acked-by: Samuel Ortiz <samuel.ortiz@intel.com>
Acked-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
---
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 12 ++++++++----
drivers/net/wireless/rndis_wlan.c | 20 +++++++++++++-------
include/linux/nl80211.h | 13 +++++++++++++
include/net/cfg80211.h | 15 +--------------
net/mac80211/cfg.c | 22 +++++++++++-----------
net/wireless/wext-compat.c | 10 +++++-----
6 files changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/cfg80211.c b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
index 902e95f..6061967 100644
--- a/drivers/net/wireless/iwmc3200wifi/cfg80211.c
+++ b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
@@ -670,20 +670,24 @@ static int iwm_cfg80211_disconnect(struct wiphy *wiphy, struct net_device *dev,
}
static int iwm_cfg80211_set_txpower(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm)
+ enum nl80211_tx_power_setting type, int mbm)
{
struct iwm_priv *iwm = wiphy_to_iwm(wiphy);
int ret;
switch (type) {
- case TX_POWER_AUTOMATIC:
+ case NL80211_TX_POWER_AUTOMATIC:
return 0;
- case TX_POWER_FIXED:
+ case NL80211_TX_POWER_FIXED:
+ if (mbm < 0 || (mbm % 100))
+ return -EOPNOTSUPP;
+
if (!test_bit(IWM_STATUS_READY, &iwm->status))
return 0;
ret = iwm_umac_set_config_fix(iwm, UMAC_PARAM_TBL_CFG_FIX,
- CFG_TX_PWR_LIMIT_USR, dbm * 2);
+ CFG_TX_PWR_LIMIT_USR,
+ MBM_TO_DBM(mbm) * 2);
if (ret < 0)
return ret;
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 4102cca..5e26edb 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -520,8 +520,9 @@ static int rndis_scan(struct wiphy *wiphy, struct net_device *dev,
static int rndis_set_wiphy_params(struct wiphy *wiphy, u32 changed);
-static int rndis_set_tx_power(struct wiphy *wiphy, enum tx_power_setting type,
- int dbm);
+static int rndis_set_tx_power(struct wiphy *wiphy,
+ enum nl80211_tx_power_setting type,
+ int mbm);
static int rndis_get_tx_power(struct wiphy *wiphy, int *dbm);
static int rndis_connect(struct wiphy *wiphy, struct net_device *dev,
@@ -1856,20 +1857,25 @@ static int rndis_set_wiphy_params(struct wiphy *wiphy, u32 changed)
return 0;
}
-static int rndis_set_tx_power(struct wiphy *wiphy, enum tx_power_setting type,
- int dbm)
+static int rndis_set_tx_power(struct wiphy *wiphy,
+ enum nl80211_tx_power_setting type,
+ int mbm)
{
struct rndis_wlan_private *priv = wiphy_priv(wiphy);
struct usbnet *usbdev = priv->usbdev;
- netdev_dbg(usbdev->net, "%s(): type:0x%x dbm:%i\n",
- __func__, type, dbm);
+ netdev_dbg(usbdev->net, "%s(): type:0x%x mbm:%i\n",
+ __func__, type, mbm);
+
+ if (mbm < 0 || (mbm % 100))
+ return -ENOTSUPP;
/* Device doesn't support changing txpower after initialization, only
* turn off/on radio. Support 'auto' mode and setting same dBm that is
* currently used.
*/
- if (type == TX_POWER_AUTOMATIC || dbm == get_bcm4320_power_dbm(priv)) {
+ if (type == NL80211_TX_POWER_AUTOMATIC ||
+ MBM_TO_DBM(mbm) == get_bcm4320_power_dbm(priv)) {
if (!priv->radio_on)
disassociate(usbdev, true); /* turn on radio */
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 64fb32b..07aa046 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -1659,4 +1659,17 @@ enum nl80211_cqm_rssi_threshold_event {
NL80211_CQM_RSSI_THRESHOLD_EVENT_HIGH,
};
+
+/**
+ * enum nl80211_tx_power_setting - TX power adjustment
+ * @NL80211_TX_POWER_AUTOMATIC: automatically determine transmit power
+ * @NL80211_TX_POWER_LIMITED: limit TX power by the mBm parameter
+ * @NL80211_TX_POWER_FIXED: fix TX power to the mBm parameter
+ */
+enum nl80211_tx_power_setting {
+ NL80211_TX_POWER_AUTOMATIC,
+ NL80211_TX_POWER_LIMITED,
+ NL80211_TX_POWER_FIXED,
+};
+
#endif /* __LINUX_NL80211_H */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 64374f4..9b8b3f4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -875,19 +875,6 @@ enum wiphy_params_flags {
WIPHY_PARAM_COVERAGE_CLASS = 1 << 4,
};
-/**
- * enum tx_power_setting - TX power adjustment
- *
- * @TX_POWER_AUTOMATIC: the dbm parameter is ignored
- * @TX_POWER_LIMITED: limit TX power by the dbm parameter
- * @TX_POWER_FIXED: fix TX power to the dbm parameter
- */
-enum tx_power_setting {
- TX_POWER_AUTOMATIC,
- TX_POWER_LIMITED,
- TX_POWER_FIXED,
-};
-
/*
* cfg80211_bitrate_mask - masks for bitrate control
*/
@@ -1149,7 +1136,7 @@ struct cfg80211_ops {
int (*set_wiphy_params)(struct wiphy *wiphy, u32 changed);
int (*set_tx_power)(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm);
+ enum nl80211_tx_power_setting type, int mbm);
int (*get_tx_power)(struct wiphy *wiphy, int *dbm);
int (*set_wds_peer)(struct wiphy *wiphy, struct net_device *dev,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 003b6ad..f4efbfa 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1329,28 +1329,28 @@ static int ieee80211_set_wiphy_params(struct wiphy *wiphy, u32 changed)
}
static int ieee80211_set_tx_power(struct wiphy *wiphy,
- enum tx_power_setting type, int dbm)
+ enum nl80211_tx_power_setting type, int mbm)
{
struct ieee80211_local *local = wiphy_priv(wiphy);
struct ieee80211_channel *chan = local->hw.conf.channel;
u32 changes = 0;
switch (type) {
- case TX_POWER_AUTOMATIC:
+ case NL80211_TX_POWER_AUTOMATIC:
local->user_power_level = -1;
break;
- case TX_POWER_LIMITED:
- if (dbm < 0)
- return -EINVAL;
- local->user_power_level = dbm;
+ case NL80211_TX_POWER_LIMITED:
+ if (mbm < 0 || (mbm % 100))
+ return -EOPNOTSUPP;
+ local->user_power_level = MBM_TO_DBM(mbm);
break;
- case TX_POWER_FIXED:
- if (dbm < 0)
- return -EINVAL;
+ case NL80211_TX_POWER_FIXED:
+ if (mbm < 0 || (mbm % 100))
+ return -EOPNOTSUPP;
/* TODO: move to cfg80211 when it knows the channel */
- if (dbm > chan->max_power)
+ if (MBM_TO_DBM(mbm) > chan->max_power)
return -EINVAL;
- local->user_power_level = dbm;
+ local->user_power_level = MBM_TO_DBM(mbm);
break;
}
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 9634299..1ff1e9f 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -829,7 +829,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
- enum tx_power_setting type;
+ enum nl80211_tx_power_setting type;
int dbm = 0;
if ((data->txpower.flags & IW_TXPOW_TYPE) != IW_TXPOW_DBM)
@@ -852,7 +852,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
if (data->txpower.value < 0)
return -EINVAL;
dbm = data->txpower.value;
- type = TX_POWER_FIXED;
+ type = NL80211_TX_POWER_FIXED;
/* TODO: do regulatory check! */
} else {
/*
@@ -860,10 +860,10 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
* passed in from userland.
*/
if (data->txpower.value < 0) {
- type = TX_POWER_AUTOMATIC;
+ type = NL80211_TX_POWER_AUTOMATIC;
} else {
dbm = data->txpower.value;
- type = TX_POWER_LIMITED;
+ type = NL80211_TX_POWER_LIMITED;
}
}
} else {
@@ -872,7 +872,7 @@ int cfg80211_wext_siwtxpower(struct net_device *dev,
return 0;
}
- return rdev->ops->set_tx_power(wdev->wiphy, type, dbm);
+ return rdev->ops->set_tx_power(wdev->wiphy, type, DBM_TO_MBM(dbm));
}
EXPORT_SYMBOL_GPL(cfg80211_wext_siwtxpower);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] nl80211: Add option to adjust transmit power
From: Juuso Oikarinen @ 2010-06-23 9:12 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1277284358-11014-1-git-send-email-juuso.oikarinen@nokia.com>
This patch adds transmit power setting type and transmit power level attributes
to NL80211_CMD_SET_WIPHY in order to facilitate adjusting of the transmit power
level of the device.
The added attributes allow selection of automatic, limited or fixed transmit
power level, with the level definable in signed mBm format.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/linux/nl80211.h | 9 +++++++++
net/wireless/nl80211.c | 31 +++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 07aa046..2c87016 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -725,6 +725,12 @@ enum nl80211_commands {
* @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
* connected to this BSS.
*
+ * @NL80211_ATTR_WIPHY_TX_POWER_SETTING: Transmit power setting type. See
+ * &enum nl80211_tx_power_setting for possible values.
+ * @NL80211_ATTR_WIPHY_TX_POWER_LEVEL: Transmit power level in signed mBm units.
+ * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
+ * for non-automatic settings.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -882,6 +888,9 @@ enum nl80211_attrs {
NL80211_ATTR_AP_ISOLATE,
+ NL80211_ATTR_WIPHY_TX_POWER_SETTING,
+ NL80211_ATTR_WIPHY_TX_POWER_LEVEL,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 41529ac..a999fc1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -153,6 +153,9 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_CQM] = { .type = NLA_NESTED, },
[NL80211_ATTR_LOCAL_STATE_CHANGE] = { .type = NLA_FLAG },
[NL80211_ATTR_AP_ISOLATE] = { .type = NLA_U8 },
+
+ [NL80211_ATTR_WIPHY_TX_POWER_SETTING] = { .type = NLA_U32 },
+ [NL80211_ATTR_WIPHY_TX_POWER_LEVEL] = { .type = NLA_U32 },
};
/* policy for the attributes */
@@ -869,6 +872,34 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
goto bad_res;
}
+ if (info->attrs[NL80211_ATTR_WIPHY_TX_POWER_SETTING]) {
+ enum nl80211_tx_power_setting type;
+ int idx, mbm = 0;
+
+ if (!rdev->ops->set_tx_power) {
+ return -EOPNOTSUPP;
+ goto bad_res;
+ }
+
+ idx = NL80211_ATTR_WIPHY_TX_POWER_SETTING;
+ type = nla_get_u32(info->attrs[idx]);
+
+ if (!info->attrs[NL80211_ATTR_WIPHY_TX_POWER_LEVEL] &&
+ (type != NL80211_TX_POWER_AUTOMATIC)) {
+ result = -EINVAL;
+ goto bad_res;
+ }
+
+ if (type != NL80211_TX_POWER_AUTOMATIC) {
+ idx = NL80211_ATTR_WIPHY_TX_POWER_LEVEL;
+ mbm = nla_get_u32(info->attrs[idx]);
+ }
+
+ result = rdev->ops->set_tx_power(&rdev->wiphy, type, mbm);
+ if (result)
+ goto bad_res;
+ }
+
changed = 0;
if (info->attrs[NL80211_ATTR_WIPHY_RETRY_SHORT]) {
--
1.6.3.3
^ permalink raw reply related
* 2.6.34 kernel + compat-wireless + Bluez-4.66 --- no Bluetooth devices
From: Andrei Moraru @ 2010-06-23 9:04 UTC (permalink / raw)
To: linux-wireless
Hello,
I have a machine with Centos 5.4, kernel version 2.6.34, Bluez-4.66,
compat-wireless for 2.6.34 kernel version.
The system knows about USB Bluetooth adapters
[root@voip ~]# lsusb
Bus 002 Device 004: ID 1131:1001 Integrated System Solution Corp.
KY-BT100 Bluetooth Adapter
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
However, hciconfig shows no devices:
[root@voip ~]# hciconfig -a
[root@voip ~]#
Also, hcitool dev
[root@voip ~]# hcitool dev
Devices:
the dmesg output about bluetooth shows
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.14
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Please suggest your opinions.
Regards,
Andrei Moraru.
^ permalink raw reply
* Re: ATH5k - Signal measurement reports wrong values - "calib" did not help
From: Jaroslav Fojtik @ 2010-06-23 9:03 UTC (permalink / raw)
To: linux-wireless; +Cc: bruno Randolf
In-Reply-To: <201006211650.50766.br1@einfach.org>
Dear Bruno & ATH5k developpers,
> > > it might be interresting to see what results you get from noise
> > > calibration. you can enable calibration debugging with "echo calib >
> > > /sys/kernel/debug/ath5k/phy0/debug"
Nothing changed after setting "calib" on.
ATH5k still reports bad values.
You could see a magenta line here:
http://78.108.103.11:11080/cgi-bin/rodga.cgi
regards
Jara
^ permalink raw reply
* Re: [PATCH 1/3] Libertas: cfg80211 support
From: Johannes Berg @ 2010-06-23 8:25 UTC (permalink / raw)
To: dkiran; +Cc: linux-wireless
In-Reply-To: <1276533086.18884.9.camel@pe-lt028>
On Mon, 2010-06-14 at 22:01 +0530, Kiran Divekar wrote:
> Holger Schurig's patch (https://patchwork.kernel.org/patch/64286/)
> is rebased to latest wireless-testing tree.
+drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in assignment (different base types)
+drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short [unsigned] [usertype] capability
+drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16 [usertype] <noident>
+drivers/net/wireless/libertas/cmdresp.c:106:5: warning: symbol 'lbs_ret_802_11d_domain_info' was not declared. Should it be static?
I'm guessing this patchset is at fault.
johannes
^ permalink raw reply
* [PATCH] ath9k: Fix the LED behaviour in idle unassociated state.
From: Vivek Natarajan @ 2010-06-23 6:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
LED should be ON when the radio is put into FULL SLEEP mode during the idle
unassociated state.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 5af2596..c908657 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -829,9 +829,14 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
ath9k_ps_wakeup(sc);
ieee80211_stop_queues(hw);
- /* Disable LED */
- ath9k_hw_set_gpio(ah, ah->led_pin, 1);
- ath9k_hw_cfg_gpio_input(ah, ah->led_pin);
+ /*
+ * Keep the LED on when the radio is disabled
+ * during idle unassociated state.
+ */
+ if (!sc->ps_idle) {
+ ath9k_hw_set_gpio(ah, ah->led_pin, 1);
+ ath9k_hw_cfg_gpio_input(ah, ah->led_pin);
+ }
/* Disable interrupts */
ath9k_hw_set_interrupts(ah, 0);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/2] wl1251: fix ELP_CTRL register reads
From: Denis 'GNUtoo' Carikli @ 2010-06-22 23:33 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Bob Copeland, Kalle Valo, John W.Linville, linux-wireless
In-Reply-To: <AANLkTildbagKqzTQbcZ8cT53s4L2OWpJ5fkBUTcejj0h@mail.gmail.com>
On Tue, 2010-06-22 at 01:48 +0300, Grazvydas Ignotas wrote:
> >> Probably not relevant to power saving, but:
> >>
> >> Are you using the dedicated irq line or sdio interrupt?
> >> It makes a big difference in overall throughput to use
> >> the former.
> > I don't know. what should I grep for?
>
> It might actually be related.. Try adding this to your board file to
> enable GPIO irq:
>
> static void wl1251_set_power(bool enable)
> {
> }
>
> static struct wl12xx_platform_data wl1251_pdata = {
> .set_power = wl1251_set_power,
> };
>
> static struct platform_device wl1251_data = {
> .name = "wl1251_data",
> .id = -1,
> .dev = {
> .platform_data = &wl1251_pdata,
> },
> };
>
> .. then from some init function:
>
> // WIFI_IRQ_GPIO is the GPIO number connected to wl1251 irq line
> wl1251_pdata.irq = gpio_to_irq(WIFI_IRQ_GPIO);
> platform_device_register(&wl1251_pdata);
Thanks a lot for the infos,they were really helpfull.
I've applied that patch(as it was not for submitting,just for reading I
didn't bother sending with git-send-email):
Index: sources/arch/arm/mach-msm/board-trout.c
===================================================================
--- sources.orig/arch/arm/mach-msm/board-trout.c 2010-06-23
00:41:54.601288614 +0200
+++ sources/arch/arm/mach-msm/board-trout.c 2010-06-23
00:43:59.893158944 +0200
@@ -52,6 +52,7 @@
#include <asm/mach/mmc.h>
#include <linux/mmc/sdio_ids.h>
#include <linux/msm_audio.h>
+#include <linux/spi/wl12xx.h>
#include "board-trout.h"
@@ -363,6 +364,17 @@
},
};
+struct wl12xx_platform_data wl12xx_data = {
+};
+
+static struct platform_device wl12xx = {
+ .name = "wl1251_data",
+ .id = -1,
+ .dev = {
+ .platform_data = &wl12xx_data,
+ },
+};
+
#ifdef CONFIG_HTC_HEADSET
static void h2w_config_cpld(int route)
{
@@ -650,6 +662,7 @@
&trout_pwr_sink,
#endif
&trout_snd,
+ &wl12xx,
};
extern struct sys_timer msm_timer;
@@ -745,6 +758,7 @@
static void __init config_gpios(void)
{
+ wl12xx_data.irq = gpio_to_irq(29);
config_gpio_table(gpio_table, ARRAY_SIZE(gpio_table));
config_camera_off_gpios();
}
Index: sources/include/linux/spi/wl12xx.h
===================================================================
--- sources.orig/include/linux/spi/wl12xx.h 2010-06-23
00:42:03.641283312 +0200
+++ sources/include/linux/spi/wl12xx.h 2010-06-23 00:42:48.103178185
+0200
@@ -26,6 +26,7 @@
struct wl12xx_platform_data {
void (*set_power)(bool enable);
+ int irq;
};
#endif
The patch was made from someone in irc and modified by me later.
Then I load the wifi as usual:
modprobe wl1251_sdio #it doesn't crash
modprobe msm_wifi
the modprobe msm_wifi gives the following result:
[ 1366.500427] wifi probe start
[ 1366.500457] trout_wifi_power: 1
[ 1366.927185] trout_wifi_reset: 0
[ 1367.030944] trout_wifi_set_carddetect: 1
[ 1367.030975] mmc0: card_present 1
[ 1367.030975] mmc0: Slot status change detected (0 -> 1)
[ 1367.031036] wifi probe done
And then I've an invisible crash/kernel panic which result in the
machine lockup and then reboot(so it should be a kernel panic).
Note that I've no serial yet(I think I should really get a serial cable
for this machine)
msm_wifi comes from here:
http://bobcopeland.com/srcs/android/msm_wifi.patch
I had already some wifi structures which may have conflicted:
struct wifi_platform_data trout_wifi_control = {
.set_power = trout_wifi_power,
.set_reset = trout_wifi_reset,
.set_carddetect = trout_wifi_set_carddetect,
#ifdef CONFIG_WIFI_MEM_PREALLOC
.mem_prealloc = trout_wifi_mem_prealloc,
#else
.mem_prealloc = NULL,
#endif
};
static struct platform_device trout_wifi = {
.name = "msm_wifi",
.id = 1,
.num_resources = 0,
.resource = NULL,
.dev = {
.platform_data = &trout_wifi_control,
},
};
Thanks a lot for the help so far.
Denis
^ permalink raw reply
* BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
From: Justin Mattock @ 2010-06-22 23:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Linux Kernel Mailing List
I remember ipsec was able to work cleanly on my machines probably
about 4/6 months ago
now I get this:
[ 302.071077] BUG: unable to handle kernel NULL pointer dereference
at 00000000000000a0
[ 302.071084] IP: [<ffffffff81387e0b>] xfrm_bundle_ok+0x14f/0x2e9
[ 302.071094] PGD 13e695067 PUD 139c7e067 PMD 0
[ 302.071100] Oops: 0000 [#1] SMP
[ 302.071104] last sysfs file:
/sys/devices/pci0000:00/0000:00:15.0/0000:04:00.0/net/eth1/statistics/tx_bytes
[ 302.071109] CPU 0
[ 302.071111] Modules linked in: xfrm4_mode_transport sco xcbc bnep
rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state
nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4
iptable_filter ip_tables x_tables firewire_ohci firewire_core evdev
lib80211_crypt_tkip uvcvideo videodev ohci1394 v4l1_compat button
thermal wl(P) nvidia(P) ohci_hcd forcedeth i2c_nforce2 aes_x86_64 lzo
lzo_compress ipcomp xfrm_ipcomp crypto_null sha256_generic cbc
des_generic cast5 blowfish serpent camellia twofish twofish_common ctr
ah4 esp4 authenc adm1021 raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart
rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor
mperf appletouch applesmc
[ 302.071185]
[ 302.071189] Pid: 2603, comm: vncviewer Tainted: P
2.6.35-rc2-00001-g8dd40f7 #3 Mac-F2218FC8/iMac9,1
[ 302.071193] RIP: 0010:[<ffffffff81387e0b>] [<ffffffff81387e0b>]
xfrm_bundle_ok+0x14f/0x2e9
[ 302.071199] RSP: 0018:ffff880139f4db58 EFLAGS: 00010246
[ 302.071202] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 302.071206] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880139f48700
[ 302.071209] RBP: ffff880139f4dbc8 R08: 0000000000000000 R09: ffff8801389cc574
[ 302.071212] R10: dead000000200200 R11: ffff880139f4dc98 R12: ffff88012739a500
[ 302.071216] R13: ffff88012739a780 R14: 0000000000000000 R15: ffff88012ed266c0
[ 302.071220] FS: 00007f201be85740(0000) GS:ffff880001a00000(0000)
knlGS:0000000000000000
[ 302.071224] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 302.071227] CR2: 00000000000000a0 CR3: 000000013b2a6000 CR4: 00000000000406f0
[ 302.071230] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 302.071234] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 302.071238] Process vncviewer (pid: 2603, threadinfo
ffff880139f4c000, task ffff880131b1dc40)
[ 302.071240] Stack:
[ 302.071242] ffff8801389366c0 ffffffff8168ff08 000000000000001c
000000000000000c
[ 302.071248] <0> 0000000000000000 00000000004623c0 0000000000000000
0000000081606c40
[ 302.071253] <0> ffff8801389cc480 ffff88012739a500 ffff88012ef80780
0000000000000000
[ 302.071260] Call Trace:
[ 302.071265] [<ffffffff81387fba>] stale_bundle+0x15/0x1f
[ 302.071270] [<ffffffff81387fdc>] xfrm_dst_check+0x18/0x2e
[ 302.071275] [<ffffffff8131d02f>] __sk_dst_check+0x27/0x53
[ 302.071281] [<ffffffff8135172a>] ip_queue_xmit+0x3c/0x2ed
[ 302.071286] [<ffffffff8136405c>] ? tcp_connect+0x1d4/0x379
[ 302.071290] [<ffffffff8131eef3>] ? __skb_clone+0x29/0x100
[ 302.071295] [<ffffffff81363dc0>] tcp_transmit_skb+0x6e1/0x71f
[ 302.071300] [<ffffffff81364175>] tcp_connect+0x2ed/0x379
[ 302.071305] [<ffffffff81243739>] ? secure_tcp_sequence_number+0x55/0x6e
[ 302.071310] [<ffffffff813692ee>] tcp_v4_connect+0x3c4/0x419
[ 302.071316] [<ffffffff811952d2>] ? avc_has_perm+0x57/0x69
[ 302.071321] [<ffffffff81375030>] inet_stream_connect+0xa7/0x260
[ 302.071326] [<ffffffff8131aa26>] sys_connect+0x75/0x9b
[ 302.071332] [<ffffffff810e403c>] ? fd_install+0x52/0x5b
[ 302.071338] [<ffffffff81092983>] ? audit_syscall_entry+0x1b6/0x1e2
[ 302.071342] [<ffffffff8131a552>] ? sys_socket+0x3b/0x57
[ 302.071348] [<ffffffff81025f42>] system_call_fastpath+0x16/0x1b
[ 302.071350] Code: 7d 58 41 80 bf c0 00 00 00 02 0f 85 98 01 00 00
41 8b 87 a8 00 00 00 41 39 85 b8 01 00 00 0f 85 84 01 00 00 49 8b 85
90 01 00 00 <8b> 80 a0 00 00 00 41 39 85 bc 01 00 00 0f 85 6a 01 00 00
83 7d
[ 302.071400] RIP [<ffffffff81387e0b>] xfrm_bundle_ok+0x14f/0x2e9
[ 302.071405] RSP <ffff880139f4db58>
[ 302.071408] CR2: 00000000000000a0
[ 302.071414] ---[ end trace b4323dbb88295950 ]---
starting a bisect, but might take some time....
--
Justin P. Mattock
^ permalink raw reply
* Re: Recent results with BCM4312 on Netbook
From: Gábor Stefanik @ 2010-06-22 22:47 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, wireless, b43-dev
In-Reply-To: <4C20D884.3010501@lwfinger.net>
On Tue, Jun 22, 2010 at 5:36 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Michael,
>
> I have some good news. The Netbook that came from John is suddenly
> developing DMA errors for the BCM4312, even though it does not have a
> Phoenix BIOS. I have no idea why it did not fail this way earlier, but at
> least I have a machine to debug that failure.
Suddenly developing DMA errors? Hmm... maybe it's a hardware issue
with the card, from which wl can silently recover?
>
> My first discovery is that if PIO mode is to be used, it is not sufficient
> to load the module with the "pio=1" option, but that both "qos=0" and
> "nohwcrypt=1" options must also be used, at least for WPA/WPA2 networks.
> No other combination works. In addition, the automatic failover to PIO
> mode does not work unless those two options were used when the module was
> loaded. Thus both of the following work:
>
> modprobe b43 pio=1 qos=0 nohwcrypt=1
> modprobe b43 qos=0 hwcrypt=1
>
> The second example gets a fatal DMA error and resets the controller before
> the network comes up. I tried setting the latter two options before the
> controller reset call in the failover, but that did not work.
>
> If you have suggestions on changes in the switch from DMA to PIO mode,
> please send them to me. In the meantime, I will be looking at differences
> in the MMIO traces between wl and b43 to try to fix the DMA problem at the
> source of the trouble.
>
> Larry
>
> _______________________________________________
> b43-dev mailing list
> b43-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: rt2500usb: WPA2 TKIP+AES does not work with HW encryption
From: Ondrej Zary @ 2010-06-22 21:46 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <4C211076.9060804@gmail.com>
On Tuesday 22 June 2010 21:35:18 Gertjan van Wingerde wrote:
> On 06/22/10 12:38, Ondrej Zary wrote:
> > Hello,
> > I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
> > 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink
> > RT2500USB]
> >
> > The problem only appears when HW encryption is enabled and connecting to
> > an AP configured as WPA2 TKIP+AES.
> >
> > HW encryption works when the AP is configured as TKIP-only or AES-only.
> > It also works when AP is configured as TKIP+AES but wpa_supplicant is
> > forced to use TKIP as pairwise cipher (pairwise=TKIP)
> >
> > SW encryption works always.
> >
> > The problem is that no packets are transmitted. I can't see DHCP
> > broadcasts on other machine using tcpdump. But when I run tcpdump on the
> > rt2500usb, I see broadcasts from the other machine, so receive seems to
> > work fine.
> >
> > Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
> > [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
> > [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
> > [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
> > [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
> > [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.274533] wlan1: authenticated
> > [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
> > [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411
> > status=0 aid=1) [ 373.277704] wlan1: associated
> > [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
> > [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx
> > = 0 OK [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
> > [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx
> > = 1 OK [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
> > [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 375.160246] rt2x00crypto_tx_overhead=8
> > [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
> > [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
> > [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 381.163507] rt2x00crypto_tx_overhead=8
> > [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
> > [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
> > [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 388.165194] rt2x00crypto_tx_overhead=8
> > [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
> > [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
> > [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 399.169481] rt2x00crypto_tx_overhead=8
> > [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
> > [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
> > [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
> > [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
> > [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 410.168850] rt2x00crypto_tx_overhead=8
> > [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
> > [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
> > [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
> > [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
> > [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
> > [ 422.169699] rt2x00crypto_tx_overhead=8
> > [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
> > [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
> >
> > Seems that it's trying to use CCMP, which is good. I wonder if the keys
> > are properly handled in rt2500usb_config_key. They seem to be uploaded to
> > the HW correctly (one at index 0, one at 1) - but can't tell without any
> > HW docs.
> >
> > I did some framedumps before but don't know what to do with them (what to
> > look for):
> > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> > http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.txt
> >
> > Anything else I can try?
>
> Hi Ondrej,
>
> Did you also test what happens if you configure the AP to be TKIP+AES and
> force wpa-supplicant to use AES pairwise key?
> If my analysis below is correct then that may work as well.
That does not work - it's probably the same case as default options (TKIP
group key + AES pairwise key).
> If my reading of the rt2570 data sheet is correct, then the rt2570 will
> only support one encryption mechanism at the time. That means that it is
> not possible to upload 1 TKIP key and 1 AES key at the same time to the
> hardware. All the configured keys have to be of the same encryption
> algorithm.
> Presumably this is why the HW encryption engine fails, as the keys are set
> with mixed settings.
> Based on that, I don't think that rt2500usb can support this TKIP+AES
> setting on wpa-supplicant.
If this is true, then the driver should fall back to SW encryption in this
case.
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH] compat-wireless: "crap" code is "not yet posted", not "not yet merged"
From: Luis R. Rodriguez @ 2010-06-22 21:11 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <20100622204048.5228.76910.stgit@mj.roinet.com>
On Tue, Jun 22, 2010 at 1:40 PM, Pavel Roskin <proski@gnu.org> wrote:
>
> ---
> scripts/admin-update.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
> index 7592546..4eb7c3e 100755
> --- a/scripts/admin-update.sh
> +++ b/scripts/admin-update.sh
> @@ -85,7 +85,7 @@ nag_pending() {
>
> nag_crap() {
> printf "${RED}%10s${NORMAL} - Crap changes not yet posted\n" $2
> - printf "${RED}%10s${NORMAL} - Crap additions not yet merged\n" $3
> + printf "${RED}%10s${NORMAL} - Crap additions not yet posted\n" $3
> printf "${RED}%10s${NORMAL} - Crap deletions not yet posted\n" $4
> printf "${RED}%10s${NORMAL} - %% of crap code\n" $(perl -e 'printf("%.4f", 100 * '$2' / '$1');')
> }
>
applied, thanks!
Luis
^ permalink raw reply
* [PATCH] compat-wireless: "crap" code is "not yet posted", not "not yet merged"
From: Pavel Roskin @ 2010-06-22 20:40 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless
---
scripts/admin-update.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
index 7592546..4eb7c3e 100755
--- a/scripts/admin-update.sh
+++ b/scripts/admin-update.sh
@@ -85,7 +85,7 @@ nag_pending() {
nag_crap() {
printf "${RED}%10s${NORMAL} - Crap changes not yet posted\n" $2
- printf "${RED}%10s${NORMAL} - Crap additions not yet merged\n" $3
+ printf "${RED}%10s${NORMAL} - Crap additions not yet posted\n" $3
printf "${RED}%10s${NORMAL} - Crap deletions not yet posted\n" $4
printf "${RED}%10s${NORMAL} - %% of crap code\n" $(perl -e 'printf("%.4f", 100 * '$2' / '$1');')
}
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 19:38 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTin1fAAgYTYegqaadkYIYP2NXRNRzCR48e-uIgYV@mail.gmail.com>
On Tue, Jun 22, 2010 at 12:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
>> On Tue, Jun 22, 2010 at 07:44:26PM +0100, Matthew Garrett wrote:
>>> On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
>>> >
>>> > Heh, this whole patch and thread was started because Jussi tested
>>> > ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
>>> > been trying to explain all along why this is a terrible idea to the
>>> > point we should probably just remove that code from the kernel. Hence
>>> > my side rants and explanations to justify my reasonings.
>>>
>>> Well, there's two things here. If you use force then you might get
>>> inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
>>> booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
>>> *with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
>>> confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
>>> the kernel to modify the BIOS default, and disabling it makes the
>>> assumption that your BIOS did something sensible.
>>
>> Does CONFIG_PCIEASPM provide a way for the user to modifiy
>> the settings at runtime?
>
> You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
>
> http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
> http://wireless.kernel.org/en/users/Documentation/ASPM
>
>> I have a Samsung N130 netbook which has a BIOS setting
>> called "CPU Power Saving Mode". When enabled it activates
>> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
>> and the PCIE bridge (with the BIOS setting off it's just L1).
>> The result is that the ethernet througput is reduced to 25Mbit/s.
>> (The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
>>
>> 99,9% of the time I want to enjoy the power savings,
>> but occationally I have to transfer some bulk data and would
>> like to switch the setting for a few minutes.
>>
>> Or, well, ideally I'd like to have power savings _and_ performance
>> at the same time without any manual intervention. I'm not sure
>> if this is a quirk of the N130 or if ASPM L0s always causes
>> performance degradation?
>
> L0s is not going to buy you much gains, getting at least L1 will
> however. L0s is just a further enhancement. I recommend you test by
> enabling L1 and L0s, check how longer your battery lasts and then test
> again with just L1. Then test without both L1 and L0s.
So defaults should always be sane and you should not have to play with
this stuff, unless you're a hacker, or are testing something for
development purposes. Tweaking ASPM settings is not something a user
should have to worry about. Period.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-22 19:37 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <20100622193143.GA17803@sig21.net>
On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
> On Tue, Jun 22, 2010 at 07:44:26PM +0100, Matthew Garrett wrote:
>> On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
>> >
>> > Heh, this whole patch and thread was started because Jussi tested
>> > ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
>> > been trying to explain all along why this is a terrible idea to the
>> > point we should probably just remove that code from the kernel. Hence
>> > my side rants and explanations to justify my reasonings.
>>
>> Well, there's two things here. If you use force then you might get
>> inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
>> booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
>> *with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
>> confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
>> the kernel to modify the BIOS default, and disabling it makes the
>> assumption that your BIOS did something sensible.
>
> Does CONFIG_PCIEASPM provide a way for the user to modifiy
> the settings at runtime?
You can tune ASPM settings at runtime, regardless of CONFIG_PCIEASPM. See:
http://kernel.org/pub/linux/kernel/people/mcgrof/aspm/enable-aspm
http://wireless.kernel.org/en/users/Documentation/ASPM
> I have a Samsung N130 netbook which has a BIOS setting
> called "CPU Power Saving Mode". When enabled it activates
> ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
> and the PCIE bridge (with the BIOS setting off it's just L1).
> The result is that the ethernet througput is reduced to 25Mbit/s.
> (The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
>
> 99,9% of the time I want to enjoy the power savings,
> but occationally I have to transfer some bulk data and would
> like to switch the setting for a few minutes.
>
> Or, well, ideally I'd like to have power savings _and_ performance
> at the same time without any manual intervention. I'm not sure
> if this is a quirk of the N130 or if ASPM L0s always causes
> performance degradation?
L0s is not going to buy you much gains, getting at least L1 will
however. L0s is just a further enhancement. I recommend you test by
enabling L1 and L0s, check how longer your battery lasts and then test
again with just L1. Then test without both L1 and L0s.
Luis
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34
From: Tim Gardner @ 2010-06-22 19:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Pavel Roskin, linux-wireless, Rafael J. Wysocki, j
In-Reply-To: <AANLkTilQSFWP7DABswlOqUOq1yjFQG6RwFzkOIY6zl4i@mail.gmail.com>
On 06/21/2010 06:26 PM, Luis R. Rodriguez wrote:
> On Mon, Jun 21, 2010 at 5:14 PM, Tim Gardner<tim.gardner@canonical.com> wrote:
>> On 06/21/2010 04:18 PM, Luis R. Rodriguez wrote:
>>>
>>> On Mon, Jun 21, 2010 at 3:01 PM, Pavel Roskin<proski@gnu.org> wrote:
>>>>
>>>> On Mon, 2010-06-21 at 11:32 -0700, Luis R. Rodriguez wrote:
>>>>
>>>>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16111
>>>>>> Subject : hostap_pci: infinite registered netdevice wifi0
>>>>>> Submitter : Petr Pisar<petr.pisar@atlas.cz>
>>>>>> Date : 2010-06-02 20:55 (19 days old)
>>>>>
>>>>> The last entry on this one says we are not sure how to fix this...
>>>>
>>>> That was a patch posted for that by Tim Gardner:
>>>> https://patchwork.kernel.org/patch/105008/
>>>>
>>>> The patch is applied to wireless-testing
>>>> (d6a574ff6bfb842bdb98065da053881ff527be46)
>>>>
>>>> $ git describe d6a574ff6bfb842bdb98065da053881ff527be46
>>>> v2.6.34-4694-gd6a574f
>>>>
>>>> I understand it was applied after 2.6.34, so it should be backported to
>>>> 2.6.34 and whatever older kernels are affected.
>>>
>>> Tim can this be sent for stable?
>>>
>>> Luis, a stable whore
>>>
>>
>> Luis,
>>
>> The patch that I sent John is already Cc stable@kernel.org, though it may
>> not now apply after 56bf882230d2266a2e07b7f404dc96d157a65daa 'Revert
>> "wireless: hostap, fix oops due to early probing interrupt"'. I'll check in
>> the morning and craft a backported patch if necessary.
>
> Sweet thanks for the heads up!
>
> Luis
>
Hmm, looks like I'm gonna have to write some backport patches. I'll wait
until this appears in Linus' tree so I can feed stable the right SHA1 info.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: rt2500usb: WPA2 TKIP+AES does not work with HW encryption
From: Gertjan van Wingerde @ 2010-06-22 19:35 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <201006221238.32745.linux@rainbow-software.org>
On 06/22/10 12:38, Ondrej Zary wrote:
> Hello,
> I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
> 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink RT2500USB]
>
> The problem only appears when HW encryption is enabled and connecting to an AP
> configured as WPA2 TKIP+AES.
>
> HW encryption works when the AP is configured as TKIP-only or AES-only. It
> also works when AP is configured as TKIP+AES but wpa_supplicant is forced to
> use TKIP as pairwise cipher (pairwise=TKIP)
>
> SW encryption works always.
>
> The problem is that no packets are transmitted. I can't see DHCP broadcasts on
> other machine using tcpdump. But when I run tcpdump on the rt2500usb, I see
> broadcasts from the other machine, so receive seems to work fine.
>
> Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
> [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
> [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
> [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
> [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
> [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
> [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
> [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
> [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
> [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
> [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
> [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
> [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
> [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
> [ 373.274533] wlan1: authenticated
> [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
> [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
> [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411 status=0 aid=1)
> [ 373.277704] wlan1: associated
> [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
> [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
> [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
> [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx = 0 OK
> [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
> [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY hw_key_idx = 1 OK
> [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
> [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 375.160246] rt2x00crypto_tx_overhead=8
> [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
> [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
> [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 381.163507] rt2x00crypto_tx_overhead=8
> [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
> [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
> [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 388.165194] rt2x00crypto_tx_overhead=8
> [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
> [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
> [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 399.169481] rt2x00crypto_tx_overhead=8
> [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
> [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
> [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
> [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
> [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 410.168850] rt2x00crypto_tx_overhead=8
> [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
> [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
> [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
> [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
> [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
> [ 422.169699] rt2x00crypto_tx_overhead=8
> [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
> [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
>
> Seems that it's trying to use CCMP, which is good. I wonder if the keys are
> properly handled in rt2500usb_config_key. They seem to be uploaded to the HW
> correctly (one at index 0, one at 1) - but can't tell without any HW docs.
>
> I did some framedumps before but don't know what to do with them (what to
> look for):
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.txt
>
> Anything else I can try?
>
Hi Ondrej,
Did you also test what happens if you configure the AP to be TKIP+AES and force
wpa-supplicant to use AES pairwise key?
If my analysis below is correct then that may work as well.
If my reading of the rt2570 data sheet is correct, then the rt2570 will only
support one encryption mechanism at the time. That means that it is not possible
to upload 1 TKIP key and 1 AES key at the same time to the hardware. All the
configured keys have to be of the same encryption algorithm.
Presumably this is why the HW encryption engine fails, as the keys are set with
mixed settings.
Based on that, I don't think that rt2500usb can support this TKIP+AES setting on
wpa-supplicant.
---
Gertjan.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-22 19:31 UTC (permalink / raw)
To: Matthew Garrett
Cc: Luis R. Rodriguez, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <20100622184426.GA24546@srcf.ucam.org>
On Tue, Jun 22, 2010 at 07:44:26PM +0100, Matthew Garrett wrote:
> On Tue, Jun 22, 2010 at 11:28:20AM -0700, Luis R. Rodriguez wrote:
> >
> > Heh, this whole patch and thread was started because Jussi tested
> > ath5k with pcie_aspm=force (on a pre PCIE 1.1 device (?)) . I have
> > been trying to explain all along why this is a terrible idea to the
> > point we should probably just remove that code from the kernel. Hence
> > my side rants and explanations to justify my reasonings.
>
> Well, there's two things here. If you use force then you might get
> inappropriate ASPM. But if your BIOS enables ASPM on an old device, then
> booting *without* CONFIG_PCIE_ASPM will leave it turned on, and booting
> *with* CONFIG_PCIE_ASPM will turn it off. The Kconfig description is
> confusing - reality is that CONFIG_PCIE_ASPM enables logic that allows
> the kernel to modify the BIOS default, and disabling it makes the
> assumption that your BIOS did something sensible.
Does CONFIG_PCIEASPM provide a way for the user to modifiy
the settings at runtime?
I have a Samsung N130 netbook which has a BIOS setting
called "CPU Power Saving Mode". When enabled it activates
ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
and the PCIE bridge (with the BIOS setting off it's just L1).
The result is that the ethernet througput is reduced to 25Mbit/s.
(The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
99,9% of the time I want to enjoy the power savings,
but occationally I have to transfer some bulk data and would
like to switch the setting for a few minutes.
Or, well, ideally I'd like to have power savings _and_ performance
at the same time without any manual intervention. I'm not sure
if this is a quirk of the N130 or if ASPM L0s always causes
performance degradation?
Thanks
Johannes
^ permalink raw reply
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