Jason Wang [Fri, 7 Dec 2012 07:04:55 +0000 (07:04 +0000)]
virtio-net: separate fields of sending/receiving queue from virtnet_info
To support multiqueue transmitq/receiveq, the first step is to separate queue
related structure from virtnet_info. This patch introduce send_queue and
receive_queue structure and use the pointer to them as the parameter in
functions handling sending/receiving.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
vxlan: Add capability of Rx checksum offload for inner packet
This patch adds capability in vxlan to identify received
checksummed inner packets and signal them to the upper layers of
the stack. The driver needs to set the skb->encapsulation bit
and also set the skb->ip_summed to CHECKSUM_UNNECESSARY.
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Allow VXLAN to make use of Tx checksum offloading and Tx scatter-gather.
The advantage to these two changes is that it also allows the VXLAN to
make use of GSO.
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Fri, 7 Dec 2012 14:14:15 +0000 (14:14 +0000)]
net: Handle encapsulated offloads before fragmentation or handing to lower dev
This change allows the VXLAN to enable Tx checksum offloading even on
devices that do not support encapsulated checksum offloads. The
advantage to this is that it allows for the lower device to change due
to routing table changes without impacting features on the VXLAN itself.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
net: Add support for hardware-offloaded encapsulation
This patch adds support in the kernel for offloading in the NIC Tx and Rx
checksumming for encapsulated packets (such as VXLAN and IP GRE).
For Tx encapsulation offload, the driver will need to set the right bits
in netdev->hw_enc_features. The protocol driver will have to set the
skb->encapsulation bit and populate the inner headers, so the NIC driver will
use those inner headers to calculate the csum in hardware.
For Rx encapsulation offload, the driver will need to set again the
skb->encapsulation flag and the skb->ip_csum to CHECKSUM_UNNECESSARY.
In that case the protocol driver should push the decapsulated packet up
to the stack, again with CHECKSUM_UNNECESSARY. In ether case, the protocol
driver should set the skb->encapsulation flag back to zero. Finally the
protocol driver should have NETIF_F_RXCSUM flag set in its features.
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
françois romieu [Fri, 7 Dec 2012 11:20:21 +0000 (11:20 +0000)]
r8169: workaround for missing extended GigaMAC registers
GigaMAC registers have been reported left unitialized in several
situations:
- after cold boot from power-off state
- after S3 resume
Tweaking rtl_hw_phy_config takes care of both.
This patch removes an excess entry (",") at the end of the exgmac_reg
array as well.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Wang YanQing <udknight@gmail.com> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sun, 9 Dec 2012 01:25:45 +0000 (20:25 -0500)]
Merge branch 'tipc_net-next_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
Paul Gortmaker says:
====================
Changes since v1:
-get rid of essentially unused variable spotted by
Neil Horman (patch #2)
-drop patch #3; defer it for 3.9 content, so Neil,
Jon and Ying can discuss its specifics at their
leisure while net-next is closed. (It had no
direct dependencies to the rest of the series, and
was just an optimization)
-fix indentation of accept() code directly in place
vs. forking it out to a separate function (was patch
#10, now patch #9).
Rebuilt and re-ran tests just to ensure nothing odd happened.
Original v1 text follows, updated pull information follows that.
---------
Here is another batch of TIPC changes. The most interesting
thing is probably the non-blocking socket connect - I'm told
there were several users looking forward to seeing this.
Also there were some resource limitation changes that had
the right intent back in 2005, but were now apparently causing
needless limitations to people's real use cases; those have
been relaxed/removed.
There is a lockdep splat fix, but no need for a stable backport,
since it is virtually impossible to trigger in mainline; you
have to essentially modify code to force the probabilities
in your favour to see it.
The rest can largely be categorized as general cleanup of things
seen in the process of getting the above changes done.
Tested between 64 and 32 bit nodes with the test suite. I've
also compile tested all the individual commits on the chain.
I'd originally figured on this queue not being ready for 3.8, but
the extended stabilization window of 3.7 has changed that. On
the other hand, this can still be 3.9 material, if that simply
works better for folks - no problem for me to defer it to 2013.
If anyone spots any problems then I'll definitely defer it,
rather than rush a last minute respin.
===================
Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Tue, 4 Dec 2012 16:01:55 +0000 (11:01 -0500)]
tipc: refactor accept() code for improved readability
In TIPC's accept() routine, there is a large block of code relating
to initialization of a new socket, all within an if condition checking
if the allocation succeeded.
Here, we simply flip the check of the if, so that the main execution
path stays at the same indentation level, which improves readability.
If the allocation fails, we jump to an already existing exit label.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Ying Xue [Mon, 3 Dec 2012 08:12:07 +0000 (16:12 +0800)]
tipc: add lock nesting notation to quiet lockdep warning
TIPC accept() call grabs the socket lock on a newly allocated
socket while holding the socket lock on an old socket. But lockdep
worries that this might be a recursive lock attempt:
[ INFO: possible recursive locking detected ]
---------------------------------------------
kworker/u:0/6 is trying to acquire lock:
(sk_lock-AF_TIPC){+.+.+.}, at: [<c8c1226c>] accept+0x15c/0x310 [tipc]
but task is already holding lock:
(sk_lock-AF_TIPC){+.+.+.}, at: [<c8c12138>] accept+0x28/0x310 [tipc]
other info that might help us debug this:
Possible unsafe locking scenario:
Tell lockdep that this locking is safe by using lock_sock_nested().
This is similar to what was done in commit 5131a184a3458d9 for
SCTP code ("SCTP: lock_sock_nested in sctp_sock_migrate").
Also note that this is isn't something that is seen normally,
as it was uncovered with some experimental work-in-progress
code not yet ready for mainline. So no need for stable
backports or similar of this commit.
Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Ying Xue [Thu, 29 Nov 2012 08:28:30 +0000 (16:28 +0800)]
tipc: eliminate connection setup for implied connect in recv_msg()
As connection setup is now completed asynchronously in BH context,
in the function filter_connect(), the corresponding code in recv_msg()
becomes redundant.
Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Ying Xue [Thu, 29 Nov 2012 23:51:19 +0000 (18:51 -0500)]
tipc: introduce non-blocking socket connect
TIPC has so far only supported blocking connect(), meaning that a call
to connect() doesn't return until either the connection is fully
established, or an error occurs. This has proved insufficient for many
users, so we now introduce non-blocking connect(), analogous to how
this is done in TCP and other protocols.
With this feature, if a connection cannot be established instantly,
connect() will return the error code "-EINPROGRESS".
If the user later calls connect() again, he will either have the
return code "-EALREADY" or "-EISCONN", depending on whether the
connection has been established or not.
The user must have explicitly set the socket to be non-blocking
(SOCK_NONBLOCK or O_NONBLOCK, depending on method used), so unless
for some reason they had set this already (the socket would anyway
remain blocking in current TIPC) this change should be completely
backwards compatible.
It is also now possible to call select() or poll() to wait for the
completion of a connection.
An effect of the above is that the actual completion of a connection
may now be performed asynchronously, independent of the calls from
user space. Therefore, we now execute this code in BH context, in
the function filter_rcv(), which is executed upon reception of
messages in the socket.
Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: minor refactoring for improved connect/disconnect function names] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Ying Xue [Thu, 29 Nov 2012 23:39:14 +0000 (18:39 -0500)]
tipc: consolidate connection-oriented message reception in one function
Handling of connection-related message reception is currently scattered
around at different places in the code. This makes it harder to verify
that things are handled correctly in all possible scenarios.
So we consolidate the existing processing of connection-oriented
message reception in a single routine. In the process, we convert the
chain of if/else into a switch/case for improved readability.
A cast on the socket_state in the switch is needed to avoid compile
warnings on 32 bit, like "net/tipc/socket.c:1252:2: warning: case value
‘4294967295’ not in enumerated type". This happens because existing
tipc code pseudo extends the default linux socket state values with:
#define SS_LISTENING -1 /* socket is listening */
#define SS_READY -2 /* socket is connectionless */
It may make sense to add these as _positive_ values to the existing
socket state enum list someday, vs. these already existing defines.
Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: add cast to fix warning; remove returns from middle of switch] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Paul Gortmaker [Thu, 29 Nov 2012 18:48:40 +0000 (13:48 -0500)]
tipc: standardize across connect/disconnect function naming
Currently we have tipc_disconnect and tipc_disconnect_port. It is
not clear from the names alone, what they do or how they differ.
It turns out that tipc_disconnect just deals with the port locking
and then calls tipc_disconnect_port which does all the work.
If we rename as follows: tipc_disconnect_port --> __tipc_disconnect
then we will be following typical linux convention, where:
__tipc_disconnect: "raw" function that does all the work.
tipc_disconnect: wrapper that deals with locking and then calls
the real core __tipc_disconnect function
With this, the difference is immediately evident, and locking
violations are more apt to be spotted by chance while working on,
or even just while reading the code.
On the connect side of things, we currently only have the single
"tipc_connect2port" function. It does both the locking at enter/exit,
and the core of the work. Pending changes will make it desireable to
have the connect be a two part locking wrapper + worker function,
just like the disconnect is already.
Here, we make the connect look just like the updated disconnect case,
for the above reason, and for consistency. In the process, we also
get rid of the "2port" suffix that was on the original name, since
it adds no descriptive value.
On close examination, one might notice that the above connect
changes implicitly move the call to tipc_link_get_max_pkt() to be
within the scope of tipc_port_lock() protected region; when it was
not previously. We don't see any issues with this, and it is in
keeping with __tipc_connect doing the work and tipc_connect just
handling the locking.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Jon Maloy [Tue, 27 Nov 2012 11:15:29 +0000 (06:15 -0500)]
tipc: change sk_receive_queue upper limit
The sk_recv_queue upper limit for connectionless sockets has empirically
turned out to be too low. When we double the current limit we get much
fewer rejected messages and no noticable negative side-effects.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Ben Hutchings [Fri, 7 Dec 2012 06:15:32 +0000 (06:15 +0000)]
bonding: Fix check for ethtool get_link operation support
Since commit 2c60db037034 ('net: provide a default dev->ethtool_ops')
all devices have a non-null ethtool_ops. Test only
dev->ethtool_ops->get_link in both places where we care.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Cong Wang [Fri, 7 Dec 2012 00:04:48 +0000 (00:04 +0000)]
bridge: export multicast database via netlink
V5: fix two bugs pointed out by Thomas
remove seq check for now, mark it as TODO
V4: remove some useless #include
some coding style fix
V3: drop debugging printk's
update selinux perm table as well
V2: drop patch 1/2, export ifindex directly
Redesign netlink attributes
Improve netlink seq check
Handle IPv6 addr as well
This patch exports bridge multicast database via netlink
message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).
(Thanks to Thomas for patient reviews)
Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Stephen Hemminger <shemminger@vyatta.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Graf <tgraf@suug.ch> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Cong Wang <amwang@redhat.com> Acked-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
Shan Wei [Thu, 6 Dec 2012 16:27:51 +0000 (16:27 +0000)]
net: doc : use more suitable word 'unexpected' to replace 'secluded'
'secluded' is used to describe places, not suitable here.
Suggested-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Shan Wei <davidshan@tencent.com> Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net: fix up function prototypes after __dev* removals
The __dev* removal patches for the network drivers ended up messing up
the function prototypes for a bunch of drivers. This patch fixes all of
them back up to be properly aligned.
Bonus is that this almost removes 100 lines of code, always a nice
surprise.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Ying Xue [Tue, 27 Nov 2012 11:15:27 +0000 (06:15 -0500)]
tipc: eliminate aggregate sk_receive_queue limit
As a complement to the per-socket sk_recv_queue limit, TIPC keeps a
global atomic counter for the sum of sk_recv_queue sizes across all
tipc sockets. When incremented, the counter is compared to an upper
threshold value, and if this is reached, the message is rejected
with error code TIPC_OVERLOAD.
This check was originally meant to protect the node against
buffer exhaustion and general CPU overload. However, all experience
indicates that the feature not only is redundant on Linux, but even
harmful. Users run into the limit very often, causing disturbances
for their applications, while removing it seems to have no negative
effects at all. We have also seen that overall performance is
boosted significantly when this bottleneck is removed.
Furthermore, we don't see any other network protocols maintaining
such a mechanism, something strengthening our conviction that this
control can be eliminated.
As a result, the atomic variable tipc_queue_size is now unused
and so it can be deleted. There is a getsockopt call that used
to allow reading it; we retain that but just return zero for
maximum compatibility.
Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Cc: Neil Horman <nhorman@tuxdriver.com>
[PG: phase out tipc_queue_size as pointed out by Neil Horman] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Thomas Graf [Thu, 6 Dec 2012 09:25:05 +0000 (09:25 +0000)]
sctp: Add RCU protection to assoc->transport_addr_list
peer.transport_addr_list is currently only protected by sk_sock
which is inpractical to acquire for procfs dumping purposes.
This patch adds RCU protection allowing for the procfs readers to
enter RCU read-side critical sections.
Modification of the list continues to be serialized via sk_lock.
V2: Use list_del_rcu() in sctp_association_free() to be safe
Skip transports marked dead when dumping for procfs
Cc: Vlad Yasevich <vyasevich@gmail.com> Cc: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Thomas Graf <tgraf@suug.ch> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Thomas Graf [Thu, 6 Dec 2012 09:25:04 +0000 (09:25 +0000)]
sctp: proc: protect bind_addr->address_list accesses with rcu_read_lock()
address_list is protected via the socket lock or RCU. Since we don't want
to take the socket lock for each assoc we dump in procfs a RCU read-side
critical section must be entered.
V2: Skip local addresses marked as dead
Cc: Vlad Yasevich <vyasevich@gmail.com> Cc: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Thomas Graf <tgraf@suug.ch> Acked-by: Vlad Yasevich <vyasevic@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 7 Dec 2012 19:09:44 +0000 (14:09 -0500)]
Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next
John W. Linville says:
====================
This pull request is intended for 3.8...
This includes a Bluetooth pull. Gustavo says:
"A few more patches to 3.8, I hope they can still make it to mainline!
The most important ones are the socket option for the SCO protocol to allow
accept/refuse new connections from userspace. Other than that I added some
fixes and Andrei did more AMP work."
Also, a mac80211 pull. Johannes says:
"If you think there's any chance this might make it still, please pull my
mac80211-next tree (per below). This contains a relatively large number
of fixes to the previous code, as well as a few small features:
* VHT association in mac80211
* some new debugfs files
* P2P GO powersave configuration
* masked MAC address verification
The biggest patch is probably the BSS struct changes to use RCU for
their IE buffers to fix potential races. I've not tagged this for stable
because it's pretty invasive and nobody has ever seen any bugs in this
area as far as I know."
Several other drivers get some attention, including ath9k, brcmfmac,
brcmsmac, and a number of others. Also, Hauke gives us a series that
improves watchdog support for the bcma and ssb busses. Finally, Bill
Pemberton delivers a group of "remove __dev* attributes" for wireless
drivers -- these generate some "section mismatch" warnings, but Greg
K-H assures me that they will disappear by the time -rc1 is released.
This also includes a pull of the wireless tree to avoid merge
conflicts.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Moore [Thu, 6 Dec 2012 05:48:38 +0000 (05:48 +0000)]
tun: correctly report an error in tun_flow_init()
On error, the error code from tun_flow_init() is lost inside
tun_set_iff(), this patch fixes this by assigning the tun_flow_init()
error code to the "err" variable which is returned by
the tun_flow_init() function on error.
Signed-off-by: Paul Moore <pmoore@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
sctp: Fix compiler warning when CONFIG_DEBUG_SECTION_MISMATCH=y
WARNING: net/sctp/sctp.o(.text+0x72f1): Section mismatch in reference
from the function sctp_net_init() to the function
.init.text:sctp_proc_init()
The function sctp_net_init() references
the function __init sctp_proc_init().
This is often because sctp_net_init lacks a __init
annotation or the annotation of sctp_proc_init is wrong.
And put __net_init after 'int' for sctp_proc_init - as it is done
everywhere else in the sctp-stack.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jan Glauber [Wed, 5 Dec 2012 23:20:14 +0000 (23:20 +0000)]
chelsio: remove get_clock and use ktime_get
The get_clock() of the chelsio driver clashes with the s390 one.
The chelsio helper reads a timespec via ktime just to convert it
back to ktime. I can see no different outcome from calling
ktime_get directly.
Remove the get_clock and use ktime_get directly.
Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Barak Witkowski [Wed, 5 Dec 2012 23:04:03 +0000 (23:04 +0000)]
bnx2x: Prevent link flaps when booting from SAN.
It is possible that the driver is configured to operate with a certain
link configuration which differs from the link's configuration during
boot from SAN - this would cause the driver to flap the link.
Said flap may be missed by specific switches, causing dcbx convergence
to be too long and boot sequence to fail. Convergence is longer because
switch ignores new dcbx packets due to counters mismatch, as only host
side reset the counters due to the link flap.
This patch causes the driver to ignore user's initial configuration during
boot from SAN, and continues with the existing link configuration.
Signed-off-by: Barak Witkowski <barak@broadcom.com> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
trem [Tue, 4 Dec 2012 08:52:10 +0000 (08:52 +0000)]
net: phy: smsc: force all capable mode if the phy is started in powerdown mode
A SMSC PHY in power down mode can't be used.
If a SMSC PHY is in this mode in the config_init
stage, the mode "all capable" is set. So the PHY
could then be used.
Signed-off-by: Philippe Reynes <tremyfr@yahoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Chan [Thu, 6 Dec 2012 10:33:12 +0000 (10:33 +0000)]
cnic, bnx2x, bnx2: Simplify cnic probing.
Instead of using symbol_get(), cnic can now directly call the cnic_probe
functions in struct bnx2x and struct bnx2. symbol_get() is not reliable
as it fails when the module is still initializing.
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Chan [Thu, 6 Dec 2012 10:33:08 +0000 (10:33 +0000)]
bnx2: Rename register read and write macros
with BNX2_ prefix for namespace consistency. Currently, these macro names
conflict with similar macros in bnx2x.h, preventing the cnic driver from
including both bnx2.h and bnx2x.h. Including bnx2x.h in cnic.c will remove
many redundant definitions and simplify the interface.
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Nicolas Dichtel [Tue, 4 Dec 2012 01:03:07 +0000 (01:03 +0000)]
ipv4/route/rtnl: get mcast attributes when dst is multicast
Commit f1ce3062c538 (ipv4: Remove 'rt_dst' from 'struct rtable') removes the
call to ipmr_get_route(), which will get multicast parameters of the route.
I revert the part of the patch that remove this call. I think the goal was only
to get rid of rt_dst field.
The patch is only compiled-tested. My first idea was to remove ipmr_get_route()
because rt_fill_info() was the only user, but it seems the previous patch cleans
the code a bit too much ;-)
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Stefan Assmann [Tue, 4 Dec 2012 06:00:17 +0000 (06:00 +0000)]
igb: release already assigned MSI-X interrupts if setup fails
During MSI-X setup the system might run out of vectors. If this happens the
already assigned vectors for this NIC should be freed before trying the
disable MSI-X. Failing to do so results in the following oops.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Stefan Assmann [Tue, 4 Dec 2012 06:00:12 +0000 (06:00 +0000)]
igb: remove duplicate code for fallback interrupt initialization
Given a small change to igb_init_interrupt_scheme() the function fits
igb_request_irq() for MSI/legacy interrupts initialization as well, instead of
duplicating most of its code there.
Also adding a missing igb_configure() to igb_request_irq() for MSI fallback
to work properly.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Jacob Keller [Tue, 4 Dec 2012 06:03:14 +0000 (06:03 +0000)]
ixgbe: check whether thermal sensor is enabled.
The X540's internal thermal sensor should not be enabled for all devices, but
only those devices which enable it in the NVM image. It is expected that
actively cooled devices will have it enabled, but passively cooled devices might
not want it enabled. This is due to passively cooled devices operating very near
the thermal threshold, sometimes within the margin of error of the thermal
sensor. Thus these devices may not be good candidates for using the thermal
sensor.
This patch uses the enabled bit in the FWSM register to check whether we should
be enabling the thermal sensor, and only sets the THERMAL_SENSOR_CAPABLE flag
for those devices which have it enabled.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Joe Perches [Wed, 24 Oct 2012 17:19:02 +0000 (17:19 +0000)]
ixgbe: Use is_valid_ether_addr
Use the normal kernel test instead of a module specific one.
Signed-off-by: Joe Perches <joe@perches.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Erik Hugne [Wed, 7 Nov 2012 07:40:07 +0000 (02:40 -0500)]
tipc: remove obsolete flush of stale reassembly buffer
Each link instance has a periodic job checking if there is a stale
ongoing message reassembly associated to the link. If no new
fragment has been received during the last 4*[link_tolerance] period,
it is assumed the missing fragment will never arrive. As a consequence,
the reassembly buffer is discarded, and a gap in the message sequence
occurs.
This assumption is wrong. After we abandoned our ambition to develop
packet routing for multi-cluster networks, only single-hop packet
transfer remains as an option. For those, all packets are guaranteed
to be delivered in sequence to the defragmentation layer. Any failure
to achieve sequenced delivery will eventually lead to link reset, and
the reassembly buffer will be flushed anyway.
So we just remove this periodic check, which is now obsolete.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
[PG: also delete get/inc_timer count, since they are now unused] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:40 +0000 (09:56 -0500)]
rtl8187: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:39 +0000 (09:56 -0500)]
rt2x00: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: users@rt2x00.serialmonkey.com (moderated for non-subscribers) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:38 +0000 (09:56 -0500)]
p54: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:37 +0000 (09:56 -0500)]
orinoco: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:35 +0000 (09:56 -0500)]
libertas: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Dan Williams <dcbw@redhat.com> Cc: libertas-dev@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:34 +0000 (09:56 -0500)]
iwlwifi: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Johannes Berg <johannes.berg@intel.com> Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com> Cc: Intel Linux Wireless <ilw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:32 +0000 (09:56 -0500)]
ipw2x00: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:31 +0000 (09:56 -0500)]
brcm80211: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Brett Rudley <brudley@broadcom.com> Cc: Roland Vossen <rvossen@broadcom.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com> Cc: Kan Yan <kanyan@broadcom.com> Cc: brcm80211-dev-list@broadcom.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:29 +0000 (09:56 -0500)]
atmel: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:28 +0000 (09:56 -0500)]
ath5k: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Nick Kossifidis <mickflemm@gmail.com> Cc: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Cc: linux-wireless@vger.kernel.org Cc: ath5k-devel@lists.ath5k.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:27 +0000 (09:56 -0500)]
wireless: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:26 +0000 (09:56 -0500)]
rfkill: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:08 +0000 (18:46 +0100)]
ssb: register watchdog driver
Register the watchdog driver to the system if it is a SoC. Using the
watchdog on a non SoC device, like a PCI card, will make the PCI
card die when the timeout expired, but starting it again is not
supported by ssb.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:07 +0000 (18:46 +0100)]
ssb: extif: add methods for watchdog driver
The watchdog driver wants to set the watchdog timeout in ms and not in
ticks, add a method converting ms to ticks before setting the watchdog
register. Return the ticks or millisecond the timer was set to in case
the provided value was bigger than the max allowed value.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:05 +0000 (18:46 +0100)]
ssb: add methods for watchdog driver
The watchdog driver wants to set the watchdog timeout in ms and not in
ticks, which is depending on the SoC type and the clock.
Calculate the number of ticks per millisecond and provide two functions
for the watchdog driver. Also return the ticks or millisecond the timer
was set to in case the provided value was bigger than the max allowed
value.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:04 +0000 (18:46 +0100)]
ssb: set the PMU watchdog if available
Some ssb based devices have a PMU and the PMU watchdog register should
be used instead of the register in the chip common part, if the device
has a PMU. This patch also calculates the maximal number the watchdog
could be set to.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:02 +0000 (18:46 +0100)]
bcma: register watchdog driver
Register the watchdog driver to the system if this is a SoC. Using the
watchdog on a non SoC device, like a PCIe card, will make the PCIe
card die when the timeout expired, but starting it again is not
supported by bcma.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:01 +0000 (18:46 +0100)]
bcma: add methods for watchdog driver
The watchdog driver wants to set the watchdog timeout in ms and not in
ticks, which is depending on the SoC type and the clock.
Calculate the number of ticks per millisecond and provide two functions
for the watchdog driver. Also return the ticks or millisecond the timer
was set to in case the provided value was bigger than the max allowed
value.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:00 +0000 (18:46 +0100)]
bcma: set the pmu watchdog if available
Mostly all bcma based devices have a PMU and the PMU watchdog should be
used and not the old one in chip common. This patch also calculates the
maximal number the watchdog could be set to.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:45:58 +0000 (18:45 +0100)]
ssb/bcma: add common header for watchdog
This adds a common header for watchdog functions, so a watchdog driver
just needs to use this and could provide watchdog functionality for ssb
and bcma based SoCs. Patches for a watchdog driver using this interface
will be send later.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Cc: stable@vger.kernel.org [3.7+] Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
carl9170: explain why sta cannot be NULL for ampdus
Dan Carpenter reported that smatch detected a potential
problem with the code [1]:
drivers/net/wireless/ath/carl9170/tx.c:1488 carl9170_op_tx()
error: we previously assumed 'sta' could be null (see line 1482)
drivers/net/wireless/ath/carl9170/tx.c
1482 if (sta) {
^^^^^ New check.
[...]
1485 }
1487 if (info->flags & IEEE80211_TX_CTL_AMPDU) {
1488 run = carl9170_tx_ampdu_queue(ar, sta, skb);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Old dereference of "sta" inside the call to carl9170_tx_ampdu_queue().
A range of solutions have been discussed in [2] and
we agreed on the following: "
> we might as well add a comment to carl9170_tx_ampdu_queue
> and explain the situation [in a way that's obvious to a
> human reader]. This way we can save the "if"... which is
> a small win since carl9170_op_tx is sort of a hot-path.
Putting a comment there is fine. Without the comment
it's easy for a human reader to get confused why the
check is there. So long as humans can read the code,
that's all that matters."
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
LD drivers/net/wireless/brcm80211/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/fwil.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/fwil.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/fweh.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/fweh.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_common.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/usb.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/usb.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.o
LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.o
LD drivers/net/wireless/brcm80211/brcmsmac/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1311:6: warning: context imbalance in 'brcms_down' - unexpected unlock
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1598:6: warning: context imbalance in 'brcms_rfkill_set_hw_state' - unexpected unlock
CC [M] drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/ampdu.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/antsel.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/antsel.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/channel.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/channel.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/main.c
drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:36: warning: Initializer entry defined twice
drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:43: also defined here
CC [M] drivers/net/wireless/brcm80211/brcmsmac/main.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/pmu.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/pmu.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/rate.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/rate.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/stf.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/stf.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/aiutils.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c:3313:46: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:17688:47: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:18187:53: warning: cast truncates bits from constant value (ffff3fff becomes 3fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:21160:36: warning: cast truncates bits from constant value (ffff3fff becomes 3fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:23321:35: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:28343:44: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/dma.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/dma.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/debug.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/debug.o
LD [M] drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.o
LD drivers/net/wireless/brcm80211/brcmutil/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmutil/utils.c
CC [M] drivers/net/wireless/brcm80211/brcmutil/utils.o
LD [M] drivers/net/wireless/brcm80211/brcmutil/brcmutil.o
Building modules, stage 2.
MODPOST 3 modules
CC drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.mod.o
LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko
CC drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.mod.o
LD [M] drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
CC drivers/net/wireless/brcm80211/brcmutil/brcmutil.mod.o
LD [M] drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko
Cc: Brett Rudley <brudley@broadcom.com> Cc: Roland Vossen <rvossen@broadcom.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com> Cc: Kan Yan <kanyan@broadcom.com> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list@broadcom.com Reported-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge tag 'nfc-fixes-3.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0
This is an NFC LLCP fix for 3.7 and contains only one patch.
It fixes a potential crash when receiving an LLCP HDLC frame acking a frame
that is not the last sent one. In that case we may dereference an already
freed pointer.
Zero copy TX has been around for a while now.
We seem to be down to eliminating theoretical bugs
and performance tuning at this point:
it's probably time to enable it by default so that
most users get the benefit.
Keep the flag around meanwhile so users can experiment
with disabling this if they experience regressions.
I expect that we will remove it in the future.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
For short packets zerocopy mode adds overhead
of managing heads which isn't necessary: we
could simly update used ring directly
same as with zerocopy disabled.
Things seem to run a bit faster if we detect
and bypass head management when zcopy isn't used.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
vhost-net: flush outstanding DMAs on memory change
When memory map changes, we need to flush outstanding
DMAs as they might in theory reference old memory addresses.
To do this simply stop initiating new DMAs
and wait for ubufs ref count to drop to 0.
Afterwards reset the count back to 1.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
vring changes already do a flush internally where appropriate, so we do
not need a second flush.
It's currently not very expensive but a follow-up patch makes flush more
heavy-weight, so remove the extra flush here to avoid regressing
performance if call or kick fds are changed on data path.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Cong Wang [Thu, 6 Dec 2012 02:04:04 +0000 (10:04 +0800)]
net: fix some compiler warning in net/core/neighbour.c
net/core/neighbour.c:65:12: warning: 'zero' defined but not used [-Wunused-variable]
net/core/neighbour.c:66:12: warning: 'unres_qlen_max' defined but not used [-Wunused-variable]
These variables are only used when CONFIG_SYSCTL is defined,
so move them under #ifdef CONFIG_SYSCTL.
Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Cong Wang <amwang@redhat.com> Acked-by: Shan Wei <davidshan@tencent.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 5 Dec 2012 21:24:45 +0000 (16:24 -0500)]
bridge: implement multicast fast leave
V3: make it a flag
V2: make the toggle per-port
Fast leave allows bridge to immediately stops the multicast
traffic on the port receives IGMP Leave when IGMP snooping is enabled,
no timeouts are observed.
Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Stephen Hemminger <shemminger@vyatta.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Cong Wang <amwang@redhat.com>
Eddie Wai [Wed, 5 Dec 2012 10:10:15 +0000 (10:10 +0000)]
cnic: Fix rare race condition during iSCSI disconnect.
If the initiator and target try to close the connection at about the same
time, there is a race condition in the termination sequence for bnx2x.
Fix the problem by waiting for the remote termination to complete before
deleting the Connection ID. This will prevent the firmware assert.
Update version to 2.5.15.
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Shan Wei [Tue, 4 Dec 2012 18:49:15 +0000 (18:49 +0000)]
net: neighbour: prohibit negative value for unres_qlen_bytes parameter
unres_qlen_bytes and unres_qlen are int type.
But multiple relation(unres_qlen_bytes = unres_qlen * SKB_TRUESIZE(ETH_FRAME_LEN))
will cause type overflow when seting unres_qlen. e.g.
The gutted value is not that we setting。
But user/administrator don't know this is caused by int type overflow.
what's more, it is meaningless and even dangerous that unres_qlen_bytes is set
with negative number. Because, for unresolved neighbour address, kernel will cache packets
without limit in __neigh_event_send()(e.g. (u32)-1 = 2GB).
Signed-off-by: Shan Wei <davidshan@tencent.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew Gallatin [Tue, 4 Dec 2012 10:17:15 +0000 (10:17 +0000)]
myri10ge: fix most sparse warnings
- convert remaining htonl/ntohl +__raw_read/__raw_writel to
swab32 + readl/writel
- add missing __iomem qualifier in myri10ge_open()
- fix dubious: x & !y warning by switching from logical to bitwise not
The swab32 conversion fixes a bug in myri10ge_led() where
big-endian machines would write the wrong pattern.
The only remaining warning (lock context imbalance) is due to
the use of __netif_tx_trylock(), and cannot easily be fixed.
Signed-off-by: Andrew Gallatin <gallatin@myri.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Amerigo Wang [Mon, 3 Dec 2012 23:56:40 +0000 (23:56 +0000)]
bridge: implement multicast fast leave
V2: make the toggle per-port
Fast leave allows bridge to immediately stops the multicast
traffic on the port receives IGMP Leave when IGMP snooping is enabled,
no timeouts are observed.
Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Stephen Hemminger <shemminger@vyatta.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Cong Wang <amwang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Serge Hallyn [Mon, 3 Dec 2012 16:17:12 +0000 (16:17 +0000)]
net: dev_change_net_namespace: send a KOBJ_REMOVED/KOBJ_ADD
When a new nic is created in namespace ns1, the kernel sends a KOBJ_ADD uevent
to ns1. When the nic is moved to ns2, we only send a KOBJ_MOVE to ns2, and
nothing to ns1.
This patch changes that behavior so that when moving a nic from ns1 to ns2, we
send a KOBJ_REMOVED to ns1 and KOBJ_ADD to ns2. (The KOBJ_MOVE is still
sent to ns2).
The effects of this can be seen when starting and stopping containers in
an upstart based host. Lxc will create a pair of veth nics, the kernel
sends KOBJ_ADD, and upstart starts network-instance jobs for each. When
one nic is moved to the container, because no KOBJ_REMOVED event is
received, the network-instance job for that veth never goes away. This
was reported at https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589
With this patch the networ-instance jobs properly go away.
The other oddness solved here is that if a nic is passed into a running
upstart-based container, without this patch no network-instance job is
started in the container. But when the container creates a new nic
itself (ip link add new type veth) then network-interface jobs are
created. With this patch, behavior comes in line with a regular host.
v2: also send KOBJ_ADD to new netns. There will then be a
_MOVE event from the device_rename() call, but that should
be innocuous.
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by: Daniel Lezcano <daniel.lezcano@free.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / karo-tx-linux.git / log