* Re: Passing a custom MAC to ath6kl
From: Kalle Valo @ 2013-07-05 20:23 UTC (permalink / raw)
To: Arend van Spriel
Cc: Hector Palacios, linux-wireless@vger.kernel.org,
ath6kl-devel@qca.qualcomm.com
In-Reply-To: <51D70A22.20607@broadcom.com>
Arend van Spriel <arend@broadcom.com> writes:
> On 07/05/2013 05:56 PM, Hector Palacios wrote:
>> Dear Kalle,
>>
>> On 07/05/2013 05:49 PM, Kalle Valo wrote:
>>> Hector Palacios <hector.palacios@digi.com> writes:
>>>
>>>> Is there a way to pass a custom MAC address to the ath6kl upstream
>>>> driver?
>>>
>>> Not right now. It has been a common feature request so I'm hoping
>>> someone will implement it soon.
>>>
>>>> In the ISC version of the driver, a softmac.c file is provided that
>>>> reads a MAC from a file if a module parameter softmac_enable=1 is
>>>> passed. Is there any reason why this has not made it upstream?
>>>
>>> Providing mac address through a file is too ugly for upstream. We need
>>> to implement it properly using the proper interface.
>>
>> I totally agree. What would be the proper interface for that?
>
> Add .ndo_set_mac_address() callback in main.c and go from there.
>
> int (*ndo_set_mac_address)(struct net_device *dev, void *addr);
And the challenge with ath6kl is that we need to stop the firmware,
change mac address in the firmware and restart the firmware. So it's not
trivial to add that but it shouldn't be too difficult either. Patches
more than welcome :)
--
Kalle Valo
^ permalink raw reply
* Re: [ath9k-devel] ath: Unable to remove station entry
From: Oleksij Rempel @ 2013-07-06 5:31 UTC (permalink / raw)
To: Michael Tokarev; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <51D68B55.3070309@msgid.tls.msk.ru>
Hi Michael,
there is no way to avoid latest wireless-testing kernel. I had similar
problems for some kernel version. But now it seems to work more or less
ok. For example it will nuke complete system only by triggering some bug
in xhcd driver :)
Am 05.07.2013 11:01, schrieb Michael Tokarev:
> Hello.
>
> Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor,
> and tried to use it as an access point for a small Wireless LAN.
>
> It works fine so far, except of one issue.
>
> Quite often to be really annoying, it stops working with the
> following message in kernel log:
>
> Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1
>
> after this, the interface is stuck, it can't be seen over WIFI,
> and any attempt to do anything with it inside the host results
> in more processes entering D state (initially right when this
> happens, there's a kworker process in D state).
>
> For example, `rmmod ath9k_htc' - which appears to be a topmost
> module on the stack - results in rmmod entering D state, with
> the following stack:
>
> rmmod D 000000010266c10c 0 10684 10643 0x00000000
> ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0
> ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0
> 0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500
> Call Trace:
> [<ffffffff81367a59>] ? __schedule+0x3a9/0x960
> [<ffffffff810558f0>] ? usleep_range+0x40/0x40
> [<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140
> [<ffffffff813689ba>] ? mutex_lock+0x1a/0x40
> [<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc]
> [<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc]
> [<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath]
> [<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath]
> [<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc]
> [<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211]
> [<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211]
> [<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211]
> [<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211]
> [<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240
> [<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211]
> [<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0
> [<ffffffff812bc638>] ? dev_close_many+0x98/0x110
> [<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250
> [<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60
> [<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211]
> [<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211]
> [<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc]
> [<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc]
> [<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore]
> [<ffffffff81274546>] ? __device_release_driver+0x76/0xe0
> [<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0
> [<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0
> [<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore]
> [<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc]
> [<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260
> [<ffffffff8136a245>] ? page_fault+0x25/0x30
> [<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b
>
> followed by:
>
> Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0
>
> (rmmod is stuck forever).
>
> Now, in order to make the interface to work again, the only way I
> found so far is to _reboot_ the machine. For example, re-plugging
> the USB cord does not help, because, as far as I can see, the driver
> is in some weird state and can't initialize the new interface.
>
> This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64),
> self-compiled, without additional patches.
>
>
> There are a few references to this message on the 'net, including
> one mentioning this very card (in russian) --
>
> http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html
>
> they claim the problem has been fixed for _some_ by upgrading the
> BIOS on the motherboard. Maybe this is actually related, because
> as far as I can tell, this started happening _after_ I upgraded
> BIOS on my motherboard, so it may be related to the bios changes.
> I don't recall whenever I noticed this erratic behavour before I
> upgraded BIOS. Looking at the BIOS history, I don't see anything
> interesting about USB in the changelog, except this:
>
> * Fixed issue with Fast Boot so USB devices still work under DOS
> if USB Optimization is enabled.
>
> This is an intel atom-based D2500CC board, with the latest BIOS.
> I had to update bios because of another issue which is now fixed,
> but I can't go back to the old bios because the old one was too
> old and current motherboard refuses to flash it.
>
>
> What can be done to diagnose the problem? I can give a more recent
> kernel a try, but I'd love to see it fixed for a -stable kernel which
> is used by several major distributions. Also, the problem is not
> easy to trigger, the system may work for a few days without issues
> or may stop working in a few hours, irrespective of the load (f.e.
> the above example at 09:51 was me awakening my android phone just
> to see what time it is now, and it trying to connect/disconnect
> to/from the default wifi network -- there were no other devices
> using wifi at that time).
>
> Thanks,
>
> /mjt
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
--
Regards,
Oleksij
^ permalink raw reply
* Re: [ath9k-devel] ath: Unable to remove station entry
From: Michael Tokarev @ 2013-07-06 6:47 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <51D7ABC6.40307@rempel-privat.de>
06.07.2013 09:31, Oleksij Rempel wrote:
> Hi Michael,
Hello!
> there is no way to avoid latest wireless-testing kernel. I had similar problems for some kernel version. But now it seems to work more or less ok. For example it will nuke complete system only by triggering some bug in xhcd driver :)
Hmm. Are you saying that no one cares about -stable, and
bugs are only fixed in latest prereleases? If that's true,
it is very unfortunate situation for the wireless subsystem...
Thanks,
/mjt
> Am 05.07.2013 11:01, schrieb Michael Tokarev:
>> Hello.
>>
>> Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor,
>> and tried to use it as an access point for a small Wireless LAN.
>>
>> It works fine so far, except of one issue.
>>
>> Quite often to be really annoying, it stops working with the
>> following message in kernel log:
>>
>> Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1
>>
>> after this, the interface is stuck, it can't be seen over WIFI,
>> and any attempt to do anything with it inside the host results
>> in more processes entering D state (initially right when this
>> happens, there's a kworker process in D state).
>>
>> For example, `rmmod ath9k_htc' - which appears to be a topmost
>> module on the stack - results in rmmod entering D state, with
>> the following stack:
>>
>> rmmod D 000000010266c10c 0 10684 10643 0x00000000
>> ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0
>> ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0
>> 0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500
>> Call Trace:
>> [<ffffffff81367a59>] ? __schedule+0x3a9/0x960
>> [<ffffffff810558f0>] ? usleep_range+0x40/0x40
>> [<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140
>> [<ffffffff813689ba>] ? mutex_lock+0x1a/0x40
>> [<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc]
>> [<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc]
>> [<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath]
>> [<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath]
>> [<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc]
>> [<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211]
>> [<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211]
>> [<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211]
>> [<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211]
>> [<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240
>> [<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211]
>> [<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0
>> [<ffffffff812bc638>] ? dev_close_many+0x98/0x110
>> [<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250
>> [<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60
>> [<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211]
>> [<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211]
>> [<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc]
>> [<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc]
>> [<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore]
>> [<ffffffff81274546>] ? __device_release_driver+0x76/0xe0
>> [<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0
>> [<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0
>> [<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore]
>> [<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc]
>> [<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260
>> [<ffffffff8136a245>] ? page_fault+0x25/0x30
>> [<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b
>>
>> followed by:
>>
>> Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0
>>
>> (rmmod is stuck forever).
>>
>> Now, in order to make the interface to work again, the only way I
>> found so far is to _reboot_ the machine. For example, re-plugging
>> the USB cord does not help, because, as far as I can see, the driver
>> is in some weird state and can't initialize the new interface.
>>
>> This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64),
>> self-compiled, without additional patches.
>>
>>
>> There are a few references to this message on the 'net, including
>> one mentioning this very card (in russian) --
>>
>> http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html
>>
>> they claim the problem has been fixed for _some_ by upgrading the
>> BIOS on the motherboard. Maybe this is actually related, because
>> as far as I can tell, this started happening _after_ I upgraded
>> BIOS on my motherboard, so it may be related to the bios changes.
>> I don't recall whenever I noticed this erratic behavour before I
>> upgraded BIOS. Looking at the BIOS history, I don't see anything
>> interesting about USB in the changelog, except this:
>>
>> * Fixed issue with Fast Boot so USB devices still work under DOS
>> if USB Optimization is enabled.
>>
>> This is an intel atom-based D2500CC board, with the latest BIOS.
>> I had to update bios because of another issue which is now fixed,
>> but I can't go back to the old bios because the old one was too
>> old and current motherboard refuses to flash it.
>>
>>
>> What can be done to diagnose the problem? I can give a more recent
>> kernel a try, but I'd love to see it fixed for a -stable kernel which
>> is used by several major distributions. Also, the problem is not
>> easy to trigger, the system may work for a few days without issues
>> or may stop working in a few hours, irrespective of the load (f.e.
>> the above example at 09:51 was me awakening my android phone just
>> to see what time it is now, and it trying to connect/disconnect
>> to/from the default wifi network -- there were no other devices
>> using wifi at that time).
>>
>> Thanks,
>>
>> /mjt
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel@lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
^ permalink raw reply
* Re: [ath9k-devel] ath: Unable to remove station entry
From: Sedat Dilek @ 2013-07-06 7:11 UTC (permalink / raw)
To: Michael Tokarev; +Cc: Oleksij Rempel, linux-wireless, ath9k-devel
In-Reply-To: <51D7BD80.6010507@msgid.tls.msk.ru>
On Sat, Jul 6, 2013 at 8:47 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> 06.07.2013 09:31, Oleksij Rempel wrote:
>> Hi Michael,
>
> Hello!
>
>> there is no way to avoid latest wireless-testing kernel. I had similar problems for some kernel version. But now it seems to work more or less ok. For example it will nuke complete system only by triggering some bug in xhcd driver :)
>
> Hmm. Are you saying that no one cares about -stable, and
> bugs are only fixed in latest prereleases? If that's true,
> it is very unfortunate situation for the wireless subsystem...
>
It's always worth to test a higher (experimental) wireless stack to
see if the problem is solved or not.
After some more wisdom, it is hard to isolate the commit(s).
Might be worth to test compat-wireless, from my POV easier.
As usually for wireless-testing... so much components involved
(wireless-card, AP, kernelspace, userspace, etc.)...
( Start to kill any viruses flying in the air around :-). )
( Demolish any walls, walk through the wall, be the wall... :-). )
- Sedat -
> Thanks,
>
> /mjt
>
>> Am 05.07.2013 11:01, schrieb Michael Tokarev:
>>> Hello.
>>>
>>> Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor,
>>> and tried to use it as an access point for a small Wireless LAN.
>>>
>>> It works fine so far, except of one issue.
>>>
>>> Quite often to be really annoying, it stops working with the
>>> following message in kernel log:
>>>
>>> Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1
>>>
>>> after this, the interface is stuck, it can't be seen over WIFI,
>>> and any attempt to do anything with it inside the host results
>>> in more processes entering D state (initially right when this
>>> happens, there's a kworker process in D state).
>>>
>>> For example, `rmmod ath9k_htc' - which appears to be a topmost
>>> module on the stack - results in rmmod entering D state, with
>>> the following stack:
>>>
>>> rmmod D 000000010266c10c 0 10684 10643 0x00000000
>>> ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0
>>> ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0
>>> 0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500
>>> Call Trace:
>>> [<ffffffff81367a59>] ? __schedule+0x3a9/0x960
>>> [<ffffffff810558f0>] ? usleep_range+0x40/0x40
>>> [<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140
>>> [<ffffffff813689ba>] ? mutex_lock+0x1a/0x40
>>> [<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc]
>>> [<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc]
>>> [<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath]
>>> [<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath]
>>> [<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc]
>>> [<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211]
>>> [<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211]
>>> [<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211]
>>> [<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211]
>>> [<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240
>>> [<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211]
>>> [<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0
>>> [<ffffffff812bc638>] ? dev_close_many+0x98/0x110
>>> [<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250
>>> [<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60
>>> [<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211]
>>> [<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211]
>>> [<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc]
>>> [<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc]
>>> [<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore]
>>> [<ffffffff81274546>] ? __device_release_driver+0x76/0xe0
>>> [<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0
>>> [<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0
>>> [<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore]
>>> [<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc]
>>> [<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260
>>> [<ffffffff8136a245>] ? page_fault+0x25/0x30
>>> [<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b
>>>
>>> followed by:
>>>
>>> Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0
>>>
>>> (rmmod is stuck forever).
>>>
>>> Now, in order to make the interface to work again, the only way I
>>> found so far is to _reboot_ the machine. For example, re-plugging
>>> the USB cord does not help, because, as far as I can see, the driver
>>> is in some weird state and can't initialize the new interface.
>>>
>>> This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64),
>>> self-compiled, without additional patches.
>>>
>>>
>>> There are a few references to this message on the 'net, including
>>> one mentioning this very card (in russian) --
>>>
>>> http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html
>>>
>>> they claim the problem has been fixed for _some_ by upgrading the
>>> BIOS on the motherboard. Maybe this is actually related, because
>>> as far as I can tell, this started happening _after_ I upgraded
>>> BIOS on my motherboard, so it may be related to the bios changes.
>>> I don't recall whenever I noticed this erratic behavour before I
>>> upgraded BIOS. Looking at the BIOS history, I don't see anything
>>> interesting about USB in the changelog, except this:
>>>
>>> * Fixed issue with Fast Boot so USB devices still work under DOS
>>> if USB Optimization is enabled.
>>>
>>> This is an intel atom-based D2500CC board, with the latest BIOS.
>>> I had to update bios because of another issue which is now fixed,
>>> but I can't go back to the old bios because the old one was too
>>> old and current motherboard refuses to flash it.
>>>
>>>
>>> What can be done to diagnose the problem? I can give a more recent
>>> kernel a try, but I'd love to see it fixed for a -stable kernel which
>>> is used by several major distributions. Also, the problem is not
>>> easy to trigger, the system may work for a few days without issues
>>> or may stop working in a few hours, irrespective of the load (f.e.
>>> the above example at 09:51 was me awakening my android phone just
>>> to see what time it is now, and it trying to connect/disconnect
>>> to/from the default wifi network -- there were no other devices
>>> using wifi at that time).
>>>
>>> Thanks,
>>>
>>> /mjt
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel@lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] brcm: add brcmfmac sdio firmware for bcm43241
From: Ben Hutchings @ 2013-07-06 15:39 UTC (permalink / raw)
To: Arend van Spriel
Cc: Linux Wireless, Franky Lin, David Woodhouse, Stephen Warren
In-Reply-To: <51D54FD2.6090107@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]
On Thu, 2013-07-04 at 12:34 +0200, Arend van Spriel wrote:
> On 07/04/2013 04:22 AM, Ben Hutchings wrote:
> > On Wed, 2013-05-29 at 15:13 +0200, Arend van Spriel wrote:
[...]
> >> --- a/WHENCE
> >> +++ b/WHENCE
> >> @@ -1652,6 +1652,7 @@ Driver: brcmfmac - Broadcom 802.11n fullmac wireless LAN driver.
> >>
> >> File: brcm/bcm4329-fullmac-4.bin
> >> File: brcm/brcmfmac43236b.bin
> >> +File: brcm/brcmfmac43241.bin
> >> File: brcm/brcmfmac4329.bin
> >> File: brcm/brcmfmac4330.bin
> >> File: brcm/brcmfmac4334.bin
> > [...]
> >
> > Unless you're doing something very clever with macros, I don't believe
> > you've posted any driver code that uses this file... or several of the
> > others. The current driver in net-next (I don't know what you've sent
> > to Nvidia) appears to request only these files:
>
> Hi, Ben
>
> Nvidia was just using the upstream brcmfmac driver. The "clever" thing
> we are doing for the SDIO part of our brcmfmac driver is that the
> firmware filename requested by the driver is always brcmfmac-sdio.bin.
> We explain on wireless.kernel.org that people should link/copy the
> firmware file for their device to brcmfmac-sdio.bin
Not a great idea, but I think you recognise that now.
> and get
> brcmfmac-sdio.txt from their board supplier as it is very board specific
> initialization data.
What if someone wants to put more than one of these devices in the same
system?
[...]
> > So I think, before this patch is applied, you owe me and David patches
> > to:
> >
> > 1. Add brcm/brcmfmac43143.bin, brcm/brcmfmac43242a.bin and
> > brcm/brcmfmac-sdio.txt.
>
> The 43143 and 43242 bin files will be submitted, but these firmwares
> have not yet been released. I have to wait for a green light on that.
>
> > 2. Rename brcm/bcm4329-fullmac-4.bin to brcm/brcmfmac-sdio.bin.
>
> That file is there for brcmfmac in older kernels (< v3.3) as the
> replacement brcmfmac4329.bin does not work with brcmfmac in those older
> kernels.
OK.
> > 3. Add symlinks from all the old names to the new names. (As
> > linux-firmware should support old in-tree drivers indefinitely.)
>
> I will look into this to see what names were used by brcmfmac since it
> was mainlined.
As I said, all the names that have been used should be supported. So
either provide multiple versions of the firmware or add symlinks, as
appropriate.
> > and you owe linux-wireless some driver patches.
> >
> > linux-firmware.git is not the appropriate place to send firmware used
> > only by out-of-tree code, and any firmware blob that has never been
> > referenced by in-tree code is subject to removal.
>
> I am aware and none of the firmwares we released are for out-of-tree
> code. We actually got feedback that using the same firmware filename for
> multiple devices was not very user-friendly. Therefore we will get rid
> of this quirky approach in the next kernel and the firmware files in
> linux-firmware will be listed in brcmfmac using the MODULE_FIRMWARE() macro.
Thanks for clearing this up.
Please re-send the new firmware, and include the firmware version in
WHENCE.
Ben.
--
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Realtek RTL8188CUS driver
From: Ivan A. Ivanchikov @ 2013-07-06 19:45 UTC (permalink / raw)
To: linux-wireless
Good day, gentlemen!
I use arch linux, and have this device
http://www.trendnet.com/downloads/list_subcategory.asp?SUBTYPE_ID=1426
Driver from stock kernel cannot be used, rtl8192cu was loaded but does not work.
I downloaded https://github.com/downloads/dvdhrm/rt8192cu/rt8192cu-3.4.3.4369.20120622.tar.gz
this sources and this patch
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1030858/comments/65
and then my network works. My current kernel version is 3.9.9.
If changes can be integrated for stock kernel?
yours respectfully, Ivan
^ permalink raw reply
* Re: Constant network assoc/disassoc loop with rtl8192cu usb adapter
From: Ilia Mirkin @ 2013-07-07 2:41 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <CAKb7UvjVyZuOjuD3oFT_jxx5T=DNamHA_YiV_yGWcmePHHd-UQ@mail.gmail.com>
On Thu, Jul 4, 2013 at 1:35 AM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> Hello,
>
> I recently got a RTL8188CUS usb adapter (which uses the rtl8192cu
> driver). I'm having trouble getting it to stay associated:
>
> [601369.845916] wlan0: associated
> [601377.106440] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try
> to reconnect now
> [601383.867706] wlan0: associated
> [601391.120270] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try
> to reconnect now
> [601397.910678] wlan0: associated
> [601405.141764] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try
> to reconnect now
>
> and so on. A different usb adapter (Ralink RT2573) has no trouble
> associating to that AP (but it keeps hanging and the kernel isn't
> always able to reset it properly). The network in question is using
> WPA2-PSK.
>
> Is there some setting I could adjust so that it would wait longer
> before deciding that the AP is off? Or something else I can do?
>
> This is on a 3.10-rc6 kernel + the __queue_work warning fix patch at
> https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-testing.git/patch/?id=1621c9466099faf21ad19738d54a7d1845a29b32.
In addition to the messages above, I also occasionally saw sequences of 3-6
rtlwifi:addbareq_rx():<100-1> sta is NULL
messages after an association timeout.
Here are a few things I tried:
(a) increasing the timeout to 20 seconds, from 6. Didn't help.
(b) printing each beacon frame (in rtl_beacon_statistic). This showed
some potentially interesting results... right after association, I see
beacons from various APs (including the right one). But after about 1
second, all the other APs die out, and I only see beacons from 2
related APs (foo and foo-guest, with nearly identical bssid's),
neither of which is the one I want. I think that they're stronger than
the AP I'm trying to connect to. Sometimes the "right" AP's beacons
come back, sometimes not.
(c) Realtek's driver (rtl8188C_8192C_usb_linux_v3.4.4_4749.20121105).
Eventually I got it to compile. It links just fine to the AP, no
wifi-related problems. (The driver hung the system on usb removal, but
that seems more related to poor coding.) So the AP isn't too far away,
and it's not a situation where there's too much noise for the hardware
to handle. Running a ping shows that there aren't any significant
connection drops.
Let me know if there are other things you think I should try. Happy to
test any patches/provide info.
-ilia
^ permalink raw reply
* [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Larry Finger @ 2013-07-07 2:47 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Fengguang Wu
Fengguang Wu reported the following errors in the build of rtlwifi with
a random configuration:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
head: bcd7351e83728859833e3c5b8aae9a2816914e4b
commit: 06e7cda3ce30dadc3454539127b4cfc3888c349e rtlwifi: Rework Kconfig
date: 5 months ago
config: i386-randconfig-s05-0703
drivers/built-in.o: In function `rtl_usb_cleanup':
usb.c:(.text+0x114895): undefined reference to `usb_kill_anchored_urbs'
usb.c:(.text+0x114964): undefined reference to `usb_kill_anchored_urbs'
usb.c:(.text+0x11497c): undefined reference to `usb_kill_anchored_urbs'
drivers/built-in.o: In function `_usb_writeN_sync':
usb.c:(.text+0x114c9e): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `rtl_usb_disconnect':
(.text+0x114d9c): undefined reference to `usb_put_dev'
drivers/built-in.o: In function `rtl_usb_start':
usb.c:(.text+0x114fb0): undefined reference to `usb_alloc_urb'
usb.c:(.text+0x115049): undefined reference to `usb_free_urb'
--snip--
Although I could not duplicate this result on my machine, it seemed likely
that it was due to the unusual configuration where rtlwifi was being built,
but none of its dependent drivers were selected.
The fix is to select rtlwifi only when it is needed. While making this
change, I simplified the configuration so that variable RTLWIFI is never seen
by the user. In addition, now that the rtlwifi family has six members, I
added a menu so that these drivers no longer appear in the long list of
wireless drivers, but in a separate panel.
Cc: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/Kconfig | 57 +++++++++++++++++++++---------------
1 file changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/Kconfig b/drivers/net/wireless/rtlwifi/Kconfig
index 7253de3..7552841 100644
--- a/drivers/net/wireless/rtlwifi/Kconfig
+++ b/drivers/net/wireless/rtlwifi/Kconfig
@@ -1,27 +1,18 @@
-config RTLWIFI
- tristate "Realtek wireless card support"
- depends on MAC80211
- select FW_LOADER
+menuconfig RTL_CARDS
+ tristate "Realtek rtlwifi family of devices"
+ depends on MAC80211 && (PCI || USB)
---help---
- This is common code for RTL8192CE/RTL8192CU/RTL8192SE/RTL8723AE
- drivers. This module does nothing by itself - the various front-end
- drivers need to be enabled to support any desired devices.
+ This option will enable support for the Realtek mac80211-based
+ wireless drivers. Drivers rtl8192ce, rtl8192cu, rtl8192se, rtl8192de,
+ rtl8723eu, and rtl8188eu share some common code.
- If you choose to build as a module, it'll be called rtlwifi.
-
-config RTLWIFI_DEBUG
- bool "Debugging output for rtlwifi driver family"
- depends on RTLWIFI
- default y
- ---help---
- To use the module option that sets the dynamic-debugging level for,
- the front-end driver, this parameter must be "Y". For memory-limited
- systems, choose "N". If in doubt, choose "Y".
+if RTL_CARDS
config RTL8192CE
tristate "Realtek RTL8192CE/RTL8188CE Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
select RTL8192C_COMMON
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8192CE/RTL8188CE 802.11n PCIe
wireless network adapters.
@@ -30,7 +21,8 @@ config RTL8192CE
config RTL8192SE
tristate "Realtek RTL8192SE/RTL8191SE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8192SE/RTL8191SE 802.11n PCIe
wireless network adapters.
@@ -39,7 +31,8 @@ config RTL8192SE
config RTL8192DE
tristate "Realtek RTL8192DE/RTL8188DE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8192DE/RTL8188DE 802.11n PCIe
wireless network adapters.
@@ -48,7 +40,8 @@ config RTL8192DE
config RTL8723AE
tristate "Realtek RTL8723AE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8723AE 802.11n PCIe
wireless network adapters.
@@ -57,7 +50,8 @@ config RTL8723AE
config RTL8188EE
tristate "Realtek RTL8188EE Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8188EE 802.11n PCIe
wireless network adapters.
@@ -66,7 +60,8 @@ config RTL8188EE
config RTL8192CU
tristate "Realtek RTL8192CU/RTL8188CU USB Wireless Network Adapter"
- depends on RTLWIFI && USB
+ depends on USB
+ select RTLWIFI
select RTL8192C_COMMON
---help---
This is the driver for Realtek RTL8192CU/RTL8188CU 802.11n USB
@@ -74,7 +69,22 @@ config RTL8192CU
If you choose to build it as a module, it will be called rtl8192cu
+config RTLWIFI
+ tristate
+ select FW_LOADER
+
+config RTLWIFI_DEBUG
+ bool "Debugging output for rtlwifi driver family"
+ depends on RTLWIFI
+ default y
+ ---help---
+ To use the module option that sets the dynamic-debugging level for,
+ the front-end driver, this parameter must be "Y". For memory-limited
+ systems, choose "N". If in doubt, choose "Y".
+
config RTL8192C_COMMON
tristate
depends on RTL8192CE || RTL8192CU
default m
+
+endif
--
1.8.1.4
^ permalink raw reply related
* Re: Fwd: User-level question: on wil6210
From: Vladimir Kondratiev @ 2013-07-07 7:51 UTC (permalink / raw)
To: Chang Liu
Cc: John W. Linville, Sujith Manoharan, erez.kirshenbaum,
linux-wireless
In-Reply-To: <CAGvsL42j1S-EFjQRn4hM3zf5s=MKJf9MVTNqOpyqJEp1DAMQ-Q@mail.gmail.com>
> On Friday, July 05, 2013 12:38:39 PM Chang Liu wrote:
>
> Dear Vladimir, and also John, Sujith and Vladimir,
>
> Thanks, thanks you all for such a kind help! I was wondering you are too
> busy to deal with this, but you do help a lot! I wish you could help me
> through this when you get a little free time. Currently I am a student and
> I am doing a project related with 60GHz communication. Now I have got the
> DELL 5000 Wireless Dock (WIFIg) and a Dell 6430u laptop, and I am trying
> to build up the 60GHz WIFI link (not the WIFI on 2.4G or 5G, and to make it
> clear, i will just call it 60G link) between the Dock and the laptop.
>
>
> This week I got all the devices and I find that, with the driver Dell
> offers, the link is successfully built in win7 platform. Dell offers a
> software to automatically detects the Dock and build the link. A snapshot
> of the link status is as follows:
>
>
> Status: SSID: D5000_C5907B; Channel: 2(60.48GHz); Security Mode: open;
> Firmware Version: 0.0.1.2989; BSSID: 04:ce:14:04:98:26
This is for WBE (not WiFi) link. It uses same infrastructure, but you can't
get WiFi connection.
>
> According to this, the hardware is working well. I tried this after I sent
> you the mail last time, so I didn't have chance to mention it.
>
>
> When I turn to Linux environment, I got problems building up the same link.
> My idea is to install the driver wil6210 as stated in
> (http://wireless.kernel.org/en/users/Drivers/wil6210) and follow the
> instructions on the page to set up the link between the laptop and the
> Dock.
>
>
> 0. Here comes the first question.
> In the webpage it also says
>
> "Chip consists of the root bridge 1ae9:0101, with 4 ports 1ae9:0201. One
> port routed to separate Atheros card 168c:0034, it is handled by the ath9k
> driver. Another port connected to the wil6210 device 1ae9:0301, that is on
> the same chip. 2 empty ports may be populated when connecting in WBE
> (PCIE-over-60g) mode. ">
> Does this mean that the wil6210 1ae9:0301 is actually for 60Gwifi while the
> atheros card 168c:0034 is for 2.4G/5G wifi?
Yes, exactly
> Since I can build the link in
> Windows platform, I believe I have the device wil6210 1ae9:0301 inside the
> laptop.
No. Device 1ae9:0301 may be hidden by firmware. Run "lspci -d 1ae9:0301"
to see whether device is present.
> Also you mentioned last time:
>
> On this card, there is firmware that is stored in the on-card flash memory,
> and is not loaded by the driver. Unfortunately, firmware on your laptop
> (and all laptops like this) flashed with device 1ae9:0301 disabled. This
> firmware support only so called WBE, that is essentially PCIE over 60g, for
> wireless docking. Wireless docking stations that are used with WBE are NOT
> access points; as far as I know there is no 60g access points available at
> this moment. You can run AP on another Linux laptop with wil6210.
>
> In order to support wifi, appropriate firmware need to be flashed on this
> card, and then you will see wi-fi device 1ae9:0301. To flash firmware, you
> need to contact Wilocity (adding Erez).
>
>
>
> You emphasized that the Dock is NOT an access point. You mean it's not an AP
> for 2.4GWIFI or 5GWIFI connection, right?
No, I mean it is not AP for 60g connection. Again, WBE is _NOT_ WiFi, and WBE
dock is not 60g AP.
> If I just want to build the 60G
> link, or WBE(do you mean wireless bus extension?), I don't need to ask for
> a new firmware, is it what you mean? With the current device (I mean the
> Dock and the laptop), I can build the 60G link between the laptop and the
> Dock as long as I get the driver (wil6210) installed in the laptop while do
> nothing to the Dock itself, is it right?
With your current firmware, you can establish WBE link; on Windows only since
WBE is not supported on Linux yet. You can not establish WiFi link with your
firmware with neither Linux nor Windows.
>
> 1. Have I installed the driver correctly?
I'd suggest to use latest kernel. At this moment, 3.10. I am not working on
back-porting, it is not tested. You are on your own if you want to use backport.
<skip>
> Does this mean that I have installed the driver wil6210 correctly?
Looks like it is compiled without errors. Without device present, I can't say
whether it works properly.
> (I didn't
> reload the module iwl4965, for I don't want WIFI, just 60G link).
>
>
> 2. About the network interface name and physical name <devname><phyname>.
> I assumed I installed the driver correctly. so I tried to build the link. My
> plan was to follow the webpage I mentioned above. First as I said in last
> letter, the identity (1ae9:0301) representing wil6210 is not shown with the
> command lspci -nn:
>
>
> root@george:/home/george# lspci -nn
<skip>
> [8086:1e22] (rev 04) 02:00.0 PCI bridge [0604]: Device [1ae9:0101] (rev 03)
> 03:00.0 PCI bridge [0604]: Device [1ae9:0200] (rev 03)
> 03:02.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> 03:03.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> 04:00.0 Network controller [0280]: Atheros Communications Inc. AR9462
> Wireless Network Adapter [168c:0034] (rev 01) 07:00.0 SD Host controller
> [0805]: O2 Micro, Inc. Device [1217:8221] (rev 05)
you have no 1ae9:301 device
>
>
> You mentioned the reason is because the firmware. We are contacting Wilocity
> now to get the firmware.
>
>
> What confuses me most now is the "network interface name". As shown on the
> page (http://wireless.kernel.org/en/users/Drivers/wil6210), I need to find
> the network interface name to execute the commands, which it represents
> with $WLAN. I cannot find where the interface comes from. I think it should
> be something like wlan*, when I tried ifconfig, it shows:
It comes from driver when it initializes its device. Without device, you will
not see network interface. Name will be like wlan0.
<skip>
> so there is no wlan*. Also these commands with iw shows nothing:
>
>
> root@george:/home/george# iw --version
> iw version 3.4
> root@george:/home/george# iw list
> root@george:/home/george# iw phy
> root@george:/home/george# iw dev
>
>
> So my biggest problem, what is the <phyname> , and what is the <devname>?
> Could you give me an example of the format? Where could I find it, or
> should set it myself? I searched google and they say wlan0 for 2.4G/5Gwifi
> will show up as long as the device and the driver are installed correctly.
> Is it the same situation for this case? If so, is the reason that I cannot
> see the interface the firmware you mentioned?
Yes, you have WBE-only firmware, so you have no device. No device - driver
don't bind to it - no network interface registered.
> Another little request is about the configuration instruction. Could you
> gave me some links on how to configure the driver wil6210? The only source
> I have now is the webpage I mentioned above and the help file for iw,
> wpa_supplicant. I lack experience, and I'm glad to learn more.
Read wiki for wpa_supplicant and iw
>
>
> Also, you mentioned I should download the latest iw and wpa_supplicant from
> Git, but I found a lot of folders I have no idea which could be a preferred
> choice. Could I beg you to give me a little more clue?
wpa_supplicant:
git clone git://w1.fi/srv/git/hostap.git
iw:
git clone http://git.sipsolutions.net/iw.git
> About the kernel, I
> would prefer to compile it and add it to the kernel because I may need to
> look inside the code later, so i keep the kernel version as 3.5 now.
Exactly for this reason, you better get kernel 3.10; then you have driver merged
into the kernel.
Thanks, Vladimir
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Ben Hutchings @ 2013-07-07 9:42 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev, Fengguang Wu
In-Reply-To: <1373165244-9536-1-git-send-email-Larry.Finger@lwfinger.net>
On Sat, 2013-07-06 at 21:47 -0500, Larry Finger wrote:
> Fengguang Wu reported the following errors in the build of rtlwifi with
> a random configuration:
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
> head: bcd7351e83728859833e3c5b8aae9a2816914e4b
> commit: 06e7cda3ce30dadc3454539127b4cfc3888c349e rtlwifi: Rework Kconfig
> date: 5 months ago
> config: i386-randconfig-s05-0703
>
> drivers/built-in.o: In function `rtl_usb_cleanup':
> usb.c:(.text+0x114895): undefined reference to `usb_kill_anchored_urbs'
> usb.c:(.text+0x114964): undefined reference to `usb_kill_anchored_urbs'
> usb.c:(.text+0x11497c): undefined reference to `usb_kill_anchored_urbs'
> drivers/built-in.o: In function `_usb_writeN_sync':
> usb.c:(.text+0x114c9e): undefined reference to `usb_control_msg'
> drivers/built-in.o: In function `rtl_usb_disconnect':
> (.text+0x114d9c): undefined reference to `usb_put_dev'
> drivers/built-in.o: In function `rtl_usb_start':
> usb.c:(.text+0x114fb0): undefined reference to `usb_alloc_urb'
> usb.c:(.text+0x115049): undefined reference to `usb_free_urb'
> --snip--
>
> Although I could not duplicate this result on my machine, it seemed likely
> that it was due to the unusual configuration where rtlwifi was being built,
> but none of its dependent drivers were selected.
I think it just requires:
CONFIG_USB=m
CONFIG_RTLWIFI=y
> The fix is to select rtlwifi only when it is needed.
I don't think so. Consider this configuration:
CONFIG_PCI=y
CONFIG_USB=m
CONFIG_RTL_CARDS=y
CONFIG_RTL8192CE=y
CONFIG_RTL8192CU=m
CONFIG_RTLWIFI=y # maximum of RTL8192CE=y and RTL8192CU=m
The same breakage occurs.
> While making this
> change, I simplified the configuration so that variable RTLWIFI is never seen
> by the user.
[...]
This will break existing configurations as RTL_CARDS defaults to n.
Perhaps you should introduce separate modules for the common PCI and USB
support code, similarly to how the rt2x00 modules are organised.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 01/20] rt2x00: rt2800lib: add MAC register initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:07 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-2-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:40AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> NICInitRT3593MacRegisters in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 02/20] rt2x00: rt2800lib: add BBP register initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:07 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-3-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:41AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> NICInitRT3593BbpRegisters in chips/rt3593.c
> NICInitBBP in common/rtmp_init.c
> NICInitAsicFromEEPROM in common/rtmp_init.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 03/20] rt2x00: rt2800lib: add RFCSR register initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:10 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-4-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:42AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> NICInitRT3593RFRegisters in chips/rt3593.c
> RT3593LoadRFNormalModeSetup in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
> case RT3390:
> rt2800_init_rfcsr_3390(rt2x00dev);
> break;
> + case RT3593:
> + rt2800_init_rfcsr_3593(rt2x00dev);
> + break;
> case RT3572:
> rt2800_init_rfcsr_3572(rt2x00dev);
> break;
Nit: RT3572 should be before RT3593.
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 04/20] rt2x00: rt2800lib: add BBP post initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:10 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-5-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:43AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> RT3593_PostBBPInitialization in chips/rt3553.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 05/20] rt2x00: rt2800lib: add TX power configuration for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:14 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-6-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:44AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> RTMPReadTxPwrPerRateExt in chips/rt3593.c
> RT3593_AsicGetTxPowerOffset in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 10/20] rt2x00: rt2800lib: introduce rt2800_get_txmixer_gain_{24, 5}g helpers
From: Stanislaw Gruszka @ 2013-07-07 14:15 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-11-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:49AM +0200, Gabor Juhos wrote:
> Move the TX mixer gain reading code into separate
> helper functions in preparation for RT3593 support.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 11/20] rt2x00: rt2800lib: hardcode TX mixer gain values for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:15 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-12-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:50AM +0200, Gabor Juhos wrote:
> The reference code uses hardcoded zero TX mixer gain value
> for RT3593. Do the same in the rt2x00 driver.
>
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> NICReadEEPROMParameters in common/rtmp_init.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 06/20] rt2x00: rt2800lib: fix BBP1_TX_ANTENNA field configuration for 3T devices
From: Stanislaw Gruszka @ 2013-07-07 14:16 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-7-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:45AM +0200, Gabor Juhos wrote:
> The field must be set to 2 instead of 0 for
> devices with three TX chains.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 07/20] rt2x00: rt2800lib: fix antenna configuration for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:16 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-8-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:46AM +0200, Gabor Juhos wrote:
> On the RT3593 chipset, BBP register 86 must be
> configured by different values based on the RX
> antenna numbers.
>
> Configure this register from the 'rt2800_config_ant'
> function.
>
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> RT3593_CONFIG_SET_BY_ANTENNA in include/chip/rt3593.h
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 08/20] rt2x00: rt2800lib: add rt2800_txpower_to_dev helper
From: Stanislaw Gruszka @ 2013-07-07 14:18 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-9-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:47AM +0200, Gabor Juhos wrote:
> Introduce a new helper function for converting
> the default TX power values from EEPROM into
> mac80211 values.
>
> The change improves the readability and it makes
> it easier to add support for other chipsets.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 09/20] rt2x00: rt2800lib: fix default TX power values for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:20 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-10-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:48AM +0200, Gabor Juhos wrote:
> The TX power values in the EEPROM are using
> a different format for the RT3593 chip. The
> default TX power value uses bits 0..4 only.
> Bits 5..8 contains value for fine grained
> power control. Additionally, the lower and
> upper limits of the TX power values are the
> same for both bands.
>
> Improve the rt2800_txpower_to_dev function,
> in order to compute the correct default power
> values for the RT3593 chip as well.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 12/20] rt2x00: rt2x00lib: fix LNA_A[12] gain values for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:23 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-13-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:51AM +0200, Gabor Juhos wrote:
> The LNA_A[12] gain values are stored at a different
> offset in the EEPROM on RT3593 based devices. However
> the current code unconditionally reads those values
> from the location used by other chipsets.
>
> Fix the code to use the correct EEPROM offset.
>
> Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> RT3593_EEPROM_RSSI2_OFFSET_ALNAGAIN1_24G_READ in include/chip/rt3593.h
> RT3593_EEPROM_RSSI2_OFFSET_ALNAGAIN2_5G_READ in include/chip/rt3593.h
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 13/20] rt2x00: rt2800lib: add default_power3 field for three-chain devices
From: Stanislaw Gruszka @ 2013-07-07 14:23 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-14-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:52AM +0200, Gabor Juhos wrote:
> The actual code uses two default TX power values.
> This is enough for 1T and for 2T devices however
> on 3T devices another value is needed for the third
> chain.
>
> Add a new field to struct channel_info and initialize
> it from the 'rt2800_probe_hw_mode' function. Also modify
> the 'rt2800_config_channel' to handle the new field as
> well.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 14/20] rt2x00: rt2800lib: add rf_vals for RF3053
From: Stanislaw Gruszka @ 2013-07-07 14:26 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-15-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:53AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> FreqItems3053 in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 15/20] rt2x00: rt2800lib: add channel configuration for RF3053
From: Stanislaw Gruszka @ 2013-07-07 14:39 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-16-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:54AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> RT3593_ChipSwitchChannel in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ 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