linux, branch v3.10.6

Linux 3.10.6

2013-08-12T01:49:02Z

hwrng: bcm2835: fix MODULE_LICENSE tag

2013-08-12T01:35:26Z

commit 22e8099f4f6621b8d165e238cdef2a1cf655e159 upstream. The MODULE_LICENSE macro invocation must use either "GPL" or "GPL v2", but not "GPLv2" in order to be detected by the module loader. This fixes the allmodconfig build error: FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister' Signed-off-by: Arnd Bergmann Acked-by: Lubomir Rintel Cc: Dom Cobley Cc: Stephen Warren Cc: Matt Mackall Cc: linux-rpi-kernel@lists.infradead.org Cc: Herbert Xu Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

iwlwifi: dvm: don't send BT_CONFIG on devices w/o Bluetooth

2013-08-12T01:35:26Z

commit 707aee401d2467baa785a697f40a6e2d9ee79ad5 upstream. The BT_CONFIG command that is sent to the device during startup will enable BT coex unless the module parameter turns it off, but on devices without Bluetooth this may cause problems, as reported in Redhat BZ 885407. Fix this by sending the BT_CONFIG command only when the device has Bluetooth. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: set SSID bits for passive channels

2013-08-12T01:35:26Z

commit bb963c4a43eb5127eb0bbfa16c7a6a209b0af5db upstream. Set SSID bitmap for direct scan even on passive channels, for the passive-to-active feature. Without this patch only the SSID from probe request template is sent on passive channels, after passive-to-active switching, causing us to not find all desired networks. Remove the unused passive scan mask constant. Reviewed-by: Emmanuel Grumbach Signed-off-by: David Spinadel Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

net/mlx4_core: VFs must ignore the enable_64b_cqe_eqe module param

2013-08-12T01:35:26Z

[ Upstream commit b30513202c6c14120f70b2e9aa1e97d47bbc2313 ] Slaves get the 64B CQE/EQE state from QUERY_HCA, not from the module parameter. If the parameter is set to zero, the slave outputs an incorrect/irrelevant warning message that 64B CQEs/EQEs are supported but not enabled (even if the hypervisor has enabled 64B CQEs/EQEs). Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net/mlx4_core: Don't give VFs MAC addresses which are derived from the PF MAC

2013-08-12T01:35:26Z

[ Upstream commit 0508ad646836007e6e6b62331eee7356844eac3d ] If the user has not assigned a MAC address to a VM, then don't give it MAC which is based on the PF one. The current derivation scheme is wrong and leads to VM MAC collisions when the number of cards/hypervisors becomes big enough. Instead, just give it zeros and let them figure out what to do with that. Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

8139cp: Add dma_mapping_error checking

2013-08-12T01:35:26Z

[ Upstream commit cf3c4c03060b688cbc389ebc5065ebcce5653e96 ] Self explanitory dma_mapping_error addition to the 8139 driver, based on this: https://bugzilla.redhat.com/show_bug.cgi?id=947250 It showed several backtraces arising for dma_map_* usage without checking the return code on the mapping. Add the check and abort the rx/tx operation if its failed. Untested as I have no hardware and the reporter has wandered off, but seems pretty straightforward. Signed-off-by: Neil Horman CC: "David S. Miller" CC: Francois Romieu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ndisc: Add missing inline to ndisc_addr_option_pad

2013-08-12T01:35:26Z

[ Upstream commit d9d10a30964504af834d8d250a0c76d4ae91eb1e ] Signed-off-by: Joe Perches Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net_sched: info leak in atm_tc_dump_class()

2013-08-12T01:35:26Z

[ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ] The "pvc" struct has a hole after pvc.sap_family which is not cleared. Signed-off-by: Dan Carpenter Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

atl1c: use custom skb allocator

2013-08-12T01:35:26Z

[ Upstream commit 7b70176421993866e616f1cbc4d0dd4054f1bf78 ] We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 ) that using high order pages for skb allocations is problematic for atl1c We do not know exactly what the problem is, but we suspect that crossing 4K pages is not well supported by this hardware. Use a custom allocator, using page allocator and 2K fragments for optimal stack behavior. We might make this allocator generic in future kernels. Signed-off-by: Eric Dumazet Cc: Luis Henriques Cc: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman