- 23 Jan, 2013 25 commits
-
-
Jacob Keller authored
This patch updates the filters for ethtool's get_ts_info to return support for all filters which can be supported by upscaling to ptp_v2_event. The intent behind this change is due to reasoning that we do in fact support the filters. (hwtstamp_ioctl returns success after setting the filter to the upscaled version). In this way we can remain consistent over which filters are supported via the get_ts_info ioctl and which filters are in practice actually supported. 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>
-
Jacob Keller authored
This patch cleans up the ethtool diagnostics test by ensuring that the tests work properly regardless of what state the adapter was in. The SRIOV VF check is done at the beginning, forgoing the link test. The if_running -> dev_close is moved before the link test, as well as a call to enable the Tx laser. This ensures that the link test will return valid results even when adapter was previously down. Also, a call to disable the Tx laser is added if the device was down before the start. This ensures consistent behavior of the Tx laser before and after the diagnostic checks. The end result is consistent behavior regardless of device state. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-nextDavid S. Miller authored
Steffen Klassert says: ==================== 1) Add a statistic counter for invalid output states and remove a superfluous state valid check, from Li RongQing. 2) Probe for asynchronous block ciphers instead of synchronous block ciphers to make the asynchronous variants available even if no synchronous block ciphers are found, from Jussi Kivilinna. 3) Make rfc3686 asynchronous block cipher and make use of the new asynchronous variant, from Jussi Kivilinna. 4) Replace some rwlocks by rcu, from Cong Wang. 5) Remove some unused defines. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Ariel Elior authored
When posting a message on the bulletin board, the PF calculates crc over the message and places the result in the message. When the VF samples the Bulletin Board it copies the message aside and validates this crc. The length of the message is crucial here and must be the same in both parties. Since the PF is running in the Hypervisor and the VF is running in a Vm, they can possibly be of different versions. As the Bulletin Board is designed to grow forward in future versions, in the VF the length must not be the size of the message structure but instead it should be a field in the message itself. Signed-off-by:
Ariel Elior <ariele@broadcom.com> Signed-off-by:
Yuval Mintz <yuvalmin@broadcom.com> Signed-off-by:
-
Yuval Mintz authored
Commit 823e1d90 caused bnx2x to fail once BNX2X_STOP_ON_ERROR is set. Fixes compilation by moving function declarations between header files. Signed-off-by:
-
Michael Chan authored
In INTA mode, cnic and bnx2x share the same IRQ. During chip reset, for example, cnic will stop servicing IRQs after it has shutdown the cnic hardware resources. However, the shared IRQ is still active as bnx2x needs to finish the reset. There is a window when bnx2x does not know that cnic is no longer handling IRQ and things don't always work properly. Add a flag to tell bnx2x that cnic is handling IRQ. The flag is set before the first cnic IRQ is expected and cleared when no more cnic IRQs are expected, so there should be no race conditions. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
Eilon Greenstein <eilong@broadcom.com> Signed-off-by:
-
Yuval Mintz authored
Fix an incorrect SR-IOV memory release which was committed in 1ab4434c. Signed-off-by:
-
Yuval Mintz authored
Remove most of the sparse warnings in the bnx2x compilation (i.e., thus resulting when compiling with `C=2 CF=-D__CHECK_ENDIAN__'). Signed-off-by:
-
Yuval Mintz authored
Don't unload the bnx2x driver if its in a recovery process, or if the previous load have failed. Signed-off-by:
-
Dmitry Kravkov authored
Since commit 15192a8c there have been a memory leak upon rmmod of the bnx2x driver. This corrects the memory leak and corrects the zeroing of internal memories upon driver load. Signed-off-by:
Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by:
-
Yuval Mintz authored
Add missing 57712_VF and 57800_VF to CHIP_IS_E2 and CHIP_IS_E3 macros (missing from commit 8395be5e). Signed-off-by:
-
Yuval Mintz authored
Add/Revise several debug prints in the bnx2x driver - on regular flows as well as error flows. Signed-off-by:
-
Yuval Mintz authored
Change the incorrect usage of `usleep_range(1000, 1000)' into `usleep_range(1000, 2000)'. Signed-off-by:
-
Yuval Mintz authored
Slightly changes the bnx2x code without `true' functional changes. Changes include: 1. Gathering macros into a single macro when combination is used multiple times. 2. Exporting parts of functions into their own functions. 3. Return values after if-else instead of only on the else condition (where current flow would simply return same value later in the code) 4. Removing some unnecessary code (either dead-code or incorrect conditions) Signed-off-by: -
Yuval Mintz authored
Mostly corrects white spaces, indentations, and comments. Signed-off-by:
-
Claudiu Manoil authored
Reactivate promiscuous mode in H/W upon gfar_init_mac(), if the net dev requires it (IFF_PROMISC flag set). This way the promisc mode is preserved accross device reset conditions like tx timeout, device restore, a.s.o. Signed-off-by:
Voncken C Acksys <cedric.voncken@acksys.fr> Signed-off-by:
Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by:
-
David S. Miller authored
Tom Herbert says: ==================== This series implements so_reuseport (SO_REUSEPORT socket option) for TCP and UDP. For TCP, so_reuseport allows multiple listener sockets to be bound to the same port. In the case of UDP, so_reuseport allows multiple sockets to bind to the same port. To prevent port hijacking all sockets bound to the same port using so_reuseport must have the same uid. Received packets are distributed to multiple sockets bound to the same port using a 4-tuple hash. The motivating case for so_resuseport in TCP would be something like a web server binding to port 80 running with multiple threads, where each thread might have it's own listener socket. This could be done as an alternative to other models: 1) have one listener thread which dispatches completed connections to workers. 2) accept on a single listener socket from multiple threads. In case #1 the listener thread can easily become the bottleneck with high connection turn-over rate. In case #2, the proportion of connections accepted per thread tends to be uneven under high connection load (assuming simple event loop: while (1) { accept(); process() }, wakeup does not promote fairness among the sockets. We have seen the disproportion to be as high as 3:1 ratio between thread accepting most connections and the one accepting the fewest. With so_reusport the distribution is uniform. The TCP implementation has a problem in that the request sockets for a listener are attached to a listener socket. If a SYN is received, a listener socket is chosen and request structure is created (SYN-RECV state). If the subsequent ack in 3WHS does not match the same port by so_reusport, the connection state is not found (reset) and the request structure is orphaned. This scenario would occur when the number of listener sockets bound to a port changes (new ones are added, or old ones closed). We are looking for a solution to this, maybe allow multiple sockets to share the same request table... The motivating case for so_reuseport in UDP would be something like a DNS server. An alternative would be to recv on the same socket from multiple threads. As in the case of TCP, the load across these threads tends to be disproportionate and we also see a lot of contection on the socket lock. Note that SO_REUSEADDR already allows multiple UDP sockets to bind to the same port, however there is no provision to prevent hijacking and nothing to distribute packets across all the sockets sharing the same bound port. This patch does not change the semantics of SO_REUSEADDR, but provides usable functionality of it for unicast. ==================== Signed-off-by: -
Tom Herbert authored
Motivation for soreuseport would be something like a DNS server. An alternative would be to recv on the same socket from multiple threads. As in the case of TCP, the load across these threads tends to be disproportionate and we also see a lot of contection on the socket lock. Note that SO_REUSEADDR already allows multiple UDP sockets to bind to the same port, however there is no provision to prevent hijacking and nothing to distribute packets across all the sockets sharing the same bound port. This patch does not change the semantics of SO_REUSEADDR, but provides usable functionality of it for unicast. Signed-off-by:
Tom Herbert <therbert@google.com> Signed-off-by:
-
Tom Herbert authored
Motivation for soreuseport would be something like a web server binding to port 80 running with multiple threads, where each thread might have it's own listener socket. This could be done as an alternative to other models: 1) have one listener thread which dispatches completed connections to workers. 2) accept on a single listener socket from multiple threads. In case #1 the listener thread can easily become the bottleneck with high connection turn-over rate. In case #2, the proportion of connections accepted per thread tends to be uneven under high connection load (assuming simple event loop: while (1) { accept(); process() }, wakeup does not promote fairness among the sockets. We have seen the disproportion to be as high as 3:1 ratio between thread accepting most connections and the one accepting the fewest. With so_reusport the distribution is uniform. Signed-off-by: -
Tom Herbert authored
Allow multiple UDP sockets to bind to the same port. Motivation soreuseport would be something like a DNS server. An alternative would be to recv on the same socket from multiple threads. As in the case of TCP, the load across these threads tends to be disproportionate and we also see a lot of contection on the socketlock. Note that SO_REUSEADDR already allows multiple UDP sockets to bind to the same port, however there is no provision to prevent hijacking and nothing to distribute packets across all the sockets sharing the same bound port. This patch does not change the semantics of SO_REUSEADDR, but provides usable functionality of it for unicast. Signed-off-by:
-
Tom Herbert authored
Allow multiple listener sockets to bind to the same port. Motivation for soresuseport would be something like a web server binding to port 80 running with multiple threads, where each thread might have it's own listener socket. This could be done as an alternative to other models: 1) have one listener thread which dispatches completed connections to workers. 2) accept on a single listener socket from multiple threads. In case #1 the listener thread can easily become the bottleneck with high connection turn-over rate. In case #2, the proportion of connections accepted per thread tends to be uneven under high connection load (assuming simple event loop: while (1) { accept(); process() }, wakeup does not promote fairness among the sockets. We have seen the disproportion to be as high as 3:1 ratio between thread accepting most connections and the one accepting the fewest. With so_reusport the distribution is uniform. Signed-off-by: -
Tom Herbert authored
Definitions and macros for implementing soreusport. Signed-off-by:
-
Matt Wilson authored
Sometimes it is useful to be able to change the MAC address of the interface for netback devices. For example, when using ebtables it may be useful to be able to distinguish traffic from different interfaces without depending on the interface name. Reported-by:
Nikita Borzykh <sample.n@gmail.com> Reported-by:
Paul Harvey <stockingpaul@hotmail.com> Cc: netdev@vger.kernel.org Cc: xen-devel@lists.xen.org Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
Matt Wilson <msw@amazon.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Cong Wang authored
Fengguang reported: net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:1049:6: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] in !CONFIG_IPV6 case, we may error out without initializing 'err'. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
Cong Wang <amwang@redhat.com> Signed-off-by:
-
Cong Wang authored
It is declared in: include/net/ip6_route.h:187:int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *)); and net/ip6_route.h is already included. Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
- 22 Jan, 2013 15 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linuxDavid S. Miller authored
Paul Gortmaker says: ==================== The Ethernet-HowTo was maintained for roughly 10 years, from 1993 to 2003. Fortunately sane hardware probing and auto detection (via PCI and ISA/PnP) largely made the document a relic of the past, hence it being abandoned a decade ago. However, there is one last useful thing that we can extract from the effort made in maintaining that document. We can use it to guide us with respect to what rare, experimental and/or super ancient 10Mbit ISA drivers don't make sense to maintain in-tree anymore. Nobody will argue that ISA is obsolete. Availability went away at about the time Pentium3 motherboards moved from 500MHz Slot1/SECC processors to the green 500MHz Socket 370 Pentium3 chips, at the turn of the century. In theory, it is possible that someone could still be running one of these 12+ year old P3 machines and want 3.9+ bleeding edge kernels (but unlikely). In light of the above (remote) possibility, we can defer the removal of some ISA network drivers that were highly popular and well tested. Typically that means the stuff more from the mid to late '90s, some with ISA PnP support, like the 3c509, the wd/SMC 8390 based stuff, PCnet/lance etc. But a lot of other drivers, typically from the early 1990s were for rare hardware, and experimental (to the point of requiring a cron job that would do a test ping, and then ifconfig down/up and/or a rmmod/insmod!). And some of these drivers (znet, and lp486e to name two) are physically tied to platforms with on motherboard ethernet -- of 486 machines that date from the early 1990s and can only have single digit amounts of memory. What I'd like to achieve here with this series, is to get rid of those old drivers that are no longer being used. In an earlier discussion where I'd proposed deleting a single driver, Alan suggested we instead dump all the historical stuff in one go, to make it "...immediately obvious where the break point is..."[1] and that it was "perfectly reasonable it (and a pile of other ISA cards) ought to be shown the door"[2]. So that is the goal here - make a clear line in the sand where the really ancient stuff finally gets kicked to the curb. Two old parallel port drivers are considered for removal here as well, since in early 386/486 ISA machines, the parallel port was typically found with the UARTS on the multi-I/O ISA controller card. These drivers also date from the early 1990's; parallel ports are no longer found on modern boards, and their performance was not even capable of 10% of 10Mbit bandwidth. Allow me a preemptive justification against the inevitable comments from well meaning bystanders who suggest "why not just leave all this alone?". Dead drivers cost us all if they are left in tree. If you think that is false, then please first consider: -every time you type "git status", you are checking to see if modifications have been made by you to all that dead code. -every time you type "git grep <regex>" you are searching through files which contain that dead code that simply does not interest you. -every time you build a "allyesconfig" and an "allmodconfig" (don't tell me you skip this step before submitting your changes to a maintainer), you waste CPU cycles building this dead code. -every time there is a tree wide API change, or cleanup, or file relocation, we pay the cost of updating dead code, or moving dead code. -daily regression tests (take linux-next as the most transparent example) spend time building (and possibly running) this dead code. -hard working people who regularly run auditing tools looking for lurking bugs (sparse/coverity/smatch/coccinelle) are wasting time checking for, and fixing bugs in this dead code. This last one is key. Please take a look at the git history for the files that are proposed for removal here. Look at the git history for any one of them ("git whatchanged --follow drivers/net/.../driver.c") Mentally sort the changes into two bins -- (1) the robotic tree-wide changes, and (2) the "look I found a real run-time bug while using this" category. You will see that category #2 is essentially empty. Further to that, realize that drivers don't simply disappear. We are not operating in the binary-only distribution space like other OS. All these drivers remain in the git history forever. If a person is an enthusiast for extreme legacy hardware, they are probably already customizing their kernel source and building it themselves to support such systems. Also keep in mind that they could still build the 3.8 kernel exactly as-is, and run it (or a 3.8.x stable variant of it) for several more years if they were really determined to cling to these old experimental ISA drivers for some reason. In summary, I hope that folks can be pragmatic about this, and not get swept up in nostalgia. Ask yourself whether it is realistic to expect a person would have a genuine use case where they would need to build a 3.9+ modern kernel and install it on some legacy hardware that has no option but to absolutely _require_ one of the drivers that are deleted here. The following series was created with --irreversible-delete for ease of review (it skips showing the content of files that are deleted); however the complete patches can be pulled as per below. ==================== Signed-off-by: -
YOSHIFUJI Hideaki / 吉藤英明 authored
Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
YOSHIFUJI Hideaki / 吉藤英明 authored
Signed-off-by:
-
YOSHIFUJI Hideaki / 吉藤英明 authored
Signed-off-by:
-
YOSHIFUJI Hideaki / 吉藤英明 authored
Signed-off-by:
-
YOSHIFUJI Hideaki / 吉藤英明 authored
Since we have removed NCE (Neighbour Cache Entry) reference from routing entries, the only refcnt holders of an NCE are its timer (if running) and its owner table, in usual cases. As a result, neigh_periodic_work() purges NCEs over and over again even for gateways. It does not make sense to purge entries, if number of them is very small, so keep them. The minimum number of entries to keep is specified by gc_thresh1. Signed-off-by:
-
Nicolas Dichtel authored
mfc_mcastgrp and mfc_origin are __be32, thus we need to convert INADDR_ANY. Because INADDR_ANY is 0, this patch just fix sparse warnings. Reported-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Paul Gortmaker authored
The last update to the Ethernet HowTo (over 10 years ago) listed this: ------------------------ SEEQ 8005 Status: Obsolete, Driver Name: seeq8005 There is little information about the card included in the driver, and hence little information to be put here. If you have a question, you are probably best trying to e-mail the driver author as listed in the source. It was marked obsolete as of the 2.4 series kernels. ------------------------ If it was obsolete over a decade ago, the situation can not have improved with the passage of time, so let us act on that. Even with today's improved search engines, I was unable to locate any real meaningful information on the ISA implementation of this rare chip. There are ARM and SGI variants of the driver in tree, but they do not depend on the original x86 driver source or header file. We leave those non-x86 drivers to be deleted by the arch maintainers when they decide to expire those legacy platforms as a whole. Signed-off-by:Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
This is another one that makes sense to target for obsolescence, since it (a)appeared pre-1995, and (b)was rather rare, and (c)did not really have any statistically significant active linux user base. Removing this ISA 10Mbit driver support is unlikely to be even noticed by the user base of 3.9+ linux kernels, especially when the documentation clearly indicates the vintage with this text: "...designed to work with all kernels > 1.1.33" Signed-off-by: -
Paul Gortmaker authored
These are old ISA 10Mbit cards from the 1st 1/2 of the 1990s and required manual jumper settings in order to configure them. Here we remove them on the premise that they are no longer used in any modern 3.9+ kernels. Signed-off-by: -
Paul Gortmaker authored
This is an area I know all too well, after being author of several 8390 drivers, and maintainer of all 8390 drivers during a large part of their active lifecycle. To that end, I can say this with a reasonable degree of confidence. The drivers deleted here represent the earliest (as in early 1990) hardware and/or rare hardware. The remaining hardware not deleted here is the more modern/sane of the lot, with ISA-PnP and jumperless "soft configuration" like the wd and smc cards had. The original ne2000 driver (ne.c) gets a pass at this time since AT/LANTIC based cards that could be both ne2000 or wd-like (with shared memory) and with jumperless configuration were made in the mid to late 1990's, and performed reasonably well for their era. Signed-off-by: -
Paul Gortmaker authored
This is another driver for relatively rare 10Mbit hardware that originated in the early 1990's. So we select it for removal at this point in time as well. Cc: Mika Kuoppala <miku@iki.fi> Signed-off-by: -
Paul Gortmaker authored
These Fujitsu MB86965 based ISA 10Mbit cards were another of the relatively rare cards dating from the early 1990s that for one reason or another didn't seem to get a lot of use in linux. So we retire it now with a reasonable degree of confidence that it won't impact anyone. Signed-off-by: -
Paul Gortmaker authored
These cards were only available in 8bit format, and in addition they only had AUI and BNC(10-Base2) interfaces (i.e. no RJ-45). In fact, they are so rare, that an internet search on these old cards almost comes up empty, unless the "Micom interlan" name is used. This puts them in the equivalent domain as the 3c501, so there should be no strong opposition to the driver removal, as nobody is seriously using 3.9+ with 8 bit ISA hardware. In doing so, the whole "ethernet/racal" category becomes empty, so we clean up the Makefile/Kconfig and subdir appropriately. Cc: Andreas Mohr <andi@lisas.de> Cc: Jan-Pascal van Best <janpascal@vanbest.org> Signed-off-by: -
Paul Gortmaker authored
Like the other drivers that were in the ISA i825xx family, the ni52 was rather rare, not widely used, and hence perhaps not as reliable as the more mainstream ISA drivers that were heavily used. Given that, it is chosen for retirement at this time as well. Signed-off-by:
-
