- 14 3月, 2013 1 次提交
-
-
由 John Crispin 提交于
Since v3.9-rc1 the kernel has basic support for Ralink WiSoC. The config symbols are named slightly different than before. Fix the rt2x00 to match the new symbols. The commit causing this breakage is: commit ae2b5bb6 Author: John Crispin <blogic@openwrt.org> Date: Sun Jan 20 22:05:30 2013 +0100 MIPS: ralink: adds Kbuild files Signed-off-by: NJohn Crispin <blogic@openwrt.org> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 1月, 2013 1 次提交
-
-
由 Kees Cook 提交于
The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: Ivo van Doorn <IvDoorn@gmail.com> CC: Gertjan van Wingerde <gwingerde@gmail.com> CC: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: NJohn W. Linville <linville@tuxdriver.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NKees Cook <keescook@chromium.org> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 6月, 2012 1 次提交
-
-
由 Woody Hung 提交于
This patch support the new chipset rt3290 wifi implementation in rt2x00. It initailize the related mac, bbp and rf register in startup phase. And this patch modify the efuse read/write method for the different efuse data offset of rt3290. Signed-off-by: NWoody Hung <Woody.Hung@mediatek.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 2月, 2012 1 次提交
-
-
由 John Li 提交于
Signed-off-by: NJohn Li <chen-yang.li@mediatek.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 6月, 2011 1 次提交
-
-
由 Gertjan van Wingerde 提交于
Now that support for these devices has been added we can enable them by default and remove the Kconfig not on support for these devices to be non-functional. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 5月, 2011 1 次提交
-
-
由 Tao Ma 提交于
We make oldconfig every time when a new kernel arrives, but if we don't have such a device(I guess this is the most common case for a new device), the default value should be 'n' so that the kernel size we build doesn't grow up too much quickly. For anyone who has the device, it is OK for them to turn it on by themselves. Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: NTao Ma <boyu.mt@taobao.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 06 5月, 2011 1 次提交
-
-
由 Gertjan van Wingerde 提交于
Add necessary RF chipset define and basic support for these devices. Tested-by: NJuan Carlos Garza <juancarlosgarza@gmail.com> Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 4月, 2011 3 次提交
-
-
由 Gertjan van Wingerde 提交于
The two functions that are in rt2x00ht.c can be much better placed closer to the places where the call-sites of these functions are (one in rt2x00config.c and one in rt2x00queue.c) allowing us to make these functions static. Also, conditional compilations doesn't seem to be necessary anymore as 802.11n support is quite common nowadays. This makes the code a bit easier readable and searchable. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
Code seems to be feature-complete, so no reason to not enable these devices by default. Also, remove the sentence about the support for these devices being non-functional. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
The rt33xx devices support for both PCI and USB devices has been in the tree for a couple of months now, and seems to be functional and not in a worse shape than the support for rt28xx and rt30xx devices. No longer mark it as experimental and enable the support for these devices by default. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 2月, 2011 1 次提交
-
-
由 RA-Shiang Tu 提交于
Add new RT5390 chip support Signed-off-by: NShiang Tu <shiang_tu@ralinktech.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 18 11月, 2010 4 次提交
-
-
由 Gertjan van Wingerde 提交于
CONFIG_RT2800PCI_PCI and CONFIG_RT2800PCI_SOC are strictly not needed as we can check the dependent symbols directly in the rest of Kconfig and the code, so clean up the Kconfig namespace a bit. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
Enabling of RT30xx devices via Kconfig variables was introduced when these devices weren't properly supported yet. Now that that they are properly supported and functional, we can remove these Kconfig variables for RT30xx devices and simply enable them whenever rt2800pci and/or rt2800usb is enabled. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
General clean up of the Kconfig part for RT28XX devices. Also remove the indications of non functional support for rt27xx/rt28xx/rt30xx devices, as this is no longer true. They just work fine. Finally, remove the experimental indications for rt27xx/rt28xx/rt30xx devices as that is no longer true. Keep the experimental indications for rt33xx/rt35xx devices, though. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
Modified from Eddy's patch by adding the RT3370 USB support as well. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Cc: Eddy Tsai <Eddy_Tsai@ralinktech.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 11月, 2010 1 次提交
-
-
由 Johannes Berg 提交于
Currently, blinking LEDs can be awkward because it is not guaranteed that all LEDs implement blinking. The trigger that wants it to blink then needs to implement its own timer solution. Rather than require that, add led_blink_set() API that triggers can use. This function will attempt to use hw blinking, but if that fails implements a timer for it. To stop blinking again, brightness_set() also needs to be wrapped into API that will stop the software blink. As a result of this, the timer trigger becomes a very trivial one, and hopefully we can finally see triggers using blinking as well because it's always easy to use. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Acked-by: NRichard Purdie <rpurdie@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 05 5月, 2010 1 次提交
-
-
由 Gertjan van Wingerde 提交于
Now that RT30xx support is at the same level as RT28xx support we can enable these devices by default. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 2月, 2010 1 次提交
-
-
由 Gertjan van Wingerde 提交于
Support for rt30xx- and rt35xx-based devices is currently not functional in rt2800pci and rt2800usb. In order to not confuse users we shouldn't claim the PCI and USB device ID's for these devices. However, to allow for testing it is good to still have them available, although disabled by default. Make support for these device configuration options that default to off. For rt2800usb a 3rd class of devices is added, which are the unknown devices. For these devices it is known that they are either based on rt28xx, rt30xx or rt35xx, but it is not known on what chipset exactly. These devices are disabled by default as well, until it can be established on what chipset exactly they are based. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 12月, 2009 1 次提交
-
-
由 Gertjan van Wingerde 提交于
There is no need for Kconfig symbols RT2800PCI_PCI and RT2800PCI_SOC to be tristates, as they are only used to check whether RT2800 PCI or SOC support is to be compiled in. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 07 11月, 2009 1 次提交
-
-
Code unification. Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 11月, 2009 2 次提交
-
-
Document known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly. Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Document known issues with the driver to aid distribution makers, users and developers in making informed decisions instead of wasting their time needlessly. Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by: NGertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 31 10月, 2009 1 次提交
-
-
由 John W. Linville 提交于
With the WLAN_PRE80211 drivers moved to drivers/staging, this distinction becomes unnecessary. Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 10月, 2009 2 次提交
-
-
由 Ivo van Doorn 提交于
Add support for the rt2860/rt3090 chipsets from Ralink. Includes various patches from a lot of people who helped getting this driver into the current shape. Signed-off-by: NAlban Browaeys <prahal@yahoo.com> Signed-off-by: NBenoit PAPILLAULT <benoit.papillault@free.fr> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NLuis Correia <luis.f.correia@gmail.com> Signed-off-by: NMattias Nissler <mattias.nissler@gmx.de> Signed-off-by: NMark Asselstine <asselsm@gmail.com> Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Add new library module for SoC drivers. This is needed to fully support the platform driver part of rt2800pci. Based on original patch from Felix. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 8月, 2009 1 次提交
-
-
由 Luis R. Rodriguez 提交于
These drivers have been around for a while, if there are issues they should be reported. rt2800usb is still a bit flaky though. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 11 7月, 2009 1 次提交
-
-
由 Ivo van Doorn 提交于
Remove the input_polldev from rt2x00 and replace it with the rfkill interface offered by the wiphy structure. This simplifies the entire rfkill handling in rt2x00 and allows us to remove the CONFIG_RT2X00_LIB_RFKILL option and always enables rfkill capabilities. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 6月, 2009 1 次提交
-
-
由 Pavel Machek 提交于
.ko is normally not included in Kconfig help, make it consistent. Signed-off-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 07 5月, 2009 2 次提交
-
-
由 Ivo van Doorn 提交于
Add support for the rt2800usb chipset. Current problems: * Cannot scan 11n AP's * No TX during first minute after association * Broken Hardware encryption Includes various patches from Mattias, Felix, Xose and Axel. Signed-off-by: NMattias Nissler <mattias.nissler@gmx.de> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by: NAxel Kollhofer <rain_maker@root-forum.org> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Extend rt2x00lib capabilities to support 802.11n, it still lacks aggregation support, but that can be added in the future. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 1月, 2009 1 次提交
-
-
由 Ivo van Doorn 提交于
As discussed on linux-wireless rt2x00 does not offer a true RFKILL key, for that reason RFKILL support should be entirely removed. The key which is attached to the hardware should be treated as normal input device instead. Implement input_poll_dev support to poll the device frequently. When the key status has changed report it as a SW event. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 12月, 2008 1 次提交
-
-
由 Ivo van Doorn 提交于
rt2500usb supports hardware encryption. rt2500usb supports up to 4 shared and pairwise keys. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 10月, 2008 1 次提交
-
-
由 Ivo van Doorn 提交于
Make menuconfig RT2X00 a tristate instead of boolean, otherwise we do not correctly inherit the mac80211 value on which RT2X00 depends, and makes it possible to compile rt2x00 into the kernel while mac80211 is a module. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 10月, 2008 1 次提交
-
-
由 Gertjan van Wingerde 提交于
Fix by disabling rt2x00 rfkill support when rt2x00 is built-in and rfkill has been modularized, and a similar scheme for the relationship between leds_class and rt2x00.. Also, give a warning to the end-user when rfkill-/leds-support is disabled this way, so that the end-user has at least some clues on what is going on. Proper fixing required some general updates of the Kconfig-structure for the rt2x00 driver, whereby internal configuration symbols had to be moved to after the user-visible configuration symbols. Signed-off-by: NGertjan van Wingerde <gwingerde@kpnplanet.nl> Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 9月, 2008 2 次提交
-
-
由 Ivo van Doorn 提交于
There isn't really a good reason to have the LED configuration options selectable per driver, lets make it default 'y' and make it depend on the NEW_LEDS and LEDS_CLASS interface. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
RFKILL should be enabled for _all_ hardware whether or not they feature a rfkill button or not. Remove driver specific RFKILL configuration options and make the rt2x00lib version depend on CONFIG_RFKILL and defaulting to 'y' to make sure it will always be enabled when RFKILL was enabled. This also fixes some bugs where RFKILL wasn't initialized and didn't respond to RFKILL key presses. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 8月, 2008 3 次提交
-
-
由 Ivo van Doorn 提交于
rt73usb supports hardware encryption. rt73usb supports up to 4 shared keys and up to 64 pairwise keys. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
rt61pci supports hardware encryption. rt61pci supports up to 4 shared keys and up to 64 pairwise keys. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Various rt2x00 devices support hardware encryption. Most of them require the IV/EIV to be generated by mac80211, but require it to be provided seperately instead of within the frame itself. This means that rt2x00lib should extract the data from the frame and place it in the frame descriptor. During RX the IV/EIV is provided in the descriptor by the hardware which means that it should be inserted into the frame by rt2x00lib. Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 7月, 2008 1 次提交
-
-
由 Ivo van Doorn 提交于
With the new rfkill interface there is no longer a need for the input_polldev. Create a delayed_work structure which we can put on the mac80211 workqueue and poll the hardware every 1000ms. v2: Decrease poll frequency from 100ms to 1000ms Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-