- 14 Mar, 2022 16 commits
-
-
Ioana Ciornei authored
This patch integrates the dpaa2-eth driver with the generic PHY infrastructure in order to search, find and reconfigure the SerDes lanes in case of a protocol change. On the .mac_config() callback, the phy_set_mode_ext() API is called so that the Lynx 28G SerDes PHY driver can change the lane's configuration. In the same phylink callback the MC firmware is called so that it reconfigures the MAC side to run using the new protocol. The consumer drivers - dpaa2-eth and dpaa2-switch - are updated to call the dpaa2_mac_start/stop functions newly added which will power_on/power_off the associated SerDes lane. Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ioana Ciornei authored
The logic to setup the supported interfaces will get annotated based on what the configuration of the SerDes PLLs supports. Move the current setup into a separate function just to try to keep it clean. Signed-off-by:
-
Ioana Ciornei authored
Retrieve the API version running on the firmware and based on it detect which features are available for usage. The first one to be listed is the capability to change the MAC protocol at runtime. Signed-off-by:
-
Ioana Ciornei authored
The MC firmware gained recently a new command which can reconfigure the running protocol on the underlying MAC. Add this new command which will be used in the next patches in order to do a major reconfig on the interface. Signed-off-by:
-
Ioana Ciornei authored
The dpmac_get_api_version command will be used in the next patches to determine if the current firmware is capable or not to change the Ethernet protocol running on the MAC. Signed-off-by:
-
Ioana Ciornei authored
Add device tree binding for the Lynx 28G SerDes PHY driver used on Layerscape based SoCs. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Ioana Ciornei authored
This patch adds a new generic PHY driver to support the Lynx 28G SerDes block found on some of the Layerscape SoCs such as LX2160A. At the moment, only the following Ethernet protocols are supported: SGMII/1000Base-X and 10GBaseR. SerDes lanes which are not running an Ethernet protocol or a currently supported Ethenet protocol will be left as it was configured through the RCW (Reset Configuration Word) at boot time. At probe time, the platform driver will read the current configuration of both PLLs found on a SerDes block and will determine what protocols are supported using that PLL. For example, if a PLL is configured to generate a clock net (frate) of 5GHz the only protocols sustained by that PLL are SGMII/1000Base-X (using a quarter of the full clock rate) and QSGMII using the full clock net frequency on the lane. On the .set_mode() callback, the PHY driver will first check if the requested operating mode (protocol) is even supported by the current PLL configuration and will error out if not. Then, the lane is reconfigured to run on the requested protocol. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Basic QoS classification on Felix DSA switch using dcbnl Basic QoS classification for Ocelot switches means port-based default priority, DSCP-based and VLAN PCP based. This is opposed to advanced QoS classification which is done through the VCAP IS1 TCAM based engine. The patch set is a logical continuation of this RFC which attempted to describe the default-prio as a matchall entry placed at the end of a series of offloaded tc filters: https://patchwork.kernel.org/project/netdevbpf/cover/20210113154139.1803705-1-olteanv@gmail.com/ I have tried my best to satisfy the feedback that we should cater for pre-configured QoS profiles. Ironically, the only pre-configured QoS profile that the Felix switch driver has is for VLAN PCP (1:1 mapping with QoS class), yet IEEE 802.1Q or dcbnl offer no mechanism for reporting or changing that. Testing was done with the iproute2 dcb app. The qos_class of packets was dumped from net/dsa/tag_ocelot.c. (1) $ dcb app show dev swp3 default-prio 0 (2) $ dcb app replace dev swp3 default-prio 3 (3) $ dcb app replace dev swp3 dscp-prio CS3:5 (4) $ dcb app replace dev swp3 dscp-prio CS2:2 (5) $ dcb app show dev swp3 default-prio 3 dscp-prio CS2:2 CS3:5 Traffic sent with "ping -Q 64 <ipaddr>", which means CS2. These packets match qos_class 0 after command (1), qos_class 3 after command (2), qos_class 3 after command (3), and qos_class 2 after command (2). ==================== Signed-off-by:
-
Vladimir Oltean authored
Follow the established programming model for this driver and provide shims in the felix DSA driver which call the implementations from the ocelot switch lib. The ocelot switchdev driver wasn't integrated with dcbnl due to lack of hardware availability. The switch doesn't have any fancy QoS classification enabled by default. The provided getters will create a default-prio app table entry of 0, and no dscp entry. However, the getters have been made to actually retrieve the hardware configuration rather than static values, to be future proof in case DSA will need this information from more call paths. For default-prio, there is a single field per port, in ANA_PORT_QOS_CFG, called QOS_DEFAULT_VAL. DSCP classification is enabled per-port, again via ANA_PORT_QOS_CFG (field QOS_DSCP_ENA), and individual DSCP values are configured as trusted or not through register ANA_DSCP_CFG (replicated 64 times). An untrusted DSCP value falls back to other QoS classification methods. If trusted, the selected ANA_DSCP_CFG register also holds the QoS class in the QOS_DSCP_VAL field. The hardware also supports DSCP remapping (DSCP value X is translated to DSCP value Y before the QoS class is determined based on the app table entry for Y) and DSCP packet rewriting. The dcbnl framework, for being so flexible in other useless areas, doesn't appear to support this. So this functionality has been left out. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Similar to the port-based default priority, IEEE 802.1Q-2018 allows the Application Priority Table to define QoS classes (0 to 7) per IP DSCP value (0 to 63). In the absence of an app table entry for a packet with DSCP value X, QoS classification for that packet falls back to other methods (VLAN PCP or port-based default). The presence of an app table for DSCP value X with priority Y makes the hardware classify the packet to QoS class Y. As opposed to the default-prio where DSA exposes only a "set" in dsa_switch_ops (because the port-based default is the fallback, it always exists, either implicitly or explicitly), for DSCP priorities we expose an "add" and a "del". The addition of a DSCP entry means trusting that DSCP priority, the deletion means ignoring it. Drivers that already trust (at least some) DSCP values can describe their configuration in dsa_switch_ops :: port_get_dscp_prio(), which is called for each DSCP value from 0 to 63. Again, there can be more than one dcbnl app table entry for the same DSCP value, DSA chooses the one with the largest configured priority. Signed-off-by:
-
Vladimir Oltean authored
The port-based default QoS class is assigned to packets that lack a VLAN PCP (or the port is configured to not trust the VLAN PCP), an IP DSCP (or the port is configured to not trust IP DSCP), and packets on which no tc-skbedit action has matched. Similar to other drivers, this can be exposed to user space using the DCB Application Priority Table. IEEE 802.1Q-2018 specifies in Table D-8 - Sel field values that when the Selector is 1, the Protocol ID value of 0 denotes the "Default application priority. For use when application priority is not otherwise specified." The way in which the dcbnl integration in DSA has been designed has to do with its requirements. Andrew Lunn explains that SOHO switches are expected to come with some sort of pre-configured QoS profile, and that it is desirable for this to come pre-loaded into the DSA slave interfaces' DCB application priority table. In the dcbnl design, this is possible because calls to dcb_ieee_setapp() can be initiated by anyone including being self-initiated by this device driver. However, what makes this challenging to implement in DSA is that the DSA core manages the net_devices (effectively hiding them from drivers), while drivers manage the hardware. The DSA core has no knowledge of what individual drivers' QoS policies are. DSA could export to drivers a wrapper over dcb_ieee_setapp() and these could call that function to pre-populate the app priority table, however drivers don't have a good moment in time to do this. The dsa_switch_ops :: setup() method gets called before the net_devices are created (dsa_slave_create), and so is dsa_switch_ops :: port_setup(). What remains is dsa_switch_ops :: port_enable(), but this gets called upon each ndo_open. If we add app table entries on every open, we'd need to remove them on close, to avoid duplicate entry errors. But if we delete app priority entries on close, what we delete may not be the initial, driver pre-populated entries, but rather user-added entries. So it is clear that letting drivers choose the timing of the dcb_ieee_setapp() call is inappropriate. The alternative which was chosen is to introduce hardware-specific ops in dsa_switch_ops, and effectively hide dcbnl details from drivers as well. For pre-populating the application table, dsa_slave_dcbnl_init() will call ds->ops->port_get_default_prio() which is supposed to read from hardware. If the operation succeeds, DSA creates a default-prio app table entry. The method is called as soon as the slave_dev is registered, but before we release the rtnl_mutex. This is done such that user space sees the app table entries as soon as it sees the interface being registered. The fact that we populate slave_dev->dcbnl_ops with a non-NULL pointer changes behavior in dcb_doit() from net/dcb/dcbnl.c, which used to return -EOPNOTSUPP for any dcbnl operation where netdev->dcbnl_ops is NULL. Because there are still dcbnl-unaware DSA drivers even if they have dcbnl_ops populated, the way to restore the behavior is to make all dcbnl_ops return -EOPNOTSUPP on absence of the hardware-specific dsa_switch_ops method. The dcbnl framework absurdly allows there to be more than one app table entry for the same selector and protocol (in other words, more than one port-based default priority). In the iproute2 dcb program, there is a "replace" syntactical sugar command which performs an "add" and a "del" to hide this away. But we choose the largest configured priority when we call ds->ops->port_set_default_prio(), using __fls(). When there is no default-prio app table entry left, the port-default priority is restored to 0. Link: https://patchwork.kernel.org/project/netdevbpf/patch/20210113154139.1803705-2-olteanv@gmail.com/Signed-off-by:
-
Victor Nogueira authored
Some tests, such as Test d052: Add 1M filters with the same action, may not work with a small timeout value. Increase timeout to 24 seconds. Signed-off-by:
Victor Nogueira <victor@mojatatu.com> Acked-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
____napi_schedule() needs to be invoked with disabled interrupts due to __raise_softirq_irqoff (in order not to corrupt the per-CPU list). ____napi_schedule() needs also to be invoked from an interrupt context so that the raised-softirq is processed while the interrupt context is left. Add lockdep asserts for both conditions. While this is the second time the irq/softirq check is needed, provide a generic lockdep_assert_softirq_will_run() which is used by both caller. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
David S. Miller authored
Ziyang Xuan says: ==================== net: macvlan: fix potential UAF problem for lowerdev Add the reference operation to lowerdev of macvlan to avoid the potential UAF problem under the following known scenario: Someone module puts the NETDEV_UNREGISTER event handler to a work, and lowerdev is accessed in the work handler. But when the work is excuted, lowerdev has been destroyed because upper macvlan did not get reference to lowerdev correctly. In addition, add net device refcount tracker to macvlan. ==================== Signed-off-by: -
Ziyang Xuan authored
Add net device refcount tracker to macvlan. Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by:
-
Ziyang Xuan authored
Add the reference operation to lowerdev of macvlan to avoid the potential UAF problem under the following known scenario: Someone module puts the NETDEV_UNREGISTER event handler to a work, and lowerdev is accessed in the work handler. But when the work is excuted, lowerdev has been destroyed because upper macvlan did not get reference to lowerdev correctly. That likes as the scenario occurred by commit 563bcbae ("net: vlan: fix a UAF in vlan_dev_real_dev()"). Signed-off-by:
-
- 13 Mar, 2022 14 commits
-
-
David S. Miller authored
Merge tag 'linux-can-next-for-5.18-20220313' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next linux-can-next-for-5.18-20220313 Marc Kleine-Budde says: ==================== pull-request: can-next 2022-03-13 this is a pull request of 13 patches for net-next/master. The 1st patch is by me and fixes the freeing of a skb in the vxcan driver (initially added in this net-next window). The remaining 12 patches are also by me and target the mcp251xfd driver. The first patch fixes a printf modifier (initially added in this net-next window). The remaining patches add ethtool based ring and RX/TX IRQ coalescing support to the driver. ==================== Signed-off-by:
-
Marc Kleine-Budde authored
This patch increases the number of RX-FIFOs to 3 and the max TX-FIFO depth to 16. This leads to the following default ring configuration. CAN-2.0 mode: | FIFO setup: TEF: 0x400: 8*12 bytes = 96 bytes | FIFO setup: RX-0: FIFO 1/0x460: 32*20 bytes = 640 bytes | FIFO setup: RX-1: FIFO 2/0x6e0: 32*20 bytes = 640 bytes | FIFO setup: RX-2: FIFO 3/0x960: 16*20 bytes = 320 bytes | FIFO setup: TX: FIFO 4/0xaa0: 8*16 bytes = 128 bytes | FIFO setup: free: 224 bytes CAN-FD mode: | FIFO setup: TEF: 0x400: 4*12 bytes = 48 bytes | FIFO setup: RX-0: FIFO 1/0x430: 16*76 bytes = 1216 bytes | FIFO setup: RX-1: FIFO 2/0x8f0: 4*76 bytes = 304 bytes | FIFO setup: TX: FIFO 3/0xa20: 4*72 bytes = 288 bytes | FIFO setup: free: 192 bytes With the previously added ethtool ring configuration support the RAM on the chip can now be runtime configured between RX and TX buffers. Link: https://lore.kernel.org/20220313083640.501791-13-mkl@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch adds support ethtool based configuration for the TX IRQ coalescing added in the previous patch. Link: https://lore.kernel.org/20220313083640.501791-12-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds TX IRQ coalescing support to the driver. The implemented algorithm is similar to the RX IRQ coalescing support added in the previous patch. Link: https://lore.kernel.org/20220313083640.501791-11-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds support ethtool based configuration for the RX IRQ coalescing added in the previous patch. Link: https://lore.kernel.org/20220313083640.501791-10-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds RX IRQ coalescing support to the driver. The mcp251xfd chip doesn't support proper hardware based coalescing, so this patch tries to implemented it in software. The RX-FIFO offers a "FIFO not empty" interrupt, which is used if no coalescing is active. With activated RX IRQ coalescing the "FIFO not empty" interrupt is disabled in the RX IRQ handler and the "FIFO half full" or "FIFO full interrupt" (depending on RX max coalesced frames IRQ) is used instead. To avoid RX CAN frame starvation a hrtimer is setup with RX coalesce usecs IRQ,on timer expiration the "FIFO not empty" is enabled again. Support for ethtool configuration is added in the next patch. Link: https://lore.kernel.org/20220313083640.501791-9-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds runtime configurable RX and TX ring parameters via ethtool to the driver. Link: https://lore.kernel.org/20220313083640.501791-8-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
So far the configuration of the hardware FIFOs is hard coded and depend only on the selected CAN mode (CAN-2.0 or CAN-FD). This patch updates the macros describing the ring, FIFO and RAM layout to prepare for the next patches that add support for runtime configurable ring parameters via ethtool. Link: https://lore.kernel.org/20220313083640.501791-7-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch prepares the driver for runtime configurable RX and TX ring parameters. The actual runtime config support will be added in the next patch. Link: https://lore.kernel.org/20220313083640.501791-6-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds basic ethtool support (to query the current and maximum ring parameters) to the driver. Link: https://lore.kernel.org/20220313083640.501791-5-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds support for coalescing to the RAM layout calculation. Link: https://lore.kernel.org/20220313083640.501791-4-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds a helper function to calculate the ring configuration of the controller based on various constraints, like available RAM, size of RX and TX objects, CAN-mode, number of FIFOs and FIFO depth. Link: https://lore.kernel.org/20220313083640.501791-3-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
In case of an erroneous ring configuration more RAM than available might be used. Change the printf modifier to a signed int to properly print this erroneous value. Fixes: 83daa863 ("can: mcp251xfd: ring: update FIFO setup debug info") Link: https://lore.kernel.org/20220313083640.501791-2-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch fixes the freeing of the "oskb", by using kfree_skb() instead of kfree(). Fixes: 1574481b ("vxcan: remove sk reference in peer skb") Link: https://lore.kernel.org/all/20220311123741.382618-1-mkl@pengutronix.de Cc: Oliver Hartkopp <socketcan@hartkopp.net> Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 12 Mar, 2022 10 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== ice: GTP support in switchdev Marcin Szycik says: Add support for adding GTP-C and GTP-U filters in switchdev mode. To create a filter for GTP, create a GTP-type netdev with ip tool, enable hardware offload, add qdisc and add a filter in tc: ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize> ethtool -K $PF0 hw-tc-offload on tc qdisc add dev $GTP0 ingress tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \ action mirred egress redirect dev $VF1_PR By default, a filter for GTP-U will be added. To add a filter for GTP-C, specify enc_dst_port = 2123, e.g.: tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \ enc_dst_port 2123 action mirred egress redirect dev $VF1_PR Note: outer IPv6 offload is not supported yet. Note: GTP-U with no payload offload is not supported yet. ICE COMMS package is required to create a filter as it contains GTP profiles. Changes in iproute2 [1] are required to be able to add GTP netdev and use GTP-specific options (QFI and PDU type). [1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel.com/T --- v2: Add more CC v3: Fix mail thread, sorry for spam v4: Add GTP echo response in gtp module v5: Change patch order v6: Add GTP echo request in gtp module v7: Fix kernel-docs in ice v8: Remove handling of GTP Echo Response v9: Add sending of multicast message on GTP Echo Response, fix GTP-C dummy packet selection v10: Rebase, fixed most 80 char line limits v11: Rebase, collect Harald's Reviewed-by on patch 3 ==================== Signed-off-by:
-
Oleksij Rempel authored
In case external PHY is used, we need to take care of embedded PHY. Since there are no methods to disable this PHY from the MAC side and keeping RMII reference clock, we need to suspend it. This patch will reduce electrical noise (PHY is continuing to send FLPs) and power consumption by 0,22W. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
-
Oleksij Rempel authored
In most cases we use own mdio bus, there is no need to create and store string for the PHY address. Signed-off-by:
-
Oleksij Rempel authored
We already read chipid on probe. There is no need to read it on reset. Signed-off-by:
-
Oleksij Rempel authored
The only difference is the reset code, so remove not needed duplicates. Signed-off-by:
-
Eric Dumazet authored
Before adding yet another possibly contended atomic_long_t, it is time to add per-cpu storage for existing ones: dev->tx_dropped, dev->rx_dropped, and dev->rx_nohandler Because many devices do not have to increment such counters, allocate the per-cpu storage on demand, so that dev_get_stats() does not have to spend considerable time folding zero counters. Note that some drivers have abused these counters which were supposed to be only used by core networking stack. v4: should use per_cpu_ptr() in dev_get_stats() (Jakub) v3: added a READ_ONCE() in netdev_core_stats_alloc() (Paolo) v2: add a missing include (reported by kernel test robot <lkp@intel.com>) Change in netdev_core_stats_alloc() (Jakub) Signed-off-by:Eric Dumazet <edumazet@google.com> Cc: jeffreyji <jeffreyji@google.com> Reviewed-by:
Brian Vazquez <brianvv@google.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Acked-by:
Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/20220311051420.2608812-1-eric.dumazet@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Simon Horman says: ==================== nfp: preliminary support for NFP-3800 This series is the first step to add support to the NFP driver for the new NFP-3800 device. In this first series the goal is to clean up small issues found while adding support for the new device, prepare an abstraction of the differences between the already supported devices and the new Kestrel device and add the new PCI ID. * Patch 1/11 and 2/11 starts by removing some dead code and incorrect assumptions found while working Kestrel support. Patch 3/11, 4/11 and 5/11 cleans up and prepares for adding the new PCI ID for Kestrel. * Patches 6/11, 7/11, 8/11, 9/11, 10/11 adds, plumb and populates a device information structure to abstract the differences between the existed supported devices (NFP-4000, NFP-5000 and NFP-6000) and the new device (NFP3800). * Finally patch 11/11 adds the new PCI ID for Kestrel. More work is needed to drive the new NFP-3800 device after this first batch of patches the foundation is prepared for the follow up work. Thanks to the work of all those who contributed to this work. ==================== Link: https://lore.kernel.org/r/20220311104306.28357-1-simon.horman@corigine.comSigned-off-by:
-
Dirk van der Merwe authored
Enable binding the nfp driver to NFP3800 and NFP3803 devices. The PCIE_SRAM offset is different for the NFP3800 device, which also only supports a single explicit group. Changes to Dirk's work: * 48-bit dma addressing is not ready yet. Keep 40-bit dma addressing for NFP3800. Signed-off-by:
Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Fei Qin <fei.qin@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Jakub Kicinski authored
NFP3800 has slightly different queue controller range bounds. Use the static chip data instead of defines. This commit still assumes unchanged descriptor format. Later datapath changes will allow adjusting for descriptor accounting. Signed-off-by:
-
Jakub Kicinski authored
The queue controller (QCP) is accessed based on a device specific offset. The NFP3800 device also supports more queues. Furthermore, the NFP3800 VFs also access the QCP differently to how the NFP6000 VFs accesses it, though still indirectly. Fortunately, we can remove the offset all together for both VF types. This is safe for NFP6000 VFs since the offset was effectively a wrap around and only used for convenience to have it set the same as the NFP6000 PF. Use nfp_dev_info to store queue controller parameters. Signed-off-by:
-
