1. 26 Sep, 2020 22 commits
    • Vladimir Oltean's avatar
      net: dsa: make the .flow_dissect tagger callback return void · 2e8cb1b3
      Vladimir Oltean authored
      There is no tagger that returns anything other than zero, so just change
      the return type appropriately.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e8cb1b3
    • Vladimir Oltean's avatar
      net: dsa: tag_ocelot: use a short prefix on both ingress and egress · 5124197c
      Vladimir Oltean authored
      There are 2 goals that we follow:
      
      - Reduce the header size
      - Make the header size equal between RX and TX
      
      The issue that required long prefix on RX was the fact that the ocelot
      DSA tag, being put before Ethernet as it is, would overlap with the area
      that a DSA master uses for RX filtering (destination MAC address
      mainly).
      
      Now that we can ask DSA to put the master in promiscuous mode, in theory
      we could remove the prefix altogether and call it a day, but it looks
      like we can't. Using no prefix on ingress, some packets (such as ICMP)
      would be received, while others (such as PTP) would not be received.
      This is because the DSA master we use (enetc) triggers parse errors
      ("MAC rx frame errors") presumably because it sees Ethernet frames with
      a bad length. And indeed, when using no prefix, the EtherType (bytes
      12-13 of the frame, bits 96-111) falls over the REW_VAL field from the
      extraction header, aka the PTP timestamp.
      
      When turning the short (32-bit) prefix on, the EtherType overlaps with
      bits 64-79 of the extraction header, which are a reserved area
      transmitted as zero by the switch. The packets are not dropped by the
      DSA master with a short prefix. Actually, the frames look like this in
      tcpdump (below is a PTP frame, with an extra dsa_8021q tag - dadb 0482 -
      added by a downstream sja1105).
      
      89:0c:a9:f2:01:00 > 88:80:00:0a:00:1d, 802.3, length 0: LLC, \
      	dsap Unknown (0x10) Individual, ssap ProWay NM (0x0e) Response, \
      	ctrl 0x0004: Information, send seq 2, rcv seq 0, \
      	Flags [Response], length 78
      
      0x0000:  8880 000a 001d 890c a9f2 0100 0000 100f  ................
      0x0010:  0400 0000 0180 c200 000e 001f 7b63 0248  ............{c.H
      0x0020:  dadb 0482 88f7 1202 0036 0000 0000 0000  .........6......
      0x0030:  0000 0000 0000 0000 0000 001f 7bff fe63  ............{..c
      0x0040:  0248 0001 1f81 0500 0000 0000 0000 0000  .H..............
      0x0050:  0000 0000 0000 0000 0000 0000            ............
      
      So the short prefix is our new default: we've shortened our RX frames by
      12 octets, increased TX by 4, and headers are now equal between RX and
      TX. Note that we still need promiscuous mode for the DSA master to not
      drop it.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5124197c
    • Vladimir Oltean's avatar
      net: dsa: tag_sja1105: request promiscuous mode for master · 707091eb
      Vladimir Oltean authored
      Currently PTP is broken when ports are in standalone mode (the tagger
      keeps printing this message):
      
      sja1105 spi0.1: Expected meta frame, is 01-80-c2-00-00-0e in the DSA master multicast filter?
      
      Sure, one might say "simply add 01-80-c2-00-00-0e to the master's RX
      filter" but things become more complicated because:
      
      - Actually all frames in the 01-80-c2-xx-xx-xx and 01-1b-19-xx-xx-xx
        range are trapped to the CPU automatically
      - The switch mangles bytes 3 and 4 of the MAC address via the incl_srcpt
        ("include source port [in the DMAC]") option, which is how source port
        and switch id identification is done for link-local traffic on RX. But
        this means that an address installed to the RX filter would, at the
        end of the day, not correspond to the final address seen by the DSA
        master.
      
      Assume RX filtering lists on DSA masters are typically too small to
      include all necessary addresses for PTP to work properly on sja1105, and
      just request promiscuous mode unconditionally.
      
      Just an example:
      Assuming the following addresses are trapped to the CPU:
      01-80-c2-00-00-00 to 01-80-c2-00-00-ff
      01-1b-19-00-00-00 to 01-1b-19-00-00-ff
      
      These are 512 addresses.
      Now let's say this is a board with 3 switches, and 4 ports per switch.
      The 512 addresses become 6144 addresses that must be managed by the DSA
      master's RX filtering lists.
      
      This may be refined in the future, but for now, it is simply not worth
      it to add the additional addresses to the master's RX filter, so simply
      request it to become promiscuous as soon as the driver probes.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      707091eb
    • Vladimir Oltean's avatar
      net: dsa: allow drivers to request promiscuous mode on master · c3975400
      Vladimir Oltean authored
      Currently DSA assumes that taggers don't mess with the destination MAC
      address of the frames on RX. That is not always the case. Some DSA
      headers are placed before the Ethernet header (ocelot), and others
      simply mangle random bytes from the destination MAC address (sja1105
      with its incl_srcpt option).
      
      Currently the DSA master goes to promiscuous mode automatically when the
      slave devices go too (such as when enslaved to a bridge), but in
      standalone mode this is a problem that needs to be dealt with.
      
      So give drivers the possibility to signal that their tagging protocol
      will get randomly dropped otherwise, and let DSA deal with fixing that.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3975400
    • Vladimir Oltean's avatar
      net: mscc: ocelot: move NPI port configuration to DSA · 2d44b097
      Vladimir Oltean authored
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d44b097
    • Jakub Kicinski's avatar
      Revert "vxlan: move encapsulation warning" · 435be28b
      Jakub Kicinski authored
      This reverts commit 546c044c.
      
      Nothing prevents user from sending frames to "external" VxLAN devices.
      In fact kernel itself may generate icmp chatter.
      
      This is fine, such frames should be dropped.
      
      The point of the "missing encapsulation" warning was that
      frames with missing encap should not make it into vxlan_xmit_one().
      And vxlan_xmit() drops them cleanly, so let it just do that.
      
      Without this revert the warning is triggered by the udp_tunnel_nic.sh
      test, but the minimal repro is:
      
      $ ip link add vxlan0 type vxlan \
           	      	     group 239.1.1.1 \
      		     dev lo \
      		     dstport 1234 \
      		     external
      $ ip li set dev vxlan0 up
      
      [  419.165981] vxlan0: Missing encapsulation instructions
      [  419.166551] WARNING: CPU: 0 PID: 1041 at drivers/net/vxlan.c:2889 vxlan_xmit+0x15c0/0x1fc0 [vxlan]
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      435be28b
    • David S. Miller's avatar
      Merge branch 'devlink-flash-update-overwrite-mask' · cb9e4a73
      David S. Miller authored
      Jacob Keller says:
      
      ====================
      devlink flash update overwrite mask
      
      This series introduces support for a new attribute to the flash update
      command: DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK.
      
      This attribute is a bitfield which allows userspace to specify what set of
      subfields to overwrite when performing a flash update for a device.
      
      The intention is to support the ability to control the behavior of
      overwriting the configuration and identifying fields in the Intel ice device
      flash update process. This is necessary  as the firmware layout for the ice
      device includes some settings and configuration within the same flash
      section as the main firmware binary.
      
      This series, and the accompanying iproute2 series, introduce support for the
      attribute. Once applied, the overwrite support can be be invoked via
      devlink:
      
        # overwrite settings
        devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings
      
        # overwrite identifiers and settings
        devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings overwrite identifiers
      
      To aid in the safe addition of new parameters, first some refactoring is
      done to the .flash_update function: its parameters are converted from a
      series of function arguments into a structure. This makes it easier to add
      the new parameter without changing the signature of the .flash_update
      handler in the future. Additionally, a "supported_flash_update_params" field
      is added to devlink_ops. This field is similar to the ethtool
      "supported_coalesc_params" field. The devlink core will now check that the
      DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT bit is set before forwarding the
      component attribute. Similarly, the new overwrite attribute will also
      require a supported bit.
      
      Doing these refactors will aid in adding any other attributes in the future,
      and creates a good pattern for other interfaces to use in the future. By
      requiring drivers to opt-in, we reduce the risk of accidentally breaking
      drivers when ever we add an additional parameter. We also reduce boiler
      plate code in drivers which do not support the parameters.
      
      Changes since v9:
      * rebased to current net-next, no other changes
      
      Changes since v7
      * resend, hopefully avoiding the SMTP server issues I experienced on Friday
      
      Changes since v6
      * Rebased to current net-next to resolve conflicts
      * Added changes to the ionic driver that recently merged flash update support
      * Fixed the changes for mlxsw to apply to core instead of spectrum.c after
        the recent refactor.
      * Picked up the review tags from Jakub
      
      Changes since v5
      * Fix *all* of the BIT usage to use _BITUL() (thanks Jakub!)
      
      Changes since v4
      * Renamed nla_overwrite to nla_overwrite_mask at Jiri's suggestion
      * Added "by this device" to the netlink error messages for unsupported
        attributes
      * Removed use of BIT() in the uapi header
      * Fixed the commit message for the netdevsim patch
      * Picked up Jakub's reviewed
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb9e4a73
    • Jacob Keller's avatar
      ice: add support for flash update overwrite mask · 50db1bca
      Jacob Keller authored
      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: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      50db1bca
    • Jacob Keller's avatar
      netdevsim: add support for flash_update overwrite mask · cbb58368
      Jacob Keller authored
      The devlink interface recently gained support for a new "overwrite mask"
      parameter that allows specifying how various sub-sections of a flash
      component are modified when updating.
      
      Add support for this to netdevsim, to enable easily testing the
      interface. Make the allowed overwrite mask values controllable via
      a debugfs parameter. This enables testing a flow where the driver
      rejects an unsupportable overwrite mask.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbb58368
    • Jacob Keller's avatar
      devlink: introduce flash update overwrite mask · 5d5b4128
      Jacob Keller authored
      Sections of device flash may contain settings or device identifying
      information. When performing a flash update, it is generally expected
      that these settings and identifiers are not overwritten.
      
      However, it may sometimes be useful to allow overwriting these fields
      when performing a flash update. Some examples include, 1) customizing
      the initial device config on first programming, such as overwriting
      default device identifying information, or 2) reverting a device
      configuration to known good state provided in the new firmware image, or
      3) in case it is suspected that current firmware logic for managing the
      preservation of fields during an update is broken.
      
      Although some devices are able to completely separate these types of
      settings and fields into separate components, this is not true for all
      hardware.
      
      To support controlling this behavior, a new
      DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK is defined. This is an
      nla_bitfield32 which will define what subset of fields in a component
      should be overwritten during an update.
      
      If no bits are specified, or of the overwrite mask is not provided, then
      an update should not overwrite anything, and should maintain the
      settings and identifiers as they are in the previous image.
      
      If the overwrite mask has the DEVLINK_FLASH_OVERWRITE_SETTINGS bit set,
      then the device should be configured to overwrite any of the settings in
      the requested component with settings found in the provided image.
      
      Similarly, if the DEVLINK_FLASH_OVERWRITE_IDENTIFIERS bit is set, the
      device should be configured to overwrite any device identifiers in the
      requested component with the identifiers from the image.
      
      Multiple overwrite modes may be combined to indicate that a combination
      of the set of fields that should be overwritten.
      
      Drivers which support the new overwrite mask must set the
      DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK in the
      supported_flash_update_params field of their devlink_ops.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d5b4128
    • Jacob Keller's avatar
      devlink: convert flash_update to use params structure · bc75c054
      Jacob Keller authored
      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: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJakub 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: default avatarDavid S. Miller <davem@davemloft.net>
      bc75c054
    • Jacob Keller's avatar
      devlink: check flash_update parameter support in net core · 22ec3d23
      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: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJakub 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: default avatarDavid S. Miller <davem@davemloft.net>
      22ec3d23
    • David S. Miller's avatar
      Merge branch 'simplify-TCP-loss-marking-code' · 6fba737a
      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: default avatarDavid S. Miller <davem@davemloft.net>
      6fba737a
    • Yuchung Cheng's avatar
      tcp: consolidate tcp_mark_skb_lost and tcp_skb_mark_lost · 534a2109
      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: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      534a2109
    • Yuchung Cheng's avatar
      tcp: simplify tcp_mark_skb_lost · 68698970
      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: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68698970
    • Yuchung Cheng's avatar
      tcp: move tcp_mark_skb_lost · fd214674
      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: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd214674
    • Yuchung Cheng's avatar
      tcp: consistently check retransmit hint · 179ac35f
      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: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      179ac35f
    • Gustavo A. R. Silva's avatar
      dpaa2-mac: Fix potential null pointer dereference · b4f43483
      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: default avatarGustavo A. R. Silva <gustavoars@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4f43483
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-small-updates' · 9b69e5eb
      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: default avatarDavid S. Miller <davem@davemloft.net>
      9b69e5eb
    • Ionut-robert Aron's avatar
      dpaa2-eth: install a single steering rule when SHARED_FS is enabled · 5e29c16f
      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: default avatarIonut-robert Aron <ionut-robert.aron@nxp.com>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e29c16f
    • Ioana Ciornei's avatar
      dpaa2-eth: no need to check link state right after ndo_open · 4c33a5bd
      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: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c33a5bd
    • Ioana Ciornei's avatar
      dpaa2-mac: do not check for both child and parent DTS nodes · 98179709
      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: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98179709
  2. 25 Sep, 2020 18 commits
    • David S. Miller's avatar
      Merge branch 'vxlan-clean-up' · bd0b68a8
      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: default avatarDavid S. Miller <davem@davemloft.net>
      bd0b68a8
    • Fabian Frederick's avatar
      vxlan: fix vxlan_find_sock() documentation for l3mdev · 78ec710e
      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: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78ec710e
    • Fabian Frederick's avatar
      vxlan: check rtnl_configure_link return code correctly · 2eabcb8a
      Fabian Frederick authored
      rtnl_configure_link is always checked if < 0 for error code.
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2eabcb8a
    • Fabian Frederick's avatar
      vxlan: move encapsulation warning · 546c044c
      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: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      546c044c
    • Fabian Frederick's avatar
      vxlan: add unlikely to vxlan_remcsum check · 0189399c
      Fabian Frederick authored
      small optimization around checking as it's being done in all
      receptions
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0189399c
    • Fabian Frederick's avatar
      vxlan: don't collect metadata if remote checksum is wrong · 2ae2904b
      Fabian Frederick authored
      call vxlan_remcsum() before md filling in vxlan_rcv()
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ae2904b
    • Nikolay Aleksandrov's avatar
      net: bridge: mcast: remove only S,G port groups from sg_port hash · 74705582
      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: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74705582
    • Chuah, Kim Tatt's avatar
      net: stmmac: Add option for VLAN filter fail queue enable · e0f9956a
      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: default avatarVoon Weifeng <weifeng.voon@intel.com>
      Reviewed-by: default avatarOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: default avatarChuah, Kim Tatt <kim.tatt.chuah@intel.com>
      Signed-off-by: default avatarOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0f9956a
    • David S. Miller's avatar
      Merge branch 'Devlink-regions-for-SJA1105-DSA-driver' · 17705434
      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: default avatarDavid S. Miller <davem@davemloft.net>
      17705434
    • Vladimir Oltean's avatar
      net: dsa: sja1105: implement .devlink_info_get · ff4cf8ea
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff4cf8ea
    • Vladimir Oltean's avatar
      net: dsa: sja1105: expose static config as devlink region · bf425b82
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf425b82
    • Vladimir Oltean's avatar
      net: dsa: sja1105: move devlink param code to sja1105_devlink.c · 0a7bdbc2
      Vladimir Oltean authored
      We'll have more devlink code soon. Group it together in a separate
      translation object.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a7bdbc2
    • David S. Miller's avatar
      Merge branch 'drivers-net-warning-clean' · e666a4c6
      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: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarSaeed Mahameed <saeed@kernel.org>
      e666a4c6
    • Jesse Brandeburg's avatar
      drivers/net/ethernet: clean up mis-targeted comments · d0ea5cbd
      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: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0ea5cbd
    • Jesse Brandeburg's avatar
      sfc: fix kdoc warning · add3c86a
      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: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Acked-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      add3c86a
    • Jesse Brandeburg's avatar
      drivers/net/ethernet: remove incorrectly formatted doc · 81929a4a
      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: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81929a4a
    • Jesse Brandeburg's avatar
      drivers/net/ethernet: add some basic kdoc tags · f410f157
      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: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f410f157
    • Jesse Brandeburg's avatar
      drivers/net/ethernet: handle one warning explicitly · 2602ddfe
      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: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2602ddfe