- 09 Sep, 2020 16 commits
-
-
Edward Cree authored
The code recently moved into this file contained a number of coding style issues, about which checkpatch and xmastree complained. Fix them. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
Stephen reported the following warning: net/bridge/br_multicast.c: In function 'br_multicast_find_port': net/bridge/br_multicast.c:1818:21: warning: unused variable 'br' [-Wunused-variable] 1818 | struct net_bridge *br = mp->br; | ^~ It happens due to bridge's mlock_dereference() when lockdep isn't defined. Silence the warning by annotating the variable as __maybe_unused. Fixes: 0436862e ("net: bridge: mcast: support for IGMPv3/MLDv2 ALLOW_NEW_SOURCES report") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): net/netlabel/netlabel_calipso.c:438: warning: Excess function parameter 'audit_secid' description in 'calipso_doi_remove' net/netlabel/netlabel_calipso.c:605: warning: Excess function parameter 'reg' description in 'calipso_req_delattr' Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/control.c:709: warning: Excess function parameter 'msg_skb' description in 'i2400m_msg_to_dev' This parameter is not in use. Remove it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess function parameter 'netdev' description in 'bnx2x_setup_tc' drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:4238: warning: Excess function parameter 'tc' description in 'bnx2x_setup_tc' Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): net/ipv4/cipso_ipv4.c:510: warning: Excess function parameter 'audit_secid' description in 'cipso_v4_doi_remove' Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wei Xu authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/smsc/smsc911x.c: In function ‘smsc911x_rx_fastforward’: drivers/net/ethernet/smsc/smsc911x.c:1199:16: warning: variable ‘temp’ set but not used [-Wunused-but-set-variable] drivers/net/ethernet/smsc/smsc911x.c: In function ‘smsc911x_eeprom_write_location’: drivers/net/ethernet/smsc/smsc911x.c:2058:6: warning: variable ‘temp’ set but not used [-Wunused-but-set-variable] Signed-off-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: misc updates There are some misc updates for the HNS3 ethernet driver. ==================== Reviewed-by: Jakub Kicinski <kuba@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guojia Liao authored
hns3_update_promisc_mode is defined, but not be used, so remove it. Signed-off-by: Guojia Liao <liaoguojia@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
There are several macros related queue defined, but never used, so remove them. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
'tc_num_last_time' is defined, but never used, so remove it. Reported-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
'io_base' has been defined and initialized, but never used, so remove it. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guangbin Huang authored
The member link of struct hclge_mac stores the link status of MAC and PHY if PHY exists, but its annotation uses word "exit", so fix it. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guangbin Huang authored
When reset fails, if there are some pending jobs for the periodic service task, it does not do anything except print error each time the task is scheduled. So skip the periodic service task if reset failed. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
Since variable send_msg and ret only used in if branch, so move their definition into the if branch. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom Rix authored
Reviewing the error handling in tcf_action_init_1() most of the early handling uses err_out: if (cookie) { kfree(cookie->data); kfree(cookie); } before cookie could ever be set. So skip the unnecessay check. Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 08 Sep, 2020 2 commits
-
-
Vladimir Oltean authored
Commit 72579e14 ("net: dsa: don't fail to probe if we couldn't set the MTU") changed, for some reason, the "err && err != -EOPNOTSUPP" check into a simple "err". This causes the MTU warning to be printed even for drivers that don't have the MTU operations implemented. Fix that. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
slave_dev->name is only populated at this stage if it was specified through a label in the device tree. However that is not mandatory. When it isn't, the error message looks like this: [ 5.037057] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d [ 5.044672] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d [ 5.052275] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d [ 5.059877] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d which is especially confusing since the error gets printed on behalf of the DSA master (fsl_enetc in this case). Printing an error message that contains a valid reference to the DSA port's name is difficult at this point in the initialization stage, so at least we should print some info that is more reliable, even if less user-friendly. That may be the driver name and the hardware port index. After this change, the error is printed as: [ 6.051587] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 0 [ 6.061192] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 1 [ 6.070765] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 2 [ 6.080324] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 3 Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 07 Sep, 2020 22 commits
-
-
Jakub Kicinski authored
This patch is born out of an investigation into which IEEE statistics correspond to which struct rtnl_link_stats64 members. Turns out that there seems to be reasonable consensus on the matter, among many drivers. To save others the time (and it took more time than I'm comfortable admitting) I'm adding comments referring to IEEE attributes to struct rtnl_link_stats64. Up until now we had two forms of documentation for stats - in Documentation/ABI/testing/sysfs-class-net-statistics and the comments on struct rtnl_link_stats64 itself. While the former is very cautious in defining the expected behavior, the latter feel quite dated and may not be easy to understand for modern day driver author (e.g. rx_over_errors). At the same time modern systems are far more complex and once obvious definitions lost their clarity. For example - does rx_packet count at the MAC layer (aFramesReceivedOK)? packets processed correctly by hardware? received by the driver? or maybe received by the stack? I tried to clarify the expectations, further clarifications from others are very welcome. The part hardest to untangle is rx_over_errors vs rx_fifo_errors vs rx_missed_errors. After much deliberation I concluded that for modern HW only two of the counters will make sense. The distinction between internal FIFO overflow and packets dropped due to back-pressure from the host is likely too implementation (driver and device) specific to expose in the standard stats. Now - which two of those counters we select to use is anyone's pick: sysfs documentation suggests rx_over_errors counts packets which did not fit into buffers due to MTU being too small, which I reused. There don't seem to be many modern drivers using it (well, CAN drivers seem to love this statistic). Of the remaining two I picked rx_missed_errors to report device drops. bnxt reports it and it's folded into "drop"s in procfs (while rx_fifo_errors is an error, and modern devices usually receive the frame OK, they just can't admit it into the pipeline). Of the drivers I looked at only AMD Lance-like and NS8390-like use all three of these counters. rx_missed_errors counts missed frames, rx_over_errors counts overflow events, and rx_fifo_errors counts frames which were truncated because they didn't fit into buffers. This suggests that rx_fifo_errors may be the correct stat for truncated packets, but I'd think a FIFO stat counting truncated packets would be very confusing to a modern reader. v2: - add driver developer notes about ethtool stat count and reset - replace Ethernet with IEEE 802.3 to better indicate source of attrs - mention byte counters don't count FCS - clarify RX counter is from device to host - drop "sightly" from sysfs paragraph - add examples of ethtool stats - s/incoming/received/ s/incoming/transmitted/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Wang Hai authored
rxrpc_min_rtt_wlen is never used after it was introduced. So better to remove it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Edward Cree says: ==================== sfc: ethtool for EF100 and related improvements This series adds the ethtool support to the EF100 driver that was held back from the original submission as the lack of phy_ops caused issues. Patch #2, removing the phy_op indirection, deals with this. There are a lot of checkpatch warnings / xmastree violations but they're all in pure code movement so I've left the code as it is. While patch #1 is technically a fix and possibly could go to 'net', I've put it in this series since it only becomes triggerable with the added 'ethtool --reset' support. ==================== Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
Christoph says[1] that dma_set_mask_and_coherent() is smart enough to truncate the mask itself if it's too long. So we can get rid of our "lop off one bit and retry" loop in efx_init_io(). [1]: https://www.spinics.net/lists/netdev/msg677266.htmlSigned-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
Per-module versions for in-tree drivers are deprecated. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
If the reported PHY capabilities do not include a given FEC mode, don't attempt to select that FEC mode anyway. If the user tries to set a mode through ethtool that is not supported, return an error. The _REQUESTED bits don't appear in the supported caps, but are implied by the corresponding FEC bits. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
Mostly just calls to existing common functions. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
Originally there were several implementations of PHY operations for the several different PHYs used on Falcon boards. But Falcon is now in a separate driver, and all sfc NICs since then have had MCDI-managed PHYs. Thus, there is no need to indirect through function pointers in efx->phy_op; we can simply call the efx_mcdi_phy_* functions directly. This also hooks up these functions for EF100, which was previously using the dummy_phy_ops. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
dev_close(), by way of ef100_net_stop(), already brings down the filter table, so there's no need to do it again (which just causes lots of WARN_ONs). Similarly, don't bring it up ourselves, as dev_open() -> ef100_net_open() will do it, and will fail if it's already been brought up. Fixes: a9dc3d56 ("sfc_ef100: RX filter table management and related gubbins") Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Wang Hai authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/dnet.c: In function dnet_start_xmit drivers/net/ethernet/dnet.c:511:15: warning: variable ‘len’ set but not used [-Wunused-but-set-variable] commit 47964174 ("dnet: Dave DNET ethernet controller driver (updated)") involved this unused variable, remove it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Nikolay Aleksandrov says: ==================== net: bridge: mcast: initial IGMPv3/MLDv2 support (part 1) This patch-set implements the control plane for initial IGMPv3/MLDv2 support which takes care of include/exclude sets and state transitions based on the different report types. Patch 01 arranges the structure better by moving the frequently used fields together, patch 02 factors out the port group deletion code which is used in a few places. Patches 03 and 04 add support for source lists and group modes per port group which are dumped. Patch 05 adds support for group-and-source specific queries required for IGMPv3/MLDv2. Then patch 06 adds support for group and group-and-source query retransmissions via a new rexmit timer. Patches 07 and 08 make use of the already present mdb fill functions when sending notifications so we can have the full mdb entries' state filled in (with sources, mode etc). Patch 09 takes care of port group expiration, it switches the group mode to include and deletes it if there are no sources with active timers. Patches 10-13 are the core changes which add support for IGMPv3/MLDv2 reports and handle the source list set operations as per RFCs 3376 and 3810, all IGMPv3/MLDv2 report types with their transitions should be supported after these patches. I've used RFCs 3376, 3810 and FRR as a reference implementation. The source lists are capped at 32 entries, we can remove that limitation at a later point which would require a better data structure to hold them. IGMPv3 processing is hidden behind the bridge's multicast_igmp_version option which must be set to 3 in order to enable it. MLDv2 processing is hidden behind the bridge's multicast_mld_version which must be set to 2 in order to enable it. Patch 14 improves other querier processing a bit (more about this below). And finally patch 15 transforms the src gc so it can be used with all mcast objects since now we have multiple timers that can be running and we need to make sure they have all finished before freeing the objects. This is part 1, it only adds control plane support and doesn't change the fast path. A following patch-set will take care of that. Here're the sets that will come next (in order): - Fast path patch-set which adds support for (S, G) mdb entries needed for IGMPv3/MLDv2 forwarding, entry add source (kernel, user-space etc) needed for IGMPv3/MLDv2 entry management, entry block mode needed for IGMPv3/MLDv2 exclude mode. This set will also add iproute2 support for manipulating and showing all the new state. - Selftests patches which will verify all state transitions and forwarding - Explicit host tracking patch-set, needed for proper fast leave and with it fast leave will be enabled for IGMPv3/MLDv2 Not implemented yet: - Host IGMPv3/MLDv2 filter support (currently we handle only join/leave as before) - Proper other querier source timer and value updates - IGMPv3/v2 MLDv2/v1 compat (I have a few rough patches for this one) v4: move old patch 05 to 02 (group del patch), before src lists patch 02: set pg's fast leave flag when deleting due to fast leave patch 03: now can use the new port del function add igmpv2/mldv1 bool which are set when the entry is added in those modes (later will be passed as update_timer) patch 10: rename update_timer to igmpv2_mldv1 and use the passed value from br_multicast_add_group's callers v3: add IPv6/MLDv2 support, most patches are changed v2: patches 03-04: make src lists RCU friendly so they can be traversed when dumping, reduce limit to a more conservative 32 src group entries for a start patches 11-13: remove helper and directly do bitops patch 15: force mcast gc on bridge port del to make sure port group timers have finished before freeing the port ==================== Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
Since each entry type has timers that can be running simultaneously we need to make sure that entries are not freed before their timers have finished. In order to do that generalize the src gc work to mcast gc work and use a callback to free the entries (mdb, port group or src). v3: add IPv6 support v2: force mcast gc on port del to make sure all port group timers have finished before freeing the bridge port Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
When an IGMPv3/MLDv2 query is received and we're operating in such mode then we need to avoid updating group timers if the suppress flag is set. Also we should update only timers for groups in exclude mode. v3: add IPv6/MLDv2 support Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
We already have all necessary helpers, so process IGMPV3/MLDv2 BLOCK_OLD_SOURCES as per the RFCs. v3: add IPv6/MLDv2 support v2: directly do flag bit operations Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
In order to process IGMPV3/MLDv2 CHANGE_TO_INCLUDE/EXCLUDE report types we need new helpers which allow us to mark entries based on their timer state and to query only marked entries. v3: add IPv6/MLDv2 support, fix other_query checks v2: directly do flag bit operations Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
In order to process IGMPV3/MLDv2_MODE_IS_INCLUDE/EXCLUDE report types we need some new helpers which allow us to set/clear flags for all current entries and later delete marked entries after the report sources have been processed. v3: add IPv6/MLDv2 support v2: drop flag helpers and directly do flag bit operations Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
This patch adds handling for the ALLOW_NEW_SOURCES IGMPv3/MLDv2 report types and limits them only when multicast_igmp_version == 3 or multicast_mld_version == 2 respectively. Now that IGMPv3/MLDv2 handling functions will be managing timers we need to delay their activation, thus a new argument is added which controls if the timer should be updated. We also disable host IGMPv3/MLDv2 handling as it's not yet implemented and could cause inconsistent group state, the host can only join a group as EXCLUDE {} or leave it. v4: rename update_timer to igmpv2_mldv1 and use the passed value from br_multicast_add_group's callers v3: Add IPv6/MLDv2 support Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
If an expired port group is in EXCLUDE mode, then we have to turn it into INCLUDE mode, remove all srcs with zero timer and finally remove the group itself if there are no more srcs with an active timer. For IGMPv2 use there would be no sources, so this will reduce to just removing the group as before. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-