- 15 Feb, 2021 40 commits
-
-
Michael Walle authored
AR8035 recently gained MDIX support. The same functions will work for the AR8031/33 PHY. We just need to add the at803x_config_aneg() callback. This was tested on a Kontron sl28 board. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: broadcom: Cleanups and APD This patch series cleans up the brcmphy.h header and its numerous unused phydev->dev_flags, fixes the RXC/TXC clock disabling bit and allows the BCM54210E PHY to utilize APD. Changes in v2: - dropped the patch that attempted to fix a possible discrepancy between the datasheet and the actual hardware - added a patch to remove a forward declaration - do additional flags cleanup ==================== Signed-off-by: -
Florian Fainelli authored
BCM54210E/BCM50212E has been verified to work correctly with the auto-power down configuration done by bcm54xx_adjust_rxrefclk(), add it to the list of PHYs working. While we are at it, provide an appropriate name for the bit we are changing which disables the RXC and TXC during auto-power down when there is no energy on the cable. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Florian Fainelli authored
We have a number of unused flags defined today and since we are scarce on space and may need to introduce new flags in the future remove and shift every existing flag down into a contiguous assignment. PHY_BCM_FLAGS_MODE_1000BX was only used internally for the BCM54616S PHY, so we allocate a driver private structure instead to store that flag instead of canibalizing one from phydev->dev_flags for that purpose. Signed-off-by:
-
Florian Fainelli authored
Avoid a forward declaration by moving the callers of bcm54xx_config_clock_delay() below its body. Signed-off-by:
-
Lijun Pan authored
The CRQ and subCRQ descriptors are DMA mapped, so dma_wmb(), though weaker, is good enough to protect the data structures. Signed-off-by:
Lijun Pan <ljp@linux.ibm.com> Acked-by:
Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
-
Lijun Pan authored
The only thing reset_long_term_buff() should do is set buffer to zero. After doing that, it is not necessary to send_request_map again to VIOS since it actually does not change the mapping. So, keep memset function and remove all others. Signed-off-by:
-
Geliang Tang authored
Add mptcpi_local_addr_used and mptcpi_local_addr_max in struct mptcp_info. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Gustavo A. R. Silva authored
It seems that the right argument to be passed is &tcp_ip6_spec->ip6dst, not &tcp_ip6_spec->ip6src, when calling function ipv6_addr_any(). Addresses-Coverity-ID: 1501734 ("Copy-paste error") Fixes: efca91e8 ("i40e: Add flow director support for IPv6") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Rafał Miłecki authored
Hardware comes up with default max frame size set to 1518. When using it with switch it results in actual Ethernet MTU 1492: 1518 - 14 (Ethernet header) - 4 (Broadcom's tag) - 4 (802.1q) - 4 (FCS) Above means hardware in its default state can't handle standard Ethernet traffic (MTU 1500). Define maximum possible Ethernet overhead and always set MAC max frame length accordingly. This change fixes handling Ethernet frames of length 1506 - 1514. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
-
David S. Miller authored
Nobuhiro Iwamatsu says: ==================== net: stmmac: Add Toshiba Visconti SoCs glue driver This series is the ethernet driver for Toshiba's ARM SoC, Visconti[0]. This provides DT binding documentation, device driver, MAINTAINER files, and updates to DT files. ==================== Signed-off-by: -
Nobuhiro Iwamatsu authored
Add the ethernet controller node in Toshiba Visconti5 SoC-specific DT file. And enable this node in TMPV7708 RM main board's board-specific DT file. Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
Nobuhiro Iwamatsu authored
Add entries for Toshiba Visconti ethernet controller binding and driver. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Add dwmac-visconti to the stmmac driver in Toshiba Visconti ARM SoCs. This patch contains only the basic function of the device. There is no clock control, PM, etc. yet. These will be added in the future. Signed-off-by:
-
Nobuhiro Iwamatsu authored
Add device tree bindings for ethernet controller of Toshiba Visconti TMPV7700 SoC series. Signed-off-by:
-
Stefan Chulski authored
With MTU less than 1500B on all ports, the driver uses per CPU pool mode. If one of the ports set to jumbo frame MTU size, all ports move to shared pools mode. Here, buffer manager TX Flow Control reconfigured on all ports. Signed-off-by:
Stefan Chulski <stefanc@marvell.com> Signed-off-by:
-
Stefan Chulski authored
1KB is enough for loopback port, so 2KB can be distributed between other ports. Signed-off-by:
-
Vladimir Oltean authored
The sja1105 driver has a limitation, extensively described under Documentation/networking/dsa/sja1105.rst and Documentation/networking/devlink/sja1105.rst, which says that when the ports are under a bridge with vlan_filtering=1, traffic to and from the network stack is not possible, unless the driver-specific best_effort_vlan_filtering devlink parameter is enabled. For users, this creates a 'wtf' moment. They need to go to the documentation and find about the existence of this property, then maybe install devlink and set it to true. Having best_effort_vlan_filtering enabled by the kernel by default delays that 'wtf' moment (maybe up to the point that it never even happens). The user doesn't need to care that the driver supports addressing the ports individually by retagging VLAN IDs until he/she needs to use more than 32 VLAN IDs (since there can be at most 32 retagging rules). Only then do they need to think whether they need the full VLAN table, at the expense of no individual port addressing, or not. But the odds that an sja1105 user will need more than 32 VLANs terminated by the CPU is probably low. And, if we were to follow the principle that more advanced use cases should require more advanced preparation steps, then it makes more sense for ping to 'just work' while CPU termination of > 32 VLAN IDs to require a bit more forethought and possibly a driver-specific devlink param. So we should be able to safely change the default here, and make this driver act just a little bit more sanely out of the box. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
-
Eric Dumazet authored
My prior cleanup missed that tcp_data_ready() has to look at SOCK_DONE. Otherwise, an application using SO_RCVLOWAT will not get EPOLLIN event if a FIN is received in the middle of expected payload. The reason SOCK_DONE is not examined in tcp_epollin_ready() is that tcp_poll() catches the FIN because tcp_fin() is also setting RCV_SHUTDOWN into sk->sk_shutdown Fixes: 05dc72ab ("tcp: factorize logic into tcp_epollin_ready()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Wei Wang <weiwan@google.com> Cc: Arjun Roy <arjunroy@google.com> Reviewed-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Fix buggy brport flags offload for SJA1105 DSA While testing the "Software fallback for bridging in DSA" on sja1105, I discovered that I managed to introduce two bugs in a single patch submitted recently to net-next. ==================== Signed-off-by: -
Vladimir Oltean authored
The prototype of br_vlan_filter_toggle was updated to include a netlink extack, but the stub definition wasn't, which results in a build error when CONFIG_BRIDGE_VLAN_FILTERING=n. Fixes: 9e781401 ("net: bridge: propagate extack through store_bridge_parm") Signed-off-by:
-
Vladimir Oltean authored
The switchdev_port_attr_set function prototype was updated only for the case where CONFIG_SWITCHDEV=y|m, leaving a prototype mismatch with the stub definition for the disabled case. This results in a build error, so update that function too. Fixes: dcbdf135 ("net: bridge: propagate extack through switchdev_port_attr_set") Signed-off-by:
-
Vladimir Oltean authored
Smatch is confused by the fact that a 32-bit BIT(port) macro is passed as argument to the ocelot_ifh_set_dest function and warns: ocelot_xmit() warn: should '(((1))) << (dp->index)' be a 64 bit type? seville_xmit() warn: should '(((1))) << (dp->index)' be a 64 bit type? The destination port mask is copied into a 12-bit field of the packet, starting at bit offset 67 and ending at 56. So this DSA tagging protocol supports at most 12 bits, which is clearly less than 32. Attempting to send to a port number > 12 will cause the packing() call to truncate way before there will be 32-bit truncation due to type promotion of the BIT(port) argument towards u64. Therefore, smatch's fears that BIT(port) will do the wrong thing and cause unexpected truncation for "port" values >= 32 are unfounded. Nonetheless, let's silence the warning by explicitly passing an u64 value to ocelot_ifh_set_dest, such that the compiler does not need to do a questionable type promotion. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Heiner Kallweit authored
Armin reported that after referenced commit his RTL8105e is dead when resuming from suspend and machine runs on battery. This patch has been confirmed to fix the issue. Fixes: e80bd76f ("r8169: work around power-saving bug on some chip versions") Reported-by:
Armin Wolf <W_Armin@gmx.de> Tested-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
David S. Miller authored
Stefan Chulski says: ==================== net: mvpp2: Minor non functional driver code improvements The patch series contains minor code improvements and did not change any functionality. ==================== Signed-off-by: -
Stefan Chulski authored
GENCONF_CTRL0_PORTX naming improved. Non functional change. Signed-off-by:
-
Stefan Chulski authored
Use PTR_ERR_OR_ZERO instead of IS_ERR and PTR_ERR. Non functional change. Signed-off-by:
-
Stefan Chulski authored
Use >= MVPP22 instead of != MVPP21. Non functional change. Signed-off-by:
-
Stefan Chulski authored
PPv2.1 contain 0 in Version ID register, priv->hw_version check can be removed. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Propagate extack for switchdev VLANs from DSA This series moves the restriction messages printed by the DSA core, and by some individual device drivers, into the netlink extended ack structure, to be communicated to user space where possible, or still printed to the kernel log from the bridge layer. ==================== Signed-off-by: -
Vladimir Oltean authored
Some drivers can't dynamically change the VLAN filtering option, or impose some restrictions, it would be nice to propagate this info through netlink instead of printing it to a kernel log that might never be read. Also netlink extack includes the module that emitted the message, which means that it's easier to figure out which ones are driver-generated errors as opposed to command misuse. Signed-off-by:
-
Vladimir Oltean authored
Allow drivers to communicate their restrictions to user space directly, instead of printing to the kernel log. Where the conversion would have been lossy and things like VLAN ID could no longer be conveyed (due to the lack of support for printf format specifier in netlink extack), I chose to keep the messages in full form to the kernel log only, and leave it up to individual driver maintainers to move more messages to extack. Signed-off-by:
-
Vladimir Oltean authored
The benefit is the ability to propagate errors from switchdev drivers for the SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING and SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL attributes. Signed-off-by:
-
Vladimir Oltean authored
The bridge sysfs interface stores parameters for the STP, VLAN, multicast etc subsystems using a predefined function prototype. Sometimes the underlying function being called supports a netlink extended ack message, and we ignore it. Let's expand the store_bridge_parm function prototype to include the extack, and just print it to console, but at least propagate it where applicable. Where not applicable, create a shim function in the br_sysfs_br.c file that discards the extra function argument. This patch allows us to propagate the extack argument to br_vlan_set_default_pvid, br_vlan_set_proto and br_vlan_filter_toggle, and from there, further up in br_changelink from br_netlink.c. Signed-off-by:
-
Vladimir Oltean authored
This function is identical with br_vlan_filter_toggle. Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== PTP for DSA tag_ocelot_8021q Changes in v2: Add stub definition for ocelot_port_inject_frame when switch driver is not compiled in. This is part two of the errata workaround begun here: https://patchwork.kernel.org/project/netdevbpf/cover/20210129010009.3959398-1-olteanv@gmail.com/ Now that we have basic traffic support when we operate the Ocelot DSA switches without an NPI port, it would be nice to regain some of the features lost due to the lack of the NPI port functionality. An important one is PTP timestamping, which is intimately tied to the DSA frame header added by the NPI port: on TX, we put a "timestamp request ID" in the Injection Frame Header, while on RX, the Extraction Frame Header contains a partial 32-bit PTP timestamp. Get rid of the NPI port and replace it with a VLAN-based tagger, and you lose PTP, right? Well, not quite, this is what this patch series is about. The NPI port is basically a regular Ethernet port configured to service the packets in and out of the switch's CPU port module (which has other non-DSA I/O mechanisms too, such as register-based MMIO and DMA). If we disable the NPI port, we can in theory still access the packets delivered to the CPU port module by doing exactly what the ocelot switchdev driver does: extracting Ethernet packets through registers (yes, it is as icky as it sounds). However, there's a catch. The Felix switch was integrated into NXP LS1028A with the idea in mind that it will operate as DSA, i.e. using the CPU port module connected to the NPI port, not having I/O over register-based MMIO which is painfully slow and CPU intensive. So register-based packet I/O not supposed to work - those registers aren't even documented in the hardware reference manual for Felix. However they kinda do, with the exception of the fact that an RX interrupt was really not wired to the CPU cores - so we don't know when the CPU port module receives a new packet. But we can hack even around that, by replicating every packet that goes to the CPU port module and making it also go to a plain internal Ethernet port. Then drop the Ethernet packet and read the other copy of it from the CPU port module, this time annotated with the much-wanted RX timestamp. This is all fine and it works, but it does raise some questions about what DSA even is anymore, if we start having switches that inject some of their packets over Ethernet and some through registers, where do we draw the line. In principle I believe these concerns are founded, but at the same time, the way that the Felix driver uses register MMIO based packet I/O is fundamentally the same as any other DSA driver capable of PTP makes use of a side-channel for timestamps like a FIFO (just that this one is a lot more complicated, and comes with the entire actual packet, not just the timestamp). Nonetheless, I tried to keep the extra pressure added by this ERR workaround upon the DSA subsystem as small as possible, so some of the patches are just a revisit of some of Andrew's complaints w.r.t. the fact that tag_ocelot already violates any driver <-> tagger boundary, and as a consequence, is not able to be used on testbeds such as dsa_loop (which it now can). So now, the tag_ocelot and tag_ocelot_8021q drivers should be dsa_loop-clean, and have the ERR workarounds as self-contained as possible, using all the designated features for PTP timestamping and nothing more. Comments appreciated. ==================== Signed-off-by:
-
Vladimir Oltean authored
For TX timestamping, we use the felix_txtstamp method which is common with the regular (non-8021q) ocelot tagger. This method says that skb deferral is needed, prepares a timestamp request ID, and puts a clone of the skb in a queue waiting for the timestamp IRQ. felix_txtstamp is called by dsa_skb_tx_timestamp() just before the tagger's xmit method. In the tagger xmit, we divert the packets classified by dsa_skb_tx_timestamp() as PTP towards the MMIO-based injection registers, and we declare them as dead towards dsa_slave_xmit. If not PTP, we proceed with normal tag_8021q stuff. Then the timestamp IRQ fires, the clone queued up from felix_txtstamp is matched to the TX timestamp retrieved from the switch's FIFO based on the timestamp request ID, and the clone is delivered to the stack. On RX, thanks to the VCAP IS2 rule that redirects the frames with an EtherType for 1588 towards two destinations: - the CPU port module (for MMIO based extraction) and - if the "no XTR IRQ" workaround is in place, the dsa_8021q CPU port the relevant data path processing starts in the ptp_classify_raw BPF classifier installed by DSA in the RX data path (post tagger, which is completely unaware that it saw a PTP packet). This time we can't reuse the same implementation of .port_rxtstamp that also works with the default ocelot tagger. That is because felix_rxtstamp is given an skb with a freshly stripped DSA header, and it says "I don't need deferral for its RX timestamp, it's right in it, let me show you"; and it just points to the header right behind skb->data, from where it unpacks the timestamp and annotates the skb with it. The same thing cannot happen with tag_ocelot_8021q, because for one thing, the skb did not have an extraction frame header in the first place, but a VLAN tag with no timestamp information. So the code paths in felix_rxtstamp for the regular and 8021q tagger are completely independent. With tag_8021q, the timestamp must come from the packet's duplicate delivered to the CPU port module, but there is potentially complex logic to be handled [ and prone to reordering ] if we were to just start reading packets from the CPU port module, and try to match them to the one we received over Ethernet and which needs an RX timestamp. So we do something simple: we tell DSA "give me some time to think" (we request skb deferral by returning false from .port_rxtstamp) and we just drop the frame we got over Ethernet with no attempt to match it to anything - we just treat it as a notification that there's data to be processed from the CPU port module's queues. Then we proceed to read the packets from those, one by one, which we deliver up the stack, timestamped, using netif_rx - the same function that any driver would use anyway if it needed RX timestamp deferral. So the assumption is that we'll come across the PTP packet that triggered the CPU extraction notification eventually, but we don't know when exactly. Thanks to the VCAP IS2 trap/redirect rule and the exclusion of the CPU port module from the flooding replicators, only PTP frames should be present in the CPU port module's RX queues anyway. There is just one conflict between the VCAP IS2 trapping rule and the semantics of the BPF classifier. Namely, ptp_classify_raw() deems general messages as non-timestampable, but still, those are trapped to the CPU port module since they have an EtherType of ETH_P_1588. So, if the "no XTR IRQ" workaround is in place, we need to run another BPF classifier on the frames extracted over MMIO, to avoid duplicates being sent to the stack (once over Ethernet, once over MMIO). It doesn't look like it's possible to install VCAP IS2 rules based on keys extracted from the 1588 frame headers. Signed-off-by:
-
Vladimir Oltean authored
Since the tag_8021q tagger is software-defined, it has no means by itself for retrieving hardware timestamps of PTP event messages. Because we do want to support PTP on ocelot even with tag_8021q, we need to use the CPU port module for that. The RX timestamp is present in the Extraction Frame Header. And because we can't use NPI mode which redirects the CPU queues to an "external CPU" (meaning the ARM CPU running Linux), then we need to poll the CPU port module through the MMIO registers to retrieve TX and RX timestamps. Sadly, on NXP LS1028A, the Felix switch was integrated into the SoC without wiring the extraction IRQ line to the ARM GIC. So, if we want to be notified of any PTP packets received on the CPU port module, we have a problem. There is a possible workaround, which is to use the Ethernet CPU port as a notification channel that packets are available on the CPU port module as well. When a PTP packet is received by the DSA tagger (without timestamp, of course), we go to the CPU extraction queues, poll for it there, then we drop the original Ethernet packet and masquerade the packet retrieved over MMIO (plus the timestamp) as the original when we inject it up the stack. Create a quirk in struct felix is selected by the Felix driver (but not by Seville, since that doesn't support PTP at all). We want to do this such that the workaround is minimally invasive for future switches that don't require this workaround. The only traffic for which we need timestamps is PTP traffic, so add a redirection rule to the CPU port module for this. Currently we only have the need for PTP over L2, so redirection rules for UDP ports 319 and 320 are TBD for now. Note that for the workaround of matching of PTP-over-Ethernet-port with PTP-over-MMIO queues to work properly, both channels need to be absolutely lossless. There are two parts to achieving that: - We keep flow control enabled on the tag_8021q CPU port - We put the DSA master interface in promiscuous mode, so it will never drop a PTP frame (for the profiles we are interested in, these are sent to the multicast MAC addresses of 01-80-c2-00-00-0e and 01-1b-19-00-00-00). Signed-off-by:
-
Vladimir Oltean authored
Since the felix DSA driver will need to poll the CPU port module for extracted frames as well, let's create some common functions that read an Extraction Frame Header, and then an skb, from a CPU extraction group. We abuse the struct ocelot_ops :: port_to_netdev function a little bit, in order to retrieve the DSA port net_device or the ocelot switchdev net_device based on the source port information from the Extraction Frame Header, but it's all in the benefit of code simplification - netdev_alloc_skb needs it. Originally, the port_to_netdev method was intended for parsing act->dev from tc flower offload code. Signed-off-by:
-
Vladimir Oltean authored
The ocelot tagger is a hot mess currently, it relies on memory initialized by the attached driver for basic frame transmission. This is against all that DSA tagging protocols stand for, which is that the transmission and reception of a DSA-tagged frame, the data path, should be independent from the switch control path, because the tag protocol is in principle hot-pluggable and reusable across switches (even if in practice it wasn't until very recently). But if another driver like dsa_loop wants to make use of tag_ocelot, it couldn't. This was done to have common code between Felix and Ocelot, which have one bit difference in the frame header format. Quoting from commit 67c24049 ("net: dsa: felix: create a template for the DSA tags on xmit"): Other alternatives have been analyzed, such as: - Create a separate tag_seville.c: too much code duplication for just 1 bit field difference. - Create a separate DSA_TAG_PROTO_SEVILLE under tag_ocelot.c, just like tag_brcm.c, which would have a separate .xmit function. Again, too much code duplication for just 1 bit field difference. - Allocate the template from the init function of the tag_ocelot.c module, instead of from the driver: couldn't figure out a method of accessing the correct port template corresponding to the correct tagger in the .xmit function. The really interesting part is that Seville should have had its own tagging protocol defined - it is not compatible on the wire with Ocelot, even for that single bit. In principle, a packet generated by DSA_TAG_PROTO_OCELOT when booted on NXP LS1028A would look in a certain way, but when booted on NXP T1040 it would look differently. The reverse is also true: a packet generated by a Seville switch would be interpreted incorrectly by Wireshark if it was told it was generated by an Ocelot switch. Actually things are a bit more nuanced. If we concentrate only on the DSA tag, what I said above is true, but Ocelot/Seville also support an optional DSA tag prefix, which can be short or long, and it is possible to distinguish the two taggers based on an integer constant put in that prefix. Nonetheless, creating a separate tagger is still justified, since the tag prefix is optional, and without it, there is again no way to distinguish. Claiming backwards binary compatibility is a bit more tough, since I've already changed the format of tag_ocelot once, in commit 5124197c ("net: dsa: tag_ocelot: use a short prefix on both ingress and egress"). Therefore I am not very concerned with treating this as a bugfix and backporting it to stable kernels (which would be another mess due to the fact that there would be lots of conflicts with the other DSA_TAG_PROTO* definitions). It's just simpler to say that the string values of the taggers have ABI value starting with kernel 5.12, which will be when the changing of tag protocol via /sys/class/net/<dsa-master>/dsa/tagging goes live. Signed-off-by:
-
