aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-11-11Merge branch 'sfp-Allow-slow-to-initialise-GPON-modules-to-work'David S. Miller1-157/+369
Russell King says: ==================== sfp: Allow slow to initialise GPON modules to work Some GPON modules take longer than the SFF MSA specified time to initialise and respond to transactions on the I2C bus for either both 0x50 and 0x51, or 0x51 bus addresses. Technically these modules are non-compliant with the SFP Multi-Source Agreement, they have been around for some time, so are difficult to just ignore. Most of the patch series is restructuring the code to make it more readable, and split various things into separate functions. We split the three state machines into three separate functions, and re-arrange them to start probing the module as soon as a module has been detected (without waiting for the network device.) We try to read the module's EEPROM, retrying quickly for the first second, and then once every five seconds for about a minute until we have read the EEPROM. So that the kernel isn't entirely silent, we print a message indicating that we're waiting for the module to respond after the first second, or when all retries have expired. Once the module ID has been read, we kick off a delayed work queue which attempts to register the hwmon, retrying for up to a minute if the monitoring parameters are unreadable; this allows us to proceed with module initialisation independently of the hwmon state. With high-power modules, we wait for the netdev to be attached before switching the module power mode, and retry this in a similar way to before until we have successfully read and written the EEPROM at 0x51. We also move the handling of the TX_DISABLE signal entirely to the main state machine, and avoid probing any on-board PHY while TX_FAULT is set. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: allow modules with slow diagnostics to probeRussell King1-22/+74
When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: allow sfp to probe slow to initialise GPON modulesRussell King1-10/+28
Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: move module insert reporting out of probeRussell King1-18/+40
Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: split power mode switching from probeRussell King1-37/+64
Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: track upstream's attachment state in state machineRussell King1-13/+29
Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: ensure TX_FAULT has deasserted before probing the PHYRussell King1-6/+25
TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: allow fault processing to transition to other statesRussell King1-6/+6
Add the next state to sfp_sm_fault() so that it can branch to other states. This will be necessary to improve the initialisation path. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: eliminate mdelay() from PHY probeRussell King1-12/+40
Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: split the PHY probe from sfp_sm_mod_init()Russell King1-8/+13
Move the PHY probe into a separate function, splitting it from sfp_sm_mod_init(). This will allow us to eliminate the 50ms mdelay() inside the state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: control TX_DISABLE and phy only from main state machineRussell King1-8/+1
We initialise TX_DISABLE when the sfp cage is probed, and then maintain its state in the main state machine. However, the module state machine: - negates it when detecting a newly inserted module when it's already guaranteed to be negated. - negates it when the module is removed, but the main state machine will do this anyway. Make TX_DISABLE entirely controlled by the main state machine. The main state machine also probes the module for a PHY, and removes the PHY when the the module is removed. Hence, removing the PHY in sfp_sm_module_remove() is also redundant, and is a left-over from when we tried to probe for the PHY from the module state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: avoid power switch on address-change modulesRussell King1-11/+20
If the module indicates that it requires an address change sequence to switch between address 0x50 and 0x51, which we don't support, we can't write to the register that controls the power mode to switch to high power mode. Warn the user that the module may not be functional in this case, and don't try to change the power mode. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: parse SFP power requirement earlierRussell King1-13/+29
Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: rename T_PROBE_WAIT to T_SERIALRussell King1-7/+6
SFF-8472 rev 12.2 defines the time for the serial bus to become ready using t_serial. Use this as our identifier for this timeout to make it clear what we are referring to. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: handle module remove outside state machineRussell King1-7/+9
Removing a module resets the module state machine back to its initial state. Rather than explicitly handling this in every state, handle it early on outside of the state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: rename sfp_sm_ins_next() as sfp_sm_mod_next()Russell King1-8/+8
sfp_sm_ins_next() modifies the module state machine. Change it's name to reflect this. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: move tx disable on device down to main state machineRussell King1-8/+2
Move the tx disable assertion on device down to the main state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: move sfp sub-state machines into separate functionsRussell King1-31/+43
Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: sfp: fix sfp_bus_put() kernel documentationRussell King1-1/+1
The kbuild test robot found a problem with htmldocs with the recent change to the SFP interfaces. Fix the kernel documentation for sfp_bus_put() which was missing an '@' before the argument name description. Fixes: 727b3668b730 ("net: sfp: rework upstream interface") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11r8169: respect EEE user setting when restarting networkHeiner Kallweit1-3/+15
Currently, if network is re-started, we advertise all supported EEE modes, thus potentially overriding a manual adjustment the user made e.g. via ethtool. Be friendly to the user and preserve a manual setting on network re-start. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11lwtunnel: ignore any TUNNEL_OPTIONS_PRESENT flags set by usersXin Long1-6/+8
TUNNEL_OPTIONS_PRESENT (TUNNEL_GENEVE_OPT|TUNNEL_VXLAN_OPT| TUNNEL_ERSPAN_OPT) flags should be set only according to tb[LWTUNNEL_IP_OPTS], which is done in ip_tun_parse_opts(). When setting info key.tun_flags, the TUNNEL_OPTIONS_PRESENT bits in tb[LWTUNNEL_IP(6)_FLAGS] passed from users should be ignored. While at it, replace all (TUNNEL_GENEVE_OPT|TUNNEL_VXLAN_OPT| TUNNEL_ERSPAN_OPT) with 'TUNNEL_OPTIONS_PRESENT'. Fixes: 3093fbe7ff4b ("route: Per route IP tunnel metadata via lightweight tunnel") Fixes: 32a2b002ce61 ("ipv6: route: per route IP tunnel metadata via lightweight tunnel") Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11lwtunnel: get nlsize for erspan options properlyXin Long1-1/+7
erspan v1 has OPT_ERSPAN_INDEX while erspan v2 has OPT_ERSPAN_DIR and OPT_ERSPAN_HWID attributes, and they require different nlsize when dumping. So this patch is to get nlsize for erspan options properly according to erspan version. Fixes: b0a21810bd5e ("lwtunnel: add options setting and dumping for erspan") Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11lwtunnel: change to use nla_parse_nested on new optionsXin Long1-8/+8
As the new options added in kernel, all should always use strict parsing from the beginning with nla_parse_nested(), instead of nla_parse_nested_deprecated(). Fixes: b0a21810bd5e ("lwtunnel: add options setting and dumping for erspan") Fixes: edf31cbb1502 ("lwtunnel: add options setting and dumping for vxlan") Fixes: 4ece47787077 ("lwtunnel: add options setting and dumping for geneve") Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11Merge branch 'Accomodate-DSA-front-end-into-Ocelot'David S. Miller8-457/+680
Vladimir Oltean says: ==================== Accomodate DSA front-end into Ocelot After the nice "change-my-mind" discussion about Ocelot, Felix and LS1028A (which can be read here: https://lkml.org/lkml/2019/6/21/630), we have decided to take the route of reworking the Ocelot implementation in a way that is DSA-compatible. This is a large series, but hopefully is easy enough to digest, since it contains mostly code refactoring. What needs to be changed: - The struct net_device, phy_device needs to be isolated from Ocelot private structures (struct ocelot, struct ocelot_port). These will live as 1-to-1 equivalents to struct dsa_switch and struct dsa_port. - The function prototypes need to be compatible with DSA (of course, struct dsa_switch will become struct ocelot). - The CPU port needs to be assigned via a higher-level API, not hardcoded in the driver. What is going to be interesting is that the new DSA front-end of Ocelot will need to have features in lockstep with the DSA core itself. At the moment, some more advanced tc offloading features of Ocelot (tc-flower, etc) are not available in the DSA front-end due to lack of API in the DSA core. It also means that Ocelot practically re-implements large parts of DSA (although it is not a DSA switch per se) - see the FDB API for example. The code has been only compile-tested on Ocelot, since I don't have access to any VSC7514 hardware. It was proven to work on NXP LS1028A, which instantiates a DSA derivative of Ocelot. So I would like to ask Alex Belloni if you could confirm this series causes no regression on the Ocelot MIPS SoC. The goal is to get this rework upstream as quickly as possible, precisely because it is a large volume of code that risks gaining merge conflicts if we keep it for too long. This is but the first chunk of the LS1028A Felix DSA driver upstreaming. For those who are interested, the concept can be seen on my private Github repo, the user of this reworked Ocelot driver living under drivers/net/dsa/vitesse/: https://github.com/vladimiroltean/ls1028ardb-linux ==================== Acked-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: don't hardcode the number of the CPU portVladimir Oltean1-4/+7
VSC7514 is a 10-port switch with 2 extra "CPU ports" (targets in the queuing subsystem for terminating traffic locally). There are 2 issues with hardcoding the CPU port as #10: - It is not clear which snippets of the code are configuring something for one of the CPU ports, and which snippets are just doing something related to the number of physical ports. - Actually any physical port can act as a CPU port connected to an external CPU (in addition to the local CPU). This is called NPI mode (Node Processor Interface) and is the way that the 6-port VSC9959 (Felix) switch is integrated inside NXP LS1028A (the "local management CPU" functionality is not used there). This patch makes it clear that the ocelot_bridge_stp_state_set function operates on the CPU port (by making it an implicit member of the bridging domain), and at the same time adds logic for the NPI port (aka a physical port) to play the role of a CPU port (it shouldn't be part of bridge_fwd_mask, as it's not explicitly enslaved to a bridge). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: split assignment of the cpu port into a separate functionVladimir Oltean3-22/+57
Now that the places that configure routing destinations for the CPU port have been marked as such, allow callers to specify their own CPU port that is different than ocelot->num_phys_ports. A user will be the Felix DSA driver, where the CPU port is one of the physical ports (NPI mode). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: refactor adjust_link into a netdev-independent functionVladimir Oltean1-10/+17
This will be called from the Felix DSA frontend, which will work in PHYLIB compatibility mode initially. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: initialize list of multicast addresses in common codeClaudiu Manoil2-1/+1
This is just common path code that belongs to ocelot_init, it has nothing to do with a specific SoC/board instance. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: separate the common implementation of ndo_open and ndo_stopVladimir Oltean1-10/+26
Allow these functions to be called from the .port_enable and .port_disable callbacks of DSA. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: move port initialization into separate functionVladimir Oltean1-21/+24
We need a function for the DSA front-end that does none of the net_device registration, but initializes the hardware ports. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: limit vlan ingress filtering to actual number of portsVladimir Oltean1-1/+2
The VSC7514 switch (Ocelot) is a 10-port device, while VSC9959 (Felix) is 6-port. Therefore the VLAN filtering mask would be out of bounds when calling for this new switch. Fix that. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: refactor ethtool callbacksVladimir Oltean1-17/+47
Convert them into an implementation that can be called from DSA as well. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: separate net_device related items out of ocelot_portVladimir Oltean6-190/+233
The ocelot and ocelot_port structures will be used by a new DSA driver, so the ocelot_board.c file will have to allocate and work with a private structure (ocelot_port_private), which embeds the generic struct ocelot_port. This is because in DSA, at least one interface does not have a net_device, and the DSA driver API does not interact with that anyway. The ocelot_port structure is equivalent to dsa_port, and ocelot to dsa_switch. The members of ocelot_port which have an equivalent in dsa_port (such as dp->vlan_filtering) have been moved to ocelot_port_private. We want to enforce the coding convention that "ocelot_port" refers to the structure, and "port" refers to the integer index. One can retrieve the structure at any time from ocelot->ports[port]. The patch is large but only contains variable renaming and mechanical movement of fields from one structure to another. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: refactor struct ocelot_port out of function prototypesVladimir Oltean4-65/+59
The ocelot_port structure has a net_device embedded in it, which makes it unsuitable for leaving it in the driver implementation functions. Leave ocelot_flower.c untouched. In that file, ocelot_port is used as an interface to the tc shared blocks. That will be addressed in the next patch. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: change prototypes of switchdev port attribute handlersVladimir Oltean1-43/+45
This is needed so that the Felix DSA front-end can call the Ocelot implementations. The implementation of the "mc_disabled" switchdev attribute has also been simplified by using the read-modify-write macro instead of open-coding that operation. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: change prototypes of hwtstamping ioctlsVladimir Oltean1-12/+13
This is needed in order to present a simpler prototype to the DSA front-end of ocelot. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: break out fdb operations into abstract implementationsVladimir Oltean1-46/+78
To be able to implement a DSA front-end over ocelot_fdb_add, ocelot_fdb_del, ocelot_fdb_dump, these need to have a simple function prototype that is independent of struct net_device, netlink skb, etc. So rename the ndo ops of the ocelot driver into ocelot_port_fdb_{add,del,dump}, and have them all call the abstract implementations. At the same time, refactor ocelot_port_fdb_do_dump into a function whose prototype is compatible with dsa_fdb_dump_cb_t, so that the do_dump implementations can live together and be called by the ocelot_fdb_dump through a function pointer. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: break apart vlan operations into ocelot_vlan_{add, del}Vladimir Oltean1-18/+42
We need an implementation of these functions that is agnostic to the higher layer (switchdev or dsa). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: mscc: ocelot: break apart ocelot_vlan_port_applyVladimir Oltean1-68/+100
This patch transforms the ocelot_vlan_port_apply function ("apply what?") into 3 standalone functions: - ocelot_port_vlan_filtering - ocelot_port_set_native_vlan - ocelot_port_set_pvid These functions have a prototype that is better aligned to the DSA API. The function also had some static initialization (TPID, drop frames with multicast source MAC) which was not being changed from any place, so that was just moved to ocelot_probe_port (one of the 6 callers of ocelot_vlan_port_apply). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11Merge branch 'net-dsa-mv88e6xxx-Add-support-for-port-mirroring'David S. Miller6-20/+188
Iwan R Timmer says: ==================== net: dsa: mv88e6xxx: Add support for port mirroring This patch series add support for port mirroring in the mv88e6xx switch driver. The first patch changes the set_egress_port function to allow different egress ports for egress and ingress traffic. The second patch adds the actual code for port mirroring support. Tested on a 88E6176 with: tc qdisc add dev wan0 clsact tc filter add dev wan0 ingress matchall skip_sw \ action mirred egress mirror dev lan2 tc filter add dev wan0 egress matchall skip_sw \ action mirred egress mirror dev lan3 Changes in v3 - Use enum for egress traffic direction - Keep track of egress ports on mv88e6390 - Move booleans in struct for better structure packing Changes in v2 - Support mirroring egress and ingress traffic to different ports - Check for invalid configurations when multiple ports are mirrored ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: dsa: mv88e6xxx: Add support for port mirroringIwan R Timmer5-4/+136
Add support for configuring port mirroring through the cls_matchall classifier. We do a full ingress and/or egress capture towards a capture port. It allows setting a different capture port for ingress and egress traffic. It keeps track of the mirrored ports and the destination ports to prevent changes to the capture port while other ports are being mirrored. Signed-off-by: Iwan R Timmer <irtimmer@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: dsa: mv88e6xxx: Split monitor port configurationIwan R Timmer4-16/+52
Separate the configuration of the egress and ingress monitor port. This allows the port mirror functionality to do ingress and egress port mirroring to separate ports. Signed-off-by: Iwan R Timmer <irtimmer@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11Support LAN743x PTP periodic output on any GPIOJohn Efstathiades2-96/+230
The LAN743x Ethernet controller provides two independent PTP event channels. Each one can be used to generate a periodic output from the PTP clock. The output can be routed to any one of the available GPIO pins on the device. The PTP clock API can now be used to: - select any LAN743x GPIO pin to function as a periodic output - select either LAN743x PTP event channel to generate the output The LAN7430 has 4 GPIO pins that are multiplexed with its internal PHY LED control signals. A pin assigned to the LED control function will be assigned to the GPIO function if selected for PTP periodic output. Signed-off-by: John Efstathiades <john.efstathiades@pebblebay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11Merge branch 'Unlock-new-potential-in-SJA1105-with-PTP-system-timestamping'David S. Miller5-52/+177
Vladimir Oltean says: ==================== Unlock new potential in SJA1105 with PTP system timestamping The SJA1105 being an automotive switch means it is designed to live in a set-and-forget environment, far from the configure-at-runtime nature of Linux. Frequently resetting the switch to change its static config means it loses track of its PTP time, which is not good. This patch series implements PTP system timestamping for this switch (using the API introduced for SPI here: https://www.mail-archive.com/netdev@vger.kernel.org/msg316725.html), adding the following benefits to the driver: - When under control of a user space PTP servo loop (ptp4l, phc2sys), the loss of sync during a switch reset is much more manageable, and the switch still remains in the s2 (locked servo) state. - When synchronizing the switch using the software technique (based on reading clock A and writing the value to clock B, as opposed to relying on hardware timestamping), e.g. by using phc2sys, the sync accuracy is vastly improved due to the fact that the actual switch PTP time can now be more precisely correlated with something of better precision (CLOCK_REALTIME). The issue is that SPI transfers are inherently bad for measuring time with low jitter, but the newly introduced API aims to alleviate that issue somewhat. This series is also a requirement for a future patch set that adds full time-aware scheduling offload support for the switch. ==================== Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: dsa: sja1105: Disallow management xmit during switch resetVladimir Oltean1-0/+4
The purpose here is to avoid ptp4l fail due to this condition: timed out while polling for tx timestamp increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug port 1: send peer delay request failed So either reset the switch before the management frame was sent, or after it was timestamped as well, but not in the middle. The condition may arise either due to a true timeout (i.e. because re-uploading the static config takes time), or due to the TX timestamp actually getting lost due to reset. For the former we can increase tx_timestamp_timeout in userspace, for the latter we need this patch. Locking all traffic during switch reset does not make sense at all, though. Forcing all CPU-originated traffic to potentially block waiting for a sleepable context to send > 800 bytes over SPI is not a good idea. Flows that are autonomously forwarded by the switch will get dropped anyway during switch reset no matter what. So just let all other CPU-originated traffic be dropped as well. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: dsa: sja1105: Restore PTP time after switch resetVladimir Oltean4-32/+114
The PTP time of the switch is not preserved when uploading a new static configuration. Work around this hardware oddity by reading its PTP time before a static config upload, and restoring it afterwards. Static config changes are expected to occur at runtime even in scenarios directly related to PTP, i.e. the Time-Aware Scheduler of the switch is programmed in this way. Perhaps the larger implication of this patch is that the PTP .gettimex64 and .settime functions need to be exposed to sja1105_main.c, where the PTP lock needs to be held during this entire process. So their core implementation needs to move to some common functions which get exposed in sja1105_ptp.h. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-11net: dsa: sja1105: Implement the .gettimex64 system call for PTPVladimir Oltean4-22/+61
Through the PTP_SYS_OFFSET_EXTENDED ioctl, it is possible for userspace applications (i.e. phc2sys) to compensate for the delays incurred while reading the PHC's time. The task itself of taking the software timestamp is delegated to the SPI subsystem, through the newly introduced API in struct spi_transfer. The goal is to cross-timestamp I/O operations on the switch's PTP clock with values in the local system clock (CLOCK_REALTIME). For that we need to understand a bit of the hardware internals. The 'read PTP time' message is a 12 byte structure, first 4 bytes of which represent the SPI header, and the last 8 bytes represent the 64-bit PTP time. The switch itself starts processing the command immediately after receiving the last bit of the address, i.e. at the middle of byte 3 (last byte of header). The PTP time is shadowed to a buffer register in the switch, and retrieved atomically during the subsequent SPI frames. A similar thing goes on for the 'write PTP time' message, although in that case the switch waits until the 64-bit PTP time becomes fully available before taking any action. So the byte that needs to be software-timestamped is byte 11 (last) of the transfer. The patch creates a common (and local) sja1105_xfer implementation for the SPI I/O, and offers 3 front-ends: - sja1105_xfer_u32 and sja1105_xfer_u64: these are capable of optionally requesting a PTP timestamp - sja1105_xfer_buf: this is for large transfers (e.g. the static config buffer) and other misc data, and there is no point in giving timestamping capabilities to this. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-09Merge branch 'r8169-improve-PHY-configuration'David S. Miller1-496/+229
Heiner Kallweit says: ==================== r8169: improve PHY configuration This series adds helpers to improve and simplify the PHY configuration on various network chip versions. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-09r8169: remove rtl8168c_4_hw_phy_configHeiner Kallweit1-6/+1
rtl8168c_4_hw_phy_config() duplicates rtl8168c_3_hw_phy_config(), so we can remove the function. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-09r8169: add helper r8168d_modify_extpageHeiner Kallweit1-82/+39
Certain integrated PHY's from RTL8168d support extended pages. On page 0x0007 the number of the extended page is written to register 0x1e, then the registers on the extended page can be accessed. Add a helper for this to improve readability and simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>