1. 28 9月, 2020 5 次提交
  2. 27 9月, 2020 1 次提交
    • V
      net: mscc: ocelot: move NPI port configuration to DSA · 2d44b097
      Vladimir Oltean 提交于
      Remove the ocelot_configure_cpu() function, which was in fact bringing
      up 2 ports: the CPU port module, which both switchdev and DSA have, and
      the NPI port, which only DSA has.
      
      The (non-Ethernet) CPU port module is at a fixed index in the analyzer,
      whereas the NPI port is selected through the "ethernet" property in the
      device tree.
      
      Therefore, the function to set up an NPI port is DSA-specific, so we
      move it there, simplifying the ocelot switch library a little bit.
      
      Cc: Horatiu Vultur <horatiu.vultur@microchip.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: UNGLinuxDriver <UNGLinuxDriver@microchip.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d44b097
  3. 26 9月, 2020 17 次提交
    • J
      ice: add support for flash update overwrite mask · 50db1bca
      Jacob Keller 提交于
      Support the recently added DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK
      parameter in the ice flash update handler. Convert the overwrite mask
      bitfield into the appropriate preservation level used by the firmware
      when updating.
      
      Because there is no equivalent preservation level for overwriting only
      identifiers, this combination is rejected by the driver as not supported
      with an appropriate extended ACK message.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50db1bca
    • J
      devlink: convert flash_update to use params structure · bc75c054
      Jacob Keller 提交于
      The devlink core recently gained support for checking whether the driver
      supports a flash_update parameter, via `supported_flash_update_params`.
      However, parameters are specified as function arguments. Adding a new
      parameter still requires modifying the signature of the .flash_update
      callback in all drivers.
      
      Convert the .flash_update function to take a new `struct
      devlink_flash_update_params` instead. By using this structure, and the
      `supported_flash_update_params` bit field, a new parameter to
      flash_update can be added without requiring modification to existing
      drivers.
      
      As before, all parameters except file_name will require driver opt-in.
      Because file_name is a necessary field to for the flash_update to make
      sense, no "SUPPORTED" bitflag is provided and it is always considered
      valid. All future additional parameters will require a new bit in the
      supported_flash_update_params bitfield.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      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>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc75c054
    • J
      devlink: check flash_update parameter support in net core · 22ec3d23
      Jacob Keller 提交于
      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: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub 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: NDavid S. Miller <davem@davemloft.net>
      22ec3d23
    • G
      dpaa2-mac: Fix potential null pointer dereference · b4f43483
      Gustavo A. R. Silva 提交于
      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: NGustavo A. R. Silva <gustavoars@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4f43483
    • I
      dpaa2-eth: install a single steering rule when SHARED_FS is enabled · 5e29c16f
      Ionut-robert Aron 提交于
      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: NIonut-robert Aron <ionut-robert.aron@nxp.com>
      Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e29c16f
    • I
      dpaa2-eth: no need to check link state right after ndo_open · 4c33a5bd
      Ioana Ciornei 提交于
      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: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c33a5bd
    • I
      dpaa2-mac: do not check for both child and parent DTS nodes · 98179709
      Ioana Ciornei 提交于
      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: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98179709
    • C
      net: stmmac: Add option for VLAN filter fail queue enable · e0f9956a
      Chuah, Kim Tatt 提交于
      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: NVoon Weifeng <weifeng.voon@intel.com>
      Reviewed-by: NOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: NChuah, Kim Tatt <kim.tatt.chuah@intel.com>
      Signed-off-by: NOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0f9956a
    • J
      drivers/net/ethernet: clean up mis-targeted comments · d0ea5cbd
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0ea5cbd
    • J
      sfc: fix kdoc warning · add3c86a
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Acked-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      add3c86a
    • J
      drivers/net/ethernet: remove incorrectly formatted doc · 81929a4a
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81929a4a
    • J
      drivers/net/ethernet: add some basic kdoc tags · f410f157
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f410f157
    • J
      drivers/net/ethernet: handle one warning explicitly · 2602ddfe
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2602ddfe
    • J
      drivers/net/ethernet: rid ethernet of no-prototype warnings · 553aca1c
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      553aca1c
    • J
      drivers/net/ethernet: clean up unused assignments · 7c8c0291
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Acked-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c8c0291
    • J
      intel: handle unused assignments · 36ec1486
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36ec1486
    • J
      intel-ethernet: clean up W=1 warnings in kdoc · b50f7bca
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b50f7bca
  4. 25 9月, 2020 8 次提交
  5. 24 9月, 2020 9 次提交