summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-12-11regulator: s5m8767: Fix to read the first DVS register.Amit Daniel Kachhap1-3/+3
This patch modifies the DVS register read function to select correct DVS1 register. This change is required because the GPIO select pin is 000 in unintialized state and hence selects the DVS1 register. Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-11regulator: s5m8767: Fix to work when platform registers less regulatorsAmit Daniel Kachhap1-4/+13
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-11Merge remote-tracking branch 'regmap/topic/type' into regmap-nextMark Brown1-1/+1
2012-12-11Merge remote-tracking branch 'regmap/topic/table' into regmap-nextMark Brown3-11/+122
2012-12-11Merge remote-tracking branch 'regmap/topic/lock' into regmap-nextMark Brown3-31/+54
2012-12-11Merge remote-tracking branch 'regmap/topic/domain' into regmap-nextMark Brown2-0/+21
2012-12-11Merge remote-tracking branch 'regmap/topic/debugfs' into regmap-nextMark Brown4-64/+260
2012-12-11Merge remote-tracking branch 'regmap/topic/core' into regmap-nextMark Brown1-1/+1
2012-12-11Linux 3.7Linus Torvalds1-1/+1
2012-12-11arm64: Fix the dtbs target buildingCatalin Marinas1-1/+1
The arch/arm64/Makefile was not passing the right target to the boot/dts/Makefile. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
2012-12-11Merge branches 'cache-l2x0', 'fixes', 'hdrs', 'misc', 'mmci', 'vic' and ↵Russell King1701-16325/+22594
'warnings' into for-next
2012-12-11ARM: 7594/1: Add .smp entry for REALVIEW_EBSteve Capper1-0/+1
The REALVIEW EB board can host tiles with multiple cores thus needs to be able to initialise SMP. There is, however, no .smp entry in the MACHINE_START struct for REALVIEW_EB. This patch adds the appropriate .smp entry to this struct. Signed-off-by: Steve Capper <steve.capper@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-12-11ARM: 7599/1: head: Remove boot-time HYP mode check for v5 and belowDave Martin1-0/+8
The kernel can only be entered on HYP mode on CPUs which actually support it, i.e. >= ARMv7. pre-v6 platform support cannot coexist in the same kernel as support for v7 and higher, so there is no advantage in having the HYP mode check on pre-v6 hardware. At least one pre-v6 board is known to fail when the HYP mode check code is present, although the exact cause remains unknown and may be unrelated. [1] This patch restores the old behaviour for pre-v6 platforms, whereby the CPSR is forced directly to SVC mode with IRQs and FIQs masked. All kernels capable of booting on v7 hardware will retain the check, so this should not impair functionality. [1] http://lists.arm.linux.org.uk/lurker/message/20121130.013814.19218413.en.html ([ARM] head.S change broke platform device registration?) Signed-off-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-12-11ARM: 7598/1: net: bpf_jit_32: fix sp-relative load/stores offsets.Schichan Nicolas1-1/+1
The offset must be multiplied by 4 to be sure to access the correct 32bit word in the stack scratch space. For instance, a store at scratch memory cell #1 was generating the following: st r4, [sp, #1] While the correct code for this is: st r4, [sp, #4] To reproduce the bug (assuming your system has a NIC with the mac address 52:54:00:12:34:56): echo 0 > /proc/sys/net/core/bpf_jit_enable tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \ == -0x3AA" # this will capture packets as expected echo 1 > /proc/sys/net/core/bpf_jit_enable tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \ == -0x3AA" # this will not. This bug was present since the original inclusion of bpf_jit for ARM (ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters). Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-12-11ARM: 7595/1: syscall: rework ordering in syscall_trace_exitWill Deacon2-10/+15
syscall_trace_exit is currently doing things back-to-front; invoking the audit hook *after* signalling the debugger, which presents an opportunity for the registers to be re-written by userspace in order to bypass auditing constaints. This patch fixes the ordering by moving the audit code first and the tracehook code last. On the face of it, it looks like current_thread_info()->syscall may be incorrect for the sys_exit tracepoint, but that's actually not an issue because it will have been set during syscall entry and cannot have changed since then. Reported-by: Andrew Gabbasov <Andrew_Gabbasov@mentor.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-12-11ARM: 7596/1: mmci: replace readsl/writesl with ioread32_rep/iowrite32_repDavide Ciminaghi1-4/+4
Not all the architectures have readsl/writesl, use the more portable ioread32_rep/iowrite32_rep functions instead. Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-12-11ARM: 7597/1: net: bpf_jit_32: fix kzalloc gfp/size mismatch.Schichan Nicolas1-2/+2
Official prototype for kzalloc is: void *kzalloc(size_t, gfp_t); The ARM bpf_jit code was having the assumption that it was: void *kzalloc(gfp_t, size); This was resulting the use of some random GFP flags depending on the size requested and some random overflows once the really needed size was more than the value of GFP_KERNEL. This bug was present since the original inclusion of bpf_jit for ARM (ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters). Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-12-11Input: matrix-keymap - provide proper module licenseFlorian Fainelli1-0/+3
The matrix-keymap module is currently lacking a proper module license, add one so we don't have this module tainting the entire kernel. This issue has been present since commit 1932811f426f ("Input: matrix-keymap - uninline and prepare for device tree support") Signed-off-by: Florian Fainelli <florian@openwrt.org> CC: stable@vger.kernel.org # v3.5+ Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds2-42/+131
Pull networking fixes from David Miller: 1) Netlink socket dumping had several missing verifications and checks. In particular, address comparisons in the request byte code interpreter could access past the end of the address in the inet_request_sock. Also, address family and address prefix lengths were not validated properly at all. This means arbitrary applications can read past the end of certain kernel data structures. Fixes from Neal Cardwell. 2) ip_check_defrag() operates in contexts where we're in the process of, or about to, input the packet into the real protocols (specifically macvlan and AF_PACKET snooping). Unfortunately, it does a pskb_may_pull() which can modify the backing packet data which is not legal if the SKB is shared. It very much can be shared in this context. Deal with the possibility that the SKB is segmented by using skb_copy_bits(). Fix from Johannes Berg based upon a report by Eric Leblond. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: ipv4: ip_check_defrag must not modify skb before unsharing inet_diag: validate port comparison byte code to prevent unsafe reads inet_diag: avoid unsafe and nonsensical prefix matches in inet_diag_bc_run() inet_diag: validate byte code to prevent oops in inet_diag_bc_run() inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state
2012-12-11Merge branch 'pci/mjg-pci-roms-from-efi' into nextBjorn Helgaas3-4/+4
* pci/mjg-pci-roms-from-efi: PCI: Use phys_addr_t for physical ROM address
2012-12-11mtd: nand: davinci: fix the binding documentationKumar, Anil1-25/+12
Since the aemif driver conversion to DT along with its movement to drivers/ folder is not yet done, fix NAND binding documentation to have NAND specific DT details only. Signed-off-by: Kumar, Anil <anilkumar.v@ti.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-12-11spi/sparc: Allow of_register_spi_devices for sparcAndreas Larsson1-1/+1
The spi support code works on SPARC too. No reason to exclude it from the party. Signed-off-by: Andreas Larsson <andreas@gaisler.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-12-11doc: Tighten-up and clarify description of tcp_fin_timeoutRick Jones1-9/+8
The description for tcp_fin_timeout should be tigher and more clear. In addition to being tighter, we should make the spelling of the state name consistent with what utilities report, remove the now dated reference to 2.2 and put the default in the consistent place. Signed-off-by: Rick Jones <rick.jones2@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-12-11minstrel: update stats after processing statusJohannes Berg1-4/+5
Instead of updating stats before sending a packet, update them after processing the packet's status. This makes minstrel in line with minstrel_ht. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-11rtc: rtc-mv: Add the device tree binding documentationGregory CLEMENT1-0/+18
The support was already written, but the binding documentation was lacking. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-12-11iwlwifi: don't handle masked interruptEmmanuel Grumbach1-2/+10
This can lead to a panic if the driver isn't ready to handle them. Since our interrupt line is shared, we can get an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks that even when the interrupt is being freed). If the op_mode has gone away, we musn't call it. To avoid this the transport disables the interrupts when the hw is stopped and the op_mode is leaving. If there is an event that would cause an interrupt the INTA register is updated regardless of the enablement of the interrupts: even if the interrupts are disabled, the INTA will be changed, but the device won't issue an interrupt. But the ISR can be called at any time, so we ought ignore the value in the INTA otherwise we can call the op_mode after it was freed. I found this bug when the op_mode_start failed, and called iwl_trans_stop_hw(trans, true). Then I played with the RFKILL button, and removed the module. While removing the module, the IRQ is freed, and the ISR is called (CONFIG_DEBUG_SHIRQ enabled). Panic. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-11iwlwifi: silently ignore fw flaws in Tx pathEmmanuel Grumbach1-31/+18
We know that we have issues with the fw in the reclaim path. This is why iwl_reclaim doesn't complain too loud when it happens since it is recoverable. Somehow, the caller of iwl_reclaim however WARNed when it happens. This doesn't make any sense. When I digged into the history of that code, I discovered that this bug occurs only when we receive a BA notification. So move the W/A in the BA notification handling code where it was before. This patch addresses: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2387 Cc: stable@vger.kernel.org Reported-by: Florian Reitmeir <florian@reitmeir.org> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-11iwlwifi: iwlagn_request_scan: Fix check for priv->scan_requestTim Gardner1-2/+3
The WARN_ON_ONCE() check for scan_request will not correctly detect a NULL pointer for scan_type == IWL_SCAN_NORMAL. Make it explicit that the check only applies to normal scans. Convert WARN_ON_ONCE to WARN_ON since priv->scan_request really _can't_ be NULL for normal scans. If it is then we should emit frequent warnings. This smatch warning led to scrutiny of iwlagn_request_scan(): drivers/net/wireless/iwlwifi/dvm/scan.c:894 iwlagn_request_scan() error: we previously assumed 'priv->scan_request' could be null (see line 792) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2012-12-11b43: fix tx path skb leaksFelix Fietkau3-8/+15
ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for tx packets passed to the driver from mac80211 Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath5k: fix tx path skb leaksFelix Fietkau2-3/+3
ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for tx packets passed to the driver from mac80211 Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k: allow to load EEPROM content via firmware APIGabor Juhos4-2/+82
The calibration data for devices w/o a separate EEPROM chip can be specified via the 'eeprom_data' field of 'ath9k_platform_data'. The 'eeprom_data' is usually filled from board specific setup functions. It is easy if the EEPROM data is mapped to the memory, but it can be complicated if it is stored elsewhere. The patch adds support for loading of the EEPROM data via the firmware API to avoid this limitation. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k: use 'struct ath_hw *' as the first argument for 'ath9k_hw_nvram_read'Gabor Juhos6-22/+17
The 'ath9k_hw_nvram_read' function takes a 'struct ath_common *' as its first argument. Almost each of its caller has a 'struct ath_hw *' parameter in their argument list, and that is dereferenced in order to get the 'struct ath_common' pointer. Change the first argument of 'ath9k_hw_nvram_read' to be a 'struct ath_hw *', and remove the dereference calls from the callers. Also change the type of the first argument of the ar9300_eeprom_read_{byte,word} functions. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k: add EEPROM offset to debug messageGabor Juhos1-1/+2
Show the EEPROM offset of the failed read operation in 'ath9k_hw_nvram_read'. The debug message is more informative this way. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k: move duplicated debug message to 'ath9k_hw_nvram_read'Gabor Juhos4-13/+11
The fill_eeprom functions are printing the same debug message in case the 'ath9k_hw_nvram_read' function fails. Remove the duplicated code from fill_eeprom functions and add the ath_dbg call directly into 'ath9k_hw_nvram_read'. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Fix signal strength / channel noise reportingFelix Fietkau2-0/+4
While AR_PHY_CCA_NOM_VAL_* does contain the expected internal noise floor for a chip measured in clean air, it refers to the lowest expected reading. Depending on the frequency, this measurement can vary by about 6db, thus causing a higher reported channel noise and signal strength. Factor in the 6db offset when converting internal noisefloor to channel noise. This patch makes the reported values more accurate for all chips without affecting NF calibration behavior. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11bcma: mips: fix clearing device IRQRafał Miłecki1-1/+1
We were using wrong IRQ number so clearing wasn't working at all. Depending on a platform this could result in a one device having two interrupts assigned. On BCM4706 this resulted in all IRQs being broken. Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: stable@vger.kernel.org Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Update intivals for AR9340Sujith Manoharan1-2/+4
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Calculate the correct training power for PAPRDSujith Manoharan2-20/+43
Assign the training power for PAPRD based on the chip. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Add HW cap for PAPRDSujith Manoharan5-7/+18
Add a HW capability to indicate whether PAPRD is enabled for the card, since PAPRD could be enabled in the EEPROM, but disabled in the driver. This makes things clearer. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Fix PAPRD retraining for AR9485Sujith Manoharan1-1/+5
Retraining of PAPRD based on agc2_pwr is required for chips other than AR9485. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Various trivial fixes for PAPRDSujith Manoharan2-8/+3
* Remove unneeded memset. All the values in the PAPRD gain table are filled, so there is no need to zero out the arrays. * Use GFP_KERNEL in ar9003_paprd_create_curve This is called from the PAPRD work, so the atomic variant is not needed. * Change return type of ar9003_paprd_setup_gain_table Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k: Fix redundant PS wrappersSujith Manoharan1-4/+6
Move the PowerSave wrappers outside ath_paprd_activate(), since they are already being used in ath_paprd_calibrate(). Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k: Add a few debug messages for PAPRDSujith Manoharan2-2/+11
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Fix PAPRD trainingSujith Manoharan1-7/+29
The PAPRD training control registers have to be programmed with values that depend on the chip. This patch ensures that the correct values are chosen for the chip in use. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k_hw: Fix PAPRD registers for AR9485Sujith Manoharan1-15/+14
Various PAPRD registers are at addresses that are different from those for the rest of the chips in the AR9003 family. Fix them. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ath9k: ar9003: fix OTP register offsets for AR9340Gabor Juhos1-3/+3
Trying to access the OTP memory on the AR9340 causes a data bus error like this: Data bus error, epc == 86e84164, ra == 86e84164 Oops[#1]: Cpu 0 $ 0 : 00000000 00000061 deadc0de 00000000 $ 4 : b8115f18 00015f18 00000007 00000004 $ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c $12 : 7c7c3c7c 001f0041 00000000 7c7c7c3c $16 : 86ee0000 00015f18 00000000 00000007 $20 : 00000004 00000064 00000004 86d71c44 $24 : 00000000 86e6ca00 $28 : 86d70000 86d71b20 86ece0c0 86e84164 Hi : 00000000 Lo : 00000064 epc : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Tainted: G O ra : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Status: 1100d403 KERNEL EXL IE Cause : 4080801c PrId : 0001974c (MIPS 74Kc) Modules linked in: ath9k(O+) ath9k_common(O) ath9k_hw(O) ath(O) ar934x_nfc mac80211(O) usbcore usb_common scsi_mod nls_base nand nand_ecc nand_ids crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_blkcipher cryptomgr aead crypto_hash crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio Process insmod (pid: 459, threadinfo=86d70000, task=87942140, tls=779ac440) Stack : 802fb500 000200da 804db150 804e0000 87816130 86ee0000 00010000 86d71b88 86d71bc0 00000004 00000003 86e9fcd0 80305300 0002c0d0 86e74c50 800b4c20 000003e8 00000001 00000000 86ee0000 000003ff 86e9fd64 80305300 80123938 fffffffc 00000004 000058bc 00000000 86ea0000 86ee0000 000001ff 878d6000 99999999 86e9fdc0 86ee0fcc 86e9e664 0000c0d0 86ee0000 0000700000007000 ... Call Trace: [<86e84164>] ath9k_hw_wait+0x58/0xb0 [ath9k_hw] [<86e9fcd0>] ath9k_hw_setup_statusring+0x16b8/0x1c7c [ath9k_hw] Code: 0000a812 0040f809 00000000 <00531024> 1054000b 24020001 0c05b5dc 2404000a 26520001 The cause of the error is that the OTP register offsets are different on the AR9340 than the actually used values. Cc: <stable@vger.kernel.org> # 3.0+ Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapterMaia Kozheva1-0/+1
D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a Ralink chipset supported by the rt2800usb driver. Currently, to work around the problem (it's missing in all present kernel versions, up to and including 3.7.x), I had to add this to /etc/rc.local: echo 2001 3c1e >> /sys/bus/usb/drivers/rt2800usb/new_id After that, the device works without problems. Been using it for over a week with no bugs in sight. The attached patch is trivial and simply adds the new USB ID to the list of devices handled by rt2800usb. Signed-off-by: Maia Kozheva <sikon@ubuntu.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11ssb: use WARN in main.cCong Ding1-2/+1
Use WARN rather than printk followed by WARN_ON(1), for conciseness. Signed-off-by: Cong Ding <dinggnu@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11carl9170: fix copy and paste mishap in carl9170_handle_mpduChristian Lamparter1-1/+1
This patch fixes a regression which was introduced by: "carl9170: split up carl9170_handle_mpdu" Previously, the ieee80211_rx_status was kept on the stack of carl9170_handle_mpdu. Now it's passed into the function as a pointer parameter. Hence, the old memcpy call needs to be fixed. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-12-11brcmsmac: add support for BCM43224 with PCI id of 14e4:a8d8Hauke Mehrtens1-2/+3
This device can be found on some embedded devices connected to a Broadcom SoC like the BCM4718. I tested this with my Netgear WNDR3400 v1. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 17:58:09 +0300