- 02 Mar, 2009 33 commits
-
-
Inaky Perez-Gonzalez authored
Firmware interface version 8.x.x has long been deprecated and is no longer supported (nor available, as it is a preproduction firmware), so it can be safely dropped. Add support for firmware interface v9.2.x (current is 9.1.x). Firmware version 9.2.x is backwards compatible with 9.1.x; new features are enabled if switches are pressed to turn them on. Forthcoming commits to the driver will start pressing those switches when the firmware interface supports it. Signed-off-by:
Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Inaky Perez-Gonzalez authored
In order to support backwards compatibility with older firmwares when a driver is updated by a new kernel release, the i2400m bus drivers can declare a list of firmware files they can work with (in general these will be each a different version). The firmware loader will try them in sequence until one loads. Thus, if a user doesn't have the latest and greatest firmware that a newly installed kernel would require, the driver would fall back to the firmware from a previous release. To support this, the i2400m->bus_fw_name is changed to be a NULL terminated array firmware file names (and renamed to bus_fw_names) and we add a new entry (i2400m->fw_name) that points to the name of the firmware being currently used. All code that needs to print the firmware file name uses i2400m->fw_name instead of the old i2400m->bus_fw_name. The code in i2400m_dev_bootstrap() that loads the firmware is changed with an iterator over the firmware file name list that tries to load each form user space, using the first one that succeeds in request_firmware() (and thus stopping the iteration). The USB and SDIO bus drivers are updated to take advantage of this and reflect which firmwares they support. Signed-off-by:
-
Gerrit Renker authored
This fixes a problem caused by the overlap of the connection-setup and established-state phases of DCCP connections. During connection setup, the client retransmits Confirm Feature-Negotiation options until a response from the server signals that it can move from the half-established PARTOPEN into the OPEN state, whereupon the connection is fully established on both ends (RFC 4340, 8.1.5). However, since the client may already send data while it is in the PARTOPEN state, consequences arise for the Maximum Packet Size: the problem is that the initial option overhead is much higher than for the subsequent established phase, as it involves potentially many variable-length list-type options (server-priority options, RFC 4340, 6.4). Applying the standard MPS is insufficient here: especially with larger payloads this can lead to annoying, counter-intuitive EMSGSIZE errors. On the other hand, reducing the MPS available for the established phase by the added initial overhead is highly wasteful and inefficient. The solution chosen therefore is a two-phase strategy: If the payload length of the DataAck in PARTOPEN is too large, an Ack is sent to carry the options, and the feature-negotiation list is then flushed. This means that the server gets two Acks for one Response. If both Acks get lost, it is probably better to restart the connection anyway and devising yet another special-case does not seem worth the extra complexity. The result is a higher utilisation of the available packet space for the data transmission phase (established state) of a connection. The patch (over-)estimates the initial overhead to be 32*4 bytes -- commonly seen values were around 90 bytes for initial feature-negotiation options. It uses sizeof(u32) to mean "aligned units of 4 bytes". For consistency, another use of 4-byte alignment is adapted. Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
-
Gerrit Renker authored
This patch resolves a long-standing FIXME to dynamically update the Maximum Packet Size depending on actual options usage. It uses the flags set by the feature-negotiation infrastructure to compute the required header option size. Most options are fixed-size, a notable exception are Ack Vectors (required currently only by CCID-2). These can have any length between 3 and 1020 bytes. As a result of testing, 16 bytes (2 bytes for type/length plus 14 Ack Vector cells) have been found to be sufficient for loss-free situations. There are currently no CCID-specific header options which may appear on data packets, thus it is not necessary to define a corresponding CCID field as suggested in the old comment. Further changes: ---------------- Adjusted the type of 'cur_mps' to match the unsigned return type of the function. Signed-off-by:
Ian McDonald <ian.mcdonald@jandi.co.nz> Signed-off-by:
-
Ilpo Järvinen authored
I guess these fields were one day 16-bit in the struct but nowadays they're just using 8 bits anyway. This is just a precaution, didn't result any change in my case but who knows what all those varying gcc versions & options do. I've been told that 16-bit is not so nice with some cpus. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Ilpo Järvinen authored
copied was assigned zero right before the goto, so if (copied) cannot ever be true. Signed-off-by:
-
Ilpo Järvinen authored
Also fixes insignificant bug that would cause sending of stale SACK block (would occur in some corner cases). Signed-off-by:
-
Ilpo Järvinen authored
It seems that implementation in yeah was inconsistent to what other did as it would increase cwnd one ack earlier than the others do. Size benefits: bictcp_cong_avoid | -36 tcp_cong_avoid_ai | +52 bictcp_cong_avoid | -34 tcp_scalable_cong_avoid | -36 tcp_veno_cong_avoid | -12 tcp_yeah_cong_avoid | -38 = -104 bytes total Signed-off-by:
-
Ilpo Järvinen authored
Similar to what is done elsewhere in TCP code when double state checks are being done. Signed-off-by:
-
Ilpo Järvinen authored
Signed-off-by:
-
Ilpo Järvinen authored
Redundant checks made indentation impossible to follow. However, it might be useful to make this ca_state+is_sack indexed array. Signed-off-by:
-
Ilpo Järvinen authored
Some comment about its current state added. So far I have seen very few cases where the thing is actually useful, usually just marginally (though admittedly I don't usually see top of window losses where it seems possible that there could be some gain), instead, more often the cases suffer from L-marking spike which is certainly not desirable (I'll bury improving it to my todo list, but on a low prio position). Signed-off-by:
-
Ilpo Järvinen authored
Arnd Hannemann <hannemann@nets.rwth-aachen.de> noticed and was puzzled by the fact that !tcp_is_fack(tp) leads to early return near the beginning and the later on tcp_is_fack(tp) was still used in an if condition. The later check was a left-over from RFC3517 SACK stuff (== !tcp_is_fack(tp) behavior nowadays) as there wasn't clear way how to handle this particular check cheaply in the spirit of RFC3517 (using only SACK blocks, not holes + SACK blocks as with FACK). I sort of left it there as a reminder but since it's confusing other people just remove it and comment the missing-feature stuff instead. Signed-off-by:
-
Ilpo Järvinen authored
If cur_mss grew very recently so that the previously G/TSOed skb now fits well into a single segment it would get send up in parts unless we calculate # of segments again. This corner-case could happen eg. after mtu probe completes or less than previously sack blocks are required for the opposite direction. Signed-off-by:
-
Ilpo Järvinen authored
1) We didn't remove any skbs, so no need to handle stale refs. 2) scoreboard_skb_hint is trivial, no timestamps were changed so no need to clear that one 3) lost_skb_hint needs tweaking similar to that of tcp_sacktag_one(). Signed-off-by:
-
Ilpo Järvinen authored
If skb can be sent right away, we certainly should do that if it's in the middle of the queue because it won't get more data into it. Signed-off-by:
-
Ilpo Järvinen authored
It is possible that lost_cnt_hint gets underflow in tcp_clean_rtx_queue because the cumulative ACK can cover the segment where lost_skb_hint points to only partially, which means that the hint is not cleared, opposite to what my (earlier) comment claimed. Also I don't agree what I ended up writing about non-trivial case there to be what I intented to say. It was not supposed to happen that the hint won't get cleared and we underflow in any scenario. In general, this is quite hard to trigger in practice. Signed-off-by:
-
Ilpo Järvinen authored
Backtracking to sacked skbs is a horrible performance killer since the hint cannot be advanced successfully past them... ...And it's totally unnecessary too. In theory this is 2.6.27..28 regression but I doubt anybody can make .28 to have worse performance because of other TCP improvements. Signed-off-by:
-
Guo-Fu Tseng authored
From: Guo-Fu Tseng <cooldavid@cooldavid.org> Advance version number after previous changes. Sorry for not come along with previous patch series. Signed-off-by: -
David S. Miller authored
Noticed by David Dillow. Signed-off-by: -
David S. Miller authored
As reported by Stephen Rothwell. > Today's linux-next build (powerpc allyesconfig) failed like this: > > net/rds/cong.c: In function 'rds_cong_set_bit': > net/rds/cong.c:284: error: implicit declaration of function 'generic___set_le_bit' > net/rds/cong.c: In function 'rds_cong_clear_bit': > net/rds/cong.c:298: error: implicit declaration of function 'generic___clear_le_bit' > net/rds/cong.c: In function 'rds_cong_test_bit': > net/rds/cong.c:309: error: implicit declaration of function 'generic_test_le_bit' Signed-off-by: -
David S. Miller authored
Conflicts: drivers/net/wireless/iwlwifi/iwl-tx.c net/8021q/vlan_core.c net/core/dev.c
-
Dmitriy Taychenachev authored
The Motorola MOTOMAGX phones (Z6, E8, Zn5 so far) are providing combined ACM/BLAN USB configuration. Since it has Vendor Specific class, the corresponding drivers (cdc-acm, zaurus) can't find it just by interface info. This patch adds usb id so the zaurus driver can properly handle this combined device. Signed-off-by:
Dmitriy Taychenachev <dimichxp@gmail.com> Signed-off-by:
-
Bjørn Mork authored
Make usbnet_get_link() fall back to ethtool_op_get_link() instead of defaulting to 1. This makes usbnet_get_link return valid results without the need for a driver specific check_connect or mii ops as long as the driver calls netif_carrier_{on,off}() as appropriate. cdc_ether is an example of such a driver. Signed-off-by:Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Eric W. Biederman authored
The current implementation of carrier detect in veth is broken. It reports the link is down until both sides of the veth pair are administatively up and then forever after it reports link up. So fix veth so that it only reports link up when both interfaces of the pair are administratively up. Signed-off-by:
Eric Biederman <ebiederm@aristanetworks.com> Signed-off-by:
-
Bjørn Mork authored
The Ericsson F3507g wireless broadband module provides a CDC Ethernet compliant interface, but identifies it as a "Mobile Direct Line" CDC subclass, thereby preventing the CDC Ethernet class driver from picking it up. This patch adds the device id to cdc_ether.c as a workaround. Ericsson has provided a "class" driver for this device: http://kerneltrap.org/mailarchive/linux-net/2008/10/28/3832094 But closer inspection of that driver reveals that it adds little more than duplication of code from cdc_ether.c. See also http://marc.info/?l=linux-usb&m=123334979706403&w=2Signed-off-by:
-
Guo-Fu Tseng authored
All JMC250 chips have no problem with higher bits support. Adding it back. Found-by:
Ethan Hsiao <ethanhsiao@jmicron.com> Signed-off-by:
Guo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by:
-
Guo-Fu Tseng authored
Clear all modified GHC register flags. Fixed-by:
-
Guo-Fu Tseng authored
We should sync ring descriptor to pci device after modifying it. Signed-off-by:
-
Guo-Fu Tseng authored
This patch modifies messages to display correct hardware version. Signed-off-by:
-
Ivan Vecera authored
This is 2nd attempt to implement the initialization/reading of MAC address from EEPROM. The first used PCI's VPD and there were some problems, some devices are not able to read EEPROM content by VPD. The 2nd one uses direct access to EEPROM through bit-banging interface and my testing results seem to be much better. I tested 5 systems each with different Realtek NICs and I didn't find any problem. AFAIK Francois's NICs also works fine. Original description: This fixes the problem when MAC address is set by ifconfig or by ip link commands and this address is stored in the device after reboot. The power-off is needed to get right MAC address. This is problem when Xen daemon is running because it renames the device name from ethX to pethX and sets its MAC address to FE:FF:FF:FF:FF:FF. After reboot the device is still using FE:FF:FF:FF:FF:FF. Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Signed-off-by:
-
David S. Miller authored
'pap' is never used in ixgbe_dcb_hw_config_82599() and 'eec' in ixgbe_acquire_eeptom() is only used when status == 0 but GCC has some trouble seeing that. Signed-off-by: -
David S. Miller authored
request_firmware() gives vmalloc'd memory, which is not suitable for pci_map_single() and friends. Use a kmalloc()'d copy of the firmware for this DMA operation. Signed-off-by:
-
- 01 Mar, 2009 7 commits
-
-
PJ Waskiewicz authored
With the hardware-specific code in place, add all supported device id's, along with base driver changes to enable 82599 devices. The devices being enabled are: 8086:10f7: 82599EB 10 Gigabit KX4 Network Connection 8086:10fb: 82599EB 10 Gigabit Network Connection The device 8086:10fb is a fully-pluggable SFP+ NIC. Signed-off-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
PJ Waskiewicz authored
This patch adds the DCB (Data Center Bridging) support for 82599 hardware. This is similar to how the 82598 DCB code works. This patch also removes the BCN (Backwards Congestion Notification) netlink configuration code from the driver. BCN was a pre-standard congestion notification framework, and was not what the IEEE body decided upon for standard congestion management. QCN (802.1Qau), Quantized Congestion Notification is the accepted standard, which is not supported by 82599, hence we remove the support altogether. Signed-off-by:
-
PJ Waskiewicz authored
This patch adds the hardware initialization code specific to 82599. This is similar to the 82598 hardware initialization code. It also includes all changes to the existing hardware init code to support 82599. Signed-off-by:
-
Ilpo Järvinen authored
There's conflicting assumptions in shifting, the caller assumes that dupsack results in S'ed skbs (or a part of it) for sure but never gave a hint to tcp_sacktag_one when dsack is actually in use. Thus DSACK retrans_out -= pcount was not taken and the counter became out of sync. Remove obstacle from that information flow to get DSACKs accounted in tcp_sacktag_one as expected. Signed-off-by:
Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by:
-
Chris Leech authored
The DCB netlink interface is required for building the userspace tools available at e1000.sourceforge.net Signed-off-by:
Chris Leech <christopher.leech@intel.com> Signed-off-by:
-
Chris Leech authored
1) add an include for <linux/types.h> 2) change dcbmsg.dcb_family from unsigned char to __u8 to be more consistent with use of kernel types Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Herbert Xu authored
The netpoll entry checks are required to ensure that we don't receive normal packets when invoked via netpoll. Unfortunately it only ever worked for the netif_receive_skb/netif_rx entry points. The VLAN (and subsequently GRO) entry point didn't have the check and therefore can trigger all sorts of weird problems. This patch adds the netpoll check to all entry points. I'm still uneasy with receiving at all under netpoll (which apparently is only used by the out-of-tree kdump code). The reason is it is perfectly legal to receive all data including headers into highmem if netpoll is off, but if you try to do that with netpoll on and someone gets a printk in an IRQ handler you're going to get a nice BUG_ON. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
