- 17 Aug, 2019 22 commits
-
-
Ido Schimmel authored
For tests that create their network interfaces dynamically or do not use interfaces at all (as with netdevsim) it is useful to define their own devlink device instead of deriving it from the first network interface. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
Have netdevsim register its trap groups and traps with devlink during initialization and periodically report trapped packets to devlink core. Since netdevsim is not a real device, the trapped packets are emulated using a workqueue that periodically reports a UDP packet with a random 5-tuple from each active packet trap and from each running netdev. Signed-off-by:
-
Ido Schimmel authored
Add initial documentation of the devlink-trap mechanism, explaining the background, motivation and the semantics of the interface. Signed-off-by:
-
Ido Schimmel authored
Add generic packet traps and groups that can report dropped packets as well as exceptions such as TTL error. Signed-off-by:
-
Ido Schimmel authored
Add the basic packet trap infrastructure that allows device drivers to register their supported packet traps and trap groups with devlink. Each driver is expected to provide basic information about each supported trap, such as name and ID, but also the supported metadata types that will accompany each packet trapped via the trap. The currently supported metadata type is just the input port, but more will be added in the future. For example, output port and traffic class. Trap groups allow users to set the action of all member traps. In addition, users can retrieve per-group statistics in case per-trap statistics are too narrow. In the future, the trap group object can be extended with more attributes, such as policer settings which will limit the amount of traffic generated by member traps towards the CPU. Beside registering their packet traps with devlink, drivers are also expected to report trapped packets to devlink along with relevant metadata. devlink will maintain packets and bytes statistics for each packet trap and will potentially report the trapped packet with its metadata to user space via drop monitor netlink channel. The interface towards the drivers is simple and allows devlink to set the action of the trap. Currently, only two actions are supported: 'trap' and 'drop'. When set to 'trap', the device is expected to provide the sole copy of the packet to the driver which will pass it to devlink. When set to 'drop', the device is expected to drop the packet and not send a copy to the driver. In the future, more actions can be added, such as 'mirror'. Signed-off-by:
-
Ido Schimmel authored
Drop monitor has start and stop commands, but so far these were only used to start and stop monitoring of software drops. Now that drop monitor can also monitor hardware drops, we should allow the user to control these as well. Do that by adding SW and HW flags to these commands. If no flag is specified, then only start / stop monitoring software drops. This is done in order to maintain backward-compatibility with existing user space applications. Signed-off-by:
-
Ido Schimmel authored
In summary alert mode a notification is sent with a list of recent drop reasons and a count of how many packets were dropped due to this reason. To avoid expensive operations in the context in which packets are dropped, each CPU holds an array whose number of entries is the maximum number of drop reasons that can be encoded in the netlink notification. Each entry stores the drop reason and a count. When a packet is dropped the array is traversed and a new entry is created or the count of an existing entry is incremented. Later, in process context, the array is replaced with a newly allocated copy and the old array is encoded in a netlink notification. To avoid breaking user space, the notification includes the ancillary header, which is 'struct net_dm_alert_msg' with number of entries set to '0'. Signed-off-by:
-
Ido Schimmel authored
In a similar fashion to software drops, extend drop monitor to send netlink events when packets are dropped by the underlying hardware. The main difference is that instead of encoding the program counter (PC) from which kfree_skb() was called in the netlink message, we encode the hardware trap name. The two are mostly equivalent since they should both help the user understand why the packet was dropped. Signed-off-by:
-
Ido Schimmel authored
The drop monitor configuration (e.g., alert mode) is global, but user will be able to enable monitoring of only software or hardware drops. Therefore, ensure that monitoring of both software and hardware drops are disabled before allowing drop monitor configuration to take place. Signed-off-by:
-
Ido Schimmel authored
Export a function that can be invoked in order to report packets that were dropped by the underlying hardware along with metadata. Subsequent patches will add support for the different alert modes. Signed-off-by:
-
Ido Schimmel authored
Like software drops, hardware drops also need the same type of per-CPU data. Therefore, initialize it during module initialization and de-initialize it during module exit. Signed-off-by:
-
Ido Schimmel authored
Currently drop monitor only reports software drops to user space, but subsequent patches are going to add support for hardware drops. Like software drops, the per-CPU data of hardware drops needs to be initialized and de-initialized upon module initialization and exit. To avoid code duplication, break this code into separate functions, so that these could be re-used for hardware drops. No functional changes intended. Signed-off-by:
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== net: bridge: mdb: allow dump/add/del of host-joined entries This set makes the bridge dump host-joined mdb entries, they should be treated as normal entries since they take a slot and are aging out. We already have notifications for them but we couldn't dump them until now so they remained hidden. We dump them similar to how they're notified, in order to keep user-space compatibility with the dumped objects (e.g. iproute2 dumps mdbs in a format which can be fed into add/del commands) we allow host-joined groups also to be added/deleted via mdb commands. That can later be used for L2 mcast MAC manipulation as was recently discussed. Note that iproute2 changes are not necessary, this set will work with the current user-space mdb code. Patch 01 - a trivial comment move Patch 02 - factors out the mdb filling code so it can be re-used for the host-joined entries Patch 03 - dumps host-joined entries Patch 04 - allows manipulation of host-joined entries via standard mdb calls v3: fix compiler warning in patch 04 (DaveM) v2: change patch 04 to avoid double notification and improve host group manual removal if no ports are present in the group ==================== Signed-off-by: -
Nikolay Aleksandrov authored
Currently this is needed only for user-space compatibility, so similar object adds/deletes as the dumped ones would succeed. Later it can be used for L2 mcast MAC add/delete. v3: fix compiler warning (DaveM) v2: don't send a notification when used from user-space, arm the group timer if no ports are left after host entry del Signed-off-by:Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Currently we dump only the port mdb entries but we can have host-joined entries on the bridge itself and they should be treated as normal temp mdbs, they're already notified: $ bridge monitor all [MDB]dev br0 port br0 grp ff02::8 temp The group will not be shown in the bridge mdb output, but it takes 1 slot and it's timing out. If it's only host-joined then the mdb show output can even be empty. After this patch we show the host-joined groups: $ bridge mdb show dev br0 port br0 grp ff02::8 temp Signed-off-by:
-
Nikolay Aleksandrov authored
We have to factor out the mdb fill portion in order to re-use it later for the bridge mdb entries. No functional changes intended. Signed-off-by:
-
Nikolay Aleksandrov authored
Trivial patch to move the vlan comments in their proper places above the vid 0 checks. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: remove genphy_config_init Supported PHY features are either auto-detected or explicitly set. In both cases calling genphy_config_init isn't needed. All that genphy_config_init does is removing features that are set as supported but can't be auto-detected. Basically it duplicates the code in genphy_read_abilities. Therefore remove genphy_config_init. v2: - remove call also from new adin driver v3: - pass NULL as config_init function pointer for dp83848 ==================== Signed-off-by: -
Heiner Kallweit authored
Now that all users have been removed we can remove genphy_config_init. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Supported PHY features are either auto-detected or explicitly set. In both cases calling genphy_config_init isn't needed. Signed-off-by:
-
Heiner Kallweit authored
Supported PHY features are either auto-detected or explicitly set. In both cases calling genphy_config_init isn't needed. All that genphy_config_init does is removing features that are set as supported but can't be auto-detected. Basically it duplicates the code in genphy_read_abilities. Therefore remove such calls from all PHY drivers. v2: - remove call also from new adin PHY driver v3: - pass NULL as config_init function pointer for dp83848 Signed-off-by:
-
- 16 Aug, 2019 17 commits
-
-
Bill Sommerfeld authored
Allow encapsulated packets sent to tunnels layered over ipvlan to use offloads rather than forcing SW fallbacks. Since commit f21e5077 ("macvlan: add offload features for encapsulation"), macvlan has set dev->hw_enc_features to include everything in dev->features; do likewise in ipvlan. Signed-off-by:
Bill Sommerfeld <wsommerfeld@google.com> Acked-by:
Mahesh Bandewar <maheshb@google.com> Signed-off-by:
-
David Ahern authored
Dan reported: The patch acda655f: "selftests: Add nettest" from Aug 1, 2019, leads to the following static checker warning: ./tools/testing/selftests/net/nettest.c:1690 main() warn: unsigned 'tmp' is never less than zero. ./tools/testing/selftests/net/nettest.c 1680 case '1': 1681 args.has_expected_raddr = 1; 1682 if (convert_addr(&args, optarg, 1683 ADDR_TYPE_EXPECTED_REMOTE)) 1684 return 1; 1685 1686 break; 1687 case '2': 1688 if (str_to_uint(optarg, 0, 0x7ffffff, &tmp) != 0) { 1689 tmp = get_ifidx(optarg); 1690 if (tmp < 0) { "tmp" is unsigned so it can't be negative. Also all the callers assume that get_ifidx() returns negatives on error but it looks like it really returns zero on error so it's a bit unclear to me. Update get_ifidx to return -1 on errors and cleanup callers of it. Fixes: acda655f ("selftests: Add nettest") Reported-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Marek Behún authored
The mv88e6xxx_port_setup_mac checks if the requested MAC settings are different from the current ones, and if not, does nothing (since chaning them requires putting the link down). In this check it only looks if the triplet [link, speed, duplex] is being changed. This patch adds support to also check if the mode parameter (of type phy_interface_t) is requested to be changed. The current mode is computed by the ->port_link_state() method, and if it is different from PHY_INTERFACE_MODE_NA, we check for equality with the requested mode. In the implementations of the mv88e6250_port_link_state() method we set the current mode to PHY_INTERFACE_MODE_NA - so the code does not check for mode change on 6250. In the mv88e6352_port_link_state() method, we use the cached cmode of the port to determine the mode as phy_interface_t (and if it is not enough, eg. for RGMII, we also look at the port control register for RX/TX timings). Signed-off-by:
Marek Behún <marek.behun@nic.cz> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
Alexandru Ardelean says: ==================== net: phy: adin: add support for Analog Devices PHYs This changeset adds support for Analog Devices Industrial Ethernet PHYs. Particularly the PHYs this driver adds support for: * ADIN1200 - Robust, Industrial, Low Power 10/100 Ethernet PHY * ADIN1300 - Robust, Industrial, Low Latency 10/100/1000 Gigabit Ethernet PHY The 2 chips are register compatible with one another. The main difference being that ADIN1200 doesn't operate in gigabit mode. The chips can be operated by the Generic PHY driver as well via the standard IEEE PHY registers (0x0000 - 0x000F) which are supported by the kernel as well. This assumes that configuration of the PHY has been done completely in HW, according to spec, i.e. no extra SW configuration required. This changeset also implements the ability to configure the chips via SW registers. Datasheets: https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1300.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1200.pdf ==================== Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
Alexandru Ardelean authored
This change adds bindings for the Analog Devices ADIN PHY driver, detailing all the properties implemented by the driver. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Alexandru Ardelean authored
This change implements retrieving all the error counters from the PHY. The counters require that the RxErrCnt register (0x0014) be read first, after which copies of the counters are latched into the registers. This ensures that all registers read after RxErrCnt are synchronized at the moment that they are read. The counter values need to be accumulated by the driver, as each time that RxErrCnt is read, the values that are latched are the ones that have incremented from the last read. Signed-off-by:
-
Alexandru Ardelean authored
Down-speed auto-negotiation may not always be enabled, in which case the PHY won't down-shift to 100 or 10 during auto-negotiation. This change enables downshift and configures the number of retries to default 4 (which is also in the datasheet The downshift control mechanism can also be controlled via the phy-tunable interface (ETHTOOL_PHY_DOWNSHIFT control). The change has been adapted from the Aquantia PHY driver. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
-
Alexandru Ardelean authored
The ADIN PHYs supports 4 types of reset: 1. The standard PHY reset via BMCR_RESET bit in MII_BMCR reg 2. Reset via GPIO 3. Reset via reg GeSftRst (0xff0c) & reload previous pin configs 4. Reset via reg GeSftRst (0xff0c) & request new pin configs Resets 2, 3 & 4 are almost identical, with the exception that the crystal oscillator is available during reset for 2. This change implements subsystem software reset via the GeSftRst and reloading the previous pin configuration (so reset number 3). This will also reset the PHY core regs (similar to reset 1). Since writing bit 1 to reg GeSftRst is self-clearing, the only thing that can be done, is to write to that register, wait a specific amount of time (10 milliseconds should be enough) and try to read back and check if there are no errors on read. A busy-wait-read won't work well, and may sometimes work or not work. In case phylib is configured to also do a reset via GPIO, the ADIN PHY may be reset twice when the PHY device registers, but that isn't a problem, since it's being done on boot (or PHY device register). Signed-off-by:
-
Alexandru Ardelean authored
The ADIN1200 & ADIN1300 PHYs support EEE by using standard Clause 45 access to access MMD registers for EEE. The EEE register addresses (when using Clause 22) are available at different addresses (than Clause 45), and since accessing these regs (via Clause 22) needs a special mechanism, a translation table is required to convert these addresses. For Clause 45, this is not needed since the driver will likely never use this access mode. Reviewed-by:
-
Alexandru Ardelean authored
The ADIN PHYs support automatic MDI/MDIX negotiation. By default this is disabled, so this is enabled at `config_init`. This is controlled via the PHY Control 1 register. The supported modes are: 1. Manual MDI 2. Manual MDIX 3. Auto MDIX - prefer MDIX 4. Auto MDIX - prefer MDI The phydev mdix & mdix_ctrl fields include modes 3 & 4 into a single auto-mode. So, the default mode this driver enables is 4 when Auto-MDI mode is used. When detecting MDI/MDIX mode, a combination of the PHY Control 1 register and PHY Status 1 register is used to determine the correct MDI/MDIX mode. If Auto-MDI mode is not set, then the manual MDI/MDIX mode is returned. If Auto-MDI mode is set, then MDIX mode is returned differs from the preferred MDI/MDIX mode. This covers all cases where: 1. MDI preferred & Pair01Swapped == MDIX 2. MDIX preferred & Pair01Swapped == MDI 3. MDI preferred & ! Pair01Swapped == MDIX 4. MDIX preferred & ! Pair01Swapped == MDI The preferred MDI/MDIX mode is not configured via SW, but can be configured via HW pins. Note that the `Pair01Swapped` is the Green-Yellow physical pairs. Reviewed-by:
-
Alexandru Ardelean authored
The FIFO depth can be configured for the RMII mode. This change adds support for doing this via device-tree (or ACPI). Reviewed-by:
-
Alexandru Ardelean authored
The internal delays for the RGMII are configurable for both RX & TX. This change adds support for configuring them via device-tree (or ACPI). Reviewed-by:
-
Alexandru Ardelean authored
The ADIN1300 chip supports RGMII, RMII & MII modes. Default (if unconfigured) is RGMII. This change adds support for configuring these modes via the device registers. For RGMII with internal delays (modes RGMII_ID,RGMII_TXID, RGMII_RXID), the default delay is 2 ns. This can be configurable and will be done in a subsequent change. Reviewed-by:
-
Alexandru Ardelean authored
Both ADIN1200 & ADIN1300 support Clause 45 access for some registers. The Extended Management Interface (EMI) registers are accessible via both Clause 45 (at register MDIO_MMD_VEND1) and using Clause 22. The Clause 22 access for MMD regs differs from the standard one defined by 802.3. The ADIN PHYs use registers ExtRegPtr (0x0010) and ExtRegData (0x0011) to access Clause 45 & EMI registers. The indirect access is done via the following mechanism (for both R/W): 1. Write the address of the register in the ExtRegPtr 2. Read/write the value of the register via reg ExtRegData This mechanism is needed to manage configuration of chip settings and to access EEE registers via Clause 22. Since Clause 45 access will likely never be used, it is not implemented via this hook. Reviewed-by:
-
Alexandru Ardelean authored
This change hooks link-status-change interrupts to phylib. Reviewed-by:
-
Alexandru Ardelean authored
The chip supports standard suspend/resume via BMCR reg. Hook these functions into the `adin` driver. Reviewed-by:
-
Alexandru Ardelean authored
This change adds support for Analog Devices Industrial Ethernet PHYs. Particularly the PHYs this driver adds support for: * ADIN1200 - Robust, Industrial, Low Power 10/100 Ethernet PHY * ADIN1300 - Robust, Industrial, Low Latency 10/100/1000 Gigabit Ethernet PHY The 2 chips are register compatible with one another. The main difference being that ADIN1200 doesn't operate in gigabit mode. The chips can be operated by the Generic PHY driver as well via the standard IEEE PHY registers (0x0000 - 0x000F) which are supported by the kernel as well. This assumes that configuration of the PHY has been done completely in HW, according to spec. Configuration can also be done via registers, which will be supported by this driver. Datasheets: https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1300.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1200.pdfReviewed-by:
-
- 15 Aug, 2019 1 commit
-
-
David S. Miller authored
Antoine Tenart says: ==================== net: mscc: PTP Hardware Clock (PHC) support This series introduces the PTP Hardware Clock (PHC) support to the Mscc Ocelot switch driver. In order to make use of this, a new register bank is added and described in the device tree, as well as a new interrupt. The use this bank and interrupt was made optional in the driver for dt compatibility reasons. Thanks! Antoine Since v5: - Made sure both the PTP interrupt and register bank were available to enable supporting h/w timestamping. - Added a check after a kzalloc. - Add Reviewed-by tags from Andrew. Since v4: - Added SKBTX_IN_PROGRESS. - Fixed two xmas trees. - Rework the loop condition in ocelot_ptp_rdy_irq_handler. Since v3: - Fixed a spin_unlock_irqrestore issue. Since v2: - Prevented from a possible infinite loop when reading the h/w timestamps. - s/GFP_KERNEL/GFP_ATOMIC/ in the Tx path. - Set rx_filter to HWTSTAMP_FILTER_PTP_V2_EVENT at probe. - Fixed s/w timestamping dependencies. - Added Paul Burton's Acked-by on patches 2 and 4. Since v1: - Used list_for_each_safe() in ocelot_deinit(). - Fixed a memory leak in ocelot_deinit() by calling dev_kfree_skb_any(). - Fixed a locking issue in get_hwtimestamp(). - Handled the NULL case of ptp_clock_register(). - Added comments on optional dt properties. ==================== Signed-off-by:
-
