summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-09-30mwifiex: remove unnecessary rx_q lockAvinash Patil4-10/+0
SKB lists have their own lock. So this lock is not needed. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: do not decrement rx_pending count twiceAvinash Patil1-6/+2
This patch fixes an issue with rx processing function where we were decrementing rx_pending count twice. Patch also queues correct main_work item when rx_pending count reaches low watermark. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: fix soft lockup during iperf UDP RXAvinash Patil1-1/+2
A soft lockup was observed on ARM multicore platform while UDP RX iperf was running on station. Reason for this is delay_main_task was not taken into consideration while jumping to process_start. Now if delay_main_task is true, we would exit mwifiex_main_process instead of going to process_start again. This ensure other process is scheduled on this CPU and soft lockup is avoided. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kevin Gan <ganhy@marvell.com> Signed-off-by: Marc Yang <yangyang@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30MAINTAINERS: change rt2x00 maintainerStanislaw Gruszka1-2/+1
After short chat with Ivo, we decided that I'll take maintenance of rt2x00 driver. Thanks for Ivo's great work in the past! Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k_hw: disable hardware ad-hoc flag on ar934x rev 3Felix Fietkau2-3/+10
On AR934x rev 3, settin the ad-hoc flag completely messes up hardware state - beacons get stuck, almost no packets make it out, hardware is constantly reset. When leaving out that flag and setting up the hw like in AP mode, TSF timers won't be automatically synced, but at least the rest works. AR934x rev 2 and older are not affected by this bug Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath9k: use ah->get_mac_revision for all SoC devices if availableFelix Fietkau1-7/+4
It is needed for AR934x as well Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30ath5k: add missing include for debug codeFelix Fietkau1-0/+1
Needed for calling vmalloc()/vfree() Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8188ee: rtl8723ae: rtl8821ae: Initialize some variablesLarry Finger7-18/+18
In a number of places, kmalloc or valloc were used to acquire memory. To ensure that these locations are correctly initialized, the calls were changed to kzalloc and vzalloc. The change fixes a problem that was causing HT operations to be cancelled. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8188ee: rtl8192com: rtl8192cu: rtl8192ee: rtl8723ae: rtl87323be: ↵Larry Finger10-139/+45
rtl8821ae: Use common cmd_send_packet A locking problem was found in routine _rtl92ee_cmd_send_packet() that led to system freezes. Upon inspection, several drivers had the same problem; however, the routines all used the same code. The common code has been moved into rtlwifi. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8192ce: rtl8192common: Update for latest version of Realtek driversLarry Finger18-973/+534
Realtek released new drivers on 06/28/2014. These changes implement all their changes into the kernel version of the driver. In addition, these modifications are part of the process of unifying the Realtek and kernel code bases. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14Larry Finger30-3167/+3833
This patch updates the driver to match the latest Realtek release, and it is an important step in getting the internal code source at Realtek to match the code in the kernel. The primary reason for this is to make it easier for Realtek to maintain the kernel source without requiring an intermediate like me. In this process of merging the two source repositories, there are a lot of changes in both, and this commit is rather large. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8723ae: Update driver to match 06/28/14 Realtek versionLarry Finger38-4836/+5403
Not only does this patch update the driver to match the latest Realtek release, it is an important step in getting the internal code source at Realtek to match the code in the kernel. The primary reason for this is to make it easier for Realtek to maintain the kernel source without requiring an intermediate like me. In this process of merging the two source repositories, there are a lot of changes in both, and this commit is rather large. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8192ee: Move driver from staging to the regular treeLarry Finger25-1/+15380
This driver was entered into staging a few cycles ago because there was not time to integrate the Realtek version into the support routines in the kernel. Now that there is an effort to converg the code base from Linux and the Realtek repo, it is time to move this driver. In addition, all the updates included in the 06/28/2014 version of the Realtek drivers are included here. With this change, it will be necessary to delete the staging driver. That will be handled in a separate patch. As it impacts the staging tree, such a patch is sent to a different destination. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30rtlwifi: rtl8188ee: rtl8821ae: Fix a queue locking problemLarry Finger3-2/+5
The code fails to lock the skb queue, which leads to a number of problems. This patch also fixes a Sparse warning about using a memset of 1 byte. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: troy_tan@realsil.com.cn Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30bcma: use chipcommon node from DT for SoC GPIO chipRafał Miłecki2-0/+16
This will allow us to define GPIO-attached devices (LEDs, buttons) in the the device tree. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30bcma: register bcma as device tree driverHauke Mehrtens5-1/+168
This driver is used by the bcm53xx ARM SoC code. Now it is possible to give the address of the chipcommon core in device tree and bcma will search for all the other cores. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: add more dump information for PCIe interfaceAmitkumar Karwar2-0/+11
We will now dump MAC, APU, CIU, ICU firmware memory segments also for PCIe interface. Following is the updated userspace script which reads firmware dump information. mwifiex_pcie_fw_dump.sh: #!/bin/bash ethtool --set-dump mlan0 0 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/ITCM.log ethtool --set-dump mlan0 1 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/DTCM.log ethtool --set-dump mlan0 2 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/SQRAM.log ethtool --set-dump mlan0 3 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/IRAM.log ethtool --set-dump mlan0 4 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/APU.log ethtool --set-dump mlan0 5 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/CIU.log ethtool --set-dump mlan0 6 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/ICU.log ethtool --set-dump mlan0 7 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/MAC.log Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-30mwifiex: error path handling in pcie firmware dumpAmitkumar Karwar1-4/+7
This patch takes care of missing error paths in firmware dump. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Fix problems with building an allyesconfigLarry Finger20-833/+223
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: rtl8821ae: Move driver from staging to regular treeLarry Finger28-6/+26865
This driver was entered into staging a few cycles ago because there was not time to integrate the Realtek version into the support routines in the kernel. Now that there is an effort to converg the code base from Linux and the Realtek repo, it is time to move this driver. In addition, all the updates included in the 06/28/2014 version of the Realtek drivers are included here. With this change, it will be necessary to delete the staging driver. That will be handled in a separate patch. As it impacts the staging tree, such a patch is sent to a different destination. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: rtl8188ee: Update driver to match Realtek release of 06282014Larry Finger25-4248/+4863
Not only does this patch update the driver to match the latest Realtek release, it is an important step in getting the internal code source at Realtek to match the code in the kernel. The primary reason for this is to make it easier for Realtek to maintain the kernel source without requiring an intermediate like me. In this process of merging the two source repositories, there are a lot of changes in both, and this commit is rather large. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Finish modifying core routines for new driversLarry Finger9-133/+174
Addition of the new drivers and the update to a new version for the others lead to changes in all the core routines. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Update power-save routines for 062814 driverLarry Finger13-253/+162
Realtek released a new version of the drivers on 06/28/2014. This patch implements the new power-save code. These changes also force corresponding changes in the drivers. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Modify cam.{c,h} and efuse.{c,h} for new driversLarry Finger4-156/+156
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Modify base.{c,h} for new driversLarry Finger3-252/+463
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Modify core.c for new driversLarry Finger4-234/+602
Each of the routines in the rtlwifi common driver needs to be modified for the coming changes. This patch prepares core.c, but also touches other files. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: rtl_pci: Start modification for new driversLarry Finger5-334/+605
Future patches will move the drivers for RTL8192EE and RTL8821AE from staging to the regular wireless tree. Here, the necessary features are added to the PCI driver. Other files are touched due to changes in the various data structs. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: Remove extra workqueue for enter/leave power stateLarry Finger1-5/+2
When the rtlwifi family of drivers was converted to use a workqueue when entering or leaving power save mode (commits a269913c52, a5ffbe0a19, 41affd5286, b9116b9a2b, and 6539306b2c), the code began scheduling work from the callback routine of a different workqueue with a resulting increase in overhead. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtlwifi: btcoexist: Fix Smatch warningLarry Finger3-3/+3
The capability for 802.11ac will soon be added to these drivers. Once that is done, a bitmask will be too large for the data storage. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Fix offchannel queuingSujith Manoharan1-3/+3
Clearing IEEE80211_TX_CTL_PS_RESPONSE in a frame that is not in the current context doesn't seem right. Instead make sure that we don't add such frames to the UAPSD queue by using a local variable. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Use normal queues for offchannel framesSujith Manoharan1-2/+1
There is no reason why frames marked with IEEE80211_TX_CTL_TX_OFFCHAN have to be sent using the UAPSD queue. Since mac80211 makes sure that RoC is done before pushing an offchannel frame to the driver, we can use the normal TX queues for transmission. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Fix queue managementSujith Manoharan1-7/+3
Since we use IEEE80211_HW_QUEUE_CONTROL now, the CAB/Offchannel queues are registered as the last two queues. There is no need to check and reassign the queues in the TX start()/done() routines. CAB frames will not reach the tx() callback since we set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING and pull the buffered frames during beacon transmission. We also don't have a special HW queue for handling off-channel frames. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rt2800: correct BBP1_TX_POWER_CTRL maskStanislaw Gruszka1-1/+1
Two bits control TX power on BBP_R1 register. Correct the mask, otherwise we clear additional bit on BBP_R1 register, what can have unknown, possible negative effect. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27wil6210: ethtool opsVladimir Kondratiev6-12/+138
Provide ethtool support; with support for interrupt coalescing through get_coalesce/set_coalesce. Placeholders for begin/complete will be used by runtime PM to make sure target is powered up while performing ethtool operations Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27bcma: gpio: use ChipCommon GPIO IRQ on BCM47XX arch onlyRafał Miłecki1-2/+2
GPIOs can be also used on bcm53xx, however this arch requires different implementation of IRQ support. It uses different IRQ number (117) and different masks & acking. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27rtl818x_pci: add RSSI information for rtl8187SEandrea.merello1-5/+23
This patch makes the driver to report signal strength information to mac80211 for rtl8187se boards. It differs from my previous RFT patch: http://marc.info/?l=linux-wireless&m=140155388332534&w=2 because: - I have now a working rtl8187se card, so I could serve my RFT by myself. :) - CCK measurement code has changed a bit, but it does basically the same things. - OFDM measurement method is changed because the older method reported incorrect measures, at least for signals stronger than -40dBm). CCK measurement seems quite good. OFDM seems less accurate, but this is the same as the "reference" staging driver dose. I wanted not to change things just to make measures of _one_ (my) card a bit more close to what _I_ (in my setup) expected.. IMHO results are still good enough to justify reporting signal in dBm rather than in "unspecified" units, so this is what this patch actually does. Results of my tests with a working rtl8187se card connected with coaxes and various RF attenuators to my AP are: Input (approx) | CCK meas | OFDM meas -------------------------------------- -30dBm | -32dBm | -31dBm -40dBm | -40dBm | -41dBm -50dBm | -50dBm | -55dBm -60dBm | -59dBm | -63dBm -70dBm | -69dBm | -73dBm -80dBm | -79dBm | -83dBm Also some real-field tests has been done (no coax, packets in the air) for the CCK measure method, and they resulted in reasonable values. Thanks-to: Bernhard Schiffner <bernhard@schiffner-limbach.de> [ for real-field tests] Signed-off-by: andrea.merello <andrea.merello@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Fix p2p address managementSujith Manoharan2-0/+37
When multiple channel contexts are enabled, a p2p interface that is assigned to a context will have an address that is different from the device mac address, which is used by wpa_s as the p2p device ID. Certain frames like provision requests use the device address and these get dropped since ath9k_calculate_summary_state() iterates over only the active interfaces in a context and the device address is not used. Fix this by adding the device mac address to the bssid mask. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27bcma: print chip ID in a more user-friendly formRafał Miłecki1-2/+6
Some chip IDs are easier to read/understand when printed in a decimal form. For example on my bcm53xx arch router this patch replaces: Found chip with id 0xCF12, rev 0x00 and package 0x02 with a: Found chip with id 53010, rev 0x00 and package 0x02 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27mwifiex: ensure user_scan_in not NULL while setting scan channel gapAvinash Patil1-16/+17
Check for scan channel gap only when user_scan_in is not NULL. user_scan_in is NULL for internal scans and if we check scan channel gap at this place, it may result into crash. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-27ath9k: Cache BSS informationSujith Manoharan3-7/+17
Using the BSS information stored in mac80211 directly is racy in certain conditions. For example, in a MCC setup, if the scheduler is switching channels when a local deauth is issued, calculation of the opmode/bssid etc. is incorrect. To avoid this, store the bss params in the driver and use it. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-26ath5k: Remove AHB bus supportPaul Bolle6-294/+3
AHB bus support was added in v2.6.38, through commit a0b907ee2a71 ("ath5k: Add AHB bus support."). That code can only be build if the Kconfig symbol ATHEROS_AR231X is set. But that symbol has never been added to the tree. So AHB bus support has always been dead code. Let's remove all code that depends on ATHEROS_AR231X. If that symbol ever gets added to the tree the AHB bus support can be re-added too. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-26Merge branch 'for-upstream' of ↵John W. Linville12-231/+518
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
2014-09-26Merge tag 'nfc-next-3.18-1' of ↵John W. Linville18-354/+1188
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next Samuel Ortiz <sameo@linux.intel.com> says: "NFC: 3.18 pull request This is the NFC pull request for 3.18. We've had major updates for TI and ST Microelectronics drivers: For TI's trf7970a driver: - Target mode support for trf7970a - Suspend/resume support for trf7970a - DT properties additions to handle different quirks - A bunch of fixes for smartphone IOP related issues For ST Microelectronics' ST21NFCA and ST21NFCB drivers: - ISO15693 support for st21nfcb - checkpatch and sparse related warning fixes - Code cleanups and a few minor fixes Finally, Marvell add ISO15693 support to the NCI stack, together with a couple of NCI fixes." Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-09-26Merge branch 'for-linville' of git://github.com/kvalo/athJohn W. Linville28-440/+1017
2014-09-26Merge branch 'master' of ↵John W. Linville23-160/+573
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
2014-09-25Bluetooth: Rename sco_param_wideband table to esco_param_msbcJohan Hedberg1-3/+3
The sco_param_wideband table represents the eSCO parameters for specifically mSBC encoding. This patch renames the table to the more descriptive esco_param_msbc name. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-09-25Bluetooth: Add retransmission effort into SCO parameter tableJohan Hedberg1-12/+11
It is expected that new parameter combinations will have the retransmission effort value different between some entries (mainly because of the new S4 configuration added by HFP 1.7), so it makes sense to move it into the table instead of having it hard coded based on the selected SCO_AIRMODE_*. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-09-24ieee802154: 6lowpan: ensure header compression does not corrupt ipv6 headerSimon Vincent1-36/+89
The 6lowpan ipv6 header compression was causing problems for other interfaces that expected a ipv6 header to still be in place, as we were replacing the ipv6 header with a compressed version. This happened if you sent a packet to a multicast address as the packet would be output on 802.15.4, ethernet, and also be sent to the loopback interface. The skb data was shared between these interfaces so all interfaces ended up with a compressed ipv6 header. The solution is to ensure that before we do any header compression we are not sharing the skb or skb data with any other interface. If we are then we must take a copy of the skb and skb data before modifying the ipv6 header. The only place we can copy the skb is inside the xmit function so we don't leave dangling references to skb. This patch moves all the header compression to inside the xmit function. Very little code has been changed it has mostly been moved from lowpan_header_create to lowpan_xmit. At the top of the xmit function we now check if the skb is shared and if so copy it. In lowpan_header_create all we do now is store the source and destination addresses for use later when we compress the header. Signed-off-by: Simon Vincent <simon.vincent@xsilon.com> Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-09-24mrf24j40: use pr_* / dev_* instead of printk()Varka Bhadram1-7/+7
Replace printk() with dev_*() pr_*(). Signed-off-by: Varka Bhadram <varkab@cdac.in> Acked-by: Alan Ott <alan@signal11.us> Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-09-24mrf24j40: remove unnecessary return statementVarka Bhadram1-2/+0
Remove the return statement in the void function. Signed-off-by: Varka Bhadram <varkab@cdac.in> Acked-by: Alan Ott <alan@signal11.us> Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-24 06:40:16 +0300