- 27 May, 2020 35 commits
-
-
Oleksij Rempel authored
Add support for Atheros 100Base-T PHYs. The only difference seems to be the ability to test 2 pairs instead of 4 and the lack of 1000Base-T specific register. Only the ATH9331 was tested with this patch. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Andrew Lunn says: ==================== Raw PHY TDR data Some ethernet PHYs allow access to raw TDR data in addition to summary diagnostics information. Add support for retrieving this data via netlink ethtool. The basic structure in the core is the same as for normal phy diagnostics, the PHY driver simply uses different helpers to fill the netlink message with different data. There is a graphical tool under development, as well a ethtool(1) which can dump the data as text and JSON. A patched ethtool(1) can be found in https://github.com/lunn/ethtool.git feature/cable-test-v5 Thanks for Chris Healy for lots of testing. v2: See the individual patches but: Pass distances in centimeters, not meters Allow the PHY to round distances to what it supports and report what it actually used along with the results. Make the Marvell PHY use steps a multiple of 0.805 meters, its native step size. v3: Move the TDR configuration into a structure Add a range check on step Use NL_SET_ERR_MSG_ATTR() when appropriate Move TDR configuration into a nest Document attributes in the request Unsquash the last two patches ==================== Signed-off-by:
-
Andrew Lunn authored
When performing a TDR measurement for a short distance, the pulse width should be low, to help differentiate between the outgoing pulse and any reflection. For longer distances, the pulse should be wider, to help with attenuation. Signed-off-by:
-
Andrew Lunn authored
Getting the TDR data requires a large number of MDIO bus transactions. The number can however be reduced if the page is only changed once. Add the needed locking to allow this, and make use of unlocked read/write methods where needed. Signed-off-by:
-
Andrew Lunn authored
Allow the user to configure where on the cable the TDR data should be retrieved, in terms of first and last sample, and the step between samples. Also add the ability to ask for TDR data for just one pair. If this configuration is not provided, it defaults to 1-150m at 1m intervals for all pairs. Signed-off-by:
-
Andrew Lunn authored
The Marvell PHYs can measure the amplitude of the returned signal for a given distance. Implement this option of the cable test infrastructure. When reporting the step, convert the distance into cm. Signed-off-by:
-
Andrew Lunn authored
Add helpers for returning raw TDR helpers in netlink messages. Signed-off-by:
-
Andrew Lunn authored
Add the generic parts of the code used to trigger a cable test and return raw TDR data. Any PHY driver which support this must implement the new driver op. Signed-off-by:
-
Andrew Lunn authored
Some Ethernet PHYs can return the raw time domain reflectromatry data. Add the attributes to allow this data to be requested and returned via netlink ethtool. Signed-off-by:
-
Armin Wolf authored
Fixed a ton of minor checkpatch errors/warnings and remove version printing at module init/when device is found and use MODULE_VERSION instead. Also modifying the RTL8029 PCI string to include the compatible RTL8029AS nic. The only mayor issue remaining is the missing SPDX tag, but since the exact version of the GPL is not stated anywhere inside the file, its impossible to add such a tag at the moment. But maybe it is possible, since 8390.h states Donald Becker's 8390 drivers are licensed under GPL 2.2 only (= GPL-2.0-only ?). The kernel module containing this patch compiles and runs without problems on a RTL8029AS-based NE2000 clone card with kernel 5.7.0-rc6. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Signed-off-by:
-
Alexander Sverdlin authored
Ignore loopback-originatig packets soon enough and don't try to process L2 header where it doesn't exist. The very similar br_handle_frame() in bridge code performs exactly the same check. This is an example of such ICMPv6 packet: skb len=96 headroom=40 headlen=96 tailroom=56 mac=(40,0) net=(40,40) trans=80 shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0)) csum(0xae2e9a2f ip_summed=1 complete_sw=0 valid=0 level=0) hash(0xc97ebd88 sw=1 l4=1) proto=0x86dd pkttype=5 iif=24 dev name=etha01.212 feat=0x0x0000000040005000 skb headroom: 00000000: 00 7c 86 52 84 88 ff ff 00 00 00 00 00 00 08 00 skb headroom: 00000010: 45 00 00 9e 5d 5c 40 00 40 11 33 33 00 00 00 01 skb headroom: 00000020: 02 40 43 80 00 00 86 dd skb linear: 00000000: 60 09 88 bd 00 38 3a ff fe 80 00 00 00 00 00 00 skb linear: 00000010: 00 40 43 ff fe 80 00 00 ff 02 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 00 00 01 86 00 61 00 40 00 00 2d skb linear: 00000030: 00 00 00 00 00 00 00 00 03 04 40 e0 00 00 01 2c skb linear: 00000040: 00 00 00 78 00 00 00 00 fd 5f 42 68 23 87 a8 81 skb linear: 00000050: 00 00 00 00 00 00 00 00 01 01 02 40 43 80 00 00 skb tailroom: 00000000: ... skb tailroom: 00000010: ... skb tailroom: 00000020: ... skb tailroom: 00000030: ... Call Trace, how it happens exactly: ... macvlan_handle_frame+0x321/0x425 [macvlan] ? macvlan_forward_source+0x110/0x110 [macvlan] __netif_receive_skb_core+0x545/0xda0 ? enqueue_task_fair+0xe5/0x8e0 ? __netif_receive_skb_one_core+0x36/0x70 __netif_receive_skb_one_core+0x36/0x70 process_backlog+0x97/0x140 net_rx_action+0x1eb/0x350 ? __hrtimer_run_queues+0x136/0x2e0 __do_softirq+0xe3/0x383 do_softirq_own_stack+0x2a/0x40 </IRQ> do_softirq.part.4+0x4e/0x50 netif_rx_ni+0x60/0xd0 dev_loopback_xmit+0x83/0xf0 ip6_finish_output2+0x575/0x590 [ipv6] ? ip6_cork_release.isra.1+0x64/0x90 [ipv6] ? __ip6_make_skb+0x38d/0x680 [ipv6] ? ip6_output+0x6c/0x140 [ipv6] ip6_output+0x6c/0x140 [ipv6] ip6_send_skb+0x1e/0x60 [ipv6] rawv6_sendmsg+0xc4b/0xe10 [ipv6] ? proc_put_long+0xd0/0xd0 ? rw_copy_check_uvector+0x4e/0x110 ? sock_sendmsg+0x36/0x40 sock_sendmsg+0x36/0x40 ___sys_sendmsg+0x2b6/0x2d0 ? proc_dointvec+0x23/0x30 ? addrconf_sysctl_forward+0x8d/0x250 [ipv6] ? dev_forward_change+0x130/0x130 [ipv6] ? _raw_spin_unlock+0x12/0x30 ? proc_sys_call_handler.isra.14+0x9f/0x110 ? __call_rcu+0x213/0x510 ? get_max_files+0x10/0x10 ? trace_hardirqs_on+0x2c/0xe0 ? __sys_sendmsg+0x63/0xa0 __sys_sendmsg+0x63/0xa0 do_syscall_64+0x6c/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Various trap changes - part 2 This patch set contains another set of small changes in mlxsw trap configuration. It is the last set before exposing control traps (e.g., IGMP query, ARP request) via devlink-trap. Tested with existing devlink-trap selftests. Please see individual patches for a detailed changelog. ==================== Signed-off-by: -
Ido Schimmel authored
The device has a trap for IPv6 packets that need be routed and have a unicast link-local destination IP (i.e., fe80::/10). This allows mlxsw to ignore link-local routes, as the packets will be trapped to the CPU in any case. However, since link-local routes are not programmed, it is possible for routed packets to hit the default route which might also be programmed to trap packets. This means that packets with a link-local destination IP might be trapped for the wrong reason. To overcome this, allow programming link-local prefix routes (usually one fe80::/64 per-table), so that the packets will be forwarded until reaching the link-local trap. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
Bidirectional Forwarding Detection (BFD) provides "low-overhead, short-duration detection of failures in the path between adjacent forwarding engines" (RFC 5880). This is accomplished by exchanging BFD packets between the two forwarding engines. Up until now these packets were trapped via the general local delivery (i.e., IP2ME) trap which also traps a lot of other packets that are not as time-sensitive as BFD packets. Expose dedicated traps for BFD packets so that user space could configure a dedicated policer for them. Signed-off-by:
-
Ido Schimmel authored
IPv6 packets that need to be forwarded and have a link-local source IP are dropped by the kernel and an ICMPv6 "Destination unreachable" is sent to the sending host. As such, change the trap group of such packets so that they do not interfere with IPv6 management packets. In the future this trap will be exposed as an exception via devlink-trap. Signed-off-by:
-
Ido Schimmel authored
Routed IP packets with the Router Alert option need to be trapped to the CPU as they might need to be locally delivered to raw sockets with the IP_ROUTER_ALERT / IPV6_ROUTER_ALERT socket option. Move them to the same group with other packets that might need to be trapped following route lookup. Signed-off-by:
-
Ido Schimmel authored
After the previous patch the split is no longer necessary and all the trap groups can be moved under the same enum. Signed-off-by:
-
Ido Schimmel authored
As explained in commit e6125230 ("mlxsw: spectrum_trap: Introduce dummy group with thin policer"), the purpose of the "thin" policer is to pass as less packets as possible to the CPU. The identifier of this policer is currently set according to the maximum number of used trap groups, but this is fragile: On Spectrum-1 the maximum number of policers is less than the maximum number of trap groups, which might result in an invalid policer identifier in case the number of used trap groups grows beyond the policer limit. Solve this by dynamically allocating the policer identifier. Signed-off-by:
-
Ido Schimmel authored
The number of Spectrum trap groups is not infinite, but two identifiers are occupied by SwitchX-2 specific trap groups. Free these identifiers by moving them out of the main enum. Signed-off-by:
-
Ido Schimmel authored
To align with recent recommended values. Will be configurable by future patches. Signed-off-by:
-
Ido Schimmel authored
Packets with an IPv6 link-local destination (i.e., fe80::/10) should not be forwarded and are therefore trapped to the CPU for local delivery. Since these packets are trapped for the same logical reason as packets hitting local routes, associate both traps with the same group. Signed-off-by:
-
Ido Schimmel authored
When a packet enters the device it is classified to a filtering identifier (FID) based on the ingress port and VLAN. The FID miss trap is used to trap packets for which a FID could not be found. In mlxsw this trap should only be triggered when a port is enslaved to an OVS bridge and a matching ACL rule could not be found, so as to trigger learning. These packets are therefore completely unrelated to packets hitting local routes and should be in a different group. Move them. Signed-off-by:
-
Ido Schimmel authored
Group these various IPv6 packets (e.g., router solicitations, router advertisement) together and subject them to the same policer. Signed-off-by:
-
Ido Schimmel authored
The IPv6 Neighbour Discovery (ND) group will be used for various IPv6 packets, not all of which fall under the definition of ND, so rename it to "IPV6" which is more appropriate. Signed-off-by:
-
Ido Schimmel authored
Trap groups that use the same policer settings can share the same switch case. Signed-off-by:
-
Ido Schimmel authored
Packets that are trapped via tc's trap action are currently subject to the same policer as packets hitting local routes. The latter are critical to the correct functioning of the control plane, while the former are mainly used for traffic inspection. Split the ACL trap to a separate group with its own policer. Use a higher priority for these traps than for traps using mirror action (e.g., ARP, IGMP). Otherwise, packets matching both traps will not be forwarded in hardware (because of trap action) and also not forwarded in software because they will be marked with 'offload_fwd_mark'. Signed-off-by:
-
Florian Westphal authored
We can try to coalesce skbs we take from the subflows rx queue with the tail of the mptcp rx queue. If successful, the skb head can be discarded early. We can also free the skb extensions, we do not access them after this. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Heiner Kallweit authored
Don't call netif_napi_del() manually, free_netdev() does this for us. In addition reorder calls to match reverse order of calls in probe(). Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
David S. Miller authored
Fugang Duan says: ==================== net: ethernet: fec: move GPR register offset and bit into DT The commit da722186 (net: fec: set GPR bit on suspend by DT configuration) set the GPR reigster offset and bit in driver for wol feature support. It brings trouble to enable wol feature on imx6sx/imx6ul/imx7d platforms that have multiple ethernet instances with different GPR bit for stop mode control. So the patch set is to move GPR register offset and bit define into DT, and enable imx6q/imx6dl imx6qp/imx6sx/imx6ul/imx7d stop mode support. Currently, below NXP i.MX boards support wol: - imx6q/imx6dl/imx6qp sabresd - imx6sx sabreauto - imx7d sdb imx6q/imx6dl/imx6qp sabresd board dts file miss the property "fsl,magic-packet;", so patch#4 is to add the property for stop mode support. v1 -> v2: - driver: switch back to store the quirks bitmask in driver_data - dt-bindings: rename 'gpr' property string to 'fsl,stop-mode' - imx6/7 dtsi: add imx6sx/imx6ul/imx7d ethernet stop mode property v2 -> v3: - driver: suggested by Sascha Hauer, use a struct fec_devinfo for abstracting differences between different hardware variants, it can give more freedom to describe the differences. - imx6/7 dtsi: correct one typo pointed out by Andrew. Thanks Martin, Andrew and Sascha Hauer for the review. ==================== Signed-off-by:
-
Fugang Duan authored
Enable ethernet wake-on-lan feature for imx6q/dl/qp sabresd boards since the PHY clock is supplied by external osc. Reviewed-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
Fugang Duan authored
- Update the imx6qdl gpr property to define gpr register offset and bit in DT. - Add imx6sx/imx6ul/imx7d ethernet stop mode property. Reviewed-by:
-
Fugang Duan authored
- rename the 'gpr' property string to 'fsl,stop-mode'. - Update the property to define gpr register offset and bit in DT, since different instance have different gpr bit. v2: * rename 'gpr' property string to 'fsl,stop-mode'. Signed-off-by:
-
Fugang Duan authored
The commit da722186 (net: fec: set GPR bit on suspend by DT configuration) set the GPR reigster offset and bit in driver for wake on lan feature. But it introduces two issues here: - one SOC has two instances, they have different bit - different SOCs may have different offset and bit So to support wake-on-lan feature on other i.MX platforms, it should configure the GPR reigster offset and bit from DT. So the patch is to improve the commit da722186 (net: fec: set GPR bit on suspend by DT configuration) to support multiple ethernet instances on i.MX series. v2: * switch back to store the quirks bitmask in driver_data v3: * suggested by Sascha Hauer, use a struct fec_devinfo for abstracting differences between different hardware variants, it can give more freedom to describe the differences. Signed-off-by:
-
Dmitry Vyukov authored
Netlink policies are generally declared as const. This is safer and prevents potential bugs. Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-next-for-net-next-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== One batch of changes, containing: * hwsim improvements from Jouni and myself, to be able to test more scenarios easily * some more HE (802.11ax) support * some initial S1G (sub 1 GHz) work for fractional MHz channels * some (action) frame registration updates to help DPP support * along with other various improvements/fixes ==================== Signed-off-by:
-
- 26 May, 2020 5 commits
-
-
David S. Miller authored
Antoine Tenart says: ==================== net: phy: mscc-miim: reduce waiting time between MDIO transactions This series aims at reducing the waiting time between MDIO transactions when using the MSCC MIIM MDIO controller. I'm not sure we need patch 4/4 and we could reasonably drop it from the series. I'm including the patch as it could help to ensure the system is functional with a non optimal configuration. We needed to improve the driver's performances as when using a PHY requiring lots of registers accesses (such as the VSC85xx family), delays would add up and ended up to be quite large which would cause issues such as: a slow initialization of the PHY, and issues when using timestamping operations (this feature will be sent quite soon to the mailing lists). ==================== Signed-off-by: -
Antoine Tenart authored
The driver uses a read polling mechanism to check the status of the MDIO bus, to know if it is ready to accept next commands. This polling mechanism uses usleep_delay() under the hood between reads which is fine as long as high resolution timers are enabled. Otherwise the delays will end up to be much longer than expected. This patch fixes this by using udelay() under the hood when CONFIG_HIGH_RES_TIMERS isn't enabled. This increases CPU usage. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Reviewed-by:
-
Antoine Tenart authored
The MSCC MIIM MDIO driver uses a waiting logic to wait for the MDIO bus to be ready to accept next commands. It does so by polling the BUSY status bit which indicates the MDIO bus has completed all pending operations. This can take time, and the controller supports writing the next command as soon as there are no pending commands (which happens while the MDIO bus is busy completing its current command). This patch implements this improved logic by adding an helper to poll the PENDING status bit, and by adjusting where we should wait for the bus to not be busy or to not be pending. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by:
-
Antoine Tenart authored
readl_poll_timeout already returns -ETIMEDOUT if the condition isn't satisfied, there's no need to check again the condition after calling it. Remove the redundant timeout check. Signed-off-by:
-
Antoine Tenart authored
The MSCC MIIM MDIO driver uses delays to read poll a status register. I made multiple tests on a Ocelot PCS120 platform which led me to reduce those delays. The delay in between which the polling function is allowed to sleep is reduced from 100us to 50us which in almost all cases is a good value to succeed at the first retry. The overall delay is also lowered as the prior value was really way to high, 10000us is large enough. Signed-off-by:
-
