- 26 Dec, 2019 23 commits
-
-
Martin Blumenstingl authored
On RTL8211F the RX and TX delays (2ns) can be configured in two ways: - pin strapping (RXD1 for the TX delay and RXD0 for the RX delay, LOW means "off" and HIGH means "on") which is read during PHY reset - using software to configure the TX and RX delay registers So far only the configuration using pin strapping has been supported. Add support for enabling or disabling the RGMII RX delay based on the phy-mode to be able to get the RX delay into a known state. This is important because the RX delay has to be coordinated between the PHY, MAC and the PCB design (trace length). With an invalid RX delay applied (for example if both PHY and MAC add a 2ns RX delay) Ethernet may not work at all. Also add debug logging when configuring the RX delay (just like the TX delay) because this is a common source of problems. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Martin Blumenstingl authored
RGMII requires a delay of 2ns between the data and the clock signal. There are at least three ways this can happen. One possibility is by having the PHY generate this delay. This is a common source for problems (for example with slow TX speeds or packet loss when sending data). The TX delay configuration of the RTL8211F PHY can be set either by pin-strappping the RXD1 pin (HIGH means enabled, LOW means disabled) or through configuring a paged register. The setting from the RXD1 pin is also reflected in the register. Add debug logging to the TX delay configuration on RTL8211F so it's easier to spot these issues (for example if the TX delay is enabled for both, the RTL8211F PHY and the MAC). This is especially helpful because there is no public datasheet for the RTL8211F PHY available with all the RX/TX delay specifics. Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: spectrum_router: Cleanups This patch set removes from mlxsw code that is no longer necessary after the simplification of the IPv4 and IPv6 route offload API. The patches eliminate unnecessary code by taking advantage of the fact that mlxsw no longer needs to maintain a list of identical routes, following recent changes in route offload API. ==================== Signed-off-by: -
Ido Schimmel authored
As explained in previous patches, the driver no longer needs to maintain a list of identical FIB entries (i.e, same {tb_id, prefix, prefix length}) and therefore each FIB node can only store one FIB entry. Remove the FIB entry list and simplify the code. Signed-off-by:Ido Schimmel <idosch@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
After the last patch mlxsw_sp_fib{4,6}_node_entry_link() and mlxsw_sp_fib{4,6}_node_entry_unlink() are identical and can therefore be consolidated into the same common function. Perform the consolidation. Signed-off-by: -
Ido Schimmel authored
Host routes that perform decapsulation of IP in IP tunnels have a special adjacency entry linked to them. This entry stores information such as the expected underlay source IP. When the route is deleted this entry needs to be freed. The allocation of the adjacency entry happens in mlxsw_sp_fib4_entry_type_set(), but it is freed in mlxsw_sp_fib4_node_entry_unlink(). Create a new function - mlxsw_sp_fib4_entry_type_unset() - and free the adjacency entry there. This will allow us to consolidate mlxsw_sp_fib{4,6}_node_entry_unlink() in the next patch. Signed-off-by: -
Ido Schimmel authored
Since the driver no longer maintains a list of identical routes there is no route to promote when a route is deleted. Remove that code that took care of it. Signed-off-by:
-
Ido Schimmel authored
Now that the networking stack takes care of only notifying the routes of interest, we do not need to maintain a list of identical routes. Remove the check that tests if the route is the first route in the FIB node. Signed-off-by:
-
Andy Roulin authored
As the LACP actor/partner state is now part of the uapi, rename the 3ad state defines with LACP prefix. The LACP prefix is preferred over BOND_3AD as the LACP standard moved to 802.1AX. Fixes: 826f66b3 ("bonding: move 802.3ad port state flags to uapi") Signed-off-by:
Andy Roulin <aroulin@cumulusnetworks.com> Signed-off-by:
-
Kevin Kou authored
The original patch bringed in the "SCTP ACK tracking trace event" feature was committed at Dec.20, 2017, it replaced jprobe usage with trace events, and bringed in two trace events, one is TRACE_EVENT(sctp_probe), another one is TRACE_EVENT(sctp_probe_path). The original patch intended to trigger the trace_sctp_probe_path in TRACE_EVENT(sctp_probe) as below code, +TRACE_EVENT(sctp_probe, + + TP_PROTO(const struct sctp_endpoint *ep, + const struct sctp_association *asoc, + struct sctp_chunk *chunk), + + TP_ARGS(ep, asoc, chunk), + + TP_STRUCT__entry( + __field(__u64, asoc) + __field(__u32, mark) + __field(__u16, bind_port) + __field(__u16, peer_port) + __field(__u32, pathmtu) + __field(__u32, rwnd) + __field(__u16, unack_data) + ), + + TP_fast_assign( + struct sk_buff *skb = chunk->skb; + + __entry->asoc = (unsigned long)asoc; + __entry->mark = skb->mark; + __entry->bind_port = ep->base.bind_addr.port; + __entry->peer_port = asoc->peer.port; + __entry->pathmtu = asoc->pathmtu; + __entry->rwnd = asoc->peer.rwnd; + __entry->unack_data = asoc->unack_data; + + if (trace_sctp_probe_path_enabled()) { + struct sctp_transport *sp; + + list_for_each_entry(sp, &asoc->peer.transport_addr_list, + transports) { + trace_sctp_probe_path(sp, asoc); + } + } + ), But I found it did not work when I did testing, and trace_sctp_probe_path had no output, I finally found that there is trace buffer lock operation(trace_event_buffer_reserve) in include/trace/trace_events.h: static notrace void \ trace_event_raw_event_##call(void *__data, proto) \ { \ struct trace_event_file *trace_file = __data; \ struct trace_event_data_offsets_##call __maybe_unused __data_offsets;\ struct trace_event_buffer fbuffer; \ struct trace_event_raw_##call *entry; \ int __data_size; \ \ if (trace_trigger_soft_disabled(trace_file)) \ return; \ \ __data_size = trace_event_get_offsets_##call(&__data_offsets, args); \ \ entry = trace_event_buffer_reserve(&fbuffer, trace_file, \ sizeof(*entry) + __data_size); \ \ if (!entry) \ return; \ \ tstruct \ \ { assign; } \ \ trace_event_buffer_commit(&fbuffer); \ } The reason caused no output of trace_sctp_probe_path is that trace_sctp_probe_path written in TP_fast_assign part of TRACE_EVENT(sctp_probe), and it will be placed( { assign; } ) after the trace_event_buffer_reserve() when compiler expands Macro, entry = trace_event_buffer_reserve(&fbuffer, trace_file, \ sizeof(*entry) + __data_size); \ \ if (!entry) \ return; \ \ tstruct \ \ { assign; } \ so trace_sctp_probe_path finally can not acquire trace_event_buffer and return no output, that is to say the nest of tracepoint entry function is not allowed. The function call flow is: trace_sctp_probe() -> trace_event_raw_event_sctp_probe() -> lock buffer -> trace_sctp_probe_path() -> trace_event_raw_event_sctp_probe_path() --nested -> buffer has been locked and return no output. This patch is to remove trace_sctp_probe_path from the TP_fast_assign part of TRACE_EVENT(sctp_probe) to avoid the nest of entry function, and trigger sctp_probe_path_trace in sctp_outq_sack. After this patch, you can enable both events individually, # cd /sys/kernel/debug/tracing # echo 1 > events/sctp/sctp_probe/enable # echo 1 > events/sctp/sctp_probe_path/enable Or, you can enable all the events under sctp. # echo 1 > events/sctp/enable Signed-off-by:Kevin Kou <qdkevin.kou@gmail.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
David S. Miller authored
Richard Cochran says: ==================== Peer to Peer One-Step time stamping This series adds support for PTP (IEEE 1588) P2P one-step time stamping along with a driver for a hardware device that supports this. If the hardware supports p2p one-step, it subtracts the ingress time stamp value from the Pdelay_Request correction field. The user space software stack then simply copies the correction field into the Pdelay_Response, and on transmission the hardware adds the egress time stamp into the correction field. This new functionality extends CONFIG_NETWORK_PHY_TIMESTAMPING to cover MII snooping devices, but it still depends on phylib, just as that option does. Expanding beyond phylib is not within the scope of the this series. User space support is available in the current linuxptp master branch. - Patch 1 adds phy_device methods for existing time stamping fields. - Patches 2-5 convert the stack and drivers to the new methods. - Patch 6 moves code around the dp83640 driver. - Patches 7-10 add support for MII time stamping in non-PHY devices. - Patch 11 adds the new P2P 1-step option. - Patch 12 adds a driver implementing the new option. Thanks, Richard Changed in v9: ~~~~~~~~~~~~~~ - Fix two more drivers' switch/case blocks WRT the new HWTSTAMP ioctl. - Picked up two more review tags from Andrew. Changed in v8: ~~~~~~~~~~~~~~ - Avoided adding forward functional declarations in the dp83640 driver. - Picked up Florian's new review tags and another one from Andrew. Changed in v7: ~~~~~~~~~~~~~~ - Converted pr_debug|err to dev_ variants in new driver. - Fixed device tree documentation per Rob's v6 review. - Picked up Andrew's and Rob's review tags. - Silenced sparse warnings in new driver. Changed in v6: ~~~~~~~~~~~~~~ - Added methods for accessing the phy_device time stamping fields. - Adjust the device tree documentation per Rob's v5 review. - Fixed the build failures due to missing exports. Changed in v5: ~~~~~~~~~~~~~~ - Fixed build failure in macvlan. - Fixed latent bug with its gcc warning in the driver. Changed in v4: ~~~~~~~~~~~~~~ - Correct error paths and PTR_ERR return values in the framework. - Expanded KernelDoc comments WRT PHY locking. - Pick up Andrew's review tag. Changed in v3: ~~~~~~~~~~~~~~ - Simplify the device tree binding and document the time stamping phandle by itself. Changed in v2: ~~~~~~~~~~~~~~ - Per the v1 review, changed the modeling of MII time stamping devices. They are no longer a kind of mdio device. ==================== Signed-off-by: -
Richard Cochran authored
The InES at the ZHAW offers a PTP time stamping IP core. The FPGA logic recognizes and time stamps PTP frames on the MII bus. This patch adds a driver for the core along with a device tree binding to allow hooking the driver to MII buses. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Richard Cochran authored
The 1588 standard defines one step operation for both Sync and PDelay_Resp messages. Up until now, hardware with P2P one step has been rare, and kernel support was lacking. This patch adds support of the mode in anticipation of new hardware developments. Signed-off-by:
-
Richard Cochran authored
When parsing a PHY node, register its time stamper, if any, and attach the instance to the PHY device. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Richard Cochran authored
This patch add a new binding that allows non-PHY MII time stamping devices to find their buses. The new documentation covers both the generic binding and one upcoming user. Signed-off-by:
-
Richard Cochran authored
While PHY time stamping drivers can simply attach their interface directly to the PHY instance, stand alone drivers require support in order to manage their services. Non-PHY MII time stamping drivers have a control interface over another bus like I2C, SPI, UART, or via a memory mapped peripheral. The controller device will be associated with one or more time stamping channels, each of which sits snoops in on a MII bus. This patch provides a glue layer that will enable time stamping channels to find their controlling device. Signed-off-by:
-
Richard Cochran authored
Currently the stack supports time stamping in PHY devices. However, there are newer, non-PHY devices that can snoop an MII bus and provide time stamps. In order to support such devices, this patch introduces a new interface to be used by both PHY and non-PHY devices. In addition, the one and only user of the old PHY time stamping API is converted to the new interface. Signed-off-by:
-
Richard Cochran authored
An upcoming patch will change how the PHY time stamping functions are registered with the networking stack, and adapting this driver would entail adding forward declarations for four time stamping methods. However, forward declarations are considered to be stylistic defects. This patch avoids the issue by moving the probe and remove methods immediately above the phy_driver interface structure. Signed-off-by:
-
Richard Cochran authored
The netcp_ethss driver tests fields of the phy_device in order to determine whether to defer to the PHY's time stamping functionality. This patch replaces the open coded logic with an invocation of the proper methods. Signed-off-by:
-
Richard Cochran authored
The ethtool layer tests fields of the phy_device in order to determine whether to invoke the PHY's tsinfo ethtool callback. This patch replaces the open coded logic with an invocation of the proper methods. Signed-off-by:
-
Richard Cochran authored
The vlan layer tests fields of the phy_device in order to determine whether to invoke the PHY's tsinfo ethtool callback. This patch replaces the open coded logic with an invocation of the proper methods. Signed-off-by:
-
Richard Cochran authored
The macvlan layer tests fields of the phy_device in order to determine whether to invoke the PHY's tsinfo ethtool callback. This patch replaces the open coded logic with an invocation of the proper methods. Signed-off-by:
-
Richard Cochran authored
Some parts of the networking stack and at least one driver test fields within the 'struct phy_device' in order to query time stamping capabilities and to invoke time stamping methods. This patch adds a functional interface around the time stamping fields. This will allow insulating the callers from future changes to the details of the time stamping implemenation. Signed-off-by:
-
- 25 Dec, 2019 17 commits
-
-
David S. Miller authored
Ido Schimmel says: ==================== Simplify IPv6 route offload API Motivation ========== This is the IPv6 counterpart of "Simplify IPv4 route offload API" [1]. The aim of this patch set is to simplify the IPv6 route offload API by making the stack a bit smarter about the notifications it is generating. This allows driver authors to focus on programming the underlying device instead of having to duplicate the IPv6 route insertion logic in their driver, which is error-prone. Details ======= Today, whenever an IPv6 route is added or deleted a notification is sent in the FIB notification chain and it is up to offload drivers to decide if the route should be programmed to the hardware or not. This is not an easy task as in hardware routes are keyed by {prefix, prefix length, table id}, whereas the kernel can store multiple such routes that only differ in metric / nexthop info. This series makes sure that only routes that are actually used in the data path are notified to offload drivers. This greatly simplifies the work these drivers need to do, as they are now only concerned with programming the hardware and do not need to replicate the IPv6 route insertion logic and store multiple identical routes. The route that is notified is the first route in the IPv6 FIB node, which represents a single prefix and length in a given table. In case the route is deleted and there is another route with the same key, a replace notification is emitted. Otherwise, a delete notification is emitted. Unlike IPv4, in IPv6 it is possible to append individual nexthops to an existing multipath route. Therefore, in addition to the replace and delete notifications present in IPv4, an append notification is also used. Testing ======= To ensure there is no degradation in route insertion rates, I averaged the insertion rate of 512k routes (/64 and /128) over 50 runs. Did not observe any degradation. Functional tests are available here [2]. They rely on route trap indication, which is added in a subsequent patch set. In addition, I have been running syzkaller for the past couple of weeks with debug options enabled. Did not observe any problems. Patch set overview ================== Patches #1-#7 gradually introduce the new FIB notifications Patch #8 converts mlxsw to use the new notifications Patch #9 remove the old notifications [1] https://patchwork.ozlabs.org/cover/1209738/ [2] https://github.com/idosch/linux/tree/fib-notifier ==================== Signed-off-by: -
Ido Schimmel authored
Now that mlxsw is converted to use the new FIB notifications it is possible to delete the old ones and use the new replace / append / delete notifications. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Ido Schimmel authored
With the new notifications mlxsw does not need to handle identical routes itself, as this is taken care of by the core IPv6 code. Instead, mlxsw only needs to take care of inserting and removing routes from the device. Convert mlxsw to use the new IPv6 route notifications and simplify the code. Signed-off-by:
-
Ido Schimmel authored
When an entire multipath route is deleted, only emit a notification if it is the first route in the node. Emit a replace notification in case the last sibling is followed by another route. Otherwise, emit a delete notification. Signed-off-by:
-
Ido Schimmel authored
For the purpose of route offload, when a single route is deleted, it is only of interest if it is the first route in the node or if it is sibling to such a route. In the first case, distinguish between several possibilities: 1. Route is the last route in the node. Emit a delete notification 2. Route is followed by a non-multipath route. Emit a replace notification for the non-multipath route. 3. Route is followed by a multipath route. Emit a replace notification for the multipath route. In the second case, only emit a delete notification to ensure the route is no longer used as a valid nexthop. Signed-off-by:
-
Ido Schimmel authored
When a new listener is registered to the FIB notification chain it receives a dump of all the available routes in the system. Instead, make sure to only replay the IPv6 routes that are actually used in the data path and are of any interest to the new listener. This is done by iterating over all the routing tables in the given namespace, but from each traversed node only the first route ('leaf') is notified. Multipath routes are notified in a single notification instead of one for each nexthop. Add fib6_rt_dump_tmp() to do that. Later on in the patch set it will be renamed to fib6_rt_dump() instead of the existing one. Signed-off-by: -
Ido Schimmel authored
In a similar fashion to previous patches, only notify the new multipath route if it is the first route in the node or if it was appended to such route. The type of the notification (replace vs. append) is determined based on the number of routes added ('nhn') and the number of sibling routes. If the two do not match, then an append notification should be sent. Signed-off-by: -
Ido Schimmel authored
Similar to the corresponding IPv4 patch, only notify the new route if it is replacing the currently offloaded one. Meaning, the one pointed to by 'fn->leaf'. Signed-off-by:
-
Ido Schimmel authored
fib6_add_rt2node() takes care of adding a single route ('struct fib6_info') to a FIB node. The route in question should only be notified in case it is added as the first route in the node (lowest metric) or if it is added as a sibling route to the first route in the node. The first criterion can be tested by checking if the route is pointed to by 'fn->leaf'. The second criterion can be tested by checking the new 'notify_sibling_rt' variable that is set when the route is added as a sibling to the first route in the node. Signed-off-by: -
Ido Schimmel authored
Subsequent patches are going to simplify the IPv6 route offload API, which will only use three events - replace, delete and append. Introduce a temporary version of replace and delete in order to make the conversion easier to review. Note that append does not need a temporary version, as it is currently not used. Signed-off-by:
-
Heiner Kallweit authored
Simplify the code by moving the call to rtl_enable_eee() from the individual PHY configs to rtl8169_init_phy(). Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Due to recent changes we don't need the call to rtl_rar_exgmac_set() and longer at this place. It's called from rtl_rar_set() which is called in rtl_init_mac_address() and rtl8169_resume(). Signed-off-by:
-
Heiner Kallweit authored
Simplify and factor out this magic from rtl8168h_2_hw_phy_config() and name it based on the vendor driver. Signed-off-by:
-
David S. Miller authored
Martin Varghese says: ==================== New openvswitch MPLS actions for layer 2 tunnelling The existing PUSH MPLS action inserts MPLS header between ethernet header and the IP header. Though this behaviour is fine for L3 VPN where an IP packet is encapsulated inside a MPLS tunnel, it does not suffice the L2 VPN (l2 tunnelling) requirements. In L2 VPN the MPLS header should encapsulate the ethernet packet. The new mpls action ADD_MPLS inserts MPLS header at the start of the packet or at the start of the l3 header depending on the value of l3 tunnel flag in the ADD_MPLS arguments. POP_MPLS action is extended to support ethertype 0x6558 OVS userspace changes - --------------------- Encap & Decap ovs actions are extended to support MPLS packet type. The encap & decap adds and removes MPLS header at the start of packet as depicted below. Actions - encap(mpls(ether_type=0x8847)),encap(ethernet) Incoming packet -> | ETH | IP | Payload | 1 Actions - encap(mpls(ether_type=0x8847)) [Kernel action - add_mpls:0x8847] Outgoing packet -> | MPLS | ETH | Payload| 2 Actions - encap(ethernet) [ Kernel action - push_eth ] Outgoing packet -> | ETH | MPLS | ETH | Payload| Decapsulation: Incoming packet -> | ETH | MPLS | ETH | IP | Payload | Actions - decap(),decap(packet_type(ns=0,type=0) 1 Actions - decap() [Kernel action - pop_eth) Outgoing packet -> | MPLS | ETH | IP | Payload| 2 Actions - decap(packet_type(ns=0,type=0) [Kernel action - pop_mpls:0x6558] Outgoing packet -> | ETH | IP | Payload ==================== Signed-off-by: -
Martin Varghese authored
The existing PUSH MPLS action inserts MPLS header between ethernet header and the IP header. Though this behaviour is fine for L3 VPN where an IP packet is encapsulated inside a MPLS tunnel, it does not suffice the L2 VPN (l2 tunnelling) requirements. In L2 VPN the MPLS header should encapsulate the ethernet packet. The new mpls action ADD_MPLS inserts MPLS header at the start of the packet or at the start of the l3 header depending on the value of l3 tunnel flag in the ADD_MPLS arguments. POP_MPLS action is extended to support ethertype 0x6558. Signed-off-by:
Martin Varghese <martin.varghese@nokia.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
Martin Varghese authored
Rephrased comments section of skb_mpls_pop() to align it with comments section of skb_mpls_push(). Signed-off-by:
-
Martin Varghese authored
The existing skb_mpls_push() implementation always inserts mpls header after the mac header. L2 VPN use cases requires MPLS header to be inserted before the ethernet header as the ethernet packet gets tunnelled inside MPLS header in those cases. Signed-off-by:
-
