- 07 Aug, 2017 20 commits
-
-
Intiyaz Basha authored
There's supposed to be a one-to-one correspondence between the 18 macros that #define the OCT_DEV states (in octeon_device.h) and the strings in the oct_dev_state_str array, but there are only 14 strings in the array. Add the missing strings (so they become 18 in total), and also revise some incorrect/outdated text of existing strings. Signed-off-by:
Intiyaz Basha <intiyaz.basha@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Russell King says: ==================== phylink and sfp support This patch series introduces generic support for SFP sockets found on various Marvell based platforms. The idea here is to provide common SFP socket support which can be re-used by network drivers as appropriate, rather than each network driver having to re-implement SFP socket support. SFP sockets typically use other system resources, eg, I2C buses to read identifying information, and GPIOs to monitor socket state and control the socket. Meanwhile, some network drivers drive multiple ethernet ports from one instantiation of the driver. It is not desirable to block the initialisation of a network driver (thus denying other ports from being operational) if the resources for the SFP socket are not yet available. This means that an element of independence between the SFP support code and the driver is required. More than that, SFP modules effectively bring hotplug PHYs to networking - SFP copper modules normally contain a standard PHY accessed over the I2C bus, and it is desirable to read their state so network drivers can be appropriately configured. To add to the complexity, SFP modules can be connected in at least two places: 1. Directly to the serdes output of a MAC with no intervening PHY. For example: mvneta ----> SFP socket 2. To a PHY, for example: mvpp2 ---> PHY ---> copper | `-----> SFP socket This code supports both setups, although it's not fully implemented with scenario (2). Moreover, the link presented by the SFP module can be one of the 10Gbase-R family (for SFP+ sockets), SGMII or 1000base-X (for SFP sockets) depending on the module, and network drivers need to reconfigure themselves accordingly for the link to come up. For example, if the MAC is configured for SGMII and a fibre module is plugged in, the link won't come up until the MAC is reconfigured for 1000base-X mode. The SFP code manages the SFP socket - detecting the module, reading the identifying information, and managing the control and status signals. Importantly, it disables the SFP module transmitter when the MAC is down, so that the laser is turned off (but that is not a guarantee.) phylink provides the mechanisms necessary to manage the link modes, based on the SFP module type, and supports hot-plugging of the PHY without needing the MAC driver to be brought up and down on transitions. phylink also supports the classical static PHY and fixed-link modes. I currently (but not included in this series) have code to convert mvneta to use phylink, and the out of tree mvpp2x driver. I have nothing for the mvpp2 driver at present as that driver is only recently becoming functional on 10G hardware, and is missing a lot of features that are necessary to make things work correctly. ==================== Signed-off-by: -
Russell King authored
Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
Add in-band autonegotation support for 10GBase-KR mode. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King authored
Add support for reading and writing the clause 45 MII registers. Signed-off-by:
-
Russell King authored
Add support for reading module EEPROMs through phylink. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Russell King authored
Signed-off-by:
-
Russell King authored
The link between the ethernet MAC and its PHY has become more complex as the interface evolves. This is especially true with serdes links, where the part of the PHY is effectively integrated into the MAC. Serdes links can be connected to a variety of devices, including SFF modules soldered down onto the board with the MAC, a SFP cage with a hotpluggable SFP module which may contain a PHY or directly modulate the serdes signals onto optical media with or without a PHY, or even a classical PHY connection. Moreover, the negotiation information on serdes links comes in two varieties - SGMII mode, where the PHY provides its speed/duplex/flow control information to the MAC, and 1000base-X mode where both ends exchange their abilities and each resolve the link capabilities. This means we need a more flexible means to support these arrangements, particularly with the hotpluggable nature of SFP, where the PHY can be attached or detached after the network device has been brought up. Ethtool information can come from multiple sources: - we may have a PHY operating in either SGMII or 1000base-X mode, in which case we take ethtool/mii data directly from the PHY. - we may have a optical SFP module without a PHY, with the MAC operating in 1000base-X mode - the ethtool/mii data needs to come from the MAC. - we may have a copper SFP module with a PHY whic can't be accessed, which means we need to take ethtool/mii data from the MAC. Phylink aims to solve this by providing an intermediary between the MAC and PHY, providing a safe way for PHYs to be hotplugged, and allowing a SFP driver to reconfigure the serdes connection. Phylink also takes over support of fixed link connections, where the speed/duplex/flow control are fixed, but link status may be controlled by a GPIO signal. By avoiding the fixed-phy implementation, phylink can provide a faster response to link events: fixed-phy has to wait for phylib to operate its state machine, which can take several seconds. In comparison, phylink takes milliseconds. Signed-off-by:
-
Russell King authored
Add an I2C MDIO bus bridge library, to allow phylib to access PHYs which are connected to an I2C bus instead of the more conventional MDIO bus. Such PHYs can be found in SFP adapters and SFF modules. Since PHYs appear at I2C bus address 0x40..0x5f, and 0x50/0x51 are reserved for SFP EEPROMs/diagnostics, we must not allow the MDIO bus to access these I2C addresses. Signed-off-by:
-
Russell King authored
phylink will need phy_start_machine exported, so lets export it as a GPL symbol. Documentation/networking/phy.txt indicates that this should be a PHY API function. Reviewed-by:
-
Russell King authored
Sometimes, we need to do additional work between the PHY coming up and marking the carrier present - for example, we may need to wait for the PHY to MAC link to finish negotiation. This changes phylib to provide a notification function pointer which avoids the built-in netif_carrier_on() and netif_carrier_off() functions. Standard ->adjust_link functionality is provided by hooking a helper into the new ->phy_link_change method. Reviewed-by:
-
Russell King authored
Add the missing 1000Base-X entry to the phy settings table. This was not included because the original code could not cope with more than 32 bits of link mode mask. Signed-off-by:
-
Russell King authored
phy_lookup_setting() provides useful functionality in ethtool code outside phylib. Move it to phy-core and allow it to be re-used (eg, in phylink) rather than duplicated elsewhere. Note that this supports the larger linkmode space. As we move the phy settings table, we also need to move the guts of phy_supported_speeds() as well. Signed-off-by:
-
Russell King authored
Other code would like to make use of this, so make the speed and duplex string generation visible, and place it in a separate file. Signed-off-by:
-
Russell King authored
Allow the phy settings table to support more than 32 link modes by switching to the ethtool link mode bit number representation, rather than storing the mask. This will allow phylink and other ethtool code to share the settings table to look up settings. Signed-off-by:
-
David S. Miller authored
Paolo Abeni says: ==================== IP: cleanup LSRR option processing The __ip_options_echo() function expect a valid dst entry in skb->dst; as result we sometimes need to preserve the dst entry for the whole IP RX path. The current usage of skb->dst looks more a relic from ancient past that a real functional constraint. This patchset tries to remove such usage, and than drops some hacks currently in place in the IP code to keep skb->dst around. __ip_options_echo() uses of skb->dst for two different purposes: retrieving the netns assicated with the skb, and modify the ingress packet LSRR address list. The first patch removes the code modifying the ingress packet, and the second one provides an explicit netns argument to __ip_options_echo(). The following patches cleanup the current code keeping arund skb->dst for __ip_options_echo's sake. Updating the __ip_options_echo() function has been previously discussed here: http://marc.info/?l=linux-netdev&m=150064533516348&w=2 ==================== Signed-off-by:
-
Paolo Abeni authored
__ip_options_echo() does not need anymore skb->dst, so we can avoid explicitly preserving it for its own sake. This is almost a revert of commit 0ddf3fb2 ("udp: preserve skb->dst if required for IP options processing") plus some lifting to fit later changes. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
ip_options_echo() does not use anymore the skb->dst and don't need to keep the dst around for options's sake only. This reverts commit 34b2cef2. Signed-off-by:
-
Paolo Abeni authored
__ip_options_echo() uses the current network namespace, and currently retrives it via skb->dst->dev. This commit adds an explicit 'net' argument to __ip_options_echo() and update all the call sites to provide it, usually via a simpler sock_net(). After this change, __ip_options_echo() no more needs to access skb->dst and we can drop a couple of hack to preserve such info in the rx path. Signed-off-by:
-
Paolo Abeni authored
While computing the response option set for LSRR, ip_options_echo() also changes the ingress packet LSRR addresses list, setting the last one to the dst specific address for the ingress packet - via memset(start[ ... The only visible effect of such change - beyond possibly damaging shared/cloned skbs - is modifying the data carried by ICMP replies changing the header information for reported the ingress packet, which violates RFC1122 3.2.2.6. All the others call sites just ignore the ingress packet IP options after calling ip_options_echo() Note that the last element in the LSRR option address list for the reply packet will be properly set later in the ip output path via ip_options_build(). This buggy memset() predates git history and apparently was present into the initial ip_options_echo() implementation in linux 1.3.30 but still looks wrong. The removal of the fib_compute_spec_dst() call will help completely dropping the skb->dst usage by __ip_options_echo() with a later patch. Signed-off-by:
-
- 05 Aug, 2017 1 commit
-
-
Pavel Belous authored
Add support for GRO (generic receive offload) for aQuantia Atlantic driver. This results in a perfomance improvement when GRO is enabled. Signed-off-by:
Pavel Belous <pavel.belous@aquantia.com> Signed-off-by:
-
- 04 Aug, 2017 19 commits
-
-
John Fastabend authored
Update BPF comments to accurately reflect XDP usage. Fixes: 97f91a7c ("bpf: add bpf_redirect_map helper routine") Reported-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== net: sched: summer cleanup part 1, mainly in exts area This patchset is one of the couple cleanup patchsets I have in queue. The motivation aside the obvious need to "make things nicer" is also to prepare for shared filter blocks introduction. That requires tp->q removal, and therefore removal of all tp->q users. Patch 1 is just some small thing I spotted on the way Patch 2 removes one user of tp->q, namely tcf_em_tree_change Patches 3-8 do preparations for exts->nr_actions removal Patches 9-10 do simple renames of functions in cls* Patches 11-19 remove unnecessary calls of tcf_exts_change helper The last patch changes tcf_exts_change to don't take lock Tested by tools/testing/selftests/tc-testing v1->v2: - removed conversion of action array to list as noted by Cong - added the past patch instead - small rebases of patches 11-19 ==================== Signed-off-by: -
Jiri Pirko authored
tcf_exts_change is always called on newly created exts, which are not used on fastpath. Therefore, simple struct copy is enough. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
As the n struct was allocated right before u32_set_parms call, no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the f struct was allocated right before route4_set_parms call, no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the fnew struct just was allocated, so no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the new struct just was allocated, so no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the prog struct was allocated right before cls_bpf_set_parms call, no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the f struct was allocated right before basic_set_parms call, no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the head struct was allocated right before mall_set_parms call, no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the f struct was allocated right before fw_set_parms call, no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
As the f struct was allocated right before fl_set_parms call, no need to use tcf_exts_change to do atomic change, and we can just fill-up the unused exts struct directly by tcf_exts_validate. Signed-off-by:
-
Jiri Pirko authored
Since the function name is misleading since it is not changing anything, name it similarly to other cls. Signed-off-by:
-
Jiri Pirko authored
The name cls_bpf_modify_existing is highly misleading, as it indeed does not modify anything existing. It does not modify at all. Signed-off-by:
-
Jiri Pirko authored
For check in tcf_exts_dump use tcf_exts_has_actions helper instead of exts->nr_actions for checking if there are any actions present. Signed-off-by:
-
Jiri Pirko authored
Leave it to tcf_action_exec to return TC_ACT_OK in case there is no action present. Signed-off-by:
-
Jiri Pirko authored
Return the defined TC_ACT_OK instead of 0. Signed-off-by:
-
Jiri Pirko authored
These two helpers are doing the same as tcf_exts_has_actions, so remove them and use tcf_exts_has_actions instead. Signed-off-by:
-
Jiri Pirko authored
Use the tcf_exts_has_actions helper instead or directly testing exts->nr_actions in tcf_exts_exec. Signed-off-by:
-
