* [PATCH] mac80211: fix register_hw error path
From: Johannes Berg @ 2009-08-19 17:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
"cfg80211: fix alignment problem in scan request"
introduced a bug into the error path, because now
we allocate the entire scan request and not just
the channel list (the channel list is allocated
together with the scan request) -- on errors we
thus also need to free the entire scan request.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/main.c 2009-08-19 19:44:18.000000000 +0200
+++ wireless-testing/net/mac80211/main.c 2009-08-19 19:44:20.000000000 +0200
@@ -930,7 +930,7 @@ int ieee80211_register_hw(struct ieee802
fail_workqueue:
wiphy_unregister(local->hw.wiphy);
fail_wiphy_register:
- kfree(local->int_scan_req->channels);
+ kfree(local->int_scan_req);
return result;
}
EXPORT_SYMBOL(ieee80211_register_hw);
^ permalink raw reply
* Re: [PATCH 2/3] Add rfkill support to compal-laptop
From: Johannes Berg @ 2009-08-19 17:13 UTC (permalink / raw)
To: Mario Limonciello
Cc: Alan Jenkins, Marcel Holtmann, cezary.jackiewicz, linux-acpi,
linux-kernel, linux-wireless@vger.kernel.org
In-Reply-To: <4A8C2C6C.2020007@dell.com>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Hi Mario,
First, let me say I agree with Alan, the option 1 is more desirable if
possible to do with the hardware. But this looks ok from an rfkill POV
now, except there's a small bug:
> + ret = setup_rfkill();
> + if (ret)
> + printk(KERN_WARNING "compal-laptop: Unable to setup
> rfkill\n");
That doesn't error out, so
> + rfkill_unregister(wifi_rfkill);
> + rfkill_destroy(wifi_rfkill);
> + rfkill_unregister(bt_rfkill);
> + rfkill_destroy(bt_rfkill);
this will crash without NULL checks.
(and you have to explicitly assign NULL in setup_rfkill() too, when
bluetooth fails and wifi is freed)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] libertas: don't use dynamic-sized array
From: Dan Williams @ 2009-08-19 17:09 UTC (permalink / raw)
To: Andrey Yurovsky; +Cc: linux-wireless
In-Reply-To: <1250210080-21960-1-git-send-email-andrey@cozybit.com>
On Thu, 2009-08-13 at 17:34 -0700, Andrey Yurovsky wrote:
> sparse complains about a bad constant expression due to the use of a
> dynamic-sized array in get_common_rates(). Allocate and free the array
> instead.
Mind testing this patch from libertas-dev? It should fix this but also
clears up some of the confustion:
Subject:
Re: Libertas: Association request to
the driver failed
Date:
Wed, 12 Aug 2009 12:34:17 -0500
Signed-off-by: Dan Williams <dcbw@redhat.com>
diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index 1902b6f..8c05388 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -35,7 +35,8 @@ static const u8 bssid_off[ETH_ALEN] __attribute__ ((aligned (2))) =
*
* @param priv A pointer to struct lbs_private structure
* @param rates the buffer which keeps input and output
- * @param rates_size the size of rate1 buffer; new size of buffer on return
+ * @param rates_size the size of rates buffer; new size of buffer on return,
+ * which will be less than or equal to original rates_size
*
* @return 0 on success, or -1 on error
*/
@@ -43,39 +44,42 @@ static int get_common_rates(struct lbs_private *priv,
u8 *rates,
u16 *rates_size)
{
- u8 *card_rates = lbs_bg_rates;
- int ret = 0, i, j;
- u8 tmp[(ARRAY_SIZE(lbs_bg_rates) - 1) * (*rates_size - 1)];
- size_t tmp_size = 0;
-
- /* For each rate in card_rates that exists in rate1, copy to tmp */
- for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && card_rates[i]; i++) {
- for (j = 0; j < *rates_size && rates[j]; j++) {
- if (rates[j] == card_rates[i])
- tmp[tmp_size++] = card_rates[i];
+ int i, j;
+ u8 intersection[MAX_RATES];
+ u16 intersection_size;
+ u16 num_rates = 0;
+
+ intersection_size = min_t(u16, *rates_size, ARRAY_SIZE(intersection));
+
+ /* Allow each rate from 'rates' that is supported by the hardware */
+ for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && lbs_bg_rates[i]; i++) {
+ for (j = 0; j < intersection_size && rates[j]; j++) {
+ if (rates[j] == lbs_bg_rates[i])
+ intersection[num_rates++] = rates[j];
}
}
lbs_deb_hex(LBS_DEB_JOIN, "AP rates ", rates, *rates_size);
- lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates,
+ lbs_deb_hex(LBS_DEB_JOIN, "card rates ", lbs_bg_rates,
ARRAY_SIZE(lbs_bg_rates));
- lbs_deb_hex(LBS_DEB_JOIN, "common rates", tmp, tmp_size);
+ lbs_deb_hex(LBS_DEB_JOIN, "common rates", intersection, num_rates);
lbs_deb_join("TX data rate 0x%02x\n", priv->cur_rate);
if (!priv->enablehwauto) {
- for (i = 0; i < tmp_size; i++) {
- if (tmp[i] == priv->cur_rate)
+ for (i = 0; i < num_rates; i++) {
+ if (intersection[i] == priv->cur_rate)
goto done;
}
lbs_pr_alert("Previously set fixed data rate %#x isn't "
"compatible with the network.\n", priv->cur_rate);
- ret = -1;
+ return -1;
}
+
done:
memset(rates, 0, *rates_size);
- *rates_size = min_t(int, tmp_size, *rates_size);
- memcpy(rates, tmp, *rates_size);
- return ret;
+ *rates_size = num_rates;
+ memcpy(rates, intersection, num_rates);
+ return 0;
}
@@ -317,8 +321,8 @@ static int lbs_associate(struct lbs_private *priv,
rates = (struct mrvl_ie_rates_param_set *) pos;
rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
- memcpy(&rates->rates, &bss->rates, MAX_RATES);
- tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
+ tmplen = min_t(u16, ARRAY_SIZE(bss->rates), MAX_RATES);
+ memcpy(&rates->rates, &bss->rates, tmplen);
if (get_common_rates(priv, rates->rates, &tmplen)) {
ret = -1;
goto done;
@@ -592,7 +596,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
/* Copy Data rates from the rates recorded in scan response */
memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
- ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
+ ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), ARRAY_SIZE (bss->rates));
memcpy(cmd.bss.rates, bss->rates, ratesize);
if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.\n");
^ permalink raw reply related
* Re: [PATCH 2/3] Add rfkill support to compal-laptop
From: Alan Jenkins @ 2009-08-19 16:57 UTC (permalink / raw)
To: Mario Limonciello
Cc: Johannes Berg, Marcel Holtmann, cezary.jackiewicz, linux-acpi,
linux-kernel, linux-wireless@vger.kernel.org
In-Reply-To: <4A8C2C6C.2020007@dell.com>
On 8/19/09, Mario Limonciello <mario_limonciello@dell.com> wrote:
> Hi Johannes:
>
> Thanks for looking.
>
> Johannes Berg wrote:
>> Ah, heh, thanks Alan for pointing out there was a patch here :)
>>
>>
>>
>> I don't quite understand the "| radio" bit since that seems to be the
>> soft kill bit according to rfkill_set()?
>>
> Yeah you're right, this bit was unnecessary. I pulled it out.
>> Anyhow, here you reject the request to set the soft bit. I suspect you
>> could let it go through but it would only change the soft bit in the
>> BIOS, nothing else really.
>>
>> Two options:
>> 1) You can let it go though, in that case do that, and remove the sw
>> block stuff from poll() completely.
>>
>> 2) You can't let it go through. In this case, you need to leave set as
>> it is, but implement poll like this:
>>
>> sw_block = rfkill_set_hw_state(rfkill, hw_blocked);
>> compal_rfkill_set(data, sw_block);
>>
>> so that when the user soft-blocks the device while hard-blocked, the
>> soft block is still honoured after pushing the button on the laptop.
>>
>>
> OK, the second option sounds more desirable, so I've implemented that.
I think the first option is more _desirable_, it's more a matter of
whether it can work well on this hardware.
In case 2), the radio will be unblocked for a short period between the
button-press, and the next poll() call. But 1) won't work if the
hardware "forgets" the soft block when the hard block is toggled on
and off.
Regards
Alan
^ permalink raw reply
* Re: [PATCH 2/3] Add rfkill support to compal-laptop
From: Mario Limonciello @ 2009-08-19 16:46 UTC (permalink / raw)
To: Johannes Berg
Cc: Alan Jenkins, Marcel Holtmann, cezary.jackiewicz, linux-acpi,
linux-kernel, linux-wireless@vger.kernel.org
In-Reply-To: <1250672475.25419.7.camel@johannes.local>
[-- Attachment #1.1: Type: text/plain, Size: 1164 bytes --]
Hi Johannes:
Thanks for looking.
Johannes Berg wrote:
> Ah, heh, thanks Alan for pointing out there was a patch here :)
>
>
>
> I don't quite understand the "| radio" bit since that seems to be the
> soft kill bit according to rfkill_set()?
>
Yeah you're right, this bit was unnecessary. I pulled it out.
> Anyhow, here you reject the request to set the soft bit. I suspect you
> could let it go through but it would only change the soft bit in the
> BIOS, nothing else really.
>
> Two options:
> 1) You can let it go though, in that case do that, and remove the sw
> block stuff from poll() completely.
>
> 2) You can't let it go through. In this case, you need to leave set as
> it is, but implement poll like this:
>
> sw_block = rfkill_set_hw_state(rfkill, hw_blocked);
> compal_rfkill_set(data, sw_block);
>
> so that when the user soft-blocks the device while hard-blocked, the
> soft block is still honoured after pushing the button on the laptop.
>
>
OK, the second option sounds more desirable, so I've implemented that.
--
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 02_add_rfkill_support.diff --]
[-- Type: text/x-patch; name="02_add_rfkill_support.diff", Size: 3952 bytes --]
From 5f5dc9c1adf041418c6dd273cd4ee83d5ae96e74 Mon Sep 17 00:00:00 2001
From: Mario Limonciello <Mario_Limonciello@Dell.com>
Date: Wed, 19 Aug 2009 11:41:27 -0500
Subject: [PATCH 2/3] Add rfkill support to compal-laptop
Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
Reviewed-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/compal-laptop.c | 91 +++++++++++++++++++++++++++++++++-
1 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/compal-laptop.c b/drivers/platform/x86/compal-laptop.c
index 11003bb..d997de5 100644
--- a/drivers/platform/x86/compal-laptop.c
+++ b/drivers/platform/x86/compal-laptop.c
@@ -52,6 +52,7 @@
#include <linux/backlight.h>
#include <linux/platform_device.h>
#include <linux/autoconf.h>
+#include <linux/rfkill.h>
#define COMPAL_DRIVER_VERSION "0.2.6"
@@ -64,6 +65,10 @@
#define WLAN_MASK 0x01
#define BT_MASK 0x02
+static struct rfkill *wifi_rfkill;
+static struct rfkill *bt_rfkill;
+static struct platform_device *compal_device;
+
static int force;
module_param(force, bool, 0);
MODULE_PARM_DESC(force, "Force driver load, ignore DMI data");
@@ -89,6 +94,82 @@ static int get_lcd_level(void)
return (int) result;
}
+static int compal_rfkill_set(void *data, bool blocked)
+{
+ unsigned long radio = (unsigned long) data;
+ u8 result, value;
+
+ ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
+
+ if ((result & KILLSWITCH_MASK) == 0)
+ return -EINVAL;
+
+ if (!blocked)
+ value = (u8) (result | radio);
+ else
+ value = (u8) (result & ~radio);
+ ec_write(COMPAL_EC_COMMAND_WIRELESS, value);
+
+ return 0;
+}
+
+static void compal_rfkill_poll(struct rfkill *rfkill, void *data)
+{
+ u8 result;
+ bool hw_blocked;
+ bool sw_blocked;
+
+ ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
+
+ hw_blocked = !(result & KILLSWITCH_MASK);
+ sw_blocked = rfkill_set_hw_state(rfkill, hw_blocked);
+ compal_rfkill_set(data,sw_blocked);
+}
+
+static const struct rfkill_ops compal_rfkill_ops = {
+ .poll = compal_rfkill_poll,
+ .set_block = compal_rfkill_set,
+};
+
+static int setup_rfkill(void)
+{
+ int ret;
+
+ wifi_rfkill = rfkill_alloc("compal-wifi", &compal_device->dev,
+ RFKILL_TYPE_WLAN, &compal_rfkill_ops,
+ (void *) WLAN_MASK);
+ if (!wifi_rfkill)
+ return -ENOMEM;
+
+ ret = rfkill_register(wifi_rfkill);
+ if (ret)
+ goto err_wifi;
+
+ bt_rfkill = rfkill_alloc("compal-bluetooth", &compal_device->dev,
+ RFKILL_TYPE_BLUETOOTH, &compal_rfkill_ops,
+ (void *) BT_MASK);
+ if (!bt_rfkill) {
+ ret = -ENOMEM;
+ goto err_allocate_bt;
+ }
+ ret = rfkill_register(bt_rfkill);
+ if (ret)
+ goto err_register_bt;
+
+ return 0;
+
+err_register_bt:
+ rfkill_destroy(bt_rfkill);
+
+err_allocate_bt:
+ rfkill_unregister(wifi_rfkill);
+
+err_wifi:
+ rfkill_destroy(wifi_rfkill);
+
+ return ret;
+}
+
static int set_wlan_state(int state)
{
u8 result, value;
@@ -258,8 +339,6 @@ static struct platform_driver compal_driver = {
}
};
-static struct platform_device *compal_device;
-
/* Initialization */
static int dmi_check_cb(const struct dmi_system_id *id)
@@ -356,6 +435,10 @@ static int __init compal_init(void)
if (ret)
goto fail_platform_device2;
+ ret = setup_rfkill();
+ if (ret)
+ printk(KERN_WARNING "compal-laptop: Unable to setup rfkill\n");
+
printk(KERN_INFO "compal-laptop: driver "COMPAL_DRIVER_VERSION
" successfully loaded.\n");
@@ -387,6 +470,10 @@ static void __exit compal_cleanup(void)
platform_device_unregister(compal_device);
platform_driver_unregister(&compal_driver);
backlight_device_unregister(compalbl_device);
+ rfkill_unregister(wifi_rfkill);
+ rfkill_destroy(wifi_rfkill);
+ rfkill_unregister(bt_rfkill);
+ rfkill_destroy(bt_rfkill);
printk(KERN_INFO "compal-laptop: driver unloaded.\n");
}
--
1.6.3.3
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply related
* Re: question about ieee80211_tx.c (fwd)
From: Dan Williams @ 2009-08-19 16:39 UTC (permalink / raw)
To: Greg KH
Cc: Zhu Yi, Gábor Stefanik, Julia Lawall,
linux-wireless@vger.kernel.org
In-Reply-To: <20090819163328.GA3057@suse.de>
On Wed, 2009-08-19 at 09:33 -0700, Greg KH wrote:
> On Wed, Aug 19, 2009 at 11:32:08AM -0500, Dan Williams wrote:
> > On Mon, 2009-08-17 at 18:35 -0700, Greg KH wrote:
> > > On Tue, Aug 18, 2009 at 09:13:41AM +0800, Zhu Yi wrote:
> > > > On Mon, 2009-08-17 at 19:50 +0800, Gábor Stefanik wrote:
> > > > > On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<julia@diku.dk> wrote:
> > > > > > The files ieee80211_tx.c in the directories
> > > > > > drivers/staging/rtl8192su/ieee80211 and
> > > > > drivers/staging/rtl8192e/ieee80211
> > > > > > both contain the following code in the function
> > > > > > ieee80211_query_protectionmode:
> > > > > >
> > > > > > if (ieee->mode == IW_MODE_MASTER)
> > > > > > goto NO_PROTECTION;
> > > > > >
> > > > > > Elsewhere in these files when there is a comparison against an
> > > > > IW_MODE
> > > > > > value, the field that is compared is iw_mode. Should that be the
> > > > > case
> > > > > > here as well?
> > > > > >
> > > > > > thanks,
> > > > > > julia
> > > > >
> > > > > I don't know; rtl8192su & rtl8192e use a modified version of the
> > > > > libipw stack, rather than the mac80211 stack found behind non-staging
> > > > > drivers.
> > > >
> > > > This is clearly a bug. The question is: who is maintaining this driver
> > > > and why it doesn't use/extend ieee80211/libipw?
> > >
> > > I maintain it, and I am working to convert it to use the existing
> > > ieee80211 stack that is in the kernel. Remember, these are drivers in
> > > the staging tree, they are usually "crap" :)
> >
> > When you say "ieee80211" you mean mac80211, right?
>
> Sorry, yes, whatever the wireless stack in the main kernel is called
> these days :)
We used to have the ieee80211 that rtl* forked its internal ieee80211
off of, but we just successfully made that code private to ipw2x00 (now
called "libipw") earlier this year. Wanted to make sure any effort was
correctly targeting mac80211 instead of libipw.
Dan
^ permalink raw reply
* Re: question about ieee80211_tx.c (fwd)
From: Greg KH @ 2009-08-19 16:33 UTC (permalink / raw)
To: Dan Williams
Cc: Zhu Yi, Gábor Stefanik, Julia Lawall,
linux-wireless@vger.kernel.org
In-Reply-To: <1250699528.5351.18.camel@localhost.localdomain>
On Wed, Aug 19, 2009 at 11:32:08AM -0500, Dan Williams wrote:
> On Mon, 2009-08-17 at 18:35 -0700, Greg KH wrote:
> > On Tue, Aug 18, 2009 at 09:13:41AM +0800, Zhu Yi wrote:
> > > On Mon, 2009-08-17 at 19:50 +0800, Gábor Stefanik wrote:
> > > > On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<julia@diku.dk> wrote:
> > > > > The files ieee80211_tx.c in the directories
> > > > > drivers/staging/rtl8192su/ieee80211 and
> > > > drivers/staging/rtl8192e/ieee80211
> > > > > both contain the following code in the function
> > > > > ieee80211_query_protectionmode:
> > > > >
> > > > > if (ieee->mode == IW_MODE_MASTER)
> > > > > goto NO_PROTECTION;
> > > > >
> > > > > Elsewhere in these files when there is a comparison against an
> > > > IW_MODE
> > > > > value, the field that is compared is iw_mode. Should that be the
> > > > case
> > > > > here as well?
> > > > >
> > > > > thanks,
> > > > > julia
> > > >
> > > > I don't know; rtl8192su & rtl8192e use a modified version of the
> > > > libipw stack, rather than the mac80211 stack found behind non-staging
> > > > drivers.
> > >
> > > This is clearly a bug. The question is: who is maintaining this driver
> > > and why it doesn't use/extend ieee80211/libipw?
> >
> > I maintain it, and I am working to convert it to use the existing
> > ieee80211 stack that is in the kernel. Remember, these are drivers in
> > the staging tree, they are usually "crap" :)
>
> When you say "ieee80211" you mean mac80211, right?
Sorry, yes, whatever the wireless stack in the main kernel is called
these days :)
thanks,
greg k-h
^ permalink raw reply
* Re: question about ieee80211_tx.c (fwd)
From: Dan Williams @ 2009-08-19 16:32 UTC (permalink / raw)
To: Greg KH
Cc: Zhu Yi, Gábor Stefanik, Julia Lawall,
linux-wireless@vger.kernel.org
In-Reply-To: <20090818013502.GD20566@suse.de>
On Mon, 2009-08-17 at 18:35 -0700, Greg KH wrote:
> On Tue, Aug 18, 2009 at 09:13:41AM +0800, Zhu Yi wrote:
> > On Mon, 2009-08-17 at 19:50 +0800, Gábor Stefanik wrote:
> > > On Mon, Aug 17, 2009 at 10:03 AM, Julia Lawall<julia@diku.dk> wrote:
> > > > The files ieee80211_tx.c in the directories
> > > > drivers/staging/rtl8192su/ieee80211 and
> > > drivers/staging/rtl8192e/ieee80211
> > > > both contain the following code in the function
> > > > ieee80211_query_protectionmode:
> > > >
> > > > if (ieee->mode == IW_MODE_MASTER)
> > > > goto NO_PROTECTION;
> > > >
> > > > Elsewhere in these files when there is a comparison against an
> > > IW_MODE
> > > > value, the field that is compared is iw_mode. Should that be the
> > > case
> > > > here as well?
> > > >
> > > > thanks,
> > > > julia
> > >
> > > I don't know; rtl8192su & rtl8192e use a modified version of the
> > > libipw stack, rather than the mac80211 stack found behind non-staging
> > > drivers.
> >
> > This is clearly a bug. The question is: who is maintaining this driver
> > and why it doesn't use/extend ieee80211/libipw?
>
> I maintain it, and I am working to convert it to use the existing
> ieee80211 stack that is in the kernel. Remember, these are drivers in
> the staging tree, they are usually "crap" :)
When you say "ieee80211" you mean mac80211, right?
Dan
^ permalink raw reply
* Re: [PATCH v5 00/33] wireless: kconfig updates
From: John W. Linville @ 2009-08-19 15:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1250530052-14783-1-git-send-email-lrodriguez@atheros.com>
On Mon, Aug 17, 2009 at 01:26:59PM -0400, Luis R. Rodriguez wrote:
> This is revision number 5 on the wireless kconfig updates, I apologize
> for the spam but I had to rebase based on reviews on some earlier
> patches. In this series I've removed the .ko references for modules
> both in the commit logs and in the kconfig entries, I've also
> made the changes pointed out in the TI kconfig, and left the comments
> on the mac80211 and cfg80211 kconfig simpler based on johill's feedback.
>
> I left out the patch that selects cfg80211 when you select mac80211
> as there is an issue there that is still under review (building cfg80211
> and mac80211 built-in but rfkill as a module).
I'm sorry, I know you've put some effort into this. A lot of it seems
fine, even welcome. But I don't really see the point of grouping
everything by manufacturer -- it just seems to add an extra level of
organization for no particular reason...?
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
* Re: [PATCH] b43: LP-PHY: Implement spec updates and remove resolved FIXMEs
From: Gábor Stefanik @ 2009-08-19 14:57 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger
Cc: Mark Huijgen, Broadcom Wireless, linux-wireless
In-Reply-To: <69e28c910908190430x5223cf6al460e8008c36c3111@mail.gmail.com>
False alert, sorry. Feel free to apply. The "regression" apparently
resulted from the use of an incorrect firmware image - when Mark
switched to the same firmware as Larry, his card started working
again.
2009/8/19 Gábor Stefanik <netrolller.3d@gmail.com>:
> John, please hold off this patch for now, it appears to be causing
> regressions. I will investigate this.
>
> 2009/8/18 Gábor Stefanik <netrolller.3d@gmail.com>:
>> Larry has started re-checking all current routines against a new
>> version of the Broadcom MIPS driver. This patch implements the first
>> round of changes he documented on the specs wiki.
>>
>> Also remove a few FIXMEs regarding missing initial values for variables
>> with dynamic initial values where reading the values has been implemented.
>>
>> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
>> ---
>> drivers/net/wireless/b43/phy_lp.c | 98
>> +++++++++++++++++++------------
>> drivers/net/wireless/b43/phy_lp.h | 18 +++---
>> drivers/net/wireless/b43/tables_lpphy.c | 12 ++++-
>> 3 files changed, 82 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/phy_lp.c
>> b/drivers/net/wireless/b43/phy_lp.c
>> index 242338f..6c69cdb 100644
>> --- a/drivers/net/wireless/b43/phy_lp.c
>> +++ b/drivers/net/wireless/b43/phy_lp.c
>> @@ -719,9 +719,39 @@ static void lpphy_set_bb_mult(struct b43_wldev *dev, u8
>> bb_mult)
>> b43_lptab_write(dev, B43_LPTAB16(0, 87), (u16)bb_mult << 8);
>> }
>>
>> -static void lpphy_disable_crs(struct b43_wldev *dev)
>> +static void lpphy_set_deaf(struct b43_wldev *dev, bool user)
>> {
>> + struct b43_phy_lp *lpphy = dev->phy.lp;
>> +
>> + if (user)
>> + lpphy->crs_usr_disable = 1;
>> + else
>> + lpphy->crs_sys_disable = 1;
>> b43_phy_maskset(dev, B43_LPPHY_CRSGAIN_CTL, 0xFF1F, 0x80);
>> +}
>> +
>> +static void lpphy_clear_deaf(struct b43_wldev *dev, bool user)
>> +{
>> + struct b43_phy_lp *lpphy = dev->phy.lp;
>> +
>> + if (user)
>> + lpphy->crs_usr_disable = 0;
>> + else
>> + lpphy->crs_sys_disable = 0;
>> +
>> + if (!lpphy->crs_usr_disable && !lpphy->crs_sys_disable) {
>> + if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ)
>> + b43_phy_maskset(dev, B43_LPPHY_CRSGAIN_CTL,
>> + 0xFF1F, 0x60);
>> + else
>> + b43_phy_maskset(dev, B43_LPPHY_CRSGAIN_CTL,
>> + 0xFF1F, 0x20);
>> + }
>> +}
>> +
>> +static void lpphy_disable_crs(struct b43_wldev *dev, bool user)
>> +{
>> + lpphy_set_deaf(dev, user);
>> b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, 0x1);
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFB);
>> @@ -749,12 +779,9 @@ static void lpphy_disable_crs(struct b43_wldev *dev)
>> b43_phy_write(dev, B43_LPPHY_RF_OVERRIDE_2, 0x3FF);
>> }
>>
>> -static void lpphy_restore_crs(struct b43_wldev *dev)
>> +static void lpphy_restore_crs(struct b43_wldev *dev, bool user)
>> {
>> - if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ)
>> - b43_phy_maskset(dev, B43_LPPHY_CRSGAIN_CTL, 0xFF1F, 0x60);
>> - else
>> - b43_phy_maskset(dev, B43_LPPHY_CRSGAIN_CTL, 0xFF1F, 0x20);
>> + lpphy_clear_deaf(dev, user);
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFF80);
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFC00);
>> }
>> @@ -800,10 +827,11 @@ static void lpphy_set_tx_gains(struct b43_wldev *dev,
>> b43_phy_maskset(dev, B43_LPPHY_TX_GAIN_CTL_OVERRIDE_VAL,
>> 0xF800, rf_gain);
>> } else {
>> - pa_gain = b43_phy_read(dev, B43_PHY_OFDM(0xFB)) & 0x7F00;
>> + pa_gain = b43_phy_read(dev, B43_PHY_OFDM(0xFB)) & 0x1FC0;
>> + pa_gain <<= 2;
>> b43_phy_write(dev, B43_LPPHY_TX_GAIN_CTL_OVERRIDE_VAL,
>> (gains.pga << 8) | gains.gm);
>> - b43_phy_maskset(dev, B43_LPPHY_TX_GAIN_CTL_OVERRIDE_VAL,
>> + b43_phy_maskset(dev, B43_PHY_OFDM(0xFB),
>> 0x8000, gains.pad | pa_gain);
>> b43_phy_write(dev, B43_PHY_OFDM(0xFC),
>> (gains.pga << 8) | gains.gm);
>> @@ -817,7 +845,7 @@ static void lpphy_set_tx_gains(struct b43_wldev *dev,
>> b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFF7F, 1 <<
>> 7);
>> b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_2, 0xBFFF, 1 <<
>> 14);
>> }
>> - b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFFBF, 1 << 6);
>> + b43_phy_maskset(dev, B43_LPPHY_AFE_CTL_OVR, 0xFFBF, 1 << 6);
>> }
>>
>> static void lpphy_rev0_1_set_rx_gain(struct b43_wldev *dev, u32 gain)
>> @@ -857,33 +885,33 @@ static void lpphy_rev2plus_set_rx_gain(struct
>> b43_wldev *dev, u32 gain)
>> }
>> }
>>
>> -static void lpphy_enable_rx_gain_override(struct b43_wldev *dev)
>> +static void lpphy_disable_rx_gain_override(struct b43_wldev *dev)
>> {
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFFE);
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFEF);
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_0, 0xFFBF);
>> if (dev->phy.rev >= 2) {
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFEFF);
>> - if (b43_current_band(dev->wl) != IEEE80211_BAND_2GHZ)
>> - return;
>> - b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFBFF);
>> - b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFFF7);
>> + if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ) {
>> + b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFBFF);
>> + b43_phy_mask(dev, B43_PHY_OFDM(0xE5), 0xFFF7);
>> + }
>> } else {
>> b43_phy_mask(dev, B43_LPPHY_RF_OVERRIDE_2, 0xFDFF);
>> }
>> }
>>
>> -static void lpphy_disable_rx_gain_override(struct b43_wldev *dev)
>> +static void lpphy_enable_rx_gain_override(struct b43_wldev *dev)
>> {
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x1);
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x10);
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x40);
>> if (dev->phy.rev >= 2) {
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x100);
>> - if (b43_current_band(dev->wl) != IEEE80211_BAND_2GHZ)
>> - return;
>> - b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x400);
>> - b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x8);
>> + if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ) {
>> + b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x400);
>> + b43_phy_set(dev, B43_PHY_OFDM(0xE5), 0x8);
>> + }
>> } else {
>> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_2, 0x200);
>> }
>> @@ -1002,26 +1030,22 @@ static u32 lpphy_qdiv_roundup(u32 dividend, u32
>> divisor, u8 precision)
>> {
>> u32 quotient, remainder, rbit, roundup, tmp;
>>
>> - if (divisor == 0) {
>> - quotient = 0;
>> - remainder = 0;
>> - } else {
>> - quotient = dividend / divisor;
>> - remainder = dividend % divisor;
>> - }
>> + if (divisor == 0)
>> + return 0;
>> +
>> + quotient = dividend / divisor;
>> + remainder = dividend % divisor;
>>
>> rbit = divisor & 0x1;
>> roundup = (divisor >> 1) + rbit;
>> - precision--;
>>
>> - while (precision != 0xFF) {
>> + while (precision != 0) {
>> tmp = remainder - roundup;
>> quotient <<= 1;
>> - remainder <<= 1;
>> - if (remainder >= roundup) {
>> + if (remainder >= roundup)
>> remainder = (tmp << 1) + rbit;
>> - quotient--;
>> - }
>> + else
>> + remainder <<= 1;
>> precision--;
>> }
>>
>> @@ -1123,11 +1147,11 @@ static void lpphy_rev0_1_rc_calib(struct b43_wldev
>> *dev)
>> struct b43_phy_lp *lpphy = dev->phy.lp;
>> struct lpphy_iq_est iq_est;
>> struct lpphy_tx_gains tx_gains;
>> - static const u32 ideal_pwr_table[22] = {
>> + static const u32 ideal_pwr_table[21] = {
>> 0x10000, 0x10557, 0x10e2d, 0x113e0, 0x10f22, 0x0ff64,
>> 0x0eda2, 0x0e5d4, 0x0efd1, 0x0fbe8, 0x0b7b8, 0x04b35,
>> 0x01a5e, 0x00a0b, 0x00444, 0x001fd, 0x000ff, 0x00088,
>> - 0x0004c, 0x0002c, 0x0001a, 0xc0006,
>> + 0x0004c, 0x0002c, 0x0001a,
>> };
>> bool old_txg_ovr;
>> u8 old_bbmult;
>> @@ -1145,7 +1169,7 @@ static void lpphy_rev0_1_rc_calib(struct b43_wldev
>> *dev)
>> "RC calib: Failed to switch to channel 7, error = %d",
>> err);
>> }
>> - old_txg_ovr = (b43_phy_read(dev, B43_LPPHY_AFE_CTL_OVR) >> 6) & 1;
>> + old_txg_ovr = !!(b43_phy_read(dev, B43_LPPHY_AFE_CTL_OVR) & 0x40);
>> old_bbmult = lpphy_get_bb_mult(dev);
>> if (old_txg_ovr)
>> tx_gains = lpphy_get_tx_gains(dev);
>> @@ -1160,7 +1184,7 @@ static void lpphy_rev0_1_rc_calib(struct b43_wldev
>> *dev)
>> old_txpctl = lpphy->txpctl_mode;
>>
>> lpphy_set_tx_power_control(dev, B43_LPPHY_TXPCTL_OFF);
>> - lpphy_disable_crs(dev);
>> + lpphy_disable_crs(dev, true);
>> loopback = lpphy_loopback(dev);
>> if (loopback == -1)
>> goto finish;
>> @@ -1193,7 +1217,7 @@ static void lpphy_rev0_1_rc_calib(struct b43_wldev
>> *dev)
>> lpphy_stop_ddfs(dev);
>>
>> finish:
>> - lpphy_restore_crs(dev);
>> + lpphy_restore_crs(dev, true);
>> b43_phy_write(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, old_rf_ovrval);
>> b43_phy_write(dev, B43_LPPHY_RF_OVERRIDE_0, old_rf_ovr);
>> b43_phy_write(dev, B43_LPPHY_AFE_CTL_OVRVAL, old_afe_ovrval);
>> diff --git a/drivers/net/wireless/b43/phy_lp.h
>> b/drivers/net/wireless/b43/phy_lp.h
>> index 99cb038..e158d1f 100644
>> --- a/drivers/net/wireless/b43/phy_lp.h
>> +++ b/drivers/net/wireless/b43/phy_lp.h
>> @@ -825,11 +825,11 @@ struct b43_phy_lp {
>> enum b43_lpphy_txpctl_mode txpctl_mode;
>>
>> /* Transmit isolation medium band */
>> - u8 tx_isolation_med_band; /* FIXME initial value? */
>> + u8 tx_isolation_med_band;
>> /* Transmit isolation low band */
>> - u8 tx_isolation_low_band; /* FIXME initial value? */
>> + u8 tx_isolation_low_band;
>> /* Transmit isolation high band */
>> - u8 tx_isolation_hi_band; /* FIXME initial value? */
>> + u8 tx_isolation_hi_band;
>>
>> /* Max transmit power medium band */
>> u16 max_tx_pwr_med_band;
>> @@ -848,7 +848,7 @@ struct b43_phy_lp {
>> s16 txpa[3], txpal[3], txpah[3];
>>
>> /* Receive power offset */
>> - u8 rx_pwr_offset; /* FIXME initial value? */
>> + u8 rx_pwr_offset;
>>
>> /* TSSI transmit count */
>> u16 tssi_tx_count;
>> @@ -864,16 +864,16 @@ struct b43_phy_lp {
>> s8 tx_pwr_idx_over; /* FIXME initial value? */
>>
>> /* RSSI vf */
>> - u8 rssi_vf; /* FIXME initial value? */
>> + u8 rssi_vf;
>> /* RSSI vc */
>> - u8 rssi_vc; /* FIXME initial value? */
>> + u8 rssi_vc;
>> /* RSSI gs */
>> - u8 rssi_gs; /* FIXME initial value? */
>> + u8 rssi_gs;
>>
>> /* RC cap */
>> u8 rc_cap; /* FIXME initial value? */
>> /* BX arch */
>> - u8 bx_arch; /* FIXME initial value? */
>> + u8 bx_arch;
>>
>> /* Full calibration channel */
>> u8 full_calib_chan; /* FIXME initial value? */
>> @@ -885,6 +885,8 @@ struct b43_phy_lp {
>> /* Used for "Save/Restore Dig Filt State" */
>> u16 dig_flt_state[9];
>>
>> + bool crs_usr_disable, crs_sys_disable;
>> +
>> unsigned int pdiv;
>> };
>>
>> diff --git a/drivers/net/wireless/b43/tables_lpphy.c
>> b/drivers/net/wireless/b43/tables_lpphy.c
>> index 2721310..60d472f 100644
>> --- a/drivers/net/wireless/b43/tables_lpphy.c
>> +++ b/drivers/net/wireless/b43/tables_lpphy.c
>> @@ -2367,7 +2367,17 @@ static void lpphy_rev2plus_write_gain_table(struct
>> b43_wldev *dev, int offset,
>> tmp = data.pad << 16;
>> tmp |= data.pga << 8;
>> tmp |= data.gm;
>> - tmp |= 0x7f000000;
>> + if (dev->phy.rev >= 3) {
>> + if (b43_current_band(dev->wl) == IEEE80211_BAND_5GHZ)
>> + tmp |= 0x10 << 24;
>> + else
>> + tmp |= 0x70 << 24;
>> + } else {
>> + if (b43_current_band(dev->wl) == IEEE80211_BAND_5GHZ)
>> + tmp |= 0x14 << 24;
>> + else
>> + tmp |= 0x7F << 24;
>> + }
>> b43_lptab_write(dev, B43_LPTAB32(7, 0xC0 + offset), tmp);
>> tmp = data.bb_mult << 20;
>> tmp |= data.dac << 28;
>> --
>> 1.6.2.4
>>
>>
>>
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!
From: Gábor Stefanik @ 2009-08-19 14:54 UTC (permalink / raw)
To: Mark Huijgen
Cc: Johannes Berg, Larry Finger, Broadcom Wireless, linux-wireless
In-Reply-To: <4A8C0B38.2020402@huijgen.tk>
2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>
>>> Gábor Stefanik wrote:
>>>
>>>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>>>
>>>>
>>>>> Gábor Stefanik wrote:
>>>>>
>>>>>
>>>>>> Mark, could you produce a dmesg output with the new firmware, patches
>>>>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>>>>> & probably associating, if possible. (Scan/assoc may produce messages
>>>>>> in dmesg.)
>>>>>>
>>>>>>
>>>>>>
>>>>> I tested this already, but with default chan set to 1, I cannot get the
>>>>> interface up.
>>>>> This is somewhere in my mail, but it got a bit messy after I noticed
>>>>> that after
>>>>> changing some of the code my modules got installed in another directory
>>>>> (-dirty).
>>>>>
>>>>> I just restarted the notebook, but now the results are different again...
>>>>>
>>>>> New firmware, with patches applied and default channel 7:
>>>>> [ 72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>>>>> 00:50:23)
>>>>> [ 72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>>>>> error = -5
>>>>> [ 72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>>>>
>>>>> Recompile module with default chan 1, patches still applied and new
>>>>> firmware,
>>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>>
>>>>> [ 430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>>>>
>>>>> Recompile again, but with default chan back to 7, still patched and
>>>>> still new firmware.
>>>>> So same as in first situation:
>>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>>
>>>>> [ 524.748062] b43-phy3 debug: Chip initialized
>>>>>
>>>>> And I can get my interface up and working!
>>>>>
>>>>> Without this procedure I have not been able to get a working chip. Seems
>>>>> the partially
>>>>> initialized state after each try, allows the next try to get a bit
>>>>> further. And together with
>>>>> the default channel switching between 1 and 7, I get a working chip, but
>>>>> a chip that does
>>>>> not seem to be able to find my AP thats on channel 1.
>>>>>
>>>>> If I now change default chan to 1 again, I am getting the same error as
>>>>> in step 2 above.
>>>>> I have not been able to get the interface up with default chan set to 1.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>>
>>>> What do you see in dmesg after running a scan?
>>>>
>>>>
>>> After step 2, interface cannot be brought up:
>>> # iw dev wlan0 scan
>>> command failed: Network is down (-100)
>>>
>>> No extra output in dmesg
>>>
>>> After step 3 (so with default chan 7 again), interface comes up and I
>>> can scan:
>>> # iw dev wlan0 scan
>>> <<list of scan results>>
>>>
>>> No extra output generated in dmesg.
>>>
>>> I must add that I do not have debugging messages enabled for any
>>> mac80211 related options, only for b43 module.
>>>
>>
>> That's not needed.
>>
>> However, try "iw dev wlan0 scan trigger".
>>
>> Also, try switching to all B/G channels manually.
>>
> To summarize, all cases with patches and new firmware:
> case 1: cold boot with default channel 7, RC calib error and 'init
> channel failed' error,
> case 2: recompile+reload b43 with default channel 1, just 'init channel
> failed' error,
> case 3: recompile+reload b43 with default channel 7, works
>
>
> You mean 'iw dev wlan0 set channel 1' for example?
>
> In case 2 (with default chan 1), ifconfig wlan0 gives error
> "SIOCSIFFLAGS: Input/output error"
>
> # iw dev wlan0 set channel 1
> no output generated, also nothing in dmesg
>
> # iw dev wlan0 scan trigger
> command failed: Network is down (-100)
> nothing in dmesg.
>
> Both commands do not give any output in dmesg in case 3 either.
>
> Tried channel 1 up to 11, 12 and higher gives 'command failed: Invalid
> argument (-22)', which is expected I think.
Set your regulatory domain to something that allows higher channels
(e.g. iw reg set JP - this one unlocks channels 1-14 (14 is
CCK/802.11b only); or iw reg set HU - channels 1-13) to test channels
14 and up.
Also, test this:
Create a monitor interface (iw dev wlan0 interface add mon0 type monitor)
Up the interface (ifconfig mon0 up)
Set channel to 1 (iwconfig mon0 channel 1 or iw dev wlan0 set channel 1)
Run tcpdump on the interface (tcpdump -i mon0).
Try for other channel values as well. (You don't need to recreate the
interface for each channel, just use the channel-setting command to
switch the channel.) You should see packets on all channels.
Another thing to try: add a printk to b43_lpphy_op_set_channel and
print out new_channel. This will log all channel change requests
(including automatic ones) to dmesg, which can be helpful.
If you set your AP to channel 11, can you connect to it & use it as normal?
>
>
>
>> One more thing to try is create a monitor interface and run kismet on
>> it. In addition, you can use aireplay-ng on the monitor interface to
>> test TX.
>>
> Never done anything with monitor mode before, so when I have some time
> I'll look into it.
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [RFT] p54: implement rfkill
From: John W. Linville @ 2009-08-19 14:41 UTC (permalink / raw)
To: Larry Finger; +Cc: Christian Lamparter, wireless
In-Reply-To: <4A7C58CC.2040708@lwfinger.net>
On Fri, Aug 07, 2009 at 11:39:40AM -0500, Larry Finger wrote:
> John W. Linville wrote:
> > On Sun, Jul 19, 2009 at 11:54:15PM +0200, Christian Lamparter wrote:
> >> This patch gets rid of the deprecated radio_enabled
> >>
> >> fwio.c: In function ‘p54_setup_mac’:
> >> fwio.c:323: warning: ‘radio_enabled’ is deprecated (declared at include/net/mac80211.h:607)
> >
> > Anyone had a chance to test this? And report the results to Christian?
>
> Sorry - I missed this one.
>
> I just tested it. With the patch, the warning is removed. As far as
> system operation, the following is observed:
>
> 1. If b43 is loaded when using p54usb, then the hardware switch will
> kill operation. This behavior is the same with or without this patch.
>
> 2. If b43 is unloaded, then p54usb no longer follows the hardware
> switch, but operation can be killed with the rfkill user-space
> utility. Again, this behavior does not depend on the patch.
>
> Based on the code changes in the patch, it looks as if the radio is
> turned off when the device is blocked, but I have no way to test that.
>
> Christian - please add a
> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> to the patch and
> submit. This change should be in 2.6.32.
>
> Larry
Original patch lacks a Signed-off-by...
--
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 6/5] dell-laptop: remove duplicate Kconfig entry under drivers/misc
From: Alan Jenkins @ 2009-08-19 14:44 UTC (permalink / raw)
To: Matthew Garrett; +Cc: marcel, linux-acpi, linux-kernel, linux-wireless
In-Reply-To: <20090819141322.GA15937@srcf.ucam.org>
Matthew Garrett wrote:
> On Wed, Aug 19, 2009 at 03:06:51PM +0100, Alan Jenkins wrote:
>
>> This is controlled by a hardware switch, so we should poll it in order
>> to pick up changes. (There does not appear to be an interrupt or any
>> other notification mechanism).
>>
>
> With the exception of this one they all look fine - I'm moving house
> next week and won't have access to any Dell hardware for over a month,
> so if anyone else could confirm that these work that would be excellent.
>
>
Ok, thanks!
Here's something else I just noticed. I was able to test this one myself.
----------------------------------------------------------------------
>From 7efa12d3ea8bb70897358b4a87f8dedce9b78cca Mon Sep 17 00:00:00 2001
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date: Wed, 19 Aug 2009 15:32:17 +0100
Subject: [PATCH] dell-laptop: remove duplicate Kconfig entry under drivers/misc
This showed up as an unselectable option when using xconfig and
searching for "dell". It must been overlooked when dell-laptop
was moved to drivers/platform/x86.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/misc/Kconfig | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 68ab39d..22414c5 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -210,19 +210,6 @@ config SGI_GRU_DEBUG
This option enables addition debugging code for the SGI GRU driver. If
you are unsure, say N.
-config DELL_LAPTOP
- tristate "Dell Laptop Extras (EXPERIMENTAL)"
- depends on X86
- depends on DCDBAS
- depends on EXPERIMENTAL
- depends on BACKLIGHT_CLASS_DEVICE
- depends on RFKILL
- depends on POWER_SUPPLY
- default n
- ---help---
- This driver adds support for rfkill and backlight control to Dell
- laptops.
-
config ISL29003
tristate "Intersil ISL29003 ambient light sensor"
depends on I2C && SYSFS
--
1.6.3.2
^ permalink raw reply related
* Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!
From: Mark Huijgen @ 2009-08-19 14:24 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Johannes Berg, Larry Finger, Broadcom Wireless, linux-wireless
In-Reply-To: <69e28c910908190703h1ad7e98bqa4fe55a5fe7800e2@mail.gmail.com>
Gábor Stefanik wrote:
> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>
>> Gábor Stefanik wrote:
>>
>>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>>
>>>
>>>> Gábor Stefanik wrote:
>>>>
>>>>
>>>>> Mark, could you produce a dmesg output with the new firmware, patches
>>>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>>>> & probably associating, if possible. (Scan/assoc may produce messages
>>>>> in dmesg.)
>>>>>
>>>>>
>>>>>
>>>> I tested this already, but with default chan set to 1, I cannot get the
>>>> interface up.
>>>> This is somewhere in my mail, but it got a bit messy after I noticed
>>>> that after
>>>> changing some of the code my modules got installed in another directory
>>>> (-dirty).
>>>>
>>>> I just restarted the notebook, but now the results are different again...
>>>>
>>>> New firmware, with patches applied and default channel 7:
>>>> [ 72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>>>> 00:50:23)
>>>> [ 72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>>>> error = -5
>>>> [ 72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>>>
>>>> Recompile module with default chan 1, patches still applied and new
>>>> firmware,
>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>
>>>> [ 430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>>>
>>>> Recompile again, but with default chan back to 7, still patched and
>>>> still new firmware.
>>>> So same as in first situation:
>>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>>
>>>> [ 524.748062] b43-phy3 debug: Chip initialized
>>>>
>>>> And I can get my interface up and working!
>>>>
>>>> Without this procedure I have not been able to get a working chip. Seems
>>>> the partially
>>>> initialized state after each try, allows the next try to get a bit
>>>> further. And together with
>>>> the default channel switching between 1 and 7, I get a working chip, but
>>>> a chip that does
>>>> not seem to be able to find my AP thats on channel 1.
>>>>
>>>> If I now change default chan to 1 again, I am getting the same error as
>>>> in step 2 above.
>>>> I have not been able to get the interface up with default chan set to 1.
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>>
>>> What do you see in dmesg after running a scan?
>>>
>>>
>> After step 2, interface cannot be brought up:
>> # iw dev wlan0 scan
>> command failed: Network is down (-100)
>>
>> No extra output in dmesg
>>
>> After step 3 (so with default chan 7 again), interface comes up and I
>> can scan:
>> # iw dev wlan0 scan
>> <<list of scan results>>
>>
>> No extra output generated in dmesg.
>>
>> I must add that I do not have debugging messages enabled for any
>> mac80211 related options, only for b43 module.
>>
>
> That's not needed.
>
> However, try "iw dev wlan0 scan trigger".
>
> Also, try switching to all B/G channels manually.
>
To summarize, all cases with patches and new firmware:
case 1: cold boot with default channel 7, RC calib error and 'init
channel failed' error,
case 2: recompile+reload b43 with default channel 1, just 'init channel
failed' error,
case 3: recompile+reload b43 with default channel 7, works
You mean 'iw dev wlan0 set channel 1' for example?
In case 2 (with default chan 1), ifconfig wlan0 gives error
"SIOCSIFFLAGS: Input/output error"
# iw dev wlan0 set channel 1
no output generated, also nothing in dmesg
# iw dev wlan0 scan trigger
command failed: Network is down (-100)
nothing in dmesg.
Both commands do not give any output in dmesg in case 3 either.
Tried channel 1 up to 11, 12 and higher gives 'command failed: Invalid
argument (-22)', which is expected I think.
> One more thing to try is create a monitor interface and run kismet on
> it. In addition, you can use aireplay-ng on the monitor interface to
> test TX.
>
Never done anything with monitor mode before, so when I have some time
I'll look into it.
^ permalink raw reply
* [PATCH 4/5] dell-laptop: add __init to init functions
From: Alan Jenkins @ 2009-08-19 14:06 UTC (permalink / raw)
To: mjg; +Cc: marcel, linux-acpi, linux-kernel, linux-wireless, Alan Jenkins
In-Reply-To: <4A8C0623.8030808@tuffmail.co.uk>
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/dell-laptop.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index a13a9f7..250c4b1 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -82,7 +82,7 @@ static const struct dmi_system_id __initdata dell_device_table[] = {
{ }
};
-static void parse_da_table(const struct dmi_header *dm)
+static void __init parse_da_table(const struct dmi_header *dm)
{
/* Final token is a terminator, so we don't want to copy it */
int tokens = (dm->length-11)/sizeof(struct calling_interface_token)-1;
@@ -111,7 +111,7 @@ static void parse_da_table(const struct dmi_header *dm)
da_num_tokens += tokens;
}
-static void find_tokens(const struct dmi_header *dm, void *dummy)
+static void __init find_tokens(const struct dmi_header *dm, void *dummy)
{
switch (dm->type) {
case 0xd4: /* Indexed IO */
@@ -214,7 +214,7 @@ static const struct rfkill_ops dell_rfkill_ops = {
.query = dell_rfkill_query,
};
-static int dell_setup_rfkill(void)
+static int __init dell_setup_rfkill(void)
{
struct calling_interface_buffer buffer;
int status;
--
1.6.3.2
^ permalink raw reply related
* [PATCH 5/5] dell-laptop: poll the rfkill hard-block
From: Alan Jenkins @ 2009-08-19 14:06 UTC (permalink / raw)
To: mjg; +Cc: marcel, linux-acpi, linux-kernel, linux-wireless, Alan Jenkins
In-Reply-To: <4A8C0623.8030808@tuffmail.co.uk>
This is controlled by a hardware switch, so we should poll it in order
to pick up changes. (There does not appear to be an interrupt or any
other notification mechanism).
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/dell-laptop.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index 250c4b1..349cf12 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -195,7 +195,7 @@ static int dell_rfkill_set(void *data, bool blocked)
return 0;
}
-static void dell_rfkill_query(struct rfkill *rfkill, void *data)
+static void dell_rfkill_poll(struct rfkill *rfkill, void *data)
{
struct calling_interface_buffer buffer;
int status;
@@ -211,7 +211,7 @@ static void dell_rfkill_query(struct rfkill *rfkill, void *data)
static const struct rfkill_ops dell_rfkill_ops = {
.set_block = dell_rfkill_set,
- .query = dell_rfkill_query,
+ .poll = dell_rfkill_poll,
};
static int __init dell_setup_rfkill(void)
--
1.6.3.2
^ permalink raw reply related
* [PATCH 1/5] dell-laptop: fix a use-after-free error on the failure path
From: Alan Jenkins @ 2009-08-19 14:06 UTC (permalink / raw)
To: mjg; +Cc: marcel, linux-acpi, linux-kernel, linux-wireless, Alan Jenkins
In-Reply-To: <4A8C0623.8030808@tuffmail.co.uk>
dell_setup_rfkill() already cleans up the rfkill devices on failure.
So if it returns an error, we should not try to unregister the rfkill
devices.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/dell-laptop.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index 74909c4..12b6f33 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -330,7 +330,7 @@ static int __init dell_init(void)
if (ret) {
printk(KERN_WARNING "dell-laptop: Unable to setup rfkill\n");
- goto out;
+ goto fail_rfkill;
}
#ifdef CONFIG_ACPI
@@ -358,7 +358,7 @@ static int __init dell_init(void)
if (IS_ERR(dell_backlight_device)) {
ret = PTR_ERR(dell_backlight_device);
dell_backlight_device = NULL;
- goto out;
+ goto fail_backlight;
}
dell_backlight_device->props.max_brightness = max_intensity;
@@ -368,13 +368,15 @@ static int __init dell_init(void)
}
return 0;
-out:
+
+fail_backlight:
if (wifi_rfkill)
rfkill_unregister(wifi_rfkill);
if (bluetooth_rfkill)
rfkill_unregister(bluetooth_rfkill);
if (wwan_rfkill)
rfkill_unregister(wwan_rfkill);
+fail_rfkill:
kfree(da_tokens);
return ret;
}
--
1.6.3.2
^ permalink raw reply related
* [PATCH 2/5] dell-laptop: fix rfkill memory leak on unload and failure paths
From: Alan Jenkins @ 2009-08-19 14:06 UTC (permalink / raw)
To: mjg; +Cc: marcel, linux-acpi, linux-kernel, linux-wireless, Alan Jenkins
In-Reply-To: <4A8C0623.8030808@tuffmail.co.uk>
rfkill_unregister() should always be followed by rfkill_destroy().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/dell-laptop.c | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index 12b6f33..8fbff38 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -268,6 +268,22 @@ err_wifi:
return ret;
}
+static void dell_cleanup_rfkill(void)
+{
+ if (wifi_rfkill) {
+ rfkill_unregister(wifi_rfkill);
+ rfkill_destroy(wifi_rfkill);
+ }
+ if (bluetooth_rfkill) {
+ rfkill_unregister(bluetooth_rfkill);
+ rfkill_destroy(bluetooth_rfkill);
+ }
+ if (wwan_rfkill) {
+ rfkill_unregister(wwan_rfkill);
+ rfkill_destroy(wwan_rfkill);
+ }
+}
+
static int dell_send_intensity(struct backlight_device *bd)
{
struct calling_interface_buffer buffer;
@@ -370,12 +386,7 @@ static int __init dell_init(void)
return 0;
fail_backlight:
- if (wifi_rfkill)
- rfkill_unregister(wifi_rfkill);
- if (bluetooth_rfkill)
- rfkill_unregister(bluetooth_rfkill);
- if (wwan_rfkill)
- rfkill_unregister(wwan_rfkill);
+ dell_cleanup_rfkill();
fail_rfkill:
kfree(da_tokens);
return ret;
@@ -384,12 +395,7 @@ fail_rfkill:
static void __exit dell_exit(void)
{
backlight_device_unregister(dell_backlight_device);
- if (wifi_rfkill)
- rfkill_unregister(wifi_rfkill);
- if (bluetooth_rfkill)
- rfkill_unregister(bluetooth_rfkill);
- if (wwan_rfkill)
- rfkill_unregister(wwan_rfkill);
+ dell_cleanup_rfkill();
}
module_init(dell_init);
--
1.6.3.2
^ permalink raw reply related
* Re: [PATCH 5/5] dell-laptop: poll the rfkill hard-block
From: Matthew Garrett @ 2009-08-19 14:13 UTC (permalink / raw)
To: Alan Jenkins; +Cc: marcel, linux-acpi, linux-kernel, linux-wireless
In-Reply-To: <1250690811-21203-5-git-send-email-alan-jenkins@tuffmail.co.uk>
On Wed, Aug 19, 2009 at 03:06:51PM +0100, Alan Jenkins wrote:
> This is controlled by a hardware switch, so we should poll it in order
> to pick up changes. (There does not appear to be an interrupt or any
> other notification mechanism).
With the exception of this one they all look fine - I'm moving house
next week and won't have access to any Dell hardware for over a month,
so if anyone else could confirm that these work that would be excellent.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH 3/5] dell-laptop: create a platform device as a parent for the rfkill devices etc.
From: Alan Jenkins @ 2009-08-19 14:06 UTC (permalink / raw)
To: mjg; +Cc: marcel, linux-acpi, linux-kernel, linux-wireless, Alan Jenkins
In-Reply-To: <4A8C0623.8030808@tuffmail.co.uk>
dell-laptop may not need to export any sysfs files, but it should still
create a platform device as a parent for the rfkill and backlight
devices. Otherwise sysfs will display these as "virtual" devices,
with no connection to either physical hardware or the dell-laptop
module.
Apparently this is useful for hardware detection.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/dell-laptop.c | 38 ++++++++++++++++++++++++++++++++---
1 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index 8fbff38..a13a9f7 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -58,6 +58,14 @@ static int da_command_code;
static int da_num_tokens;
static struct calling_interface_token *da_tokens;
+static struct platform_driver platform_driver = {
+ .driver = {
+ .name = "dell-laptop",
+ .owner = THIS_MODULE,
+ }
+};
+
+static struct platform_device *platform_device;
static struct backlight_device *dell_backlight_device;
static struct rfkill *wifi_rfkill;
static struct rfkill *bluetooth_rfkill;
@@ -217,7 +225,8 @@ static int dell_setup_rfkill(void)
status = buffer.output[1];
if ((status & (1<<2|1<<8)) == (1<<2|1<<8)) {
- wifi_rfkill = rfkill_alloc("dell-wifi", NULL, RFKILL_TYPE_WLAN,
+ wifi_rfkill = rfkill_alloc("dell-wifi", &platform_device->dev,
+ RFKILL_TYPE_WLAN,
&dell_rfkill_ops, (void *) 1);
if (!wifi_rfkill) {
ret = -ENOMEM;
@@ -229,7 +238,8 @@ static int dell_setup_rfkill(void)
}
if ((status & (1<<3|1<<9)) == (1<<3|1<<9)) {
- bluetooth_rfkill = rfkill_alloc("dell-bluetooth", NULL,
+ bluetooth_rfkill = rfkill_alloc("dell-bluetooth",
+ &platform_device->dev,
RFKILL_TYPE_BLUETOOTH,
&dell_rfkill_ops, (void *) 2);
if (!bluetooth_rfkill) {
@@ -242,7 +252,9 @@ static int dell_setup_rfkill(void)
}
if ((status & (1<<4|1<<10)) == (1<<4|1<<10)) {
- wwan_rfkill = rfkill_alloc("dell-wwan", NULL, RFKILL_TYPE_WWAN,
+ wwan_rfkill = rfkill_alloc("dell-wwan",
+ &platform_device->dev,
+ RFKILL_TYPE_WWAN,
&dell_rfkill_ops, (void *) 3);
if (!wwan_rfkill) {
ret = -ENOMEM;
@@ -342,6 +354,18 @@ static int __init dell_init(void)
return -ENODEV;
}
+ ret = platform_driver_register(&platform_driver);
+ if (ret)
+ goto fail_platform_driver;
+ platform_device = platform_device_alloc("dell-laptop", -1);
+ if (!platform_device) {
+ ret = -ENOMEM;
+ goto fail_platform_device1;
+ }
+ ret = platform_device_add(platform_device);
+ if (ret)
+ goto fail_platform_device2;
+
ret = dell_setup_rfkill();
if (ret) {
@@ -368,7 +392,7 @@ static int __init dell_init(void)
if (max_intensity) {
dell_backlight_device = backlight_device_register(
"dell_backlight",
- NULL, NULL,
+ &platform_device->dev, NULL,
&dell_ops);
if (IS_ERR(dell_backlight_device)) {
@@ -388,6 +412,12 @@ static int __init dell_init(void)
fail_backlight:
dell_cleanup_rfkill();
fail_rfkill:
+ platform_device_del(platform_device);
+fail_platform_device2:
+ platform_device_put(platform_device);
+fail_platform_device1:
+ platform_driver_unregister(&platform_driver);
+fail_platform_driver:
kfree(da_tokens);
return ret;
}
--
1.6.3.2
^ permalink raw reply related
* Re: [PATCH 0/5] dell-laptop improvements
From: Matthew Garrett @ 2009-08-19 14:09 UTC (permalink / raw)
To: Alan Jenkins
Cc: Marcel Holtmann, linux acpi, linux-kernel,
linux-wireless@vger.kernel.org
In-Reply-To: <4A8C0623.8030808@tuffmail.co.uk>
On Wed, Aug 19, 2009 at 03:03:15PM +0100, Alan Jenkins wrote:
> The last patch adds polling for the hardware switch which blocks all
> radios. This exercises the hardware a little more than before; it would
> benefit from testing. It should be possible to see events generated by
> the hardware switch using "udevadm monitor --kernel --environment".
We get a hardware event (via the keyboard controller...) when the switch
is set. I need to fix up my i8042 filtering patch to match feedback from
the maintainer, but there's no real need to poll.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!
From: Gábor Stefanik @ 2009-08-19 14:03 UTC (permalink / raw)
To: Mark Huijgen
Cc: Johannes Berg, Larry Finger, Broadcom Wireless, linux-wireless
In-Reply-To: <4A8C056A.4050005@huijgen.tk>
2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>>
>>> Gábor Stefanik wrote:
>>>
>>>> Mark, could you produce a dmesg output with the new firmware, patches
>>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>>> & probably associating, if possible. (Scan/assoc may produce messages
>>>> in dmesg.)
>>>>
>>>>
>>> I tested this already, but with default chan set to 1, I cannot get the
>>> interface up.
>>> This is somewhere in my mail, but it got a bit messy after I noticed
>>> that after
>>> changing some of the code my modules got installed in another directory
>>> (-dirty).
>>>
>>> I just restarted the notebook, but now the results are different again...
>>>
>>> New firmware, with patches applied and default channel 7:
>>> [ 72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>>> 00:50:23)
>>> [ 72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>>> error = -5
>>> [ 72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>>
>>> Recompile module with default chan 1, patches still applied and new
>>> firmware,
>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>
>>> [ 430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>>
>>> Recompile again, but with default chan back to 7, still patched and
>>> still new firmware.
>>> So same as in first situation:
>>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>>
>>> [ 524.748062] b43-phy3 debug: Chip initialized
>>>
>>> And I can get my interface up and working!
>>>
>>> Without this procedure I have not been able to get a working chip. Seems
>>> the partially
>>> initialized state after each try, allows the next try to get a bit
>>> further. And together with
>>> the default channel switching between 1 and 7, I get a working chip, but
>>> a chip that does
>>> not seem to be able to find my AP thats on channel 1.
>>>
>>> If I now change default chan to 1 again, I am getting the same error as
>>> in step 2 above.
>>> I have not been able to get the interface up with default chan set to 1.
>>>
>>> Mark
>>>
>>>
>>>
>>
>> What do you see in dmesg after running a scan?
>>
> After step 2, interface cannot be brought up:
> # iw dev wlan0 scan
> command failed: Network is down (-100)
>
> No extra output in dmesg
>
> After step 3 (so with default chan 7 again), interface comes up and I
> can scan:
> # iw dev wlan0 scan
> <<list of scan results>>
>
> No extra output generated in dmesg.
>
> I must add that I do not have debugging messages enabled for any
> mac80211 related options, only for b43 module.
That's not needed.
However, try "iw dev wlan0 scan trigger".
Also, try switching to all B/G channels manually.
One more thing to try is create a monitor interface and run kismet on
it. In addition, you can use aireplay-ng on the monitor interface to
test TX.
>
> Mark
>
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH 0/5] dell-laptop improvements
From: Alan Jenkins @ 2009-08-19 14:03 UTC (permalink / raw)
To: Matthew Garrett
Cc: Marcel Holtmann, linux acpi, linux-kernel,
linux-wireless@vger.kernel.org
Mario Limonciello's compal-laptop changes were partly based on a reading
of dell-laptop. Unfortunately dell-laptop set a few bad examples; let's
fix them.
I don't have the hardware to test this, but the first four patches
should be nice and low risk.
dell-laptop: fix a use-after-free error on the failure path
dell-laptop: fix rfkill memory leak on unload and failure paths
dell-laptop: create a platform device as a parent for the rfkill devices
etc.
dell-laptop: add __init to init functions
The last patch adds polling for the hardware switch which blocks all
radios. This exercises the hardware a little more than before; it would
benefit from testing. It should be possible to see events generated by
the hardware switch using "udevadm monitor --kernel --environment".
dell-laptop: poll the rfkill hard-block
^ permalink raw reply
* Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!
From: Mark Huijgen @ 2009-08-19 14:00 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Johannes Berg, Larry Finger, Broadcom Wireless, linux-wireless
In-Reply-To: <69e28c910908190654v231d66c7k6a223f481f702c7c@mail.gmail.com>
Gábor Stefanik wrote:
> 2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
>
>> Gábor Stefanik wrote:
>>
>>> Mark, could you produce a dmesg output with the new firmware, patches
>>> applied, and channel set to 1? Post the output of dmesg after scanning
>>> & probably associating, if possible. (Scan/assoc may produce messages
>>> in dmesg.)
>>>
>>>
>> I tested this already, but with default chan set to 1, I cannot get the
>> interface up.
>> This is somewhere in my mail, but it got a bit messy after I noticed
>> that after
>> changing some of the code my modules got installed in another directory
>> (-dirty).
>>
>> I just restarted the notebook, but now the results are different again...
>>
>> New firmware, with patches applied and default channel 7:
>> [ 72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
>> 00:50:23)
>> [ 72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
>> error = -5
>> [ 72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>>
>> Recompile module with default chan 1, patches still applied and new
>> firmware,
>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>
>> [ 430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>>
>> Recompile again, but with default chan back to 7, still patched and
>> still new firmware.
>> So same as in first situation:
>> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>>
>> [ 524.748062] b43-phy3 debug: Chip initialized
>>
>> And I can get my interface up and working!
>>
>> Without this procedure I have not been able to get a working chip. Seems
>> the partially
>> initialized state after each try, allows the next try to get a bit
>> further. And together with
>> the default channel switching between 1 and 7, I get a working chip, but
>> a chip that does
>> not seem to be able to find my AP thats on channel 1.
>>
>> If I now change default chan to 1 again, I am getting the same error as
>> in step 2 above.
>> I have not been able to get the interface up with default chan set to 1.
>>
>> Mark
>>
>>
>>
>
> What do you see in dmesg after running a scan?
>
After step 2, interface cannot be brought up:
# iw dev wlan0 scan
command failed: Network is down (-100)
No extra output in dmesg
After step 3 (so with default chan 7 again), interface comes up and I
can scan:
# iw dev wlan0 scan
<<list of scan results>>
No extra output generated in dmesg.
I must add that I do not have debugging messages enabled for any
mac80211 related options, only for b43 module.
Mark
^ permalink raw reply
* Re: [ANN] b43 LP-PHY support (BCM4310/4312/4315) working (partially)!
From: Gábor Stefanik @ 2009-08-19 13:54 UTC (permalink / raw)
To: Mark Huijgen
Cc: Johannes Berg, Larry Finger, Broadcom Wireless, linux-wireless
In-Reply-To: <4A8C02D8.7080309@huijgen.tk>
2009/8/19 Mark Huijgen <mark.sf.net@huijgen.tk>:
> Gábor Stefanik wrote:
>> Mark, could you produce a dmesg output with the new firmware, patches
>> applied, and channel set to 1? Post the output of dmesg after scanning
>> & probably associating, if possible. (Scan/assoc may produce messages
>> in dmesg.)
>>
> I tested this already, but with default chan set to 1, I cannot get the
> interface up.
> This is somewhere in my mail, but it got a bit messy after I noticed
> that after
> changing some of the code my modules got installed in another directory
> (-dirty).
>
> I just restarted the notebook, but now the results are different again...
>
> New firmware, with patches applied and default channel 7:
> [ 72.160057] b43-phy1: Loading firmware version 478.104 (2008-07-01
> 00:50:23)
> [ 72.163484] b43-phy1 debug: RC calib: Failed to switch to channel 7,
> error = -5
> [ 72.168100] b43-phy1 debug: Switch to init channel failed, error = -5.
>
> Recompile module with default chan 1, patches still applied and new
> firmware,
> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>
> [ 430.259877] b43-phy2 debug: Switch to init channel failed, error = -5.
>
> Recompile again, but with default chan back to 7, still patched and
> still new firmware.
> So same as in first situation:
> # modprobe -r b43 && modprobe b43 verbose=3 && ifconfig wlan0 up
>
> [ 524.748062] b43-phy3 debug: Chip initialized
>
> And I can get my interface up and working!
>
> Without this procedure I have not been able to get a working chip. Seems
> the partially
> initialized state after each try, allows the next try to get a bit
> further. And together with
> the default channel switching between 1 and 7, I get a working chip, but
> a chip that does
> not seem to be able to find my AP thats on channel 1.
>
> If I now change default chan to 1 again, I am getting the same error as
> in step 2 above.
> I have not been able to get the interface up with default chan set to 1.
>
> Mark
>
>
What do you see in dmesg after running a scan?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ 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