- 19 Jun, 2014 40 commits
-
-
Chaitanya Hazarey authored
Fixed open brace placement to address the following code-style errors: ERROR: that open brace { should be on the previous line Signed-off-by:Chaitanya Hazarey <c@24.io> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Chaitanya Hazarey authored
Converted some C99 warnings to fix the following error: ERROR: trailing statements should be on next line Signed-off-by:
-
Chaitanya Hazarey authored
Rearranged statements around if and switch statements to address the following error: ERROR: trailing statements should be on next line Signed-off-by:
-
Chaitanya Hazarey authored
Added spaces after ',' to fix the following warning: ERROR: space required after that ',' (ctx:VxV) Signed-off-by:
-
Chaitanya Hazarey authored
Removed dead code from the file. Signed-off-by:
-
Paul Bolle authored
Ever since rtl8192u was added as a staging driver in v2.6.33 it contained checks for CONFIG_IEEE80211_CRYPT_TKIP. But the Kconfig symbol IEEE80211_CRYPT_TKIP was renamed to LIB80211_CRYPT_TKIP in v2.6.29. So these checks have always evaluated to false. And these checks were rather odd to begin with, since rtl8192u comes with its own ieee80211 stack, which has support for TKIP built in. Now the safe and easy thing to do here would be to remove these checks and the code they hide. But it turns out that with some minor cleanup the code currently hidden behind these checks builds cleanly. And by building it we allow the people actually running this code to test whether it is any good. That minor cleanup is needed because ieee80211_encrypt_fragment() accesses struct sk_buff's data member as if it is a struct ieee80211_hdr. It's not. See, in ieee80211_xmit() a struct ieee80211_hdr_3addrqos is skb_put() into the sk_buff with which ieee80211_encrypt_fragment() will be called. So switch from ieee80211_hdr to ieee80211_hdr_3addrqos here. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
Chaitanya Hazarey authored
Added a space around '|' to address: ERROR: need consistent spacing around '|' (ctx:VxW) Signed-off-by:
-
Chaitanya Hazarey authored
To address the error - ERROR: do not use C99 // comments Removed all C99 comments. Signed-off-by:
-
Chaitanya Hazarey authored
Removed dead code, commented out printks and DMESG. Signed-off-by:
-
Magnus Damm authored
Add staging board support for the KZM9D board and add an emxx_udc platform device to allow in-tree continous development of the driver on the KZM9D board. When DT bindings are ready for the emxx_udc driver then the platform device in the KZM9D staging board code can easily be removed. Until then we use platform devices to continously improve the driver and integration code. Signed-off-by:
Magnus Damm <damm+renesas@opensource.se> Acked-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Magnus Damm authored
Add staging board base support to allow continuous upstream in-tree development and integration of platform devices. Helps developers integrate devices as platform devices for device drivers that only provide platform device bindings. This in turn allows for incremental development of both hardware feature support and DT binding work in parallel. Two separate pieces of board staging functionality is provided to ease per-board staging board support: - The board_staging() macro allows easy per-board callbacks - The board_staging_dt_node_available() provides DT node checking Tested on the KZM9D board with the emxx_udc staging driver. Signed-off-by:
-
Magnus Damm authored
Add a TODO file for emxx_udc to show what is left to do. Signed-off-by:
-
Magnus Damm authored
Adjust the emxx_udc driver to make use of the standard driver model to pass I/O memory and IRQ as resources instead of hard coding those things in the driver. Needs more work - the VBUS signal is yet not handled. Signed-off-by:
-
Magnus Damm authored
Add the emxx_udc driver to staging based on an old linux-2.6.35.7 android tree. The driver has been brushed up slightly to complile but it is still in great need of cleanup. At this point DT bindings are clearly lacking and I doubt that the driver even can run with multiple instances (global variables, hurray!). Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit cc0be81f, it was incorrect. Reported-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
H Hartley Sweeten authored
The drivers that include ni_mio_common.c set the stc register read/write callbacks to private functions that handle the read/write operations in the correct manner for the hardware. The ni_atmio and ni_mio_cs drivers use identical code to handle the operations. The ni_pcimio driver is a bit different due to the non-windowed setup of the stc registers on the m series boards. For the other boards supported by the ni_pcimio driver, the direct access of the first 8 STC registers is also disabled due to a difference on the 611x devices. These differences can all be handled in the ni_stc_{read,write}[lw]() helpers. Refactor the helpers and remove the callbacks from the private data. Also, move the helper functions the handle the mapping of the windowed STC register offsets to M series register offset from ni_pcimio.c to ni_mio_common.c. Signed-off-by:H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
H Hartley Sweeten authored
The drivers that include ni_mio_common.c set the read/write callbacks to private functions that handle the read/write operations in the correct manner for the hardware. The ni_atmio and ni_mio_cs drivers use ioport register access and the ni_pcimio driver uses memory mapped register access. The memory mapped base address is stored in the 'mite' pointer in the private data which is only allocated and initialized by the ni_pcimio driver. Detect the need for memory mapped register access by checking if the 'mite' pointer is set in the private data and remove the callbacks from the private data. Signed-off-by:
-
H Hartley Sweeten authored
The ni_atmio, ni_pcimio, and ni_mio_cs drivers all include this source file to handle the common functionality of the drivers. Each of those drivers set some function pointers in the private data to handle the read/write operations to the normal registers. Like done for the stc register operations, wrap these operations with some helper functions to clarify the code a bit and make it easier to read and maintain. Signed-off-by:
-
H Hartley Sweeten authored
The ni_atmio, ni_pcimio, and ni_mio_cs drivers all include this source file to handle the common functionality of the drivers. Each of those drivers set some function pointers in the private data to handle the read/write operations to the stc registers. Wrap these operations with some helper functions to clarify the code a bit and make it easier to read and maintain. Signed-off-by:
-
H Hartley Sweeten authored
This function is used to enable/disable the second irq on NI e-series boards. This irq used used to generate dma requests for the counters. There are only 2 counters (NUM_GPCT) so the default case of the switch can never occur. Tidy up this function and remove the unreachable BUG(). Signed-off-by:
-
H Hartley Sweeten authored
The (board->reg_type & ni_reg_m_series_mask) test is commonly used in ni_mio_common.c to detect if the driver is being used with a National Instruments "M series" DAQ board. Simplify the code a bit by adding an 'is_m_series' bit-field flag to the private data. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
This eliminates yet another user of rtw_get_capability23a_from_ie() Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Another case where the driver was copying IEs in front of the probe_resp data in the management frame, when running in AP mode. This would result in badly corrupted frames hitting the wire - ouf ouf ouf! Signed-off-by:
-
Jes Sorensen authored
Why on Earth we have two functions in the driver constructing beacon frames is beyond me ... but one step at a time Signed-off-by:
-
Jes Sorensen authored
Not sure how this happened, but one should never copy the IEs in front of the beacon frame info. This could lead to some nasty corrupted beacon frames hitting the wire if running AP mode - ouf! Signed-off-by:
-
Jes Sorensen authored
This gets rid of a bunch of hard coded offsets and reduces the dependency of the ugly rtw_get_*_from_ie() functions. Signed-off-by:
-
Jes Sorensen authored
We already have the capability info in struct wlan_bssid_ex, no point in searching for it once again. Signed-off-by:
-
Jes Sorensen authored
Pull out the core info beacon_interval, capability, and tsf and update cur_network.network with the info in rtw_add_beacon() instead of relying on it being in ->IEs. This will help later when getting rid of the beacon struct info from ->IEs and only carrying the actual IEs there. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
This is to be more consistent mapping the names in wlan_bssid_ex to those in struct ieee80211_mgmt. Signed-off-by:
-
Jes Sorensen authored
No point in pulling capability info out of the IE array when it's already stored in struct wlan_bssid_ex Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Use the beacon interval we already retreived in collect_bss_info() instead of pulling it out of the saved IE array again. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
There is no point in creating a fake beacon frame to call cfg80211_inform_bss_frame() when we can just call cfg80211_inform_bss() with the parameters we were sticking into the fake frame. Signed-off-by:
-
