aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-08-17octeontx2-pf: Unify flow management variablesSunil Goutham4-46/+80
Variables used for TC flow management like maximum number of flows, number of flows installed etc are a copy of ntuple flow management variables. Since both TC and NTUPLE are not supported at the same time, it's better to unify these with common variables. This patch addresses this unification and also does cleanup of other minor stuff wrt TC. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-17octeontx2-pf: Sort the allocated MCAM entry indicesSunil Goutham1-0/+15
Per single mailbox request a maximum of 256 MCAM entries can be allocated. If more than 256 are being allocated, then the mcam indices in the final list could get jumbled. Hence sort the indices. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-17octeontx2-pf: Ntuple filters support for VF netdevRakesh Babu5-60/+98
Add packet flow classification support for both LMAC mapped virtual functions and loopback VFs. This patch adds supports for ntuple offload feature. Signed-off-by: Rakesh Babu <rsaladi2@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-17octeontx2-pf: Enable NETIF_F_RXALL support for VF driverSunil Goutham2-4/+4
Enabled NETIF_F_RXALL support for VF driver. Also removed MTU range comments which are no longer valid. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-17octeontx2-af: Add debug messages for failuresSunil Goutham1-19/+73
Added debug messages for various failures during probe. This will help in quickly identifying the API where the failure is happening. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-17octeontx2-af: add proper return codes for AF mailbox handlersNaveen Mamindlapalli4-21/+47
Add appropriate error codes to be used when returning from AF mailbox handlers due to some error condition. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-17octeontx2-af: Modify install flow error codesSubbaraya Sundeep2-8/+15
When installing a flow using npc_install_flow mailbox there are number of reasons to reject the request like caller is not permitted, invalid channel specified in request, flow not supported in extraction profile and so on. Hence define new error codes for npc flows and use them instead of generic error codes. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-17Merge tag 'mlx5-updates-2021-08-16' of ↵David S. Miller19-716/+1696
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2021-08-16 The following patchset provides two separate mlx5 updates 1) Ethtool RSS context and MQPRIO channel mode support: 1.1) enable mlx5e netdev driver to allow creating Transport Interface RX (TIRs) objects on the fly to be used for ethtool RSS contexts and TX MQPRIO channel mode 1.2) Introduce mlx5e_rss object to manage such TIRs. 1.3) Ethtool support for RSS context 1.4) Support MQPRIO channel mode 2) Bridge offloads Lag support: to allow adding bond net devices to mlx5 bridge 2.1) Address bridge port by (vport_num, esw_owner_vhca_id) pair since vport_num is only unique per eswitch and in lag mode we need to manage ports from both eswitches. 2.2) Allow connectivity between representors of different eswitch instances that are attached to same bridge 2.3) Bridge LAG, Require representors to be in shared FDB mode and introduce local and peer ports representors, match on paired eswitch metadata in peer FDB entries, And finally support addition/deletion and aging of peer flows. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16tcp: enable data-less, empty-cookie SYN with TFO_SERVER_COOKIE_NOT_REQDLuke Hsiao1-2/+1
Since the original TFO server code was implemented in commit 168a8f58059a22feb9e9a2dcc1b8053dbbbc12ef ("tcp: TCP Fast Open Server - main code path") the TFO server code has supported the sysctl bit flag TFO_SERVER_COOKIE_NOT_REQD. Currently, when the TFO_SERVER_ENABLE and TFO_SERVER_COOKIE_NOT_REQD sysctl bit flags are set, a server connection will accept a SYN with N bytes of data (N > 0) that has no TFO cookie, create a new fast open connection, process the incoming data in the SYN, and make the connection ready for accepting. After accepting, the connection is ready for read()/recvmsg() to read the N bytes of data in the SYN, ready for write()/sendmsg() calls and data transmissions to transmit data. This commit changes an edge case in this feature by changing this behavior to apply to (N >= 0) bytes of data in the SYN rather than only (N > 0) bytes of data in the SYN. Now, a server will accept a data-less SYN without a TFO cookie if TFO_SERVER_COOKIE_NOT_REQD is set. Caveat! While this enables a new kind of TFO (data-less empty-cookie SYN), some firewall rules setup may not work if they assume such packets are not legit TFOs and will filter them. Signed-off-by: Luke Hsiao <lukehsiao@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210816205105.2533289-1-luke.w.hsiao@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16Merge branch 'ptp-ocp-minor-updates-and-fixes'Jakub Kicinski3-4/+12
Jonathan Lemon says: ==================== ptp: ocp: minor updates and fixes. Fix errors spotted by automated tools. Add myself to the MAINTAINERS for the ptp_ocp driver. ==================== Link: https://lore.kernel.org/r/20210816221337.390645-1-jonathan.lemon@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16MAINTAINERS: Update for ptp_ocp driver.Jonathan Lemon1-0/+6
Add maintainer info for the OpenCompute PTP driver. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16ptp: ocp: Have Kconfig select NET_DEVLINKJonathan Lemon1-0/+1
NET doesn't imply NET_DEVLINK. Select this separately, so that random config combinations don't complain. Reported-by: kernel test robot <lkp@intel.com> Fixes: 773bda964921 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16ptp: ocp: Fix error path for pci_ocp_device_init()Jonathan Lemon1-3/+4
If ptp_ocp_device_init() fails, pci_disable_device() is skipped. Fix the error handling so this case is covered. Update ptp_ocp_remove() so the normal exit path is identical. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 773bda964921 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16ptp: ocp: Fix uninitialized variable warning spotted by clang.Jonathan Lemon1-1/+1
If attempting to flash the firmware with a blob of size 0, the entire write loop is skipped and the uninitialized err is returned. Fix by setting to 0 first. Fixes: 773bda964921 ("ptp: ocp: Expose various resources on the timecard.") Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16net/mlx5: Bridge, support LAGVlad Buslov3-48/+159
Allow adding bond net devices to mlx5 bridge with following changes: - Modify bridge representor code to obtain uplink represetor that belongs to eswitch that is registered for notification. Require representor to be in shared FDB mode. If representor is the lag master, then consider its port as local, otherwise treat it as peer. - Use devcom to match on paired eswitch metadata in peer FDB entries. This is necessary for shared FDB LAG to function since packets are always received on active eswitch instance as opposed to parent eswitch of port. - Support for deleting peer flows when receiving SWITCHDEV_FDB_DEL_TO_BRIDGE notification was implemented in one of previous patches in series. Now also implement support for handling SWITCHDEV_FDB_ADD_TO_BRIDGE which can be generated on peer by bridge update workqueue task in LAG configuration. Refresh the flow 'lastuse' timestamp to current jiffies when receiving such notification on eswitch that manages the local FDB entry. This allows peer entries to prevent ageing of the FDB. Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5: Bridge, allow merged eswitch connectivityVlad Buslov5-28/+112
Allow connectivity between representors of different eswitch instances that are attached to same bridge when merged_eswitch capability is enabled. Add ports of peer eswitch to bridge instance and mark them with MLX5_ESW_BRIDGE_PORT_FLAG_PEER. Mark FDBs offloaded on peer ports with MLX5_ESW_BRIDGE_FLAG_PEER flag. Such FDBs can only be aged out on their local eswitch instance, which then sends SWITCHDEV_FDB_DEL_TO_BRIDGE event. Listen to the event on mlx5 bridge implementation and delete peer FDBs in event handler. Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5: Bridge, extract FDB delete notification to functionVlad Buslov1-14/+13
SWITCHDEV_FDB_DEL_TO_BRIDGE notification is generated in multiple places in bridge code. Following patch in series changes the condition for the notification. Extract the notification into dedicated helper function mlx5_esw_bridge_fdb_del_notify() to only modify it in single place in the future changes. Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5: Bridge, identify port by vport_num+esw_owner_vhca_id pairVlad Buslov6-208/+263
Following patches in series allow traffic between vports of different eswitch instances, which requires addressing bridge port by vport_num+esw_owner_vhca_id pair since vport_num is only unique per-eswitch. As a preparation, extend struct mlx5_esw_bridge_port with 'esw_owner_vhca_id' field and use it as part of key for mlx5_esw_bridge->vports xarray. With this change we can't rely on switchdev_handle_port_obj_add() helper to get mlx5 representor from stacked device because we need specifically representor from parent eswitch that registered the callback to obtain correct esw_owner_vhca_id. The helper doesn't allow passing additional parameters to predicate function and doesn't provide access to the notifier block to obtain eswitch through br_offloads. Implement custom helpers to obtain mlx5 representor and use them in mlx5_esw_bridge_port_obj_{add|del|attr_set}() implementations. Remove direct pointer to parent bridge from struct mlx5_vport as it is no longer needed. Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5: Bridge, obtain core device from eswitch instead of privVlad Buslov1-4/+2
Following patches in series will pass bond device to bridge, which means the code can't assume the device is mlx5 representor. Moreover, the core device can be easily obtained from eswitch instance, so there is no reason for more complex code that obtains struct mlx5_priv from net_device in order to use its mdev. Refactor the code to use esw->dev instead of priv->mdev. Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5: Bridge, release bridge in same function where it is takenVlad Buslov1-7/+9
Refactor mlx5_esw_bridge_vport_link() to release the bridge instance if mlx5_esw_bridge_vport_init() returned an error instead of relying on it to release the bridge. This improves the design because object instance is taken and released in same layer and simplifies following patches that add more logic to mlx5_esw_bridge_vport_link(). Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Support MQPRIO channel modeTariq Toukan3-8/+102
Add support for MQPRIO channel mode, in which a partition to TCs is defined over the channels. We allow partitions with contiguous queue indices, with no holes within. We do not allow modification to the num of channels while this MQPRIO mode is active. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Handle errors of netdev_set_num_tc()Tariq Toukan1-6/+14
Add handling for failures in netdev_set_num_tc(). Let mlx5e_netdev_set_tcs return an int. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Maintain MQPRIO mode parameterTariq Toukan2-17/+28
This is in preparation for supporting MQPRIO CHANNEL mode in downstream patch, in addition to DCB mode that's supported today. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Abstract MQPRIO paramsTariq Toukan6-25/+37
Abstract the MQPRIO params into a struct. Use a getter for DCB mode num_tcs. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Support flow classification into RSS contextsTariq Toukan5-21/+131
Extend the existing flow classification support, to steer flows not only directly to a receive ring, but also into the new RSS contexts. Create needed TIR objects on demand, and hold reference on the RSS context. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Support multiple RSS contextsTariq Toukan5-51/+273
Add support to multiple RSS contexts. Resources of the non-default RSS contexts are allocated and created on demand. Each RSS context can be controlled and configured separately, via the implemented ethtool ops. Here we limit the num of total contexts to 16. We do not enforce any kind of new limitation over the indirection table content. More specifically, two separate contexts can be configured to fully or partially point to the same set of receive rings. The default RSS context (index 0) is created with its full set of TIRs. All other contexts are created with an empty set, then TIRs are added upon first usage when steering rules are added. We use a reference counting mechanism to make sure an RSS context is not removed before the rules pointing to it. Block ethtool set_channels operations when multiple RSS contexts exist, as currently the kernel doesn't protect against inconsistent channels configs that break non-default RSS contexts. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Dynamically allocate TIRs in RSS contextsTariq Toukan1-13/+56
Move from static to dynamic memory allocations for TIR. This is in preparation to supporting on-demand TIR operations in downstream patches, where every RSS context will be init with an empty set of TIRs. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Convert RSS to a dedicated objectTariq Toukan5-428/+604
Code related to RSS is now encapsulated into a dedicated object and put into new files en/rss.{c,h}. All usages are converted. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Introduce abstraction of RSS contextTariq Toukan3-73/+105
Bring all fields that define and maintain RSS behavior together into a new structure. Align all usages with this new structure. Keep it hidden within rx_res.c. This helps supporting multiple RSS contexts in downstream patch. Use dynamic allocations for the RSS context. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Introduce TIR create/destroy API in rx_resTariq Toukan1-57/+83
Take TIR control operations in rx_res into functions. This is in preparation to supporting on-demand TIR operations in downstream patches. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16net/mlx5e: Do not try enable RSS when resetting indir tableTariq Toukan1-5/+2
All calls to mlx5e_rx_res_rss_set_indir_uniform() occur while the RSS state is inactive, i.e. the RQT is pointing to the drop RQ, not to the channels' RQs. It means that the "apply" part of the function is not called. Remove this part from the function, and document the change. It will be useful for next patches in the series, allows code simplifications when multiple RSS contexts are introduced. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-08-16Merge branch 'net-hns3-add-support-ethtool-extended-link-state'Jakub Kicinski7-15/+137
Guangbin Huang says: ==================== net: hns3: add support ethtool extended link state This series adds support for ethtool extended link state in the HNS3 ethernet driver to add one additional information for user to know why a link is not up. ==================== Link: https://lore.kernel.org/r/1629080129-46507-1-git-send-email-huangguangbin2@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16net: hns3: add support ethtool extended link stateGuangbin Huang5-0/+101
In order to know the reason of link up failure, add supporting ethtool extended link state. Driver reads the link status code from firmware if in link down state and converts it to ethtool extended link state. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16net: hns3: add header file hns3_ethtoo.hGuangbin Huang2-15/+26
Add a new file hns3_ethtool.h, and move struct type definitions from hns3_ethtool.c to hns3_ethtool.h. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16ethtool: add two link extended substates of bad signal integrityGuangbin Huang1-0/+2
ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_REFERENCE_CLOCK_LOST means the input external clock signal for SerDes is too weak or lost. ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_ALOS means the received signal for SerDes is too weak because analog loss of signal. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16docs: ethtool: Add two link extended substates of bad signal integrityGuangbin Huang1-0/+8
Add documentation for two bad signal integrity substates: ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_REFERENCE_CLOCK_LOST ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_ALOS. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-16bonding: improve nl error msg when device can't be enslaved because of ↵Antoine Tenart1-1/+1
IFF_MASTER Use a more user friendly netlink error message when a device can't be enslaved because it has IFF_MASTER, by not referring directly to a kernel internal flag. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16Merge branch 'bridge-mcast-fixes'David S. Miller1-2/+12
Nikolay Aleksandrov says: ==================== net: bridge: mcast: fixes for mcast querier state These three fix querier state dumping. The first patch can be considered a minor behaviour improvement, it avoids dumping querier state when mcast snooping is disabled. The second patch was a report of sizeof(0) used for nested netlink attribute size which should be just 0, and the third patch accounts for IPv6 querier state size when allocating skb for notifications. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: bridge: mcast: account for ipv6 size when dumping querier stateNikolay Aleksandrov1-1/+7
We need to account for the IPv6 attributes when dumping querier state. Fixes: 5e924fe6ccfd ("net: bridge: mcast: dump ipv6 querier state") Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: bridge: mcast: drop sizeof for nest attribute's zero sizeNikolay Aleksandrov1-1/+1
This was a dumb error I made instead of writing nla_total_size(0) for a nest attribute, I wrote nla_total_size(sizeof(0)). Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 606433fe3e11 ("net: bridge: mcast: dump ipv4 querier state") Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: bridge: mcast: don't dump querier state if snooping is disabledNikolay Aleksandrov1-0/+4
A minor improvement to avoid dumping mcast ctx querier state if snooping is disabled for that context (either bridge or vlan). Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16Merge branch 'stmmac-per-queue-stats'David S. Miller4-3/+89
Vijayakannan Ayyathurai says: ==================== net: stmmac: Add ethtool per-queue statistic Adding generic ethtool per-queue statistic framework to display the statistics for each rx/tx queue. In future, users can avail it to add more per-queue specific counters. Number of rx/tx queues displayed is depending on the available rx/tx queues in that particular MAC config and this number is limited up to the MTL_MAX_{RX|TX}_QUEUES defined in the driver. Ethtool per-queue statistic display will look like below, when users start adding more counters. Example - 1: q0_tx_statA: q0_tx_statB: q0_tx_statC: | q0_tx_statX: . . . qMAX_tx_statA: qMAX_tx_statB: qMAX_tx_statC: | qMAX_tx_statX: q0_rx_statA: q0_rx_statB: q0_rx_statC: | q0_rx_statX: . . . qMAX_rx_statA: qMAX_rx_statB: qMAX_rx_statC: | qMAX_rx_statX: Example - 2: Ping test using the tx queue 3. $ tc qdisc add dev enp0s30f4 root mqprio num_tc 2 map 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 3@0 1@3 hw 0 Statistic before ping: --------------------- $ ethtool -S enp0s30f4 [ snip ] q3_tx_pkt_n: 7916 q3_tx_irq_n: 316 [ snip ] $ cat /proc/interrupts [ snip ] 143: 0 0 0 316 0 0 0 0 IR-PCI-MSI 499719-edge enp0s30f4:tx-3 [ snip ] $ ping -I enp0s30f4 192.168.1.10 -i 0.01 -c 100 > /dev/null Statistic after ping: --------------------- $ ethtool -S enp0s30f4 [ snip ] q3_tx_pkt_n: 8016 q3_tx_irq_n: 320 [ snip ] $ cat /proc/interrupts [ snip ] 143: 0 0 0 320 0 0 0 0 IR-PCI-MSI 499719-edge enp0s30f4:tx-3 [ snip ] ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: stmmac: add ethtool per-queue irq statistic supportVijayakannan Ayyathurai3-0/+6
Adding ethtool per-queue statistics support to show number of interrupts generated at DMA tx and DMA rx. All the counters are incremented at dwmac4_dma_interrupt function. Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: stmmac: add ethtool per-queue statistic frameworkVijayakannan Ayyathurai3-1/+80
Adding generic ethtool per-queue statistic framework to display the statistics for each rx/tx queue. In future, users can avail it to add more per-queue specific counters. Number of rx/tx queues displayed is depending on the available rx/tx queues in that particular MAC config and this number is limited up to the MTL_MAX_{RX|TX}_QUEUES defined in the driver. Ethtool per-queue statistic display will look like below, when users start adding more counters. Example: q0_tx_statA: q0_tx_statB: q0_tx_statC: | q0_tx_statX: . . . qMAX_tx_statA: qMAX_tx_statB: qMAX_tx_statC: | qMAX_tx_statX: q0_rx_statA: q0_rx_statB: q0_rx_statC: | q0_rx_statX: . . . qMAX_rx_statA: qMAX_rx_statB: qMAX_rx_statC: | qMAX_rx_statX: In addition, this patch has the support on displaying the number of packets received and transmitted per queue. Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: stmmac: fix INTR TBU status affecting irq count statisticVoon Weifeng1-2/+3
DMA channel status "Transmit buffer unavailable(TBU)" bit is not considered as a successful dma tx. Hence, it should not affect all the irq count statistic. Fixes: 1103d3a5531c ("net: stmmac: dwmac4: Also use TBU interrupt to clean TX path") Signed-off-by: Voon Weifeng <weifeng.voon@intel.com> Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: dsa: sja1105: reorganize probe, remove, setup and teardown orderingVladimir Oltean1-198/+199
The sja1105 driver's initialization and teardown sequence is a chaotic mess that has gathered a lot of cruft over time. It works because there is no strict dependency between the functions, but it could be improved. The basic principle that teardown should be the exact reverse of setup is obviously not held. We have initialization steps (sja1105_tas_setup, sja1105_flower_setup) in the probe method that are torn down in the DSA .teardown method instead of driver unbind time. We also have code after the dsa_register_switch() call, which implicitly means after the .setup() method has finished, which is pretty unusual. Also, sja1105_teardown() has calls set up in a different order than the error path of sja1105_setup(): see the reversed ordering between sja1105_ptp_clock_unregister and sja1105_mdiobus_unregister. Also, sja1105_static_config_load() is called towards the end of sja1105_setup(), but sja1105_static_config_free() is also towards the end of the error path and teardown path. The static_config_load() call should be earlier. Also, making and breaking the connections between struct sja1105_port and struct dsa_port could be refactored into dedicated functions, makes the code easier to follow. We move some code from the DSA .setup() method into the probe method, like the device tree parsing, and we move some code from the probe method into the DSA .setup() method to be symmetric with its placement in the DSA .teardown() method, which is nice because the unbind function has a single call to dsa_unregister_switch(). Example of the latter type of code movement are the connections between ports mentioned above, they are now in the .setup() method. Finally, due to fact that the kthread_init_worker() call is no longer in sja1105_probe() - located towards the bottom of the file - but in sja1105_setup() - located much higher - there is an inverse ordering with the worker function declaration, sja1105_port_deferred_xmit. To avoid that, the entire sja1105_setup() and sja1105_teardown() functions are moved towards the bottom of the file. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16r8169: rename rtl_csi_access_enable to rtl_set_aspm_entry_latencyHeiner Kallweit1-4/+7
Rename the function to reflect what it's doing. Also add a description of the register values as kindly provided by Realtek. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16Merge branch 'ocelot-phylink'David S. Miller8-292/+338
Vladimir Oltean says: ==================== Convert ocelot to phylink The ocelot switchdev and felix dsa drivers are interesting because they target the same class of hardware switches but used in different modes. Colin has an interesting use case where he wants to use a hardware switch supported by the ocelot switchdev driver with the felix dsa driver. So far, the existing hardware revisions were similar between the ocelot and felix drivers, but not completely identical. With identical hardware, it is absurd that the felix driver uses phylink while the ocelot driver uses phylib - this should not be one of the differences between the switchdev and dsa driver, and we could eliminate it. Colin will need the common phylink support in ocelot and felix when adding a phylink_pcs driver for the PCS1G block inside VSC7514, which will make the felix driver work with either the NXP or the Microchip PCS. As usual, Alex, Horatiu, sorry for bugging you, but it would be appreciated if you could give this a quick run on actual VSC7514 hardware (which I don't have) to make sure I'm not introducing any breakage. ==================== Fixes: 0f06a6787e05 ("samples: Add an IPv6 "-6" option to the pktgen scripts") Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: mscc: ocelot: convert to phylinkVladimir Oltean8-254/+329
The felix DSA driver, which is a wrapper over the same hardware class as ocelot, is integrated with phylink, but ocelot is using the plain PHY library. It makes sense to bring together the two implementations, which is what this patch achieves. This is a large patch and hard to break up, but it does the following: The existing ocelot_adjust_link writes some registers, and felix_phylink_mac_link_up writes some registers, some of them are common, but both functions write to some registers to which the other doesn't. The main reasons for this are: - Felix switches so far have used an NXP PCS so they had no need to write the PCS1G registers that ocelot_adjust_link writes - Felix switches have the MAC fixed at 1G, so some of the MAC speed changes actually break the link and must be avoided. The naming conventions for the functions introduced in this patch are: - vsc7514_phylink_{mac_config,validate} are specific to the Ocelot instantiations and placed in ocelot_net.c which is built only for the ocelot switchdev driver. - ocelot_phylink_mac_link_{up,down} are shared between the ocelot switchdev driver and the felix DSA driver (they are put in the common lib). One by one, the registers written by ocelot_adjust_link are: DEV_MAC_MODE_CFG - felix_phylink_mac_link_up had no need to write this register since its out-of-reset value was fine and did not need changing. The write is moved to the common ocelot_phylink_mac_link_up and on felix it is guarded by a quirk bit that makes the written value identical with the out-of-reset one DEV_PORT_MISC - runtime invariant, was moved to vsc7514_phylink_mac_config PCS1G_MODE_CFG - same as above PCS1G_SD_CFG - same as above PCS1G_CFG - same as above PCS1G_ANEG_CFG - same as above PCS1G_LB_CFG - same as above DEV_MAC_ENA_CFG - both ocelot_adjust_link and ocelot_port_disable touched this. felix_phylink_mac_link_{up,down} also do. We go with what felix does and put it in ocelot_phylink_mac_link_up. DEV_CLOCK_CFG - ocelot_adjust_link and felix_phylink_mac_link_up both write this, but to different values. Move to the common ocelot_phylink_mac_link_up and make sure via the quirk that the old values are preserved for both. ANA_PFC_PFC_CFG - ocelot_adjust_link wrote this, felix_phylink_mac_link_up did not. Runtime invariant, speed does not matter since PFC is disabled via the RX_PFC_ENA bits which are cleared. Move to vsc7514_phylink_mac_config. QSYS_SWITCH_PORT_MODE_PORT_ENA - both ocelot_adjust_link and felix_phylink_mac_link_{up,down} wrote this. Ocelot also wrote this register from ocelot_port_disable. Keep what felix did, move in ocelot_phylink_mac_link_{up,down} and delete ocelot_port_disable. ANA_POL_FLOWC - same as above SYS_MAC_FC_CFG - same as above, except slight behavior change. Whereas ocelot always enabled RX and TX flow control, felix listened to phylink (for the most part, at least - see the 2500base-X comment). The registers which only felix_phylink_mac_link_up wrote are: SYS_PAUSE_CFG_PAUSE_ENA - this is why I am not sure that flow control worked on ocelot. Not it should, since the code is shared with felix where it does. ANA_PORT_PORT_CFG - this is a Frame Analyzer block register, phylink should be the one touching them, deleted. Other changes: - The old phylib registration code was in mscc_ocelot_init_ports. It is hard to work with 2 levels of indentation already in, and with hard to follow teardown logic. The new phylink registration code was moved inside ocelot_probe_port(), right between alloc_etherdev() and register_netdev(). It could not be done before (=> outside of) ocelot_probe_port() because ocelot_probe_port() allocates the struct ocelot_port which we then use to assign ocelot_port->phy_mode to. It is more preferable to me to have all PHY handling logic inside the same function. - On the same topic: struct ocelot_port_private :: serdes is only used in ocelot_port_open to set the SERDES protocol to Ethernet. This is logically a runtime invariant and can be done just once, when the port registers with phylink. We therefore don't even need to keep the serdes reference inside struct ocelot_port_private, or to use the devm variant of of_phy_get(). - Phylink needs a valid phy-mode for phylink_create() to succeed, and the existing device tree bindings in arch/mips/boot/dts/mscc/ocelot_pcb120.dts don't define one for the internal PHY ports. So we patch PHY_INTERFACE_MODE_NA into PHY_INTERFACE_MODE_INTERNAL. - There was a strategically placed: switch (priv->phy_mode) { case PHY_INTERFACE_MODE_NA: continue; which made the code skip the serdes initialization for the internal PHY ports. Frankly that is not all that obvious, so now we explicitly initialize the serdes under an "if" condition and not rely on code jumps, so everything is clearer. - There was a write of OCELOT_SPEED_1000 to DEV_CLOCK_CFG for QSGMII ports. Since that is in fact the default value for the register field DEV_CLOCK_CFG_LINK_SPEED, I can only guess the intention was to clear the adjacent fields, MAC_TX_RST and MAC_RX_RST, aka take the port out of reset, which does match the comment. I don't even want to know why this code is placed there, but if there is indeed an issue that all ports that share a QSGMII lane must all be up, then this logic is already buggy, since mscc_ocelot_init_ports iterates using for_each_available_child_of_node, so nobody prevents the user from putting a 'status = "disabled";' for some QSGMII ports which would break the driver's assumption. In any case, in the eventuality that I'm right, we would have yet another issue if ocelot_phylink_mac_link_down would reset those ports and that would be forbidden, so since the ocelot_adjust_link logic did not do that (maybe for a reason), add another quirk to preserve the old logic. The ocelot driver teardown goes through all ports in one fell swoop. When initialization of one port fails, the ocelot->ports[port] pointer for that is reset to NULL, and teardown is done only for non-NULL ports, so there is no reason to do partial teardowns, let the central mscc_ocelot_release_ports() do its job. Tested bind, unbind, rebind, link up, link down, speed change on mock-up hardware (modified the driver to probe on Felix VSC9959). Also regression tested the felix DSA driver. Could not test the Ocelot specific bits (PCS1G, SERDES, device tree bindings). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-16net: dsa: felix: stop calling ocelot_port_{enable,disable}Vladimir Oltean4-38/+9
ocelot_port_enable touches ANA_PORT_PORT_CFG, which has the following fields: - LOCKED_PORTMOVE_CPU, LEARNDROP, LEARNCPU, LEARNAUTO, RECV_ENA, all of which are written with their hardware default values, also runtime invariants. So it makes no sense to write these during every .ndo_open. - PORTID_VAL: this field has an out-of-reset value of zero for all ports and must be initialized by software. Additionally, the ocelot_setup_logical_port_ids() code path sets up different logical port IDs for the ports in a hardware LAG, and we absolutely don't want .ndo_open to interfere there and reset those values. So in fact the write from ocelot_port_enable can better be moved to ocelot_init_port, and the .ndo_open hook deleted. ocelot_port_disable touches DEV_MAC_ENA_CFG and QSYS_SWITCH_PORT_MODE_PORT_ENA, in an attempt to undo what ocelot_adjust_link did. But since .ndo_stop does not get called each time the link falls (i.e. this isn't a substitute for .phylink_mac_link_down), felix already does better at this by writing those registers already in felix_phylink_mac_link_down. So keep ocelot_port_disable (for now, until ocelot is converted to phylink too), and just delete the felix call to it, which is not necessary. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Powered by cgit, Gruvboxed by Blaster4385.