- 26 Sep, 2020 11 commits
-
-
Jacob Keller authored
When implementing .flash_update, drivers which do not support per-component update are manually checking the component parameter to verify that it is NULL. Without this check, the driver might accept an update request with a component specified even though it will not honor such a request. Instead of having each driver check this, move the logic into net/core/devlink.c, and use a new `supported_flash_update_params` field in the devlink_ops. Drivers which will support per-component update must now specify this by setting DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT in the supported_flash_update_params in their devlink_ops. This helps ensure that drivers do not forget to check for a NULL component if they do not support per-component update. This also enables a slightly better error message by enabling the core stack to set the netlink bad attribute message to indicate precisely the unsupported attribute in the message. Going forward, any new additional parameter to flash update will require a bit in the supported_flash_update_params bitfield. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Cc: Jiri Pirko <jiri@mellanox.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Michael Chan <michael.chan@broadcom.com> Cc: Bin Luo <luobin9@huawei.com> Cc: Saeed Mahameed <saeedm@mellanox.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: Ido Schimmel <idosch@mellanox.com> Cc: Danielle Ratson <danieller@mellanox.com> Cc: Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Yuchung Cheng says: ==================== simplify TCP loss marking code The TCP loss marking is implemented by a set of intertwined subroutines. TCP has several loss detection algorithms (RACK, RFC6675/FACK, NewReno, etc) each calls a subset of these routines to mark a packet lost. This has led to various bugs (and fixes and fixes of fixes). This patch set is to consolidate the loss marking code so all detection algorithms call the same routine tcp_mark_skb_lost(). ==================== Signed-off-by: -
Yuchung Cheng authored
tcp_skb_mark_lost is used by RFC6675-SACK and can easily be replaced with the new tcp_mark_skb_lost handler. Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Yuchung Cheng authored
This patch consolidates and simplifes the loss marking logic used by a few loss detections (RACK, RFC6675, NewReno). Previously each detection uses a subset of several intertwined subroutines. This unncessary complexity has led to bugs (and fixes of bug fixes). tcp_mark_skb_lost now is the single one routine to mark a packet loss when a loss detection caller deems an skb ist lost: 1. rewind tp->retransmit_hint_skb if skb has lower sequence or all lost ones have been retransmitted. 2. book-keeping: adjust flags and counts depending on if skb was retransmitted or not. Signed-off-by: -
Yuchung Cheng authored
A pure refactor to move tcp_mark_skb_lost to tcp_input.c to prepare for the later loss marking consolidation. Signed-off-by:
-
Yuchung Cheng authored
tcp_simple_retransmit() used for path MTU discovery may not adjust the retransmit hint properly by deducting retrans_out before checking it to adjust the hint. This patch fixes this by a correct routine tcp_mark_skb_lost() already used by the RACK loss detection. Signed-off-by:
-
Gustavo A. R. Silva authored
There is a null-check for _pcs_, but it is being dereferenced prior to this null-check. So, if _pcs_ can actually be null, then there is a potential null pointer dereference that should be fixed by null-checking _pcs_ before being dereferenced. Addresses-Coverity-ID: 1497159 ("Dereference before null check") Fixes: 94ae899b ("dpaa2-mac: add PCS support through the Lynx module") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
David S. Miller authored
Ioana Ciornei says: ==================== dpaa2-eth: small updates This patch set is just a collection of small updates to the dpaa2-eth driver. First, we only need to check the availability of the DTS child node, not both child and parent node. Then remove a call to dpaa2_eth_link_state_update() which is now just a leftover and it's not useful in how are things working now in the PHY integration. Lastly, modify how the driver is behaving when the the flow steering table is used between all the traffic classes. ==================== Signed-off-by: -
Ionut-robert Aron authored
When SHARED_FS is enabled on a DPNI object the flow steering tables are shared between all the traffic classes. Modify the driver so that we only add a new flow steering entry on the TC#0 when this new option is enabled. Signed-off-by:
Ionut-robert Aron <ionut-robert.aron@nxp.com> Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
Ioana Ciornei authored
The call to dpaa2_eth_link_state_update() is a leftover from the time when on DPAA2 platforms the PHYs were started at boot time so when an ifconfig was issued on the associated interface, the link status needed to be checked directly from the ndo_open() callback. This is not needed anymore since we are now properly integrated with the PHY layer thus a link interrupt will come directly from the PHY eventually without the need to call the sync function. Fix this up by removing the call to dpaa2_eth_link_state_update(). Signed-off-by:
-
Ioana Ciornei authored
There is no need to check if both the MDIO controller node and its child node, the PCS device, are available since there is no chance that the child node would be enabled when the parent it's not. Suggested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
- 25 Sep, 2020 29 commits
-
-
David S. Miller authored
Fabian Frederick says: ==================== vxlan: clean-up This small patchet does some clean-up on vxlan. Second version removes VXLAN_NL2FLAG macro relevant patches as suggested by Michal and David I hope to have some feedback/ACK from vxlan developers. ==================== Signed-off-by: -
Fabian Frederick authored
Since commit aab8cc36 ("vxlan: add support for underlay in non-default VRF") vxlan_find_sock() also checks if socket is assigned to the right level 3 master device when lower device is not in the default VRF. Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Fabian Frederick authored
rtnl_configure_link is always checked if < 0 for error code. Signed-off-by:
-
Fabian Frederick authored
vxlan_xmit_one() was only called from vxlan_xmit() without rdst and info was already tested. Emit warning in that function instead Signed-off-by:
-
Fabian Frederick authored
small optimization around checking as it's being done in all receptions Signed-off-by:
-
Fabian Frederick authored
call vxlan_remcsum() before md filling in vxlan_rcv() Signed-off-by:
-
Nikolay Aleksandrov authored
We should remove a group from the sg_port hash only if it's an S,G entry. This makes it correct and more symmetric with group add. Also since *,G groups are not added to that hash we can hide a bug. Fixes: 085b53c8 ("net: bridge: mcast: add sg_port rhashtable") Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Chuah, Kim Tatt authored
Add option in plat_stmmacenet_data struct to enable VLAN Filter Fail Queuing. This option allows packets that fail VLAN filter to be routed to a specific Rx queue when Receive All is also set. When this option is enabled: - Enable VFFQ only when entering promiscuous mode, because Receive All will pass up all rx packets that failed address filtering (similar to promiscuous mode). - VLAN-promiscuous mode is never entered to allow rx packet to fail VLAN filters and get routed to selected VFFQ Rx queue. Reviewed-by:
Voon Weifeng <weifeng.voon@intel.com> Reviewed-by:
Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by:
Chuah, Kim Tatt <kim.tatt.chuah@intel.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Devlink regions for SJA1105 DSA driver This series exposes the SJA1105 static config as a devlink region. This can be used for debugging, for example with the sja1105_dump user space program that I have derived from Andrew Lunn's mv88e6xxx_dump: https://github.com/vladimiroltean/mv88e6xxx_dump/tree/sja1105 Changes in v2: - Tear down devlink params on initialization failure. - Add driver identification through devlink. ==================== Signed-off-by:
-
Vladimir Oltean authored
Return the driver name and ASIC ID so that generic user space application are able to know they're looking at sja1105 devlink regions when pretty-printing them. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
As explained in Documentation/networking/dsa/sja1105.rst, this switch has a static config held in the driver's memory and re-uploaded from time to time into the device (after any major change). The format of this static config is in fact described in UM10944.pdf and it contains all the switch's settings (it also contains device ID, table CRCs, etc, just like in the manual). So it is a useful and universal devlink region to expose to user space, for debugging purposes. Signed-off-by:
-
Vladimir Oltean authored
We'll have more devlink code soon. Group it together in a separate translation object. Signed-off-by:
-
David S. Miller authored
Jesse Brandeburg says: ==================== make drivers/net/ethernet W=1 clean The Goal: move to W=1 being default for drivers/net/ethernet, and then use automation to catch more code issues (warnings) being introduced. The status: Getting much closer but not quite done for all architectures. After applying the patches below, the drivers/net/ethernet directory can be built as modules with W=1 with no warnings (so far on x64_64 arch only!). As Jakub pointed out, there is much more work to do to clean up C=1, but that will be another series of changes. This series removes 1,247 warnings and hopefully allows the ethernet directory to move forward from here without more warnings being added. There is only one objtool warning now. This version drops one of the Intel patches, as I couldn't reproduce the original issue to document the warning. Some of these patches are already sent and tested on Intel Wired Lan, but the rest of the series titled drivers/net/ethernet affects other drivers. The changes are all pretty straightforward. ==================== Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by:
Saeed Mahameed <saeed@kernel.org>
-
Jesse Brandeburg authored
As part of the W=1 cleanups for ethernet, a million [*] driver comments had to be cleaned up to get the W=1 compilation to succeed. This change finally makes the drivers/net/ethernet tree compile with W=1 set on the command line. NOTE: The kernel uses kdoc style (see Documentation/process/kernel-doc.rst) when documenting code, not doxygen or other styles. After this patch the x86_64 build has no warnings from W=1, however scripts/kernel-doc says there are 1545 more warnings in source files, that I need to develop a script to fix in a followup patch. The errors fixed here are all kdoc of a few classes, with a few outliers: In file included from drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c:10: drivers/net/ethernet/qlogic/netxen/netxen_nic.h:1193:18: warning: ‘FW_DUMP_LEVELS’ defined but not used [-Wunused-const-variable=] 1193 | static const u32 FW_DUMP_LEVELS[] = { 0x3, 0x7, 0xf, 0x1f, 0x3f, 0x7f, 0xff }; | ^~~~~~~~~~~~~~ ... repeats 4 times... drivers/net/ethernet/sun/cassini.c:2084:24: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] 2084 | RX_USED_ADD(page, i); drivers/net/ethernet/natsemi/ns83820.c: In function ‘phy_intr’: drivers/net/ethernet/natsemi/ns83820.c:603:6: warning: variable ‘tbisr’ set but not used [-Wunused-but-set-variable] 603 | u32 tbisr, tanar, tanlpar; | ^~~~~ drivers/net/ethernet/natsemi/ns83820.c: In function ‘ns83820_get_link_ksettings’: drivers/net/ethernet/natsemi/ns83820.c:1207:11: warning: variable ‘tanar’ set but not used [-Wunused-but-set-variable] 1207 | u32 cfg, tanar, tbicr; | ^~~~~ drivers/net/ethernet/packetengines/yellowfin.c:1063:18: warning: variable ‘yf_size’ set but not used [-Wunused-but-set-variable] 1063 | int data_size, yf_size; | ^~~~~~~ Normal kdoc fixes: warning: Function parameter or member 'x' not described in 'y' warning: Excess function parameter 'x' description in 'y' warning: Cannot understand <string> on line <NNN> - I thought it was a doc line [*] - ok it wasn't quite a million, but it felt like it. Signed-off-by: -
Jesse Brandeburg authored
kernel-doc script as used by W=1, is confused by the macro usage inside the header describing the efx_ptp_data struct. drivers/net/ethernet/sfc/ptp.c:345: warning: Function parameter or member 'MC_CMD_PTP_IN_TRANSMIT_LENMAX' not described in 'efx_ptp_data' After some discussion on the list, break this patch out to a separate one, and fix the issue through a creative macro declaration. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Jesse Brandeburg authored
As part of the W=1 series for ethernet, these drivers were discovered to be using kdoc style comments but were not actually doing kdoc. The kernel uses kdoc style when documenting code, not doxygen or other styles. Fixed Warnings: drivers/net/ethernet/amazon/ena/ena_com.c:613: warning: Function parameter or member 'ena_dev' not described in 'ena_com_set_llq' drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c:1540: warning: Cannot understand * @brief Set VLAN filter table drivers/net/ethernet/xilinx/ll_temac_main.c:114: warning: Function parameter or member 'lp' not described in 'temac_indirect_busywait' drivers/net/ethernet/xilinx/ll_temac_main.c:129: warning: Function parameter or member 'lp' not described in 'temac_indirect_in32' drivers/net/ethernet/xilinx/ll_temac_main.c:129: warning: Function parameter or member 'reg' not described in 'temac_indirect_in32' drivers/net/ethernet/xilinx/ll_temac_main.c:147: warning: Function parameter or member 'lp' not described in 'temac_indirect_in32_locked' drivers/net/ethernet/xilinx/ll_temac_main.c:147: warning: Function parameter or member 'reg' not described in 'temac_indirect_in32_locked' drivers/net/ethernet/xilinx/ll_temac_main.c:172: warning: Function parameter or member 'lp' not described in 'temac_indirect_out32' drivers/net/ethernet/xilinx/ll_temac_main.c:172: warning: Function parameter or member 'reg' not described in 'temac_indirect_out32' drivers/net/ethernet/xilinx/ll_temac_main.c:172: warning: Function parameter or member 'value' not described in 'temac_indirect_out32' drivers/net/ethernet/xilinx/ll_temac_main.c:188: warning: Function parameter or member 'lp' not described in 'temac_indirect_out32_locked' drivers/net/ethernet/xilinx/ll_temac_main.c:188: warning: Function parameter or member 'reg' not described in 'temac_indirect_out32_locked' drivers/net/ethernet/xilinx/ll_temac_main.c:188: warning: Function parameter or member 'value' not described in 'temac_indirect_out32_locked' drivers/net/ethernet/xilinx/ll_temac_main.c:212: warning: Function parameter or member 'lp' not described in 'temac_dma_in32_be' drivers/net/ethernet/xilinx/ll_temac_main.c:212: warning: Function parameter or member 'reg' not described in 'temac_dma_in32_be' drivers/net/ethernet/xilinx/ll_temac_main.c:228: warning: Function parameter or member 'lp' not described in 'temac_dma_out32_be' drivers/net/ethernet/xilinx/ll_temac_main.c:228: warning: Function parameter or member 'reg' not described in 'temac_dma_out32_be' drivers/net/ethernet/xilinx/ll_temac_main.c:228: warning: Function parameter or member 'value' not described in 'temac_dma_out32_be' drivers/net/ethernet/xilinx/ll_temac_main.c:247: warning: Function parameter or member 'lp' not described in 'temac_dma_dcr_in' drivers/net/ethernet/xilinx/ll_temac_main.c:247: warning: Function parameter or member 'reg' not described in 'temac_dma_dcr_in' drivers/net/ethernet/xilinx/ll_temac_main.c:255: warning: Function parameter or member 'lp' not described in 'temac_dma_dcr_out' drivers/net/ethernet/xilinx/ll_temac_main.c:255: warning: Function parameter or member 'reg' not described in 'temac_dma_dcr_out' drivers/net/ethernet/xilinx/ll_temac_main.c:255: warning: Function parameter or member 'value' not described in 'temac_dma_dcr_out' drivers/net/ethernet/xilinx/ll_temac_main.c:265: warning: Function parameter or member 'lp' not described in 'temac_dcr_setup' drivers/net/ethernet/xilinx/ll_temac_main.c:265: warning: Function parameter or member 'op' not described in 'temac_dcr_setup' drivers/net/ethernet/xilinx/ll_temac_main.c:265: warning: Function parameter or member 'np' not described in 'temac_dcr_setup' drivers/net/ethernet/xilinx/ll_temac_main.c:300: warning: Function parameter or member 'ndev' not described in 'temac_dma_bd_release' drivers/net/ethernet/xilinx/ll_temac_main.c:330: warning: Function parameter or member 'ndev' not described in 'temac_dma_bd_init' drivers/net/ethernet/xilinx/ll_temac_main.c:600: warning: Function parameter or member 'ndev' not described in 'temac_setoptions' drivers/net/ethernet/xilinx/ll_temac_main.c:600: warning: Function parameter or member 'options' not described in 'temac_setoptions' Signed-off-by:
-
Jesse Brandeburg authored
A couple of drivers had a "generic documentation" section that would trigger a "can't understand" message from W=1 compiles. Fix by using correct DOC: tags in the generic sections. Fixed Warnings: drivers/net/ethernet/arc/emac_arc.c:4: info: Scanning doc for c drivers/net/ethernet/cadence/macb_pci.c:3: warning: missing initial short description on line: * Cadence GEM PCI wrapper. drivers/net/ethernet/cadence/macb_pci.c:3: info: Scanning doc for Cadence Signed-off-by:
-
Jesse Brandeburg authored
While fixing the W=1 builds, this warning came up because the developers used a very tricky way to get structures initialized to a non-zero value, but this causes GCC to warn about an override. In this case the override was intentional, so just disable the warning for this code with a kernel macro that results in disabling the warning for compiles on GCC versions after 8. It is not appropriate to change the struct to initialize all the values as it will just add a lot more code for no value. The code is completely correct as is, we just want to acknowledge that this code could generate a warning and we're ok with that. NOTE: the __diag_ignore macro currently only accepts a second argument of 8 (version 80000), it's either use this one or open code the pragma. Fixed Warnings example (all the same): drivers/net/ethernet/renesas/sh_eth.c:51:12: warning: initialized field overwritten [-Woverride-init] drivers/net/ethernet/renesas/sh_eth.c:52:12: warning: initialized field overwritten [-Woverride-init] drivers/net/ethernet/renesas/sh_eth.c:53:13: warning: initialized field overwritten [-Woverride-init] + 256 more... Signed-off-by:
-
Jesse Brandeburg authored
The W=1 builds showed a few files exporting functions (non-static) that were not prototyped. What actually happened is that there were prototypes, but the include file was forgotten in the implementation file. Add the include file and remove the warnings. Fixed Warnings: drivers/net/ethernet/cavium/liquidio/cn68xx_device.c:124:5: warning: no previous prototype for ‘lio_setup_cn68xx_octeon_device’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:159:1: warning: no previous prototype for ‘octeon_pci_read_core_mem’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:168:1: warning: no previous prototype for ‘octeon_pci_write_core_mem’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:176:5: warning: no previous prototype for ‘octeon_read_device_mem64’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:185:5: warning: no previous prototype for ‘octeon_read_device_mem32’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:194:6: warning: no previous prototype for ‘octeon_write_device_mem32’ [-Wmissing-prototypes] drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c:453:6: warning: no previous prototype for ‘hclge_dcb_ops_set’ [-Wmissing-prototypes] Signed-off-by:
-
Jesse Brandeburg authored
As part of the W=1 compliation series, these lines all created warnings about unused variables that were assigned a value. Most of them are from register reads, but some are just picking up a return value from a function and never doing anything with it. Fixed warnings: .../ethernet/brocade/bna/bnad.c:3280:6: warning: variable ‘rx_count’ set but not used [-Wunused-but-set-variable] .../ethernet/brocade/bna/bnad.c:3280:6: warning: variable ‘rx_count’ set but not used [-Wunused-but-set-variable] .../ethernet/cortina/gemini.c:512:6: warning: variable ‘val’ set but not used [-Wunused-but-set-variable] .../ethernet/cortina/gemini.c:2110:21: warning: variable ‘config0’ set but not used [-Wunused-but-set-variable] .../ethernet/cavium/liquidio/octeon_device.c:1327:6: warning: variable ‘val32’ set but not used [-Wunused-but-set-variable] .../ethernet/cavium/liquidio/octeon_device.c:1358:6: warning: variable ‘val32’ set but not used [-Wunused-but-set-variable] .../ethernet/dec/tulip/media.c:322:8: warning: variable ‘setup’ set but not used [-Wunused-but-set-variable] .../ethernet/dec/tulip/de4x5.c:4928:13: warning: variable ‘r3’ set but not used [-Wunused-but-set-variable] .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] .../ethernet/micrel/ksz884x.c:4981:6: warning: variable ‘rx_status’ set but not used [-Wunused-but-set-variable] .../ethernet/micrel/ksz884x.c:6510:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable] .../ethernet/micrel/ksz884x.c:6087: warning: cannot understand function prototype: 'struct hw_regs ' .../ethernet/microchip/lan743x_main.c:161:6: warning: variable ‘int_en’ set but not used [-Wunused-but-set-variable] .../ethernet/microchip/lan743x_main.c:1702:6: warning: variable ‘int_sts’ set but not used [-Wunused-but-set-variable] .../ethernet/microchip/lan743x_main.c:3041:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] .../ethernet/natsemi/ns83820.c:603:6: warning: variable ‘tbisr’ set but not used [-Wunused-but-set-variable] .../ethernet/natsemi/ns83820.c:1207:11: warning: variable ‘tanar’ set but not used [-Wunused-but-set-variable] .../ethernet/marvell/mvneta.c:754:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] .../ethernet/neterion/vxge/vxge-traffic.c:33:6: warning: variable ‘val64’ set but not used [-Wunused-but-set-variable] .../ethernet/neterion/vxge/vxge-traffic.c:160:6: warning: variable ‘val64’ set but not used [-Wunused-but-set-variable] .../ethernet/neterion/vxge/vxge-traffic.c:490:6: warning: variable ‘val32’ set but not used [-Wunused-but-set-variable] .../ethernet/neterion/vxge/vxge-traffic.c:2378:6: warning: variable ‘val64’ set but not used [-Wunused-but-set-variable] .../ethernet/packetengines/yellowfin.c:1063:18: warning: variable ‘yf_size’ set but not used [-Wunused-but-set-variable] .../ethernet/realtek/8139cp.c:1242:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable] .../ethernet/mellanox/mlx4/en_tx.c:858:6: warning: variable ‘ring_cons’ set but not used [-Wunused-but-set-variable] .../ethernet/sis/sis900.c:792:6: warning: variable ‘status’ set but not used [-Wunused-but-set-variable] .../ethernet/sfc/falcon/farch.c:878:11: warning: variable ‘rx_ev_pkt_type’ set but not used [-Wunused-but-set-variable] .../ethernet/sfc/falcon/farch.c:877:23: warning: variable ‘rx_ev_mcast_pkt’ set but not used [-Wunused-but-set-variable] .../ethernet/sfc/falcon/farch.c:877:7: warning: variable ‘rx_ev_hdr_type’ set but not used [-Wunused-but-set-variable] .../ethernet/sfc/falcon/farch.c:876:7: warning: variable ‘rx_ev_other_err’ set but not used [-Wunused-but-set-variable] .../ethernet/sfc/falcon/farch.c:1646:21: warning: variable ‘buftbl_min’ set but not used [-Wunused-but-set-variable] .../ethernet/sfc/falcon/farch.c:2535:32: warning: variable ‘spec’ set but not used [-Wunused-but-set-variable] .../ethernet/via/via-velocity.c:880:6: warning: variable ‘curr_status’ set but not used [-Wunused-but-set-variable] .../ethernet/ti/tlan.c:656:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable] .../ethernet/ti/davinci_emac.c:1230:6: warning: variable ‘num_tx_pkts’ set but not used [-Wunused-but-set-variable] .../ethernet/synopsys/dwc-xlgmac-common.c:516:8: warning: variable ‘str’ set but not used [-Wunused-but-set-variable] .../ethernet/ti/cpsw_new.c:1662:22: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable] The register reads should be OK, because the current implementation of readl and friends will always execute even without an lvalue. When it makes sense, just remove the lvalue assignment and the local. Other times, just remove the offending code, and occasionally, just mark the variable as maybe unused since it could be used in an ifdef or debug scenario. Only compile tested with W=1. Signed-off-by:
-
Jesse Brandeburg authored
Remove variables that were storing a return value from a register read or other read, where the return value wasn't used. Those conversions to remove the lvalue of the assignment should be safe because the readl memory mapped reads are marked volatile and should not be optimized out without an lvalue (I suspect a very long time ago this wasn't guaranteed as it is today). These changes are part of a separate patch to make it easier to review. Warnings Fixed: .../intel/e100.c:2596:9: warning: variable ‘err’ set but not used [-Wunused-but-set-variable] .../intel/ixgb/ixgb_hw.c:101:6: warning: variable ‘icr_reg’ set but not used [-Wunused-but-set-variable] .../intel/ixgb/ixgb_hw.c:277:6: warning: variable ‘ctrl_reg’ set but not used [-Wunused-but-set-variable] .../intel/ixgb/ixgb_hw.c:952:15: warning: variable ‘temp_reg’ set but not used [-Wunused-but-set-variable] .../intel/ixgb/ixgb_hw.c:1164:7: warning: variable ‘mdio_reg’ set but not used [-Wunused-but-set-variable] .../intel/e1000/e1000_hw.c:132:6: warning: variable ‘ret_val’ set but not used [-Wunused-but-set-variable] .../intel/e1000/e1000_hw.c:380:6: warning: variable ‘icr’ set but not used [-Wunused-but-set-variable] .../intel/e1000/e1000_hw.c:2378:6: warning: variable ‘signal’ set but not used [-Wunused-but-set-variable] .../intel/e1000/e1000_hw.c:2374:6: warning: variable ‘ctrl’ set but not used [-Wunused-but-set-variable] .../intel/e1000/e1000_hw.c:2373:6: warning: variable ‘rxcw’ set but not used [-Wunused-but-set-variable] .../intel/e1000/e1000_hw.c:4678:15: warning: variable ‘temp’ set but not used [-Wunused-but-set-variable] Signed-off-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Jesse Brandeburg authored
This takes care of all of the trivial W=1 fixes in the Intel Ethernet drivers, which allows developers and maintainers to build more of the networking tree with more complete warning checks. There are three classes of kdoc warnings fixed: - cannot understand function prototype: 'x' - Excess function parameter 'x' description in 'y' - Function parameter or member 'x' not described in 'y' All of the changes were trivial comment updates on function headers. Inspired by Lee Jones' series of wireless work to do the same. Compile tested only, and passes simple test of $ git ls-files *.[ch] | egrep drivers/net/ethernet/intel | \ xargs scripts/kernel-doc -none Signed-off-by:
-
Florian Fainelli authored
While we should always make sure that we specify a valid VLAN protocol to vlan_proto_idx(), killing the machine when an invalid value is specified is too harsh and not helpful for debugging. All callers are capable of dealing with an error returned by vlan_proto_idx() so check the index value and propagate it accordingly. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-2020-09-25' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.10 Second set of patches for v5.10. Biggest change here is wcn3680 support to wcn36xx driver, otherwise smaller features. And naturally the usual fixes and cleanups. Major changes: brcmfmac * support 4-way handshake offloading for WPA/WPA2-PSK in AP mode * support SAE authentication offload in AP mode mt76 * mt7663 runtime power management improvements * mt7915 A-MSDU offload wcn36xx * add support wcn3680 Wi-Fi 5 devices ath11k * spectral scan support for ipq6018 ==================== Signed-off-by:
-
Kalle Valo authored
kbuild bot reported than link fails when CONFIG_ATH11K_DEBUGFS is disabled: drivers/net/wireless/ath/ath11k/dp_rx.c:1662: undefined reference to `ath11k_debugfs_htt_ext_stats_handler' This was because I had missed to move the static inline version of the function (which are used when CONFIG_ATH11K_DEBUGFS is disabled) to debufs_htt_stats.h. Also move ath11k_debugfs_htt_stats_req() at the same time. And create a stub also for ath11k_debugfs_htt_stats_init() for consistency, even if it's not needed. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 568f0603 ("ath11k: debugfs: move some function declarations to correct header files") Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601024241-16594-1-git-send-email-kvalo@codeaurora.org
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: updates for -next There are some updates for the HNS3 ethernet driver. ==================== Signed-off-by: -
Guangbin Huang authored
VF devices do not have speed division, its speed is depended on its PF. So macro name of PCI device id of VF is incorrent to have 100G info, it should be renamed by removing 100G info. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guangbin Huang authored
The 200G device has a new device id 0xA228, so adds this device id to pci table, then the driver can probe it. As speed_ability queried from firmware has only 8 bits and already be used up, so firmware adds extra speed_ability_ext to indicate more speed abilities to support 200G and driver needs to parse it. Signed-off-by:
-
Yufeng Mo authored
The pf's interrupt resources will be changed with the number of enabled pf. Dumping this resource information will be helpful for debugging. Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
-
