* Re: ar9170 makes machine hang when shut down
From: Malte Gell @ 2009-09-25 9:32 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4ABBE5DB.5070201@gmx.de>
Joerg Albert <jal2@gmx.de> wrote
> > Does it make sense to use "rmmod --force ar9170" to force removing that
> > module before shutting down?
>
> Why are you sure that the hang is caused by the ar9170 driver?
You are right.... I thought this way, because my machine never hung and after
installing the USB stick it hang... But, I noticed when i disable ISDN
subsystem, it did not hang, so maybe it is the ISDN subsystem, I will try
further.
> The vendor driver is called arusb_lnx, the new one ar9170usb
Vendor driver? Does this mean, Atheros made a driver on its own? Are there
several drivers for the same chip now?
My system loads ar9170:
lsmod | grep ar91*
ar9170 32632 0
mac80211 237208 1 ar9170
led_class 4028 1 ar9170
usbcore 183280 15
usbserial,ar9170,usbhid,uvcvideo,snd_usb_audio,snd_usb_lib,usblp,ehci_hcd,uhci_hcd,ohci_hcd,usb_storage
Regards
Malte
^ permalink raw reply
* zd1211rw on Debian not working with new kernels
From: Michele Alessandrini @ 2009-09-25 8:47 UTC (permalink / raw)
To: linux-wireless
Hi everybody,
I have a Sitecom WL-113 USB wireless adapter, and I use Debian testing with
zd1211rw. My wireless network uses WPA.
The adapter is working with kernel up to 2.6.24. It is not working anymore
with kernels 2.6.26 and 2.6.30 (these are the kernels I could test).
>From what I can see, wpa_supplicant gets a series of errors from the driver
when it tries to associate to the network.
Provided that the OS is exactly the same, and the only variable is which
kernel is booted, I think it's something related to the driver (kernel 2.6.26
is where the MAC layer has been changed) or to the interface between it and
wpa_supplicant.
I'm just writing to ask if this is a know issue or if someone else is getting
similar problems.
Thank you very much for your work
Bye
Michele Alessandrini, Italy
^ permalink raw reply
* [PATCH] [RFT] sony-laptop: re-read the rfkill state when resuming from suspend
From: Alan Jenkins @ 2009-09-25 9:18 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, Mattia Dongili, Norbert Preining
Without this, the hard-blocked state will be reported incorrectly if
the hardware switch is changed while the laptop is suspended.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
--
Again, this is from code inspection only. Since suspend/resume can
be tricky, please test that this change works (and is necessary).
diff a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1044,6 +1044,9 @@ static int sony_nc_resume(struct acpi_device *device)
sony_backlight_update_status(sony_backlight_device) < 0)
printk(KERN_WARNING DRV_PFX "unable to restore brightness level\n");
+ /* re-read rfkill state */
+ sony_nc_rfkill_update();
+
return 0;
}
^ permalink raw reply
* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Alan Jenkins @ 2009-09-25 9:13 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, Mattia Dongili, Norbert Preining,
Almer S. Tigelaar, Matthias Welwarsky, Johannes Berg
In-Reply-To: <20090924223805.GA29169@kamineko.org>
Mattia Dongili wrote:
> On Thu, Sep 24, 2009 at 08:15:24PM +0100, Alan Jenkins wrote:
>
>> "I recently (on a flight) I found out that when I boot with the hard-switch
>> activated, so turning off all wireless activity on my laptop, the state
>> is not correctly announced in /dev/rfkill (reading it with rfkill command,
>> or my own gnome applet)...
>>
>> After turning off and on again the hard-switch the events were right."
>>
>> We can fix this by querying the firmware at load time and calling
>> rfkill_set_hw_state().
>>
>
> Is it worth trying to get this into a stable release?
>
Sure. It seems to fit, and all we have to do is add a CC to the patch
>> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
>> Tested-by: Norbert Preining <preining@logic.at>
>>
>
> Acked-by: Mattia Dongili <malattia@linux.it>
>
CC: stable@kernel.org
>
>> ---
>> drivers/platform/x86/sony-laptop.c | 6 ++++++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
>> index dafaa4a..a234a9d 100644
>> --- a/drivers/platform/x86/sony-laptop.c
>> +++ b/drivers/platform/x86/sony-laptop.c
>> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
>> struct rfkill *rfk;
>> enum rfkill_type type;
>> const char *name;
>> + int result;
>> + bool hwblock;
>>
>> switch (nc_type) {
>> case SONY_WIFI:
>> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
>> if (!rfk)
>> return -ENOMEM;
>>
>> + sony_call_snc_handle(0x124, 0x200, &result);
>> + hwblock = !(result & 0x1);
>> + rfkill_set_hw_state(rfk, hwblock);
>> +
>> err = rfkill_register(rfk);
>> if (err) {
>> rfkill_destroy(rfk);
>> --
>> 1.6.3.2
>>
>>
>>
>>
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Holger Schurig @ 2009-09-25 8:45 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909250838420.3783@sister.anvils>
> I wonder, have there been more yet more regdom reworks since 2.6.31?
> Would this be the stage at which regdom problems manifest? I'm not
> running whatever-it-is daemon for setting regdom, usually just patch
> static char *ieee80211_regdom = "EU";
> into my kernels; but in the past have only needed that when the router
> decides to use channel 13 or something - currently it's on channel 1.
I've install crada and it works great with 2.6.31, althought I had
to override the EEPROM, which reports bugus data:
- ath_regd_sanitize(reg);
-
- printk(KERN_DEBUG "ath: EEPROM regdomain: 0x%0x\n", reg->current_rd);
+ reg->current_rd = CTRY_GERMANY | COUNTRY_ERD_FLAG;
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Johannes Berg @ 2009-09-25 8:43 UTC (permalink / raw)
To: Hugh Dickins; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909250838420.3783@sister.anvils>
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
On Fri, 2009-09-25 at 09:06 +0100, Hugh Dickins wrote:
> Should be, but you're right, for whatever reason it is not running
> with these recent kernels.
>
> I expect that correlates with iwconfig showing me ESSID:off/any.
Well it showing you that means that nothing is even trying to connect :)
> I'm thinking that (unless you've a better idea) I should do another
> bisect for when that behaviour starts - hoping that whatever problem
> led me to your patch, got fixed up later on, but superseded by this
> different problem.
Not sure, might be very time consuming.
> The bootup messages on the Aspire One tell me:
> wlan0 device: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
> wlan0 is controlled by ifplugd
> wlan0
> waiting
> wlan0 device: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
> wlan0 ifplugd is running
> wlan0 no cable connected
> wlan0 DHCP4 client NOT running
> wlan0
>
> And the bootup messages on the Fujitsu Siemens say:
> wlan0 device: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
> wlan0 is controlled by ifplugd
> wlan0
> wlan0 device: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
> wlan0 ifplugd is running
> wlan0 no cable connected
> wlan0 . . . is just beeing set up
> wlan0
>
> In each case, "no cable connected".
Oi. This looks like it doesn't know that it's a wireless device I guess?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Hugh Dickins @ 2009-09-25 8:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <1253856038.3868.500.camel@johannes.local>
On Fri, 25 Sep 2009, Johannes Berg wrote:
>
> Very odd. Haven't really looked at the config, but I see the phy0: idle
> message that indicates you have debug on. However, it's like nothing
> ever tells the kernel to connect to a network.
>
> Are you running wpa_supplicant?
Should be, but you're right, for whatever reason it is not running
with these recent kernels.
I expect that correlates with iwconfig showing me ESSID:off/any.
I'm thinking that (unless you've a better idea) I should do another
bisect for when that behaviour starts - hoping that whatever problem
led me to your patch, got fixed up later on, but superseded by this
different problem.
The bootup messages on the Aspire One tell me:
wlan0 device: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
wlan0 is controlled by ifplugd
wlan0
waiting
wlan0 device: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
wlan0 ifplugd is running
wlan0 no cable connected
wlan0 DHCP4 client NOT running
wlan0
And the bootup messages on the Fujitsu Siemens say:
wlan0 device: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
wlan0 is controlled by ifplugd
wlan0
wlan0 device: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
wlan0 ifplugd is running
wlan0 no cable connected
wlan0 . . . is just beeing set up
wlan0
In each case, "no cable connected".
I wonder, have there been more yet more regdom reworks since 2.6.31?
Would this be the stage at which regdom problems manifest? I'm not
running whatever-it-is daemon for setting regdom, usually just patch
static char *ieee80211_regdom = "EU";
into my kernels; but in the past have only needed that when the router
decides to use channel 13 or something - currently it's on channel 1.
Hugh
^ permalink raw reply
* Re: Question on general wireless testing tree compilation.
From: Holger Schurig @ 2009-09-25 6:58 UTC (permalink / raw)
To: Balaji Ravindran; +Cc: Linux Wireless
In-Reply-To: <16D9C5FD-4A2A-4061-9C26-FF5C0B0CDFBA@w1an.in>
> I followed the instructions from
> http://www.cyberciti.biz/tips/compiling-linux-kernel-26.html
> and ended up with a compile error in 'make', while trying to
> create the bzimage. (error is on make: initramfs_data.cpi.o
> failed)
Hmm, I simply compile almost-self-contained kernels, without any
initramfs. Slows down the boot and isn't needed for the usual
IDE/SATA desktop PCs anyway.
If you don't want to go that way, you'd better post the whole
error. Maybe when doing "make V=1", and include some (10 or so)
lines from above the error message above.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Problems with "cfg80211: fix SME connect" commit
From: Johannes Berg @ 2009-09-25 6:22 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless
In-Reply-To: <3ace41890909241213q5b4992a0sffd4c34a69ac9bb6@mail.gmail.com>
Thanks for your analysis.
> This seems to look like/relate to a little problem I have for the last
> few days - lately I have authentication failure on first try and have
> to click on NM a 2nd time for it to go through; blow away
> compat-wireless & revert to as-shipped distro modules gives me the
> older/smooth behavior of NM just associating without me
> clicking/asking.
>
> v2.6.31-38294-ged3ac87 + 'cfg80211: don't set privacy w/o key' doesn't
> improve my situation.
>
> wpa_supplicant log:
> --------- distro modules:
> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
> Associated with <id>
> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>
> -------- compat-wireless
> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
> Authentication with 00:00:00:00:00:00 timed out.
> Trying to associate with <id> (SSID='ID' freq=2437 MHz)
> Associated with <id>
> CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
>
> ------ dmesg distro modules
> wlan2: direct probe to AP <id> try 1
> wlan2 direct probe responded
> wlan2: authenticate with AP <id>
> wlan2: authenticated
> wlan2: associate with AP <id>
> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
> wlan2: associated
>
> ------ compat-wireless, note the extra deauth at the beginning, and
> all those 'try 1''s.
> wlan2: deauthenticating by local choice (reason=3)
> wlan2: direct probe to AP <id> (try 1)
> wlan2 direct probe responded
> wlan2: authenticate with AP <id> (try 1)
> wlan2: authenticated
> wlan2: associate with AP <id> (try 1)
> wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
> wlan2: associated
I've analysed this, and now know the reason for the extra deauth, but it
shouldn't hurt since we never send a wireless extensions event. The
reason is that once wpa_supplicant sets the SSID we already start to
connect with the new changes, but then setting the BSSID might require
restarting the process. This could be optimised, but I would prefer not
having to.
I can see a problem with the code and it trying to scan once more again
etc. Below patch seems to help for me. However, I only once managed to
reproduce the problem you were seeing with the authentication timeout in
wpa_supplicant.
Can you try this? The last hunk is most important, but the other stuff
helps debugging.
johannes
--- wireless-testing.orig/net/mac80211/mlme.c 2009-09-25 07:38:46.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2009-09-25 08:12:26.000000000 +0200
@@ -1675,7 +1675,7 @@ static void ieee80211_rx_mgmt_probe_resp
/* direct probe may be part of the association flow */
if (wk && wk->state == IEEE80211_MGD_STATE_PROBE) {
- printk(KERN_DEBUG "%s direct probe responded\n",
+ printk(KERN_DEBUG "%s: direct probe responded\n",
sdata->dev->name);
wk->tries = 0;
wk->state = IEEE80211_MGD_STATE_AUTH;
@@ -2411,6 +2411,9 @@ int ieee80211_mgd_auth(struct ieee80211_
list_add(&wk->list, &sdata->u.mgd.work_list);
mutex_unlock(&ifmgd->mtx);
+ printk(KERN_DEBUG "%s: starting authentication with %pM\n",
+ sdata->dev->name, req->bss->bssid);
+
ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.work);
return 0;
}
@@ -2485,6 +2488,9 @@ int ieee80211_mgd_assoc(struct ieee80211
else
ifmgd->flags &= ~IEEE80211_STA_CONTROL_PORT;
+ printk(KERN_DEBUG "%s: starting association with %pM\n",
+ sdata->dev->name, req->bss->bssid);
+
ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.work);
err = 0;
@@ -2502,9 +2508,6 @@ int ieee80211_mgd_deauth(struct ieee8021
struct ieee80211_mgd_work *wk;
const u8 *bssid = NULL;
- printk(KERN_DEBUG "%s: deauthenticating by local choice (reason=%d)\n",
- sdata->dev->name, req->reason_code);
-
mutex_lock(&ifmgd->mtx);
if (ifmgd->associated && &ifmgd->associated->cbss == req->bss) {
@@ -2532,6 +2535,9 @@ int ieee80211_mgd_deauth(struct ieee8021
mutex_unlock(&ifmgd->mtx);
+ printk(KERN_DEBUG "%s: deauthenticating from %pM by local choice (reason=%d)\n",
+ sdata->dev->name, bssid, req->reason_code);
+
ieee80211_send_deauth_disassoc(sdata, bssid,
IEEE80211_STYPE_DEAUTH, req->reason_code,
cookie);
@@ -2545,9 +2551,6 @@ int ieee80211_mgd_disassoc(struct ieee80
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- printk(KERN_DEBUG "%s: disassociating by local choice (reason=%d)\n",
- sdata->dev->name, req->reason_code);
-
mutex_lock(&ifmgd->mtx);
/*
@@ -2561,6 +2564,9 @@ int ieee80211_mgd_disassoc(struct ieee80
return -ENOLINK;
}
+ printk(KERN_DEBUG "%s: disassociating from %pM by local choice (reason=%d)\n",
+ sdata->dev->name, req->bss->bssid, req->reason_code);
+
ieee80211_set_disassoc(sdata, false);
mutex_unlock(&ifmgd->mtx);
--- wireless-testing.orig/net/wireless/sme.c 2009-09-25 08:05:20.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-09-25 08:13:42.000000000 +0200
@@ -762,9 +762,8 @@ int __cfg80211_connect(struct cfg80211_r
wdev->conn->params.ssid = wdev->ssid;
wdev->conn->params.ssid_len = connect->ssid_len;
- /* don't care about result -- but fill bssid & channel */
- if (!wdev->conn->params.bssid || !wdev->conn->params.channel)
- bss = cfg80211_get_conn_bss(wdev);
+ /* see if we have the bss already */
+ bss = cfg80211_get_conn_bss(wdev);
wdev->sme_state = CFG80211_SME_CONNECTING;
wdev->connect_keys = connkeys;
^ permalink raw reply
* Question on general wireless testing tree compilation.
From: Balaji Ravindran @ 2009-09-25 5:21 UTC (permalink / raw)
To: Linux Wireless
Hi Everyone,
Sorry for a very amateur question. Could anyone just help me get
started with compiling the linux kernel from the wireless-testing
tree? I just pulled the local wireless-testing repo, trying to
navigate through the code, and wanted to compile the kernel, and to
boot up to it. Could anyone just help me get started?
I followed the instructions from http://www.cyberciti.biz/tips/compiling-linux-kernel-26.html
and ended up with a compile error in 'make', while trying to create
the bzimage. (error is on make: initramfs_data.cpi.o failed)
Is there any other easy way to compile the kernel/debug.
Thanks
Balaji R
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Johannes Berg @ 2009-09-25 5:20 UTC (permalink / raw)
To: Hugh Dickins; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909242036270.7469@sister.anvils>
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
On Thu, 2009-09-24 at 20:45 +0100, Hugh Dickins wrote:
> I've now tried recent Linus -git plus both those patches on both machines,
> but no joy on either.
Thanks.
> >
> > Anyhow, I'm grasping at straws -- can you tell me more about the failure
> > mode, and possibly enable CONFIG_MAC80211_DEBUG_MENU and
> > CONFIG_MAC80211_VERBOSE_DEBUG?
>
> I enabled those on both machines for that trial, will keep them on for now.
>
> The failure mode is that iwconfig says ESSID:off/any instead of showing
> my essid, and I've no connectivity; but you probably need something more
> specific than that.
>
> I'll send you privately the .config of each machine, and the dmesg of
> each machine, from that trial. I've just compared the .configs against
> what works for 2.6.31, and everything relevant still seems to be there.
Very odd. Haven't really looked at the config, but I see the phy0: idle
message that indicates you have debug on. However, it's like nothing
ever tells the kernel to connect to a network.
Are you running wpa_supplicant?
> I do wonder if this is an openSUSE interaction, whether another distro
> with the same kernel would be fine.
I'm not sure why that would be? But then again this is the first I've
heard of such a problem.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: John W. Linville @ 2009-09-25 4:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <43e72e890909241320j592e347die8a14f8bdd962ffb@mail.gmail.com>
On Thu, Sep 24, 2009 at 01:20:35PM -0700, Luis R. Rodriguez wrote:
> On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> > Here's my suggestion how to provide firmware and hardware version to
> > user space. First I was thinking adding a new nl80211 command and
> > it looked so ugly that I decided include the versions in struct wiphy
> > instead.
> >
> > Please comment.
>
> What was the conclusion on ethtool stuff again? I forgot.
IIRC, I suggested that the cfg80211 driver API (or just the wiphy
data structure) could be extended for appropriate bits like this,
then cfg80211 could catch ethtool operations in a way similar to how
it catches wireless extensions now.
I was thinking to look at this after I get home, maybe next week.
Others are welcome to beat me to it, of course. :-)
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: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-25 0:53 UTC (permalink / raw)
To: tim.gardner
Cc: Hauke Mehrtens, Bryan Wu, Mauro Di Domenico, bcm43xx-dev,
linux-wireless
In-Reply-To: <4ABC0B60.5070909@canonical.com>
On Thu, Sep 24, 2009 at 5:14 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
> Luis R. Rodriguez wrote:
>>
>> On Thu, Sep 24, 2009 at 5:04 PM, Tim Gardner <tim.gardner@canonical.com>
>> wrote:
>>>
>>> Luis R. Rodriguez wrote:
>>>>
>>>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de>
>>>> wrote:
>>>>>
>>>>> Bryan Wu wrote:
>>>>>>
>>>>>> Mauro Di Domenico wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>>>>> machine with kernel version 2.6.30-6.
>>>>>>>
>>>>>>> During the boot I experience this problem:
>>>>>>>
>>>>>>> $ dmesg|egrep "b43|ssb"
>>>>>>>
>>>>>>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17
>>>>>>> (level,
>>>>>>> low) -> IRQ 17
>>>>>>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to
>>>>>>> 64
>>>>>>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>>>>> 0000:06:00.0
>>>>>>> [ 6.968981] b43: disagrees about version of symbol
>>>>>>> ssb_device_is_enabled
>>>>>>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>>>>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>>>>> [ 6.969407] b43: disagrees about version of symbol
>>>>>>> ssb_pcicore_dev_irqvecs_enable
>>>>>>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>>>>> .....
>>>>>>> ....
>>>>>>> ...
>>>>>>>
>>>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>>>>>> have
>>>>>> no time to take a deeper look.
>>>>>>
>>>>>> Thanks
>>>>>
>>>>> Hi,
>>>>>
>>>>> I had the same problem with the ssb module and compat-wireless in
>>>>> ubuntu
>>>>> 9.04. The problem is that the ssb module is integrated into the
>>>>> initramfs image. The version out of the initramfs image is loaded on
>>>>> startup and not the version of compat-wireless. Running "sudo
>>>>> update-initramfs -u" after installing compat-wireless and restaing the
>>>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>>>>> form default initramfs image or compat-wireless should update the image
>>>>> with the install command. At least the compat-wireless documentation
>>>>> needs an update.
>>>>>
>>>>> Hauke
>>>>>
>>>>> (adding Luis and linux-wireless list)
>>>>
>>>> Tim, do you guys update the initramfs upon installation of lbm? If a
>>>> user does not use lbm and uses compat-wireless I suppose we need to do
>>>> something similar.
>>>>
>>>> Luis
>>>
>>> No, initramfs is not updated when LBM is installed. I think maybe its a
>>> bug
>>> that ssb is in the initramfs modules list since AFAIK its not a boot
>>> essential device. Even in the netboot case, ssb/b44 should be in a udeb.
>>
>> That would make life much easier.
>>
>> Luis
>>
>
> I'm looking at the Karmic initramfs-tools package and am not seeing _any_
> reference to ssb or b44.
Seems like a Debian 2.6.30-6 bug then.
Luis
^ permalink raw reply
* Re: A problem loading ssb module
From: Tim Gardner @ 2009-09-25 0:14 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Hauke Mehrtens, Bryan Wu, Mauro Di Domenico, bcm43xx-dev,
linux-wireless
In-Reply-To: <43e72e890909241708v55af30baia5f6fca8eb5d9d59@mail.gmail.com>
Luis R. Rodriguez wrote:
> On Thu, Sep 24, 2009 at 5:04 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
>> Luis R. Rodriguez wrote:
>>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>> Bryan Wu wrote:
>>>>> Mauro Di Domenico wrote:
>>>>>> Hi,
>>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>>>> machine with kernel version 2.6.30-6.
>>>>>>
>>>>>> During the boot I experience this problem:
>>>>>>
>>>>>> $ dmesg|egrep "b43|ssb"
>>>>>>
>>>>>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>>>>> low) -> IRQ 17
>>>>>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>>>>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>>>> 0000:06:00.0
>>>>>> [ 6.968981] b43: disagrees about version of symbol
>>>>>> ssb_device_is_enabled
>>>>>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>>>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>>>> [ 6.969407] b43: disagrees about version of symbol
>>>>>> ssb_pcicore_dev_irqvecs_enable
>>>>>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>>>> .....
>>>>>> ....
>>>>>> ...
>>>>>>
>>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>>>>> have
>>>>> no time to take a deeper look.
>>>>>
>>>>> Thanks
>>>> Hi,
>>>>
>>>> I had the same problem with the ssb module and compat-wireless in ubuntu
>>>> 9.04. The problem is that the ssb module is integrated into the
>>>> initramfs image. The version out of the initramfs image is loaded on
>>>> startup and not the version of compat-wireless. Running "sudo
>>>> update-initramfs -u" after installing compat-wireless and restaing the
>>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>>>> form default initramfs image or compat-wireless should update the image
>>>> with the install command. At least the compat-wireless documentation
>>>> needs an update.
>>>>
>>>> Hauke
>>>>
>>>> (adding Luis and linux-wireless list)
>>> Tim, do you guys update the initramfs upon installation of lbm? If a
>>> user does not use lbm and uses compat-wireless I suppose we need to do
>>> something similar.
>>>
>>> Luis
>> No, initramfs is not updated when LBM is installed. I think maybe its a bug
>> that ssb is in the initramfs modules list since AFAIK its not a boot
>> essential device. Even in the netboot case, ssb/b44 should be in a udeb.
>
> That would make life much easier.
>
> Luis
>
I'm looking at the Karmic initramfs-tools package and am not seeing
_any_ reference to ssb or b44.
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-25 0:08 UTC (permalink / raw)
To: tim.gardner
Cc: Hauke Mehrtens, Bryan Wu, Mauro Di Domenico, bcm43xx-dev,
linux-wireless
In-Reply-To: <4ABC08FA.8030104@canonical.com>
On Thu, Sep 24, 2009 at 5:04 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
> Luis R. Rodriguez wrote:
>>
>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>
>>> Bryan Wu wrote:
>>>>
>>>> Mauro Di Domenico wrote:
>>>>>
>>>>> Hi,
>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>>> machine with kernel version 2.6.30-6.
>>>>>
>>>>> During the boot I experience this problem:
>>>>>
>>>>> $ dmesg|egrep "b43|ssb"
>>>>>
>>>>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>>>> low) -> IRQ 17
>>>>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>>>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>>> 0000:06:00.0
>>>>> [ 6.968981] b43: disagrees about version of symbol
>>>>> ssb_device_is_enabled
>>>>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>>> [ 6.969407] b43: disagrees about version of symbol
>>>>> ssb_pcicore_dev_irqvecs_enable
>>>>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>>> .....
>>>>> ....
>>>>> ...
>>>>>
>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>>>> have
>>>> no time to take a deeper look.
>>>>
>>>> Thanks
>>>
>>> Hi,
>>>
>>> I had the same problem with the ssb module and compat-wireless in ubuntu
>>> 9.04. The problem is that the ssb module is integrated into the
>>> initramfs image. The version out of the initramfs image is loaded on
>>> startup and not the version of compat-wireless. Running "sudo
>>> update-initramfs -u" after installing compat-wireless and restaing the
>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>>> form default initramfs image or compat-wireless should update the image
>>> with the install command. At least the compat-wireless documentation
>>> needs an update.
>>>
>>> Hauke
>>>
>>> (adding Luis and linux-wireless list)
>>
>> Tim, do you guys update the initramfs upon installation of lbm? If a
>> user does not use lbm and uses compat-wireless I suppose we need to do
>> something similar.
>>
>> Luis
>
> No, initramfs is not updated when LBM is installed. I think maybe its a bug
> that ssb is in the initramfs modules list since AFAIK its not a boot
> essential device. Even in the netboot case, ssb/b44 should be in a udeb.
That would make life much easier.
Luis
^ permalink raw reply
* Re: A problem loading ssb module
From: Tim Gardner @ 2009-09-25 0:04 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Hauke Mehrtens, Bryan Wu, Mauro Di Domenico, bcm43xx-dev,
linux-wireless
In-Reply-To: <43e72e890909241137o7e853edfxb9e159df34927d7b@mail.gmail.com>
Luis R. Rodriguez wrote:
> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>> Bryan Wu wrote:
>>> Mauro Di Domenico wrote:
>>>> Hi,
>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>> machine with kernel version 2.6.30-6.
>>>>
>>>> During the boot I experience this problem:
>>>>
>>>> $ dmesg|egrep "b43|ssb"
>>>>
>>>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>>> low) -> IRQ 17
>>>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>> 0000:06:00.0
>>>> [ 6.968981] b43: disagrees about version of symbol
>>>> ssb_device_is_enabled
>>>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>> [ 6.969407] b43: disagrees about version of symbol
>>>> ssb_pcicore_dev_irqvecs_enable
>>>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>> .....
>>>> ....
>>>> ...
>>>>
>>> I faced the exactly same issue as Mauro did. +1 from me, but currently have
>>> no time to take a deeper look.
>>>
>>> Thanks
>> Hi,
>>
>> I had the same problem with the ssb module and compat-wireless in ubuntu
>> 9.04. The problem is that the ssb module is integrated into the
>> initramfs image. The version out of the initramfs image is loaded on
>> startup and not the version of compat-wireless. Running "sudo
>> update-initramfs -u" after installing compat-wireless and restaing the
>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>> form default initramfs image or compat-wireless should update the image
>> with the install command. At least the compat-wireless documentation
>> needs an update.
>>
>> Hauke
>>
>> (adding Luis and linux-wireless list)
>
> Tim, do you guys update the initramfs upon installation of lbm? If a
> user does not use lbm and uses compat-wireless I suppose we need to do
> something similar.
>
> Luis
No, initramfs is not updated when LBM is installed. I think maybe its a
bug that ssb is in the initramfs modules list since AFAIK its not a boot
essential device. Even in the netboot case, ssb/b44 should be in a udeb.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Mattia Dongili @ 2009-09-24 23:04 UTC (permalink / raw)
To: Alan Jenkins
Cc: Gábor Stefanik, linux-wireless@vger.kernel.org,
Norbert Preining, Johannes Berg, Almer S. Tigelaar,
Matthias Welwarsky
In-Reply-To: <4ABBD278.3050207@tuffmail.co.uk>
On Thu, Sep 24, 2009 at 09:11:36PM +0100, Alan Jenkins wrote:
> Gábor Stefanik wrote:
> > On Thu, Sep 24, 2009 at 9:15 PM, Alan Jenkins
> > <alan-jenkins@tuffmail.co.uk> wrote:
> >
...
> >> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> >> if (!rfk)
> >> return -ENOMEM;
> >>
> >> + sony_call_snc_handle(0x124, 0x200, &result);
> >>
> >
> > Please define these somewhere, don't use magic numbers.
> >
>
> The rfkill functions are all together in the file, it's not that bad.
> But ok.
>
> There's another bug / missing feature - it doesn't re-read the hard
> states on resume from suspend.
>
> I'll submit two more patches then. I won't convert all of the magic
> numbers though. This isn't hardware I know anything about, and "magic
> numbers" is a good description of some of them -
right and the whole purpose of them is to hit specific code paths
in the DSDT tables. Not sure we would benefit that much from having
names for them.
--
mattia
:wq!
^ permalink raw reply
* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Mattia Dongili @ 2009-09-24 22:38 UTC (permalink / raw)
To: Alan Jenkins
Cc: linux-wireless@vger.kernel.org, Norbert Preining, Johannes Berg,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABBC54C.5010103@tuffmail.co.uk>
On Thu, Sep 24, 2009 at 08:15:24PM +0100, Alan Jenkins wrote:
> "I recently (on a flight) I found out that when I boot with the hard-switch
> activated, so turning off all wireless activity on my laptop, the state
> is not correctly announced in /dev/rfkill (reading it with rfkill command,
> or my own gnome applet)...
>
> After turning off and on again the hard-switch the events were right."
>
> We can fix this by querying the firmware at load time and calling
> rfkill_set_hw_state().
Is it worth trying to get this into a stable release?
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Tested-by: Norbert Preining <preining@logic.at>
Acked-by: Mattia Dongili <malattia@linux.it>
> ---
> drivers/platform/x86/sony-laptop.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
> index dafaa4a..a234a9d 100644
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> struct rfkill *rfk;
> enum rfkill_type type;
> const char *name;
> + int result;
> + bool hwblock;
>
> switch (nc_type) {
> case SONY_WIFI:
> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> if (!rfk)
> return -ENOMEM;
>
> + sony_call_snc_handle(0x124, 0x200, &result);
> + hwblock = !(result & 0x1);
> + rfkill_set_hw_state(rfk, hwblock);
> +
> err = rfkill_register(rfk);
> if (err) {
> rfkill_destroy(rfk);
> --
> 1.6.3.2
>
>
>
--
mattia
:wq!
^ permalink raw reply
* Re: [PATCH] iwlagn: fix panic in iwl{5000,4965}_rx_reply_tx
From: reinette chatre @ 2009-09-24 21:38 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org, John W. Linville
In-Reply-To: <1253695894-4553-1-git-send-email-sgruszka@redhat.com>
Hi Stanislaw,
On Wed, 2009-09-23 at 01:51 -0700, Stanislaw Gruszka wrote:
> In some cases firmware can give us bad value of index in transmit
> buffers array. This patch add sanity check for such values and return
> from processing function instantly when it happens.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=521931
>
> Patch was tested by reporter on iwl5000. I think check can be also
> helpful for 4965.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
I looked at the bugzilla entry and I think that there may be another fix
required here. After the driver submitted the five frames it received a
surprisingly large number of tx responses from firmware, with one of
these causing the problem. The bad value from the firmware may be a
result of something else done incorrectly by driver here since the
firmware has been trying for more than 40 times at this point to inform
driver about tx results.
I commented in that bugzilla and we can continue to debug this issue
there. Until then I'd like to hold off on this patch.
Reinette
^ permalink raw reply
* Re: ar9170 makes machine hang when shut down
From: Joerg Albert @ 2009-09-24 21:34 UTC (permalink / raw)
To: Malte Gell; +Cc: linux-wireless
In-Reply-To: <200909242155.19485.malte.gell@gmx.de>
On 09/24/2009 09:55 PM, Malte Gell wrote:
> I use the compat 2.6.30 and the ar9170 driver for my Netgear WN111 USB stick.
> I use the packages from
> http://download.opensuse.org/repositories/driver:/wireless/11.1-update/i586/
> for openSUSE 11.1.
>
> When I shutdown my machine, it hangs after the last messages "system now
> rebooting" or similar.
>
> Does it make sense to use "rmmod --force ar9170" to force removing that module
> before shutting down?
Why are you sure that the hang is caused by the ar9170 driver?
The vendor driver is called arusb_lnx, the new one ar9170usb
If you only use the packages from the above URL and haven't compile compat-wireless yourself,
chances are that you use the vendor driver. You may check the loaded module list:
lsmod
and try to remove the module:
rmmod arusb_lnx
before shutting down.
If this fails, try to close the corresponding netdev first:
ifconfig X down
with X = ath0 or wlan0 (see the output of "iwconfig").
Needing "--force" for rmmod is IMHO a bug in the driver.
Regards,
Jörg.
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Joerg Albert @ 2009-09-24 21:13 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20090924180251.14503.64152.stgit@tikku>
On 09/24/2009 08:02 PM, Kalle Valo wrote:
> + len = sizeof(wiphy->fw_version);
> + snprintf(wiphy->fw_version, len, "%d.%d.%d-%d",
> + priv->fw_version.major, priv->fw_version.minor,
> + priv->fw_version.patch, priv->fw_version.build);
> +
> + len = sizeof(wiphy->hw_version);
> + snprintf(wiphy->hw_version, len, "%d", priv->board_type);
> +
> + /* null terminate the strings in case they were truncated */
> + wiphy->fw_version[len - 1] = '\0';
> + wiphy->hw_version[len - 1] = '\0';
This only works as long as sizeof(wiphy->fw_version) == sizeof(wiphy->hw_version) - which is currently the case.
For sizeof(wiphy->fw_version) < sizeof(wiphy_hw_version) it overwrites memory behind wiphy->fw_version.
IMHO this is more robust against changes in the lengths of the char arrays:
+ wiphy->fw_version[sizeof(wiphy->fw_version) - 1] = '\0';
+ wiphy->hw_version[sizeof(wiphy->hw_version) - 1] = '\0';
Regards,
Jörg.
^ permalink raw reply
* Is this normal: ath9k: Two wiphys trying to scan at the same time
From: ASIC Felix @ 2009-09-24 20:51 UTC (permalink / raw)
To: linux-wireless
Hi,
is this normal:
ath9k: Two wiphys trying to scan at the same time
afaik, I did not enable virtual phy stuff. Connection appears to be
working okay. I've been seeing this for quite some time.
Setup: Laptop, Atheros MB92, kernel wireless-testing master-2009-09-23
wlan0: deauthenticated from 00:0b:85:6f:20:8c (Reason: 1)
ath9k: Two wiphys trying to scan at the same time
wlan0: direct probe to AP 00:0b:85:6f:20:8c (try 1)
wlan0 direct probe responded
wlan0: authenticate with AP 00:0b:85:6f:20:8c (try 1)
wlan0: authenticated
wlan0: associate with AP 00:0b:85:6f:20:8c (try 1)
wlan0: RX ReassocResp from 00:0b:85:6f:20:8c (capab=0x431 status=0
aid=5)
wlan0: associated
Best regards,
Felix
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: Luis R. Rodriguez @ 2009-09-24 20:20 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> Here's my suggestion how to provide firmware and hardware version to
> user space. First I was thinking adding a new nl80211 command and
> it looked so ugly that I decided include the versions in struct wiphy
> instead.
>
> Please comment.
What was the conclusion on ethtool stuff again? I forgot.
Luis
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Luis R. Rodriguez @ 2009-09-24 20:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Felix Bitterli
In-Reply-To: <da94abde0909241210m69bd619sce62645c3aca9aae@mail.gmail.com>
On Thu, Sep 24, 2009 at 12:10 PM, Kalle Valo <kalle.valo@iki.fi> wrote:
> BTW, is there an easy way to get the module name for the interface?
> That's also helpful information for the user.
If you can map the interface to PCI ID then I think its possible,
lspci -k seems to do it. It would be a nice addition to iw output as
well IMHO.
Luis
^ permalink raw reply
* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Alan Jenkins @ 2009-09-24 20:11 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Mattia Dongili, linux-wireless@vger.kernel.org, Norbert Preining,
Johannes Berg, Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <69e28c910909241224q10202a47o37ba0f3975ee3294@mail.gmail.com>
Gábor Stefanik wrote:
> On Thu, Sep 24, 2009 at 9:15 PM, Alan Jenkins
> <alan-jenkins@tuffmail.co.uk> wrote:
>
>> "I recently (on a flight) I found out that when I boot with the hard-switch
>> activated, so turning off all wireless activity on my laptop, the state
>> is not correctly announced in /dev/rfkill (reading it with rfkill command,
>> or my own gnome applet)...
>>
>> After turning off and on again the hard-switch the events were right."
>>
>> We can fix this by querying the firmware at load time and calling
>> rfkill_set_hw_state().
>>
>> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
>> Tested-by: Norbert Preining <preining@logic.at>
>> ---
>> drivers/platform/x86/sony-laptop.c | 6 ++++++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
>> index dafaa4a..a234a9d 100644
>> --- a/drivers/platform/x86/sony-laptop.c
>> +++ b/drivers/platform/x86/sony-laptop.c
>> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
>> struct rfkill *rfk;
>> enum rfkill_type type;
>> const char *name;
>> + int result;
>> + bool hwblock;
>>
>> switch (nc_type) {
>> case SONY_WIFI:
>> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
>> if (!rfk)
>> return -ENOMEM;
>>
>> + sony_call_snc_handle(0x124, 0x200, &result);
>>
>
> Please define these somewhere, don't use magic numbers.
>
The rfkill functions are all together in the file, it's not that bad.
But ok.
There's another bug / missing feature - it doesn't re-read the hard
states on resume from suspend.
I'll submit two more patches then. I won't convert all of the magic
numbers though. This isn't hardware I know anything about, and "magic
numbers" is a good description of some of them -
/* Setup hotkeys */
sony_call_snc_handle(0x0100, 0, &result);
sony_call_snc_handle(0x0101, 0, &result);
sony_call_snc_handle(0x0102, 0x100, &result);
sony_call_snc_handle(0x0127, 0, &result);
Others are already sufficiently obvious, and the extra indirection would
only serve to obscure
/* Enable all events */
acpi_callsetfunc(sony_nc_acpi_handle, "SN02", 0xffff, &result);
^ 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