* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Johannes Berg @ 2009-07-16 23:58 UTC (permalink / raw)
To: Thomas Backlund; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <4A5FB944.90709@mandriva.org>
On Fri, 2009-07-17 at 02:35 +0300, Thomas Backlund wrote:
> > So far so good. Your platform's soft-switch is wired to the card's hard
> > kill line. Mind trying
> >
> > ./rfkill unblock 0
> >
> > (or whatever ID the acer-wireless has) at this point to see what
> > happens? I would hope it goes back to the working state.
> >
>
> Nothing happends...
>
> It does not change anything on either acer-wireless or phy0
Humm. Can you try this?
johannes
--- wireless-testing.orig/drivers/platform/x86/acer-wmi.c 2009-07-17 00:19:20.000000000 +0200
+++ wireless-testing/drivers/platform/x86/acer-wmi.c 2009-07-17 01:58:11.000000000 +0200
@@ -973,7 +973,7 @@ static int acer_rfkill_set(void *data, b
{
acpi_status status;
u32 cap = (unsigned long)data;
- status = set_u32(!!blocked, cap);
+ status = set_u32(!blocked, cap);
if (ACPI_FAILURE(status))
return -ENODEV;
return 0;
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Johannes Berg @ 2009-07-16 23:53 UTC (permalink / raw)
To: Thomas Backlund; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <4A5FBD19.6000803@mandriva.org>
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
On Fri, 2009-07-17 at 02:51 +0300, Thomas Backlund wrote:
> > pressing rfkill when I have a working wireless gets this:
> And here is the above rfkill/ iwlagn error with "debug=0x01043fff":
>
> Jul 17 02:41:06 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:41:06 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
> Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
> 77, i = 75, REPLY_RX, 0xc3
Yeah the errors are kinda expected.. not sure how we can hide them.
> Oh, btw is this below a refcounting bug?
> For each time I unload & reload the iwlagn,
> the number in front of phy0 gets increased:
>
> [root@tmb-laptop rfkill]# ./rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: yes
> Hard blocked: no
> 5: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
No, we just assign increasing numbers all the time.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Thomas Backlund @ 2009-07-16 23:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <4A5FB957.80407@mandriva.org>
Thomas Backlund skrev:
> Johannes Berg skrev:
>> On Fri, 2009-07-17 at 00:18 +0200, Johannes Berg wrote:
>>
>>>> And pressing it again gets this:
>>>> [root@tmb-laptop rfkill]# ./rfkill list
>>>> 0: acer-wireless: Wireless LAN
>>>> Soft blocked: no
>>>> Hard blocked: no
>>>> 1: acer-bluetooth: Bluetooth
>>>> Soft blocked: yes
>>>> Hard blocked: no
>>>> 2: phy0: Wireless LAN
>>>> Soft blocked: yes
>>>> Hard blocked: no
>>>>
>>>> And after that I cant get wireless back until I again do a:
>>>> ./rfkill unblock 2
>>>> (works only when acer-wireless is no/no and Wireless LAN is yes/no)
>>> Right. This is bad. The button press shouldn't have affected the
>>> soft-state of the rfkill #2.
>>>
>>>> Applying this patch:
>>>> [PATCH] rfkill: fix rfkill_set_states() to set the hw state
>>>> sent by Alan Jenkins does not help this issue either...
>>>>
>>>> Any suggestions how to fix the rfkill ?
>>> I'll poke at the acer code to see what it's doing wrong...
>>
>> Can't see anything wrong. I wonder if the button you have sends both the
>> ACPI event _and_ an input event.
>>
>> Can you try this patch and tell us what happens?
>>
>
> pressing rfkill when I have a working wireless gets this:
>
> Jul 17 02:24:35 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
> REPLY_RXON_ASSOC: enqueue_hcmd failed: -5
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error setting
> RXON_ASSOC (-5)
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
> REPLY_ADD_STA: enqueue_hcmd failed: -5
> Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key
> (0, 00:19:5b:51:dc:27) from hardware (-5)
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
> REPLY_ADD_STA: enqueue_hcmd failed: -5
> Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key
> (1, ff:ff:ff:ff:ff:ff) from hardware (-5)
> Jul 17 02:24:35 tmb-laptop dhclient: receive_packet failed on wlan0:
> Network is down
> Jul 17 02:24:35 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
> Jul 17 02:24:36 tmb-laptop ifplugd(wlan0)[1790]: Link beat lost.
>
>
And here is the above rfkill/ iwlagn error with "debug=0x01043fff":
Jul 17 02:41:06 tmb-laptop klogd: rfkill_schedule_toggle(1)
Jul 17 02:41:06 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
77, i = 75, REPLY_RX, 0xc3
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_dbg_report_frame
Beacon: 0x0080, dst=0xff, src=0x27, len=228, rssi=-38, tim=2957610510
usec, phy=0x33, chnl=8
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
77, i = 76, STATISTICS_NOTIFICATION, 0x9d
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_statistics
Statistics notification received (480 vs 484).
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
79, i = 77, REPLY_RX, 0xc3
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_dbg_report_frame
Beacon: 0x0080, dst=0xff, src=0x27, len=228, rssi=-34, tim=2957712910
usec, phy=0x33, chnl=8
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
79, i = 78, STATISTICS_NOTIFICATION, 0x9d
Jul 17 02:41:06 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_statistics
Statistics notification received (480 vs 484).
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
81, i = 79, REPLY_RX, 0xc3
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_dbg_report_frame
Beacon: 0x0080, dst=0xff, src=0x27, len=228, rssi=-37, tim=2957815309
usec, phy=0x33, chnl=8
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
81, i = 80, STATISTICS_NOTIFICATION, 0x9d
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_statistics
Statistics notification received (480 vs 484).
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_rx_handle r =
82, i = 81, CARD_STATE_NOTIFICATION, 0xa1
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_mac_tx enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_tx_skb Dropping
- RF KILL
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_mac_tx leave
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx
leave - RF not ready
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx
leave - RF not ready
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx
leave - RF not ready
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_conf_tx
leave - RF not ready
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_config enter
to channel 8 changed 0x100
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_set_rxon_chain
rx_chain=0x6806 active=2 idle=2
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_config Not
re-sending same RXON configuration.
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_config leave
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_config enter
to channel 8 changed 0x40
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_set_rxon_chain
rx_chain=0x2806 active=2 idle=2
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_enqueue_hcmd Not
sending command - RF KILL
Jul 17 02:41:07 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
REPLY_RXON_ASSOC: enqueue_hcmd failed: -5
Jul 17 02:41:07 tmb-laptop klogd: iwlagn 0000:04:00.0: Error setting
RXON_ASSOC (-5)
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_config leave
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_bss_info_changed
changes = 0x8F
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_bss_info_changed
BSSID 00:00:00:00:00:00
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_bss_info_changed
ERP_PREAMBLE 0
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_bss_info_changed
ERP_CTS 0
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_bss_info_changed
ASSOC 0
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_bss_info_changed
leave
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_set_key enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_enqueue_hcmd Not
sending command - RF KILL
Jul 17 02:41:07 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
REPLY_ADD_STA: enqueue_hcmd failed: -5
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_set_key
disable hwcrypto key
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_set_key leave
Jul 17 02:41:07 tmb-laptop klogd: mac80211-phy0: failed to remove key
(0, 00:19:5b:51:dc:27) from hardware (-5)
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: I iwl_configure_filter
Enter: changed: 0x0, total: 0x80000000
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_set_key enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_enqueue_hcmd Not
sending command - RF KILL
Jul 17 02:41:07 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
REPLY_ADD_STA: enqueue_hcmd failed: -5
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_set_key
disable hwcrypto key
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_set_key leave
Jul 17 02:41:07 tmb-laptop klogd: mac80211-phy0: failed to remove key
(2, ff:ff:ff:ff:ff:ff) from hardware (-5)
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U
iwl_mac_remove_interface enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U
iwl_mac_remove_interface leave
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_stop enter
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U __iwl_down iwlagn is
going down
Jul 17 02:41:07 tmb-laptop dhclient: receive_packet failed on wlan0:
Network is down
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U
iwl4965_apm_stop_master stop master
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U
iwl_clear_free_frames 0 frames on pre-allocated heap on clear.
Jul 17 02:41:07 tmb-laptop klogd: ieee80211 phy0: U iwl_mac_stop leave
Jul 17 02:41:07 tmb-laptop ifplugd(wlan0)[27042]: Link beat lost.
Oh, btw is this below a refcounting bug?
For each time I unload & reload the iwlagn,
the number in front of phy0 gets increased:
[root@tmb-laptop rfkill]# ./rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
5: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
--
Thomas
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Luis R. Rodriguez @ 2009-07-16 23:51 UTC (permalink / raw)
To: Thomas Backlund
Cc: Johannes Berg, reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <43e72e890907161643v28a621e7ne29ec1e032e0ae95@mail.gmail.com>
On Thu, Jul 16, 2009 at 4:43 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Thu, Jul 16, 2009 at 4:35 PM, Thomas Backlund<tmb@mandriva.org> wrote:
>> Johannes Berg skrev:
>>>
>>> On Fri, 2009-07-17 at 00:18 +0200, Johannes Berg wrote:
>>>
>>>>> And pressing it again gets this:
>>>>> [root@tmb-laptop rfkill]# ./rfkill list
>>>>> 0: acer-wireless: Wireless LAN
>>>>> Soft blocked: no
>>>>> Hard blocked: no
>>>>> 1: acer-bluetooth: Bluetooth
>>>>> Soft blocked: yes
>>>>> Hard blocked: no
>>>>> 2: phy0: Wireless LAN
>>>>> Soft blocked: yes
>>>>> Hard blocked: no
>>>>>
>>>>> And after that I cant get wireless back until I again do a:
>>>>> ./rfkill unblock 2
>>>>> (works only when acer-wireless is no/no and Wireless LAN is yes/no)
>>>>
>>>> Right. This is bad. The button press shouldn't have affected the
>>>> soft-state of the rfkill #2.
>>>>
>>>>> Applying this patch:
>>>>> [PATCH] rfkill: fix rfkill_set_states() to set the hw state
>>>>> sent by Alan Jenkins does not help this issue either...
>>>>>
>>>>> Any suggestions how to fix the rfkill ?
>>>>
>>>> I'll poke at the acer code to see what it's doing wrong...
>>>
>>> Can't see anything wrong. I wonder if the button you have sends both the
>>> ACPI event _and_ an input event.
>>>
>>> Can you try this patch and tell us what happens?
>>>
>>
>> pressing rfkill when I have a working wireless gets this:
>>
>> Jul 17 02:24:35 tmb-laptop klogd: rfkill_schedule_toggle(1)
>> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
>> REPLY_RXON_ASSOC: enqueue_hcmd failed: -5
>> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error setting
>> RXON_ASSOC (-5)
>> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
>> REPLY_ADD_STA: enqueue_hcmd failed: -5
>> Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key (0,
>> 00:19:5b:51:dc:27) from hardware (-5)
>> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
>> REPLY_ADD_STA: enqueue_hcmd failed: -5
>> Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key (1,
>> ff:ff:ff:ff:ff:ff) from hardware (-5)
>> Jul 17 02:24:35 tmb-laptop dhclient: receive_packet failed on wlan0: Network
>> is down
>> Jul 17 02:24:35 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
>> Jul 17 02:24:36 tmb-laptop ifplugd(wlan0)[1790]: Link beat lost.
>>
>>
>> After that I only get (when pressing rfkill several times...):
>> Jul 17 02:30:16 tmb-laptop klogd: rfkill_schedule_toggle(1)
>> Jul 17 02:30:16 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
>>
>> Jul 17 02:30:28 tmb-laptop klogd: rfkill_schedule_toggle(1)
>> Jul 17 02:30:28 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
>>
>> Jul 17 02:30:31 tmb-laptop klogd: rfkill_schedule_toggle(1)
>> Jul 17 02:30:31 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
>>
>> Jul 17 02:30:45 tmb-laptop klogd: rfkill_schedule_toggle(1)
>> Jul 17 02:30:45 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
>>
>> Jul 17 02:32:23 tmb-laptop klogd: rfkill_schedule_toggle(1)
>> Jul 17 02:32:23 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
>>
>> And no wireless network...
>>
>> Issuing ./rfkill unblock 2 gets the wireless back
>> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::radio
>> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::assoc
>> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::RX
>> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::TX
>> Jul 17 02:33:00 tmb-laptop ifplugd(wlan0)[1790]: Link beat detected.
>
> I think we're missing two rfkill defines for compat. Give me a second to review.
nevermind
Luis
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jouni Malinen @ 2009-07-16 23:50 UTC (permalink / raw)
To: Jon Fairbairn; +Cc: linux-wireless
In-Reply-To: <wf63dsmvjg.fsf@calligramme.charmers>
On Thu, Jul 16, 2009 at 05:39:47PM +0100, Jon Fairbairn wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com>
> writes:
> > http://wireless.kernel.org/en/users/Drivers/ath9k
> Thanks, but I've seen that page and "products with supported ath9k
> cards" points to a page that lists "Laptops with ath9k cards" (I'm
> looking for PCIe, not mini-PCIe) and "APs with ath9k cards", not "ath9k
> cards". Before I can buy a card, I need to know what it is called in the
> shops (on-line or otherwise), not what chipset it has.
I don't know how the product list ended up being split that way, but the
"laptops" page does actually include number of D-Link adapters,
including a PCIe desktop adapter (D-Link DWA-556) that seems to match
the request. I saw it at Fry's last week and it does indeed look like a
PCIe card. It is not exactly the least expensive option and is not the
latest 11n MAC revision, but at least it is available and I would expect
it to work with ath9k in AP mode.
> I realise this is the manufacturer's fault, but this is a perennial
> problem for Linux users who want to buy an new card for something: "OK,
> I want something with such-and-such a chipset, but the on-line shops
> just don't say what the chipset is.
Combination of model number (and revision in some cases! urgh) and
driver download and/or FCCID lookup can help with that, but yes, this is
quite painful in many cases. However, I've also seen some cards that
have the box actually listing both the chipset vendor (even both MAC and
PHY model number) and Linux support, so there is some hope in figuring
this out even at a store without having to do an internet lookup..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Luis R. Rodriguez @ 2009-07-16 23:43 UTC (permalink / raw)
To: Thomas Backlund
Cc: Johannes Berg, reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <4A5FB957.80407@mandriva.org>
On Thu, Jul 16, 2009 at 4:35 PM, Thomas Backlund<tmb@mandriva.org> wrote:
> Johannes Berg skrev:
>>
>> On Fri, 2009-07-17 at 00:18 +0200, Johannes Berg wrote:
>>
>>>> And pressing it again gets this:
>>>> [root@tmb-laptop rfkill]# ./rfkill list
>>>> 0: acer-wireless: Wireless LAN
>>>> Soft blocked: no
>>>> Hard blocked: no
>>>> 1: acer-bluetooth: Bluetooth
>>>> Soft blocked: yes
>>>> Hard blocked: no
>>>> 2: phy0: Wireless LAN
>>>> Soft blocked: yes
>>>> Hard blocked: no
>>>>
>>>> And after that I cant get wireless back until I again do a:
>>>> ./rfkill unblock 2
>>>> (works only when acer-wireless is no/no and Wireless LAN is yes/no)
>>>
>>> Right. This is bad. The button press shouldn't have affected the
>>> soft-state of the rfkill #2.
>>>
>>>> Applying this patch:
>>>> [PATCH] rfkill: fix rfkill_set_states() to set the hw state
>>>> sent by Alan Jenkins does not help this issue either...
>>>>
>>>> Any suggestions how to fix the rfkill ?
>>>
>>> I'll poke at the acer code to see what it's doing wrong...
>>
>> Can't see anything wrong. I wonder if the button you have sends both the
>> ACPI event _and_ an input event.
>>
>> Can you try this patch and tell us what happens?
>>
>
> pressing rfkill when I have a working wireless gets this:
>
> Jul 17 02:24:35 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
> REPLY_RXON_ASSOC: enqueue_hcmd failed: -5
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error setting
> RXON_ASSOC (-5)
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
> REPLY_ADD_STA: enqueue_hcmd failed: -5
> Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key (0,
> 00:19:5b:51:dc:27) from hardware (-5)
> Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
> REPLY_ADD_STA: enqueue_hcmd failed: -5
> Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key (1,
> ff:ff:ff:ff:ff:ff) from hardware (-5)
> Jul 17 02:24:35 tmb-laptop dhclient: receive_packet failed on wlan0: Network
> is down
> Jul 17 02:24:35 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
> Jul 17 02:24:36 tmb-laptop ifplugd(wlan0)[1790]: Link beat lost.
>
>
> After that I only get (when pressing rfkill several times...):
> Jul 17 02:30:16 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:30:16 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
>
> Jul 17 02:30:28 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:30:28 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
>
> Jul 17 02:30:31 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:30:31 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
>
> Jul 17 02:30:45 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:30:45 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
>
> Jul 17 02:32:23 tmb-laptop klogd: rfkill_schedule_toggle(1)
> Jul 17 02:32:23 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
>
> And no wireless network...
>
> Issuing ./rfkill unblock 2 gets the wireless back
> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::radio
> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::assoc
> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::RX
> Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::TX
> Jul 17 02:33:00 tmb-laptop ifplugd(wlan0)[1790]: Link beat detected.
I think we're missing two rfkill defines for compat. Give me a second to review.
Luis
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Thomas Backlund @ 2009-07-16 23:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <1247783433.31442.11.camel@johannes.local>
Johannes Berg skrev:
> On Fri, 2009-07-17 at 00:18 +0200, Johannes Berg wrote:
>
>>> And pressing it again gets this:
>>> [root@tmb-laptop rfkill]# ./rfkill list
>>> 0: acer-wireless: Wireless LAN
>>> Soft blocked: no
>>> Hard blocked: no
>>> 1: acer-bluetooth: Bluetooth
>>> Soft blocked: yes
>>> Hard blocked: no
>>> 2: phy0: Wireless LAN
>>> Soft blocked: yes
>>> Hard blocked: no
>>>
>>> And after that I cant get wireless back until I again do a:
>>> ./rfkill unblock 2
>>> (works only when acer-wireless is no/no and Wireless LAN is yes/no)
>> Right. This is bad. The button press shouldn't have affected the
>> soft-state of the rfkill #2.
>>
>>> Applying this patch:
>>> [PATCH] rfkill: fix rfkill_set_states() to set the hw state
>>> sent by Alan Jenkins does not help this issue either...
>>>
>>> Any suggestions how to fix the rfkill ?
>> I'll poke at the acer code to see what it's doing wrong...
>
> Can't see anything wrong. I wonder if the button you have sends both the
> ACPI event _and_ an input event.
>
> Can you try this patch and tell us what happens?
>
pressing rfkill when I have a working wireless gets this:
Jul 17 02:24:35 tmb-laptop klogd: rfkill_schedule_toggle(1)
Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
REPLY_RXON_ASSOC: enqueue_hcmd failed: -5
Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error setting
RXON_ASSOC (-5)
Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
REPLY_ADD_STA: enqueue_hcmd failed: -5
Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key
(0, 00:19:5b:51:dc:27) from hardware (-5)
Jul 17 02:24:35 tmb-laptop klogd: iwlagn 0000:04:00.0: Error sending
REPLY_ADD_STA: enqueue_hcmd failed: -5
Jul 17 02:24:35 tmb-laptop klogd: mac80211-phy0: failed to remove key
(1, ff:ff:ff:ff:ff:ff) from hardware (-5)
Jul 17 02:24:35 tmb-laptop dhclient: receive_packet failed on wlan0:
Network is down
Jul 17 02:24:35 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
Jul 17 02:24:36 tmb-laptop ifplugd(wlan0)[1790]: Link beat lost.
After that I only get (when pressing rfkill several times...):
Jul 17 02:30:16 tmb-laptop klogd: rfkill_schedule_toggle(1)
Jul 17 02:30:16 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
Jul 17 02:30:28 tmb-laptop klogd: rfkill_schedule_toggle(1)
Jul 17 02:30:28 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
Jul 17 02:30:31 tmb-laptop klogd: rfkill_schedule_toggle(1)
Jul 17 02:30:31 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
Jul 17 02:30:45 tmb-laptop klogd: rfkill_schedule_toggle(1)
Jul 17 02:30:45 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [1]
Jul 17 02:32:23 tmb-laptop klogd: rfkill_schedule_toggle(1)
Jul 17 02:32:23 tmb-laptop klogd: __rfkill_handle_normal_op(1, 1) [0]
And no wireless network...
Issuing ./rfkill unblock 2 gets the wireless back
Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::radio
Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::assoc
Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::RX
Jul 17 02:32:48 tmb-laptop klogd: Registered led device: iwl-phy0::TX
Jul 17 02:33:00 tmb-laptop ifplugd(wlan0)[1790]: Link beat detected.
--
Thomas
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Thomas Backlund @ 2009-07-16 23:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <1247782731.31442.3.camel@johannes.local>
Johannes Berg skrev:
> On Fri, 2009-07-17 at 01:09 +0300, Thomas Backlund wrote:
>
>> Nope.
>> Nothing gets logged when I press the rfkill...
>>
>> I'd say that the rfkill rewrite killed my wireless :-(
>>
>> Bluetooth works at it whould, but not the wireless
>>
>> But now I have atleast found one way to get it working...
>>
>> I've built the rfkill utility, and with it I can get the wireless working...
>
> Thanks for the analysis!
>
>> Here is the output when wireless works:
>> [root@tmb-laptop rfkill]# ./rfkill list
>> 0: acer-wireless: Wireless LAN
>> Soft blocked: no
>> Hard blocked: no
>> 1: acer-bluetooth: Bluetooth
>> Soft blocked: yes
>> Hard blocked: no
>> 2: phy0: Wireless LAN
>> Soft blocked: no
>> Hard blocked: no
>
> Makes sense that it works at this point :)
>
>> Pressing the rfkill button gets me this:
>> [root@tmb-laptop rfkill]# ./rfkill list
>> 0: acer-wireless: Wireless LAN
>> Soft blocked: yes
>> Hard blocked: no
>> 1: acer-bluetooth: Bluetooth
>> Soft blocked: yes
>> Hard blocked: no
>> 2: phy0: Wireless LAN
>> Soft blocked: no
>> Hard blocked: yes
>
> So far so good. Your platform's soft-switch is wired to the card's hard
> kill line. Mind trying
>
> ./rfkill unblock 0
>
> (or whatever ID the acer-wireless has) at this point to see what
> happens? I would hope it goes back to the working state.
>
Nothing happends...
It does not change anything on either acer-wireless or phy0
--
Thomas
^ permalink raw reply
* Re: [RFC] cfg80211: add WoW support
From: Luis R. Rodriguez @ 2009-07-16 23:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247786409.1055.7.camel@johannes.local>
On Thu, Jul 16, 2009 at 4:20 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-16 at 15:55 -0700, Luis R. Rodriguez wrote:
>
>> + * NL80211_WOW_TRIGGER_DISABLE_ALL: Disables all WoW triggers on
>> + * the device.
>
> I don't understand the need for this. How is that different from
> userspace passing a 0 value for the attribute?
That's fine as well.
>> + triggers_requested =
>> + nla_get_u32(info->attrs[NL80211_ATTR_WOW_TRIGGERS_ENABLED]);
>> +
>> + if (triggers_requested & NL80211_WOW_TRIGGER_DISABLE_ALL) {
>> + rdev->wow.triggers_enabled = 0;
>> + goto out;
>> + }
>
> I mean, what do these extra lines of code buy us?
Sure, OK, I'll just use 0.
>> + /* We only support magic packet right now */
>> + if (!triggers_requested ||
>> + !(triggers_requested & NL80211_WOW_TRIGGER_MAGIC_PACKET)) {
>> + err = -EOPNOTSUPP;
>> + goto out;
>> + }
>
> Oi that seems like a roundabout way of saying
>
> if (triggers_requested & ~NL80211_WOW_TRIGGER_MAGIC_PACKET)
> ...
:) true
>> + mutex_lock(&rdev->devlist_mtx);
>> + /*
>> + * It only makes sense to enable WoW if we're associated as a STA,
>> + * the AP should be buffering frames for us. We'll discard all frames
>> + * and only process the frames which will trigger us on in hardware.
>> + */
>> + list_for_each_entry(wdev, &rdev->netdev_list, list) {
>
> I don't understand. You already have a netdev pointer from
>
> get_rdev_dev_by_info_ifindex(info->attrs, &rdev, &dev);
>
> why not just check the corresponding wdev for that netdev?
Well I was thinking of checking all netdevs, not just its own.
> I would store
> this netdev in the cfg80211_wow struct too, so you know on
> __cfg80211_disconnected() whether it was this netdev. And reject wow
> configuration if a wow configuration is already active for a different
> netdev?
>
> That way you can configure wow 'per netdev' but it's really only for one
> at a time.
Alright, this makes it a lot simpler, will do it this way, thanks.
Luis
^ permalink raw reply
* Re: [PATCH v2 16/21] mac80211: add helper for management / no-ack frame rate decision
From: Felix Fietkau @ 2009-07-16 23:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: johannes, linville, linux-wireless, ath9k-devel, Zhu Yi,
Reinette Chatre, ipw3945-devel, Gabor Juhos, Derek Smithies,
Chittajit Mitra
In-Reply-To: <1247763941-21396-1-git-send-email-lrodriguez@atheros.com>
Luis R. Rodriguez wrote:
> All current rate control algorithms agree to send management and no-ack
> frames at the lowest rate. They also agree to do this when sta
> and the private rate control data is NULL. We add a hlper to mac80211
> for this and simplify the rate control algorithm code.
>
> Developers wishing to make enhancements to rate control algorithms
> are for broadcast/multicast can opt to not use this in their
> gate_rate() mac80211 callback.
>
> Cc: Zhu Yi <yi.zhu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: ipw3945-devel@lists.sourceforge.net
> Cc: Gabor Juhos <juhosg@openwrt.org>
> Cc: Felix Fietkau <nbd@openwrt.org>
> Cc: Derek Smithies <derek@indranet.co.nz>
> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/rc.c | 14 +------------
> drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 13 ++---------
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 7 +-----
> include/net/mac80211.h | 23 ++++++++++++++++++++++
> net/mac80211/rate.c | 29 ++++++++++++++++++++++++++++
> net/mac80211/rc80211_minstrel.c | 22 +--------------------
> net/mac80211/rc80211_pid_algo.c | 11 +---------
> 7 files changed, 59 insertions(+), 60 deletions(-)
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply
* Re: [RFC] cfg80211: add WoW support
From: Johannes Berg @ 2009-07-16 23:20 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1247784904-805-1-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
On Thu, 2009-07-16 at 15:55 -0700, Luis R. Rodriguez wrote:
> + * NL80211_WOW_TRIGGER_DISABLE_ALL: Disables all WoW triggers on
> + * the device.
I don't understand the need for this. How is that different from
userspace passing a 0 value for the attribute?
> + triggers_requested =
> + nla_get_u32(info->attrs[NL80211_ATTR_WOW_TRIGGERS_ENABLED]);
> +
> + if (triggers_requested & NL80211_WOW_TRIGGER_DISABLE_ALL) {
> + rdev->wow.triggers_enabled = 0;
> + goto out;
> + }
I mean, what do these extra lines of code buy us?
> + /* We only support magic packet right now */
> + if (!triggers_requested ||
> + !(triggers_requested & NL80211_WOW_TRIGGER_MAGIC_PACKET)) {
> + err = -EOPNOTSUPP;
> + goto out;
> + }
Oi that seems like a roundabout way of saying
if (triggers_requested & ~NL80211_WOW_TRIGGER_MAGIC_PACKET)
...
> + mutex_lock(&rdev->devlist_mtx);
> + /*
> + * It only makes sense to enable WoW if we're associated as a STA,
> + * the AP should be buffering frames for us. We'll discard all frames
> + * and only process the frames which will trigger us on in hardware.
> + */
> + list_for_each_entry(wdev, &rdev->netdev_list, list) {
I don't understand. You already have a netdev pointer from
get_rdev_dev_by_info_ifindex(info->attrs, &rdev, &dev);
why not just check the corresponding wdev for that netdev? I would store
this netdev in the cfg80211_wow struct too, so you know on
__cfg80211_disconnected() whether it was this netdev. And reject wow
configuration if a wow configuration is already active for a different
netdev?
That way you can configure wow 'per netdev' but it's really only for one
at a time.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [KARMIC] review these for rt2x00 (adds rt2800pci)
From: Luis R. Rodriguez @ 2009-07-16 23:15 UTC (permalink / raw)
To: Stefan Bader, Ivo van Doorn; +Cc: Manoj Iyer, kernel-team, linux-wireless
On Thu, Jul 16, 2009 at 9:56 AM, Stefan Bader<stefan.bader@canonical.com> wrote:
> At least this seems to be material for 3 or 4 patches
> - adapt the rfkill stuff
> - some documentation update
> - add the new pci version of the 2800 (with that rt2x00soc lib
> which might be another patch)
> - and some fixes...
Not only that but this driver is not yet merged upstream, there should
be a good reason for that.
Ivo, what's the status on rt2800pci? Some users have been asking about it.
Luis
^ permalink raw reply
* [RFC] cfg80211: add WoW support
From: Luis R. Rodriguez @ 2009-07-16 22:55 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luis R. Rodriguez
We support a set and get for WoW parameters. We aware of
4 type of triggers:
* Magic Packet
* Beacon miss
* Link change (no longer associated)
* User pattern match
We currently only support Magic Packet.
The user pattern match will need a parser as patterns
can be customized.
WoW will require suspend to S3 Hot (power cable plugged),
and proper BIOS support to receive PCI PMEs and kick the box on,
and of course a capable device.
For USB this may be easier and no BIOS intervention should
be required.
Drivers which support WoW must set their supported hardware/driver
triggers on the wiphy's cfg80211 wow_triggers_supported. cfg80211
drivers will be informed of the enabled wow triggers through the
suspend() cfg80211 callback. By default we disable all triggers.
To enable WoW you must first be associated to an AP, WoW triggers
will also be disabled upon disconnect due to the security reasons
and the natural roaming nature of wireless. Userspace is expected
to enable WoW per BSS, and users running things manual will have
to enabe Wow every time they connect to the AP.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
I've done a few things differently, to disable we have a new
disable trigger, 'd' to match ethtool. Then, we enforce an
association required in order to enable WoW.
The next step would be to disable WoW upon cfg80211_disconnect()
if no device is connected.
Is this closer to what you were suggesting?
include/linux/nl80211.h | 39 +++++++++++
include/net/cfg80211.h | 26 +++++++-
net/wireless/core.h | 3 +
net/wireless/nl80211.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++
net/wireless/sysfs.c | 2 +-
5 files changed, 229 insertions(+), 3 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 962e223..3cb9a55 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -262,6 +262,18 @@
* reasons, for this the %NL80211_ATTR_DISCONNECTED_BY_AP and
* %NL80211_ATTR_REASON_CODE attributes are used.
*
+ * @NL80211_CMD_GET_WOW: get Wake-on-Wireless-LAN (WoW) settings.
+ * @NL80211_CMD_SET_WOW: set Wake-on-Wireless-LAN (Wow) settings. Wake on
+ * wireless makes use of standard Wake-on-LAN (WoL) frames, you receive
+ * a WoW frame when your AP sends you a regular WOL frame. The difference
+ * difference WoL is you need to be associated to an AP in order to
+ * receive WoW frames, so additional triggers are available for a wakeup.
+ * A driver capable of WoW should initialize the wiphy with its supported
+ * WoW triggers. Upon suspend cfg80211 will inform the driver of the user
+ * enabled triggers. By default no WoW triggers are enabled.
+ * For more information see:
+ * http://wireless.kernel.org/en/users/Documentation/WoW
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -336,6 +348,9 @@ enum nl80211_commands {
NL80211_CMD_ROAM,
NL80211_CMD_DISCONNECT,
+ NL80211_CMD_GET_WOW,
+ NL80211_CMD_SET_WOW,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -355,6 +370,8 @@ enum nl80211_commands {
#define NL80211_CMD_DEAUTHENTICATE NL80211_CMD_DEAUTHENTICATE
#define NL80211_CMD_DISASSOCIATE NL80211_CMD_DISASSOCIATE
#define NL80211_CMD_REG_BEACON_HINT NL80211_CMD_REG_BEACON_HINT
+#define NL80211_CMD_GET_WOW NL80211_CMD_GET_WOW
+#define NL80211_CMD_SET_WOW NL80211_CMD_SET_WOW
/**
* enum nl80211_attrs - nl80211 netlink attributes
@@ -573,6 +590,12 @@ enum nl80211_commands {
* and join_ibss(), key information is in a nested attribute each
* with %NL80211_KEY_* sub-attributes
*
+ * @NL80211_ATTR_WOW_TRIGGERS_SUPPORTED: the supported WoW triggers
+ * @NL80211_ATTR_WOW_TRIGGERS_ENABLED: used by %NL80211_CMD_SET_WOW to
+ * indicate which WoW triggers should be enabled. This is also
+ * used by %NL80211_CMD_GET_WOW to get the currently enabled WoW
+ * triggers.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -701,6 +724,9 @@ enum nl80211_attrs {
NL80211_ATTR_KEY,
NL80211_ATTR_KEYS,
+ NL80211_ATTR_WOW_TRIGGERS_SUPPORTED,
+ NL80211_ATTR_WOW_TRIGGERS_ENABLED,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -1372,4 +1398,17 @@ enum nl80211_key_attributes {
NL80211_KEY_MAX = __NL80211_KEY_AFTER_LAST - 1
};
+/**
+ * enum nl80211_wow_triggers - Wake-on-Wireless-LAN triggers
+ *
+ * NL80211_WOW_TRIGGER_DISABLE_ALL: Disables all WoW triggers on
+ * the device.
+ * NL80211_WOW_TRIGGER_MAGIC_PACKET: a wake signal will be sent to the
+ * devices if a magic packet is received.
+ */
+enum nl80211_wow_triggers {
+ NL80211_WOW_TRIGGER_DISABLE_ALL = 1 << 0,
+ NL80211_WOW_TRIGGER_MAGIC_PACKET = 1 << 1,
+};
+
#endif /* __LINUX_NL80211_H */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index a981ca8..d45fcec 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -828,6 +828,21 @@ struct cfg80211_bitrate_mask {
u32 maxrate; /* in kbps, 0 == no limit */
};
+/*
+ * struct cfg80211_wow - Wake on Wireless-LAN support info
+ *
+ * This structure defines the WoW triggers enabled and set for the device.
+ * For now we only carry the supported tiggers but this is expected to grow
+ * once we add support for user patterns.
+ *
+ * @triggers_enabled: enabled triggers by the user. Default
+ * is to disable all triggers. The flags for this bitmask
+ * are %NL80211_WOW_TRIGGER_*.
+ */
+struct cfg80211_wow {
+ u32 triggers_enabled;
+};
+
/**
* struct cfg80211_ops - backend description for wireless configuration
*
@@ -841,7 +856,8 @@ struct cfg80211_bitrate_mask {
* wireless extensions but this is subject to reevaluation as soon as this
* code is used more widely and we have a first user without wext.
*
- * @suspend: wiphy device needs to be suspended
+ * @suspend: wiphy device needs to be suspended. We pass the struct cfg80211_wow
+ * so the device enables the appropriate triggers during suspend.
* @resume: wiphy device needs to be resumed
*
* @add_virtual_intf: create a new virtual interface with the given name,
@@ -931,7 +947,7 @@ struct cfg80211_bitrate_mask {
* @testmode_cmd: run a test mode command
*/
struct cfg80211_ops {
- int (*suspend)(struct wiphy *wiphy);
+ int (*suspend)(struct wiphy *wiphy, struct cfg80211_wow *wow);
int (*resume)(struct wiphy *wiphy);
int (*add_virtual_intf)(struct wiphy *wiphy, char *name,
@@ -1088,6 +1104,10 @@ struct cfg80211_ops {
* @frag_threshold: Fragmentation threshold (dot11FragmentationThreshold);
* -1 = fragmentation disabled, only odd values >= 256 used
* @rts_threshold: RTS threshold (dot11RTSThreshold); -1 = RTS/CTS disabled
+ * @wow_triggers_supported: supported bitmask of Wake-on-Wireless triggers.
+ * The flags for this bitmask are %NL80211_WOW_TRIGGER_*. The driver
+ * should set the capabilities before registering the wiphy. WoW triggers
+ * which should be used are passed to the driver upon suspend.
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -1115,6 +1135,8 @@ struct wiphy {
u32 frag_threshold;
u32 rts_threshold;
+ u32 wow_triggers_supported;
+
/* If multiple wiphys are registered and you're handed e.g.
* a regular netdev with assigned ieee80211_ptr, you won't
* know whether it points to a wiphy your driver has registered
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 2ec8ddb..1d250cd 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -66,6 +66,9 @@ struct cfg80211_registered_device {
struct work_struct conn_work;
struct work_struct event_work;
+ /* Used to keep track of user configurable triggers */
+ struct cfg80211_wow wow;
+
#ifdef CONFIG_CFG80211_DEBUGFS
/* Debugfs entries */
struct wiphy_debugfsdentries {
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 6dad3e7..12506d9 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -133,6 +133,9 @@ static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
[NL80211_ATTR_PRIVACY] = { .type = NLA_FLAG },
[NL80211_ATTR_CIPHER_SUITE_GROUP] = { .type = NLA_U32 },
[NL80211_ATTR_WPA_VERSIONS] = { .type = NLA_U32 },
+
+ [NL80211_ATTR_WOW_TRIGGERS_SUPPORTED] = { .type = NLA_U32 },
+ [NL80211_ATTR_WOW_TRIGGERS_ENABLED] = { .type = NLA_U32 },
};
/* policy for the attributes */
@@ -4023,6 +4026,153 @@ unlock_rtnl:
return err;
}
+static int nl80211_get_wow(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev;
+ struct net_device *dev;
+ struct wiphy *wiphy;
+ int err;
+ void *hdr;
+ struct sk_buff *msg;
+
+ rtnl_lock();
+
+ /* Look up our device */
+ err = get_rdev_dev_by_info_ifindex(info->attrs, &rdev, &dev);
+ if (err)
+ goto out_rtnl;
+
+ wiphy = &rdev->wiphy;
+
+ /* Draw up a netlink message to send back */
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!msg) {
+ err = -ENOBUFS;
+ goto out;
+ }
+ hdr = nl80211hdr_put(msg, info->snd_pid, info->snd_seq, 0,
+ NL80211_CMD_GET_WOW);
+ if (!hdr)
+ goto nla_put_failure;
+ NLA_PUT_U32(msg, NL80211_ATTR_WOW_TRIGGERS_SUPPORTED,
+ wiphy->wow_triggers_supported);
+ NLA_PUT_U32(msg, NL80211_ATTR_WOW_TRIGGERS_ENABLED,
+ rdev->wow.triggers_enabled);
+
+ genlmsg_end(msg, hdr);
+ err = genlmsg_unicast(msg, info->snd_pid);
+ goto out;
+
+ nla_put_failure:
+ genlmsg_cancel(msg, hdr);
+ err = -EMSGSIZE;
+ out:
+ /* Cleanup */
+ cfg80211_unlock_rdev(rdev);
+ dev_put(dev);
+ out_rtnl:
+ rtnl_unlock();
+
+ return err;
+}
+
+static int nl80211_set_wow(struct sk_buff *skb, struct genl_info *info)
+{
+ int err;
+ struct cfg80211_registered_device *rdev;
+ struct net_device *dev;
+ struct wiphy *wiphy;
+ struct wireless_dev *wdev;
+ u32 triggers_requested;
+ bool found_assoc = false;
+
+ if (!info->attrs[NL80211_ATTR_WOW_TRIGGERS_ENABLED])
+ return -EINVAL;
+
+ rtnl_lock();
+
+ err = get_rdev_dev_by_info_ifindex(info->attrs, &rdev, &dev);
+ if (err)
+ goto out_rtnl;
+
+ wiphy = &rdev->wiphy;
+
+ if (!wiphy->wow_triggers_supported) {
+ err = -EOPNOTSUPP;
+ goto out;
+ }
+
+ triggers_requested =
+ nla_get_u32(info->attrs[NL80211_ATTR_WOW_TRIGGERS_ENABLED]);
+
+ if (triggers_requested & NL80211_WOW_TRIGGER_DISABLE_ALL) {
+ rdev->wow.triggers_enabled = 0;
+ goto out;
+ }
+
+ /* We only support magic packet right now */
+ if (!triggers_requested ||
+ !(triggers_requested & NL80211_WOW_TRIGGER_MAGIC_PACKET)) {
+ err = -EOPNOTSUPP;
+ goto out;
+ }
+
+ if ((triggers_requested & wiphy->wow_triggers_supported) !=
+ triggers_requested) {
+ err = -EOPNOTSUPP;
+ goto out;
+ }
+
+ mutex_lock(&rdev->devlist_mtx);
+ /*
+ * It only makes sense to enable WoW if we're associated as a STA,
+ * the AP should be buffering frames for us. We'll discard all frames
+ * and only process the frames which will trigger us on in hardware.
+ */
+ list_for_each_entry(wdev, &rdev->netdev_list, list) {
+
+ wdev_lock(wdev);
+
+ if (wdev->iftype != NL80211_IFTYPE_STATION) {
+ wdev_unlock(wdev);
+ continue;
+ }
+
+ if (wdev->sme_state != CFG80211_SME_CONNECTED) {
+ wdev_unlock(wdev);
+ continue;
+ }
+
+ wdev_unlock(wdev);
+
+ found_assoc = true;
+ break;
+
+ }
+ mutex_unlock(&rdev->devlist_mtx);
+
+ if (!found_assoc) {
+ err = -ENOLINK;
+ goto out;
+ }
+
+ /*
+ * Apply changes. This information gets passed to the
+ * drivers during suspend.
+ */
+ rdev->wow.triggers_enabled = triggers_requested;
+
+ out:
+ /* cleanup */
+ cfg80211_unlock_rdev(rdev);
+ dev_put(dev);
+ out_rtnl:
+ rtnl_unlock();
+
+ return err;
+}
+
static struct genl_ops nl80211_ops[] = {
{
.cmd = NL80211_CMD_GET_WIPHY,
@@ -4256,6 +4406,18 @@ static struct genl_ops nl80211_ops[] = {
.policy = nl80211_policy,
.flags = GENL_ADMIN_PERM,
},
+ {
+ .cmd = NL80211_CMD_GET_WOW,
+ .doit = nl80211_get_wow,
+ .policy = nl80211_policy,
+ /* can be retrieved by unprivileged users */
+ },
+ {
+ .cmd = NL80211_CMD_SET_WOW,
+ .doit = nl80211_set_wow,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ },
};
static struct genl_multicast_group nl80211_mlme_mcgrp = {
.name = "mlme",
diff --git a/net/wireless/sysfs.c b/net/wireless/sysfs.c
index efe3c5c..8b60a5b 100644
--- a/net/wireless/sysfs.c
+++ b/net/wireless/sysfs.c
@@ -64,7 +64,7 @@ static int wiphy_suspend(struct device *dev, pm_message_t state)
if (rdev->ops->suspend) {
rtnl_lock();
- ret = rdev->ops->suspend(&rdev->wiphy);
+ ret = rdev->ops->suspend(&rdev->wiphy, &rdev->wow);
rtnl_unlock();
}
--
1.6.3.3
^ permalink raw reply related
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Johannes Berg @ 2009-07-16 22:30 UTC (permalink / raw)
To: Thomas Backlund; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <1247782731.31442.3.camel@johannes.local>
On Fri, 2009-07-17 at 00:18 +0200, Johannes Berg wrote:
> > And pressing it again gets this:
> > [root@tmb-laptop rfkill]# ./rfkill list
> > 0: acer-wireless: Wireless LAN
> > Soft blocked: no
> > Hard blocked: no
> > 1: acer-bluetooth: Bluetooth
> > Soft blocked: yes
> > Hard blocked: no
> > 2: phy0: Wireless LAN
> > Soft blocked: yes
> > Hard blocked: no
> >
> > And after that I cant get wireless back until I again do a:
> > ./rfkill unblock 2
> > (works only when acer-wireless is no/no and Wireless LAN is yes/no)
>
> Right. This is bad. The button press shouldn't have affected the
> soft-state of the rfkill #2.
>
> > Applying this patch:
> > [PATCH] rfkill: fix rfkill_set_states() to set the hw state
> > sent by Alan Jenkins does not help this issue either...
> >
> > Any suggestions how to fix the rfkill ?
>
> I'll poke at the acer code to see what it's doing wrong...
Can't see anything wrong. I wonder if the button you have sends both the
ACPI event _and_ an input event.
Can you try this patch and tell us what happens?
johannes
--- wireless-testing.orig/net/rfkill/input.c 2009-07-17 00:27:29.000000000 +0200
+++ wireless-testing/net/rfkill/input.c 2009-07-17 00:29:50.000000000 +0200
@@ -57,6 +57,8 @@ static void __rfkill_handle_global_op(en
{
unsigned int i;
+ printk(KERN_DEBUG "__rfkill_handle_global_op(%d)\n", op);
+
switch (op) {
case RFKILL_GLOBAL_OP_EPO:
rfkill_epo();
@@ -87,6 +89,7 @@ static void __rfkill_handle_normal_op(co
bool blocked;
blocked = rfkill_get_global_sw_state(type);
+ printk(KERN_DEBUG "__rfkill_handle_normal_op(%d, %d) [%d]\n", type, complement, blocked);
if (complement)
blocked = !blocked;
@@ -175,6 +178,8 @@ static void rfkill_schedule_toggle(enum
{
unsigned long flags;
+ printk(KERN_DEBUG "rfkill_schedule_toggle(%d)\n", type);
+
if (rfkill_is_epo_lock_active())
return;
@@ -189,6 +194,8 @@ static void rfkill_schedule_toggle(enum
static void rfkill_schedule_evsw_rfkillall(int state)
{
+ printk(KERN_DEBUG "rfkill_schedule_evsw_rfkillall(%d)\n", state);
+
if (state)
rfkill_schedule_global_op(rfkill_master_switch_op);
else
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Johannes Berg @ 2009-07-16 22:18 UTC (permalink / raw)
To: Thomas Backlund; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <4A5FA52D.7030701@mandriva.org>
[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]
On Fri, 2009-07-17 at 01:09 +0300, Thomas Backlund wrote:
> Nope.
> Nothing gets logged when I press the rfkill...
>
> I'd say that the rfkill rewrite killed my wireless :-(
>
> Bluetooth works at it whould, but not the wireless
>
> But now I have atleast found one way to get it working...
>
> I've built the rfkill utility, and with it I can get the wireless working...
Thanks for the analysis!
> Here is the output when wireless works:
> [root@tmb-laptop rfkill]# ./rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: yes
> Hard blocked: no
> 2: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: no
Makes sense that it works at this point :)
> Pressing the rfkill button gets me this:
> [root@tmb-laptop rfkill]# ./rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: yes
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: yes
> Hard blocked: no
> 2: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: yes
So far so good. Your platform's soft-switch is wired to the card's hard
kill line. Mind trying
./rfkill unblock 0
(or whatever ID the acer-wireless has) at this point to see what
happens? I would hope it goes back to the working state.
> And pressing it again gets this:
> [root@tmb-laptop rfkill]# ./rfkill list
> 0: acer-wireless: Wireless LAN
> Soft blocked: no
> Hard blocked: no
> 1: acer-bluetooth: Bluetooth
> Soft blocked: yes
> Hard blocked: no
> 2: phy0: Wireless LAN
> Soft blocked: yes
> Hard blocked: no
>
> And after that I cant get wireless back until I again do a:
> ./rfkill unblock 2
> (works only when acer-wireless is no/no and Wireless LAN is yes/no)
Right. This is bad. The button press shouldn't have affected the
soft-state of the rfkill #2.
> Applying this patch:
> [PATCH] rfkill: fix rfkill_set_states() to set the hw state
> sent by Alan Jenkins does not help this issue either...
>
> Any suggestions how to fix the rfkill ?
I'll poke at the acer code to see what it's doing wrong...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: Thomas Backlund @ 2009-07-16 22:09 UTC (permalink / raw)
To: reinette chatre; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <1247672725.17896.1974.camel@rc-desk>
reinette chatre skrev:
> Thomas,
>
> On Tue, 2009-07-14 at 15:45 -0700, Thomas Backlund wrote:
>> Johannes Berg skrev:
>>> On Wed, 2009-07-15 at 01:15 +0300, Thomas Backlund wrote:
>>>> --- cut ---
>>>> Bringing up interface wlan0: RTNETLINK answers: Unknown error 132
>>>> RTNETLINK answers: Unknown error 132
>>> press your rfkill button.
>> I wish it was that simple :-(
>>
>> I already tried it, but it does not help...
>> I get no reaction what so ever from pressing it...
>>
>> The laptop is an Acer 5720G if that makes any difference...
>>
>> Could it be that rfkill has been broken for my laptop ?
>>
>> And why should I need to press rfkill now, when I didn't before ?
>> Has some kernel defaults changed since 2.6.30 series ?
>
> Do you have debugging enabled? Does your logs contain anything useful?
>
Nope.
Nothing gets logged when I press the rfkill...
I'd say that the rfkill rewrite killed my wireless :-(
Bluetooth works at it whould, but not the wireless
But now I have atleast found one way to get it working...
I've built the rfkill utility, and with it I can get the wireless working...
Here is the output when wireless works:
[root@tmb-laptop rfkill]# ./rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
Pressing the rfkill button gets me this:
[root@tmb-laptop rfkill]# ./rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: yes
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
And pressing it again gets this:
[root@tmb-laptop rfkill]# ./rfkill list
0: acer-wireless: Wireless LAN
Soft blocked: no
Hard blocked: no
1: acer-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: no
And after that I cant get wireless back until I again do a:
./rfkill unblock 2
(works only when acer-wireless is no/no and Wireless LAN is yes/no)
Applying this patch:
[PATCH] rfkill: fix rfkill_set_states() to set the hw state
sent by Alan Jenkins does not help this issue either...
Any suggestions how to fix the rfkill ?
--
Thomas
^ permalink raw reply
* Re: [RFC/RFT 0/5] mac80211: implement background scan
From: Helmut Schaa @ 2009-07-16 21:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247779378.30529.46.camel@johannes.local>
Am Donnerstag, 16. Juli 2009 schrieb Johannes Berg:
> On Thu, 2009-07-16 at 11:04 +0200, Helmut Schaa wrote:
>
> > So, it would be great if somebody could test the patches on other
> > hardware as well.
>
> If you repost with the stuff we talked about fixed, I'll give them a
> spin, but for all I can tell they should be good to go in, it's a huge
> improvement and we can build on that.
Will do that soon. However, I still have an issue that sometimes
the connection is stuck and I'm still unsure if it is related to the
bg scan patches or something else :(
Helmut
^ permalink raw reply
* Re: [RFC/RFT 0/5] mac80211: implement background scan
From: Johannes Berg @ 2009-07-16 21:22 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless
In-Reply-To: <200907161104.41975.helmut.schaa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
On Thu, 2009-07-16 at 11:04 +0200, Helmut Schaa wrote:
> So, it would be great if somebody could test the patches on other
> hardware as well.
If you repost with the stuff we talked about fixed, I'll give them a
spin, but for all I can tell they should be good to go in, it's a huge
improvement and we can build on that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] ath: add support for special 0x8000 regulatory domain
From: Luis R. Rodriguez @ 2009-07-16 21:18 UTC (permalink / raw)
To: linville, jal2
Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, Stephen Chen,
David Quan, Tony Yang
Two users of ar9170 devices have now reported their cards
have been programmed with a regulatory domain of 0x8000.
This is not a valid regulatory domain as such these users were
unable to use these devices. Since this doesn't seem to be
a device EEPROM corruption we must treat it specially.
We default these devices to the default Atheros 0x64 world
regulatory domain.
Reported-by: DavidFreeman on #linux-wireless
Reported-by: Joerg Albert <jal2@gmx.de>
Cc: Christian Lamparter <chunkeey@web.de>,
Cc: Stephen Chen <Stephen.Chen@atheros.com>
Cc: David Quan <David.Quan@atheros.com>
Cc: Tony Yang <Tony.Yang@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
David, or Joerg, can you please test this patch.
drivers/net/wireless/ath/regd.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index f37c832..62aa270 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -474,6 +474,21 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
return 0;
}
+/*
+ * Some users have reported their EEPROM programmed with
+ * 0x8000 set, this is not a supported regulatory domain
+ * but since we have more than one user with it we need
+ * a solution for them. We default to 0x64, which is the
+ * default Atheros world regulatory domain.
+ */
+static void ath_regd_sanitize(struct ath_regulatory *reg)
+{
+ if (reg->current_rd != CTRY_DEFAULT)
+ return;
+ printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
+ reg->current_rd = 0x64;
+}
+
int
ath_regd_init(struct ath_regulatory *reg,
struct wiphy *wiphy,
@@ -486,6 +501,8 @@ ath_regd_init(struct ath_regulatory *reg,
if (!reg)
return -EINVAL;
+ ath_regd_sanitize(reg);
+
printk(KERN_DEBUG "ath: EEPROM regdomain: 0x%0x\n", reg->current_rd);
if (!ath_regd_is_eeprom_valid(reg)) {
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC/RFT 5/5] mac80211: implement basic background scanning
From: Johannes Berg @ 2009-07-16 21:17 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless
In-Reply-To: <200907162252.09504.helmut.schaa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Thu, 2009-07-16 at 22:52 +0200, Helmut Schaa wrote:
> Am Donnerstag, 16. Juli 2009 schrieb Johannes Berg:
> > On Thu, 2009-07-16 at 11:50 +0200, Helmut Schaa wrote:
> > > I didn't do much performance testing, just a single wget and the performance
> > > dropped to about 50%. I still have to run some iperf tests (both RX and TX) to
> > > see how it behaves.
> >
> > I'd be more interested in the rtt stats that ping -f prints after you
> > abort it:
> >
> > rtt min/avg/max/mdev = 0.021/0.028/1.726/0.051 ms
>
> JFI, here's the result:
>
> 30851 packets transmitted, 30796 received, 0% packet loss, time 80592ms
> rtt min/avg/max/mdev = 1.512/8.235/251.145/32.479 ms, pipe 12, ipg/ewma 2.612/1.709 ms
Nice. Much better than the multiple seconds I had :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC/RFT 5/5] mac80211: implement basic background scanning
From: Helmut Schaa @ 2009-07-16 20:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247739394.29762.9.camel@johannes.local>
Am Donnerstag, 16. Juli 2009 schrieb Johannes Berg:
> On Thu, 2009-07-16 at 11:50 +0200, Helmut Schaa wrote:
> > I didn't do much performance testing, just a single wget and the performance
> > dropped to about 50%. I still have to run some iperf tests (both RX and TX) to
> > see how it behaves.
>
> I'd be more interested in the rtt stats that ping -f prints after you
> abort it:
>
> rtt min/avg/max/mdev = 0.021/0.028/1.726/0.051 ms
JFI, here's the result:
30851 packets transmitted, 30796 received, 0% packet loss, time 80592ms
rtt min/avg/max/mdev = 1.512/8.235/251.145/32.479 ms, pipe 12, ipg/ewma 2.612/1.709 ms
Helmut
^ permalink raw reply
* Re: [PATCH 7/8] rt2x00: Use %pM conversion specifier
From: Luis R. Rodriguez @ 2009-07-16 20:35 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Tobias Klauser, linville, netdev, linux-wireless, users
In-Reply-To: <200907162227.30362.IvDoorn@gmail.com>
On Thu, Jul 16, 2009 at 1:27 PM, Ivo van Doorn<ivdoorn@gmail.com> wrote:
> On Thursday 16 July 2009, Tobias Klauser wrote:
>> Use the %pM conversion specifier for printk instead of print_mac.
>>
>> Signed-off-by: Tobias Klauser <klto@zhaw.ch>
>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Johannes already has a patch for this posted which takes care of all of these.
http://marc.info/?l=linux-wireless&m=124767211929848&w=2
Luis
^ permalink raw reply
* Re: [PATCH] handle broken V4 fw region code shift
From: Marek Vasut @ 2009-07-16 20:29 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Dan Williams, libertas-dev
In-Reply-To: <43e72e890907161311m99e454v7daf9c58a340ae77@mail.gmail.com>
Dne Čt 16. července 2009 22:11:26 Luis R. Rodriguez napsal(a):
> On Thu, Jul 16, 2009 at 11:32 AM, Marek Vasut<marek.vasut@gmail.com> wrote:
> > Dne Čt 16. července 2009 20:21:30 Dan Williams napsal(a):
> >> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> >> > Hi,
> >> >
> >> > please consider applying/commenting on the following trivial fix. The
> >> > description is in the patch. Thanks.
> >>
> >> Please CC to linux-wireless@vger.kernel and I'll ack there so Linville
> >> will pick it up. Any patch that you consider appropriate for actual
> >> inclusion at the time you send it is better on linux-wireless.
> >> libertas-dev should really be only for hardware/firmware discussions and
> >> not-yet-ready patches.
> >>
> >> Thanks!
> >> Dan
> >
> > Done, thanks! :-)
> > (sorry for sending it twice, I missed the address was incomplete in your
> > mail)
>
> Please resend inline
>
> Luis
Here you go
>From d69e6db9d424e40dade6bbf107dbab2ff4d692d5 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marek.vasut@gmail.com>
Date: Thu, 16 Jul 2009 19:19:53 +0200
Subject: [PATCH] Fix problem with broken V4 firmware on CF8381
Firmware V4 on CF8381 reports region code shifted by 1 byte to left.
The following patch checks for this and handles it properly.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
---
drivers/net/wireless/libertas/cmd.c | 8 +++++++-
drivers/net/wireless/libertas/defs.h | 2 ++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index 01db705..445288d 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -135,8 +135,14 @@ int lbs_update_hw_spec(struct lbs_private *priv)
/* Clamp region code to 8-bit since FW spec indicates that it should
* only ever be 8-bit, even though the field size is 16-bit. Some
firmware
* returns non-zero high 8 bits here.
+ *
+ * Firmware version 4.0.102 used in CF8381 has region code shifted. We
+ * need to check for this problem and handle it properly.
*/
- priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
+ if (MRVL_FW_MAJOR_REV(priv->fwrelease) == MRVL_FW_V4)
+ priv->regioncode = (le16_to_cpu(cmd.regioncode) >> 8) & 0xFF;
+ else
+ priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
for (i = 0; i < MRVDRV_MAX_REGION_CODE; i++) {
/* use the region code to search for the index */
diff --git a/drivers/net/wireless/libertas/defs.h
b/drivers/net/wireless/libertas/defs.h
index 48da157..72f3479 100644
--- a/drivers/net/wireless/libertas/defs.h
+++ b/drivers/net/wireless/libertas/defs.h
@@ -234,6 +234,8 @@ static inline void lbs_deb_hex(unsigned int grp, const
char *prompt, u8 *buf, in
/** Mesh enable bit in FW capability */
#define MESH_CAPINFO_ENABLE_MASK (1<<16)
+/** FW definition from Marvell v4 */
+#define MRVL_FW_V4 (0x04)
/** FW definition from Marvell v5 */
#define MRVL_FW_V5 (0x05)
/** FW definition from Marvell v10 */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 7/8] rt2x00: Use %pM conversion specifier
From: Ivo van Doorn @ 2009-07-16 20:27 UTC (permalink / raw)
To: Tobias Klauser; +Cc: linville, netdev, linux-wireless, users
In-Reply-To: <1247734839-21394-1-git-send-email-klto@zhaw.ch>
On Thursday 16 July 2009, Tobias Klauser wrote:
> Use the %pM conversion specifier for printk instead of print_mac.
>
> Signed-off-by: Tobias Klauser <klto@zhaw.ch>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 3756166..da84afb 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -2224,10 +2224,8 @@ static int rt2800usb_validate_eeprom(struct rt2x00_dev *rt2x00dev)
> */
> mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
> if (!is_valid_ether_addr(mac)) {
> - DECLARE_MAC_BUF(macbuf);
> -
> random_ether_addr(mac);
> - EEPROM(rt2x00dev, "MAC: %s\n", print_mac(macbuf, mac));
> + EEPROM(rt2x00dev, "MAC: %pM\n", mac);
> }
>
> rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Pavel Roskin @ 2009-07-16 20:20 UTC (permalink / raw)
To: Jon Fairbairn; +Cc: linux-wireless
In-Reply-To: <wf1vogmujw.fsf@calligramme.charmers>
On Thu, 2009-07-16 at 18:01 +0100, Jon Fairbairn wrote:
> Ah, thanks for that. Three questions arise:
>
> Are the pci ids quoted above recognised as needing ath5k?
Yes, 168c:001c is served by ath5k.
> Is the WLP-01 really ath5k/really have those ids?
The Abit site had only one driver for WLP-01. There are references that
some WLP-01 devices use Atheros chipset. Thus we conclude that all
WLP-01 use Atheros chipset, or there would be more that one driver.
The Atheros PCI ID is 168c. Search on Google for "WLP-01 168c" without
quotes finds 001c everywhere. So it should work with ath5k.
I cannot guarantee anything, but I think chances are very high.
> The distro I'm using (fedora 11) has 2.6.29 -- will the relevant modules
> build for that, or would I have to build a whole 2.6.31?
You can build compat-wireless, which includes the latest ath5k driver
backported from the wireless-testing kernel. Alternatively, you can
build madwifi (be sure to use the trunk snapshot).
--
Regards,
Pavel Roskin
^ 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