- 11 Jun, 2011 10 commits
-
-
Mika Westerberg authored
Russell King said: > > So, to summarize what its doing: > > 1. It allocates buffers for rx and tx. > 2. It maps them with dma_map_single(). > This transfers ownership of the buffer to the DMA device. > 3. In ep93xx_xmit, > 3a. It copies the data into the buffer with skb_copy_and_csum_dev() > This violates the DMA buffer ownership rules - the CPU should > not be writing to this buffer while it is (in principle) owned > by the DMA device. > 3b. It then calls dma_sync_single_for_cpu() for the buffer. > This transfers ownership of the buffer to the CPU, which surely > is the wrong direction. > 4. In ep93xx_rx, > 4a. It calls dma_sync_single_for_cpu() for the buffer. > This at least transfers the DMA buffer ownership to the CPU > before the CPU reads the buffer > 4b. It then uses skb_copy_to_linear_data() to copy the data out. > At no point does it transfer ownership back to the DMA device. > 5. When the driver is removed, it dma_unmap_single()'s the buffer. > This transfers ownership of the buffer to the CPU. > 6. It frees the buffer. > > While it may work on ep93xx, it's not respecting the DMA API rules, > and with DMA debugging enabled it will probably encounter quite a few > warnings. This patch fixes these violations. Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Tested-by: Petr Stetiar <ynezz@true.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mika Westerberg authored
Commit a197b59a (mm: fail GFP_DMA allocations when ZONE_DMA is not configured) made page allocator to return NULL if GFP_DMA is set but CONFIG_ZONE_DMA is disabled. This causes ep93xx_eth to fail: WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638() Modules linked in: [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60) [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec) [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60) [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864) [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108) [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128) [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48) [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68) [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c) [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134) [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8) Since there is no restrictions for DMA on ep93xx, we can fix this by just removing the GFP_DMA flag from the call. Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Tested-by: Petr Stetiar <ynezz@true.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mika Westerberg authored
We can use simply kmalloc() to allocate the buffers. This also simplifies the code and allows us to perform DMA sync operations more easily. Memory is allocated with only GFP_KERNEL since there are no DMA allocation restrictions on this platform. Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Tested-by: Petr Stetiar <ynezz@true.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mika Westerberg authored
We shouldn't use NULL for any DMA API functions, unless we are dealing with ISA or EISA device. So pass correct struct dev pointer to these functions. Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mika Westerberg authored
Since the driver uses the DMA API, we should pass it valid DMA masks. Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Tested-by: Petr Stetiar <ynezz@true.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Testing of VLAN_FLAG_REORDER_HDR does not belong in vlan_untag but rather in vlan_do_receive. Otherwise the vlan header will not be properly put on the packet in the case of vlan header accelleration. As we remove the check from vlan_check_reorder_header rename it vlan_reorder_header to keep the naming clean. Fix up the skb->pkt_type early so we don't look at the packet after adding the vlan tag, which guarantees we don't goof and look at the wrong field. Use a simple if statement instead of a complicated switch statement to decided that we need to increment rx_stats for a multicast packet. Hopefully at somepoint we will just declare the case where VLAN_FLAG_REORDER_HDR is cleared as unsupported and remove the code. Until then this keeps it working correctly. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Jiri Pirko <jpirko@redhat.com> Acked-by: Changli Gao <xiaosuo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Hellstrom authored
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Russell King - ARM Linux authored
Fix: /tmp/ccvoZ6h8.s: Assembler messages: /tmp/ccvoZ6h8.s:284: Warning: register range not in ascending order /tmp/ccvoZ6h8.s:881: Warning: register range not in ascending order /tmp/ccvoZ6h8.s:1087: Warning: register range not in ascending order by ensuring that we have temporary variables placed into specific registers. Reorder the code a bit to allow the resulting assembly to be slightly more optimal. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Russell King - ARM Linux authored
We were clearing out the multicast filter whenever the interface was upped, and not setting the mode bits correctly. This can cause problems if there are any multicast addresses already set at this point, or if ALLMULTI was set. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Russell King - ARM Linux authored
Without this the compiler can (and does) optimize register reads away from within loops, and other such optimizations. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 09 Jun, 2011 7 commits
-
-
Yegor Yefremov authored
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
H Hartley Sweeten authored
Lennert stated that he has been short on time lately. Since I'm maintaining the ep93xx core stuff, I'm willing to also take over maintaining the Ethernet driver. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: Mika Westerberg <mika.westerberg@iki.fi> Acked-by: Lennert Buytenhek <kernel@wantstofly.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steffen Klassert authored
We assume that transhdrlen is positive on the first fragment which is wrong for raw packets. So we don't add exthdrlen to the packet size for raw packets. This leads to a reallocation on IPsec because we have not enough headroom on the skb to place the IPsec headers. This patch fixes this by adding exthdrlen to the packet size whenever the send queue of the socket is empty. This issue was introduced with git commit 1470ddf7 (inet: Remove explicit write references to sk/inet in ip_append_data) Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 into for-davem
-
WANG Cong authored
In commit 8d8fc29d (netpoll: disable netpoll when enslave a device), we automatically disable netpoll when the underlying device is being enslaved, we also need to prevent people from setuping netpoll on devices that are already enslaved. Signed-off-by: WANG Cong <amwang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
commit 2c8cec5c (ipv4: Cache learned PMTU information in inetpeer) added some racy peer->pmtu_expires accesses. As its value can be changed by another cpu/thread, we should be more careful, reading its value once. Add peer_pmtu_expired() and peer_pmtu_cleaned() helpers Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wu Jiajun-B06378 authored
Each eTSEC device should own localized filer table. Signed-off-by: Jiajun Wu <b06378@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 08 Jun, 2011 4 commits
-
-
Stanislaw Gruszka authored
We use priv->mutex to avoid race conditions between chswitch_done() and mac_channel_switch(), when marking channel switch in progress. But chswitch_done() can be called in atomic context from rx_csa() or with mutex already taken from commit_rxon(). To fix remove mutex from chswitch_done() and use atomic bitops for marking channel switch pending. Cc: stable@kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Ignacy reports that sometimes after leaving an IBSS joining a new one didn't work because there still were stations on the list. He fixed it by flushing stations when attempting to join a new IBSS, but this shouldn't be happening in the first case. When I looked into it I saw a race condition in teardown that could cause stations to be added after flush, and thus cause this situation. Ignacy confirms that after applying my patch he hasn't seen this happen again. Reported-by: Ignacy Gawedzki <i@lri.fr> Debugged-by: Ignacy Gawedzki <i@lri.fr> Tested-by: Ignacy Gawedzki <i@lri.fr> Cc: stable@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
During channge channel, tx power will not send to uCode, the tx power command should send after scan complete. but should also can send after RXON command. Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Cc: stable@kernel.org [2.6.38+] Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Steffen Klassert authored
We may write 4 byte too much when we reinitialize the anti replay window in the replay advance functions. This patch fixes this by adjusting the last index of the initialization loop. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 07 Jun, 2011 9 commits
-
-
Williams, Mitch A authored
When SR-IOV is enabled, i350 devices fail to pass traffic. This is due to the driver attempting to enable RSS on the PF device, which is not supported by the i350. When max_vfs is specified on an i350 adapter, set the number of RSS queues to 1. This issue affects 2.6.39 as well. CC: stable@kernel.org Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Luciano Coelho authored
When one of the SSID's length passed in a scan or sched_scan request is larger than 255, there will be an overflow in the u8 that is used to store the length before checking. This causes the check to fail and we overrun the buffer when copying the SSID. Fix this by checking the nl80211 attribute length before copying it to the struct. This is a follow up for the previous commit 208c72f4, which didn't fix the problem entirely. Reported-by: Ido Yariv <ido@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mike McCormack authored
In the case we fail to allocate a new skb, the old skb should be resubmitted unmodified. Fixes bug introduced in a9e12869. Signed-off-by: Mike McCormack <mikem@ring3k.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mike McCormack authored
Should pass along packet if there's no CRC and no hardware error. Signed-off-by: Mike McCormack <mikem@ring3k.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This reverts commit 1d38c16c. The mac80211 maintainer raised complaints about abuse of the CSA stop reason, and about whether this patch actually serves its intended purpose at all. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Heiko Carstens authored
Frank Blaschka reported : <quote> During heavy network load we turn off/on cpus. Sometimes this causes a stall on the network device. Digging into the dump I found out following: napi is scheduled but does not run. From the I/O buffers and the napi state I see napi/rx_softirq processing has stopped because the budget was reached. napi stays in the softnet_data poll_list and the rx_softirq was raised again. I assume at this time the cpu offline comes in, the rx softirq is raised/moved to another cpu but napi stays in the poll_list of the softnet_data of the now offline cpu. Reviewing dev_cpu_callback (net/core/dev.c) I did not find the poll_list is transfered to the new cpu. </quote> This patch is a straightforward implementation of Frank suggestion : Transfert poll_list and trigger NET_RX_SOFTIRQ on new cpu. Reported-by: Frank Blaschka <blaschka@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Holler authored
Like in commit 0972ddb2 (provide cow_metrics() methods to blackhole dst_ops), we must provide a cow_metrics for bridges fake_dst_ops as well. This fixes a regression coming from commits 62fa8a84 (net: Implement read-only protection and COW'ing of metrics.) and 33eb9873 (bridge: initialize fake_rtable metrics) ip link set mybridge mtu 1234 --> [ 136.546243] Pid: 8415, comm: ip Tainted: P 2.6.39.1-00006-g40545b7 #103 ASUSTeK Computer Inc. V1Sn /V1Sn [ 136.546256] EIP: 0060:[<00000000>] EFLAGS: 00010202 CPU: 0 [ 136.546268] EIP is at 0x0 [ 136.546273] EAX: f14a389c EBX: 000005d4 ECX: f80d32c0 EDX: f80d1da1 [ 136.546279] ESI: f14a3000 EDI: f255bf10 EBP: f15c3b54 ESP: f15c3b48 [ 136.546285] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 136.546293] Process ip (pid: 8415, ti=f15c2000 task=f4741f80 task.ti=f15c2000) [ 136.546297] Stack: [ 136.546301] f80c658f f14a3000 ffffffed f15c3b64 c12cb9c8 f80d1b80 ffffffa1 f15c3bbc [ 136.546315] c12da347 c12d9c7d 00000000 f7670b00 00000000 f80d1b80 ffffffa6 f15c3be4 [ 136.546329] 00000004 f14a3000 f255bf20 00000008 f15c3bbc c11d6cae 00000000 00000000 [ 136.546343] Call Trace: [ 136.546359] [<f80c658f>] ? br_change_mtu+0x5f/0x80 [bridge] [ 136.546372] [<c12cb9c8>] dev_set_mtu+0x38/0x80 [ 136.546381] [<c12da347>] do_setlink+0x1a7/0x860 [ 136.546390] [<c12d9c7d>] ? rtnl_fill_ifinfo+0x9bd/0xc70 [ 136.546400] [<c11d6cae>] ? nla_parse+0x6e/0xb0 [ 136.546409] [<c12db931>] rtnl_newlink+0x361/0x510 [ 136.546420] [<c1023240>] ? vmalloc_sync_all+0x100/0x100 [ 136.546429] [<c1362762>] ? error_code+0x5a/0x60 [ 136.546438] [<c12db5d0>] ? rtnl_configure_link+0x80/0x80 [ 136.546446] [<c12db27a>] rtnetlink_rcv_msg+0xfa/0x210 [ 136.546454] [<c12db180>] ? __rtnl_unlock+0x20/0x20 [ 136.546463] [<c12ee0fe>] netlink_rcv_skb+0x8e/0xb0 [ 136.546471] [<c12daf1c>] rtnetlink_rcv+0x1c/0x30 [ 136.546479] [<c12edafa>] netlink_unicast+0x23a/0x280 [ 136.546487] [<c12ede6b>] netlink_sendmsg+0x26b/0x2f0 [ 136.546497] [<c12bb828>] sock_sendmsg+0xc8/0x100 [ 136.546508] [<c10adf61>] ? __alloc_pages_nodemask+0xe1/0x750 [ 136.546517] [<c11d0602>] ? _copy_from_user+0x42/0x60 [ 136.546525] [<c12c5e4c>] ? verify_iovec+0x4c/0xc0 [ 136.546534] [<c12bd805>] sys_sendmsg+0x1c5/0x200 [ 136.546542] [<c10c2150>] ? __do_fault+0x310/0x410 [ 136.546549] [<c10c2c46>] ? do_wp_page+0x1d6/0x6b0 [ 136.546557] [<c10c47d1>] ? handle_pte_fault+0xe1/0x720 [ 136.546565] [<c12bd1af>] ? sys_getsockname+0x7f/0x90 [ 136.546574] [<c10c4ec1>] ? handle_mm_fault+0xb1/0x180 [ 136.546582] [<c1023240>] ? vmalloc_sync_all+0x100/0x100 [ 136.546589] [<c10233b3>] ? do_page_fault+0x173/0x3d0 [ 136.546596] [<c12bd87b>] ? sys_recvmsg+0x3b/0x60 [ 136.546605] [<c12bdd83>] sys_socketcall+0x293/0x2d0 [ 136.546614] [<c13629d0>] sysenter_do_call+0x12/0x26 [ 136.546619] Code: Bad EIP value. [ 136.546627] EIP: [<00000000>] 0x0 SS:ESP 0068:f15c3b48 [ 136.546645] CR2: 0000000000000000 [ 136.546652] ---[ end trace 6909b560e78934fa ]--- Signed-off-by: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
In 2.6.27, commit 393e52e3 (packet: deliver VLAN TCI to userspace) added a small information leak. Add padding field and make sure its zeroed before copy to user. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> CC: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
The SEQ output functions grab the obj->attrib->hb_spinlock lock of sub-objects found in the hash traversal. These locks are in a different realm than the one used for the irias_objects hash table itself. So put the latter into it's own lockdep class. Reported-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 06 Jun, 2011 10 commits
-
-
David S. Miller authored
This interface uses a temporary buffer, but for no real reason. And now can generate warnings like: net/sched/sch_generic.c: In function dev_watchdog net/sched/sch_generic.c:254:10: warning: unused variable drivername Just return driver->name directly or "". Reported-by: Connor Hansen <cmdkhh@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marcus Meissner authored
Same check as for IPv4, also do for IPv6. (If you passed in a IPv4 sockaddr_in here, the sizeof check in the line before would have triggered already though.) Signed-off-by: Marcus Meissner <meissner@suse.de> Cc: Reinhard Max <max@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stanislaw Gruszka authored
Setting tx power can be deferred during scan or changing channel. If after that correct tx power settings will not be sent to device, we can observe transmission problems and timeouts. Force to send tx power settings also after partial rxon change, to assure device always be configured with up-to-date settings. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=36492 Cc: stable@kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Avoid queue and run autowakeup_work when device is not present anymore. That prevent rmmod and device remove crash introduced by: commit 1c0bcf89 Author: Ivo van Doorn <ivdoorn@gmail.com> Date: Sat Apr 30 17:18:18 2011 +0200 rt2x00: Add autowake support for USB hardware Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
This patch fixes 802.11n stability and performance regression we have since 2.6.35. It boost performance on my 5GHz N-only network from about 5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz. These are test results of 5x downloading of approximately 700MB iso image: vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110 patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946 This was achieved with NetworkManager configured to do not perform periodical scans, by configuring constant BSSID. With periodical scans, after some time, performance downgrade to unpatched driver level, like in example below: patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683 However patch still make better here, since similar test on unpatched driver make link disconnects with below messages after some time: wlan1: authenticate with 00:23:69:35:d1:3f (try 1) wlan1: authenticate with 00:23:69:35:d1:3f (try 2) wlan1: authenticate with 00:23:69:35:d1:3f (try 3) wlan1: authentication with 00:23:69:35:d1:3f timed out On 2.6.35 kernel patch helps against connection hangs with messages: iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload. iwlagn 0000:20:00.0: On demand firmware reload iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting Cc: stable@kernel.org # 2.6.35+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This reverts commit aac6af55. Conflicts: net/mac80211/key.c That commit has a race that causes a warning, as documented in the thread here: http://marc.info/?l=linux-wireless&m=130717684914101&w=2Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 into for-davem
-
-
Grant Likely authored
Fix missing semicolon at end of smc91x.c match tabledevice driver. Also remove unnecessary #ifdef around of_match_table pointer. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
-