* Re: [PATCH v5 00/33] wireless: kconfig updates
From: John W. Linville @ 2009-08-19 18:35 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Luis Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <20090819180235.GA7126@mosca>
On Wed, Aug 19, 2009 at 11:02:35AM -0700, Luis R. Rodriguez wrote:
> On Wed, Aug 19, 2009 at 08:01:38AM -0700, John W. Linville wrote:
> > 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...?
>
> Well at first I didn't really intend to group them by manufacturer really,
> I just tried to get rid of clutter and wanted to group related drivers
> together to make it easier to find for users. After a few iterations the
> manufacturer grouping just happened naturally, and later it also just seemed
> natural to remove the typical postfix "wireless device support" or the like.
>
> I welcome others to try to clean the stuff up some more in a different
> way but I think you may end up with something very similar.
Can we just drop the "INTEL_80211" and the like, keeping the comments
and basic organization in the Kconfig files as you have them?
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: bisecting with wireless-testing
From: John W. Linville @ 2009-08-19 18:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Pavel Roskin, Luis R. Rodriguez,
ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <20090819183416.GE7126@mosca>
On Wed, Aug 19, 2009 at 11:34:16AM -0700, Luis R. Rodriguez wrote:
> Renaming subject and adding linux-wireless.
>
> On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:
> > It should not be necessary to bisect through reverts. I maintain
> > different tags for such purposes.
> >
> > Always use the lastest merge-* tag as the base for bisection.
> > This should be equivalent to whichever -rc release from Linus is the
> > current base for wireless-testing. If you need to go any earlier
> > than that, you should be using linux-2.6.
> >
> > So for example with current tree:
> >
> > git bisect start
> > git bisect bad master-2009-08-19
> > git bisect good merge-2009-08-14
> >
> > This should include all of the current wireless patches in
> > wireless-testing but not in the base linux-2.6 kernel.
>
> This does indeed help alot. Just to be clear let me provide an
> example. So say git tag -l | grep merge | tail -3 yields:
>
> merge-2009-07-24
> merge-2009-08-03
> merge-2009-08-14
>
> I believe what you are indicating if you are bisecting using to avoid
> running into the reverts you'd have to ensure then that you bisect between
> a bad commit and the next dated merge tag. So if you ran into a snag say
> on master-2009-08-06, you should test if merge-2009-08-03 is good first,
> and if its not then consider using linux-2.6.git ? If so wouldn't
> the code on master-2009-08-06 not yet be available on linux-2.6.git?
If you look, merge-2009-08-03 is identical to 2.6.31-rc5:
git diff merge-2009-08-03..v2.6.31-rc5
So if you have a problem in master-2009-08-06, then either the
problem exists in v2.6.31-rc5 or it is between merge-2009-08-03 and
master-2009-08-06. (Read the tags carefully, they look similar.)
The point is, it never makes sense to use a good marker any
farther back than the most recent merge-* tag when trying to bisect
wireless-testing. Otherwise, all the reverts and such will cause
confusion. If the problem still exists at the most recent merge-*
tag, then the problem is in linux-2.6 and should be bisected there.
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: bug? sme.c:610 __cfg80211_disconnected
From: Bob Copeland @ 2009-08-19 18:43 UTC (permalink / raw)
To: ASIC Felix; +Cc: linux-wireless
In-Reply-To: <8f3763990908191119l37c7dff3y8884b1228059cb22@mail.gmail.com>
On Wed, Aug 19, 2009 at 2:19 PM, ASIC Felix<ic.felix@gmail.com> wrote:
> Hi,
>
> update:
> occurs during rekeying/reauth on wpa2 office network
> still present in master-2009-08-19
>
> Aug 19 11:04:02 darkslate klogd: WARNING: at net/wireless/sme.c:613
> __cfg80211_disconnected+0x1bc/0x210 [cfg80211]()
Please post the entire warning's stack trace inline (i.e.
not as an attachment).
I looked at your previous email in which you had attached
the log, and it looked like ath9k was the wireless driver,
though it could be a bug in {mac,cfg}80211 as well. It's
impossible to tell just from this one line though.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 2/3] Add rfkill support to compal-laptop
From: Johannes Berg @ 2009-08-19 18:42 UTC (permalink / raw)
To: Mario Limonciello
Cc: cezary.jackiewicz, linux-kernel, linux-acpi, linux-wireless
In-Reply-To: <1250706969-10382-1-git-send-email-Mario_Limonciello@Dell.com>
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
On Wed, 2009-08-19 at 13:36 -0500, Mario Limonciello wrote:
> Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
> Reviewed-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> + ret = setup_rfkill();
> + if (ret)
> + goto fail_rfkill;
> +
> printk(KERN_INFO "compal-laptop: driver "COMPAL_DRIVER_VERSION
> " successfully loaded.\n");
>
> return 0;
>
> +fail_rfkill:
> fail_platform_device2:
Isn't that missing sysfs_remove_group()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] Add rfkill support to compal-laptop
From: Mario Limonciello @ 2009-08-19 18:39 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: <1250702012.8073.1.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
Johannes:
Johannes Berg wrote:
> 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:
>
>
It looks like option 1 works properly on my hardware, so I've switched
the other code around.
>
> That doesn't error out, so
>
>
>
> this will crash without NULL checks.
>
> (and you have to explicitly assign NULL in setup_rfkill() too, when
> bluetooth fails and wifi is freed)
>
>
OK, i've cleaned that up to just error out on the module if rfkill
doesn't get initialized right.
> johannes
>
I've resent separately, and think I have git send-email working, so
hopefully won't have to attach in the future.
--
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* [PATCH 2/3] Add rfkill support to compal-laptop
From: Mario Limonciello @ 2009-08-19 18:36 UTC (permalink / raw)
To: cezary.jackiewicz
Cc: linux-kernel, linux-acpi, linux-wireless, Mario Limonciello
Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
Reviewed-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/compal-laptop.c | 87 +++++++++++++++++++++++++++++++++-
1 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/compal-laptop.c b/drivers/platform/x86/compal-laptop.c
index c1c8c03..da7ead6 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,77 @@ 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 (!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;
+
+ ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
+
+ hw_blocked = !(result & KILLSWITCH_MASK);
+ rfkill_set_hw_state(rfkill, hw_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 +334,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)
@@ -397,11 +471,16 @@ static int __init compal_init(void)
if (ret)
goto fail_platform_device2;
+ ret = setup_rfkill();
+ if (ret)
+ goto fail_rfkill;
+
printk(KERN_INFO "compal-laptop: driver "COMPAL_DRIVER_VERSION
" successfully loaded.\n");
return 0;
+fail_rfkill:
fail_platform_device2:
platform_device_del(compal_device);
@@ -428,6 +507,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
^ permalink raw reply related
* Re: bisecting with wireless-testing
From: Luis R. Rodriguez @ 2009-08-19 18:34 UTC (permalink / raw)
To: John W. Linville
Cc: Luis Rodriguez, Pavel Roskin, Luis R. Rodriguez,
ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <20090819175809.GD5905@tuxdriver.com>
Renaming subject and adding linux-wireless.
On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:
> On Tue, Aug 18, 2009 at 02:57:48PM -0700, Luis R. Rodriguez wrote:
> > On Tue, Aug 18, 2009 at 02:45:00PM -0700, Pavel Roskin wrote:
> > > On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:
> > >
> > > > > Anyway, why is it better for bisecting?
Just for reference for linux-wireles readers here I had indicated
wireless-next-2.6 was better for bisecting than wireless-testing.
> > > >
> > > > Because to help developers not have to do:
> > > >
> > > > git branch -m poo
> > > > git checkout -b master origin/master
> > > > # Then apply patches manually
> > > >
> > > > Instead of the better rebasing:
> > > >
> > > > git branch -m save-my-stuff
> > > > git checkout -b master origin/master
> > > > git checkout save-my-stuff
> > > > git rebase master
> > >
> > > I use STGit, so perhaps I miss all that fun. I have never had any
> > > trouble tracking wireless-testing while keeping my patches.
> >
> > Oh this was a long time ago, pre ath5k I think.
> >
> > > > john reverts his patches on wireless-testing before rebasing to Linus'
> > > > tree. There may be some other added benefit other than helping us
> > > > rebase cleanly, not sure. But I do remember before that I never was
> > > > able to rebase my patches, and now rebasing works quite nicely.
> > >
> > > You mean it's better to track wireless-next-2.6 for those of us trying
> > > to stay on top of the wireless development?
> >
> > No, not at all, I meant wireless-next-2.6 is best for bisecting.
> >
> > wireless-testing is indeed the place to look at for development.
> >
> > > I must have missed the
> > > memo.
> >
> > I don't think we ever really publized this much, because technically
> > the reverting won't happen unless John rebases and typically between
> > rebases to a next RC kernel you *could* technically bisect an issue.
> > But not all the times.
> >
> > > Indeed, wireless-next-2.6 has a couple of commits that
> > > wireless-testing doesn't have yet.
> > >
> > > I agree that having to bisect through reverts is not fun, and it takes
> > > one or two extra iterations.
> >
> > Right, which is why I wanted to mention it, will extend the info on
> > the wiki on the development section once John ACKs/NACKs this.
>
> It should not be necessary to bisect through reverts. I maintain
> different tags for such purposes.
>
> Always use the lastest merge-* tag as the base for bisection.
> This should be equivalent to whichever -rc release from Linus is the
> current base for wireless-testing. If you need to go any earlier
> than that, you should be using linux-2.6.
>
> So for example with current tree:
>
> git bisect start
> git bisect bad master-2009-08-19
> git bisect good merge-2009-08-14
>
> This should include all of the current wireless patches in
> wireless-testing but not in the base linux-2.6 kernel.
This does indeed help alot. Just to be clear let me provide an
example. So say git tag -l | grep merge | tail -3 yields:
merge-2009-07-24
merge-2009-08-03
merge-2009-08-14
I believe what you are indicating if you are bisecting using to avoid
running into the reverts you'd have to ensure then that you bisect between
a bad commit and the next dated merge tag. So if you ran into a snag say
on master-2009-08-06, you should test if merge-2009-08-03 is good first,
and if its not then consider using linux-2.6.git ? If so wouldn't
the code on master-2009-08-06 not yet be available on linux-2.6.git?
> I haven't tracked-down this thread in the archives...am I addressing
> the issue correctly?
Indeed! Thanks a lot.
Luis
^ permalink raw reply
* bug? sme.c:610 __cfg80211_disconnected
From: ASIC Felix @ 2009-08-19 18:19 UTC (permalink / raw)
To: linux-wireless
Hi,
update:
occurs during rekeying/reauth on wpa2 office network
still present in master-2009-08-19
Aug 19 11:04:02 darkslate klogd: WARNING: at net/wireless/sme.c:613
__cfg80211_disconnected+0x1bc/0x210 [cfg80211]()
Cheers,
Felix
^ permalink raw reply
* Re: [PATCH v5 00/33] wireless: kconfig updates
From: Luis R. Rodriguez @ 2009-08-19 18:02 UTC (permalink / raw)
To: John W. Linville; +Cc: Luis Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <20090819150138.GB5905@tuxdriver.com>
On Wed, Aug 19, 2009 at 08:01:38AM -0700, John W. Linville wrote:
> 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...?
Well at first I didn't really intend to group them by manufacturer really,
I just tried to get rid of clutter and wanted to group related drivers
together to make it easier to find for users. After a few iterations the
manufacturer grouping just happened naturally, and later it also just seemed
natural to remove the typical postfix "wireless device support" or the like.
I welcome others to try to clean the stuff up some more in a different
way but I think you may end up with something very similar.
Luis
^ permalink raw reply
* [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
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