1. 06 Jul, 2022 12 commits
  2. 05 Jul, 2022 7 commits
  3. 04 Jul, 2022 21 commits
    • Zhang Jiaming's avatar
      net: hns: Fix spelling mistakes in comments. · 874bdbfe
      Zhang Jiaming authored
      Fix spelling of 'waitting' in comments.
      remove unnecessary space of 'MDIO_COMMAND_REG 's'.
      Signed-off-by: default avatarZhang Jiaming <jiaming@nfschina.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      874bdbfe
    • David S. Miller's avatar
      Merge branch 'nfp-vlan-strip-and-insert' · fd4b96c4
      David S. Miller authored
      Simon Horman says:
      
      ====================
      nfp: support VLAN strip and insert
      
      this series adds support to the NFP driver for HW offload of both:
      
      * RX VLAN ctag/stag strip
      * TX VLAN ctag insert
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd4b96c4
    • Diana Wang's avatar
      nfp: support TX VLAN ctag insert · d80702ff
      Diana Wang authored
      Add support for TX VLAN ctag insert
      which may be configured via ethtool.
      
      e.g.
           # ethtool -K $DEV tx-vlan-offload on
      
      The NIC supplies VLAN insert information as packet metadata.
      The fields of this VLAN metadata are gotten from sk_buff, including
      vlan_proto and vlan tag.
      
      Configuration control bit NFP_NET_CFG_CTRL_TXVLAN_V2 is to
      signal availability of ctag-insert features of the firmware.
      
      NFDK is used to communicate via PCIE to NFP-3800 based NICs
      while NFD3 is used for other NICs supported by the NFP driver.
      The metadata format on tx side of NFD3 is different from NFDK.
      This feature is not currently implemented for NFDK.
      Signed-off-by: default avatarDiana Wang <na.wang@corigine.com>
      Reviewed-by: default avatarLouis Peens <louis.peens@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d80702ff
    • Diana Wang's avatar
      nfp: support RX VLAN ctag/stag strip · 67d2656b
      Diana Wang authored
      Add support for RX VLAN ctag/stag strip
      which may be configured via ethtool.
      
      e.g.
           # ethtool -K $DEV rx-vlan-offload on
           # ethtool -K $DEV rx-vlan-stag-hw-parse on
      
      Ctag-stripped and stag-stripped cannot be enabled at the same time
      because currently the kernel supports only one layer of VLAN stripping.
      
      The NIC supplies VLAN strip information as packet metadata.
      The fields of this VLAN metadata are:
      
      * strip flag: 1 for stripped; 0 for unstripped
      * tci: VLAN TCI ID
      * tpid: 1 for ETH_P_8021AD; 0 for ETH_P_8021Q
      
      Configuration control bits NFP_NET_CFG_CTRL_RXVLAN_V2 and
      NFP_NET_CFG_CTRL_RXQINQ are to signal availability of
      ctag-strip and stag-strip features of the firmware.
      Signed-off-by: default avatarDiana Wang <na.wang@corigine.com>
      Reviewed-by: default avatarLouis Peens <louis.peens@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67d2656b
    • David S. Miller's avatar
      Merge branch 'smsc95xx-deadlock' · 5ee4bba2
      David S. Miller authored
      Lukas Wunner says:
      
      ====================
      Deadlock no more in LAN95xx
      
      Second attempt at fixing a runtime resume deadlock in the LAN95xx USB driver:
      
      In short, the driver isn't using the "nopm" register accessors in portions
      of its runtime resume path, causing a deadlock.  I'm fixing that by
      auto-detecting whether nopm accessors shall be used, instead of
      having to explicitly call them wherever it's necessary.
      As a byproduct, code size shrinks significantly (see diffstat below).
      
      Back in April I submitted a first attempt which was rejected by Alan Stern:
      https://lore.kernel.org/all/6710d8c18ff54139cdc538763ba544187c5a0cee.1651041411.git.lukas@wunner.de/
      
      That approach only detected whether a PM callback is running concurrently,
      not whether the access is performed by the PM callback.  I've come up with
      a different approach which should resolve the objection (see patch [1/3]).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ee4bba2
    • Lukas Wunner's avatar
      usbnet: smsc95xx: Clean up unnecessary BUG_ON() upon register access · 03b3df43
      Lukas Wunner authored
      smsc95xx_read_reg() and smsc95xx_write_reg() call BUG_ON() if the
      struct usbnet pointer passed in is NULL.
      
      The functions have just been amended to dereference the pointer on
      entry.  So the kernel now oopses if the pointer is NULL, eliminating
      the need for an explicit BUG_ON().
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03b3df43
    • Lukas Wunner's avatar
      usbnet: smsc95xx: Clean up nopm handling · 31472429
      Lukas Wunner authored
      The LAN95xx driver has just been amended to auto-detect whether the
      _nopm variant of usbnet_read_cmd() / usbnet_write_cmd() shall be used.
      
      Drop all the now unnecessary open coding of that distinction.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31472429
    • Lukas Wunner's avatar
      usbnet: smsc95xx: Fix deadlock on runtime resume · 7b960c96
      Lukas Wunner authored
      Commit 05b35e7e ("smsc95xx: add phylib support") amended
      smsc95xx_resume() to call phy_init_hw().  That function waits for the
      device to runtime resume even though it is placed in the runtime resume
      path, causing a deadlock.
      
      The problem is that phy_init_hw() calls down to smsc95xx_mdiobus_read(),
      which never uses the _nopm variant of usbnet_read_cmd().
      
      Commit b4df480f ("usbnet: smsc95xx: add reset_resume function with
      reset operation") causes a similar deadlock on resume if the device was
      already runtime suspended when entering system sleep:
      
      That's because the commit introduced smsc95xx_reset_resume(), which
      calls down to smsc95xx_reset(), which neglects to use _nopm accessors.
      
      Fix by auto-detecting whether a device access is performed by the
      suspend/resume task_struct and use the _nopm variant if so.  This works
      because the PM core guarantees that suspend/resume callbacks are run in
      task context.
      
      Stacktrace for posterity:
      
        INFO: task kworker/2:1:49 blocked for more than 122 seconds.
        Workqueue: usb_hub_wq hub_event
        schedule
        rpm_resume
        __pm_runtime_resume
        usb_autopm_get_interface
        usbnet_read_cmd
        __smsc95xx_read_reg
        __smsc95xx_phy_wait_not_busy
        __smsc95xx_mdio_read
        smsc95xx_mdiobus_read
        __mdiobus_read
        mdiobus_read
        smsc_phy_reset
        phy_init_hw
        smsc95xx_resume
        usb_resume_interface
        usb_resume_both
        usb_runtime_resume
        __rpm_callback
        rpm_callback
        rpm_resume
        __pm_runtime_resume
        usb_autoresume_device
        hub_event
        process_one_work
      
      Fixes: b4df480f ("usbnet: smsc95xx: add reset_resume function with reset operation")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: stable@vger.kernel.org # v3.16+
      Cc: Andre Edich <andre.edich@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b960c96
    • Kurt Kanzenbach's avatar
      net: phy: broadcom: Add support for BCM53128 internal PHYs · 39bfb3c1
      Kurt Kanzenbach authored
      Add support for BCM53128 internal PHYs. These support interrupts as well as
      statistics. Therefore, enable the Broadcom PHY driver for them.
      
      Tested on BCM53128 switch using the mainline b53 DSA driver.
      Signed-off-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39bfb3c1
    • Clément Léger's avatar
      dt-bindings: net: dsa: renesas,rzn1-a5psw: add interrupts description · 326569cc
      Clément Léger authored
      Describe the switch interrupts (dlr, switch, prp, hub, pattern) which
      are connected to the GIC.
      Signed-off-by: default avatarClément Léger <clement.leger@bootlin.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      326569cc
    • Casper Andersson's avatar
      selftest: net: bridge mdb add/del entry to port that is down · 0d153dd2
      Casper Andersson authored
      Tests that permanent mdb entries can be added/deleted on ports with state down.
      Signed-off-by: default avatarCasper Andersson <casper.casan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d153dd2
    • XueBing Chen's avatar
      net: ipconfig: use strscpy to replace strlcpy · 634b215b
      XueBing Chen authored
      The strlcpy should not be used because it doesn't limit the source
      length. Preferred is strscpy.
      Signed-off-by: default avatarXueBing Chen <chenxuebing@jari.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      634b215b
    • David S. Miller's avatar
      Merge branch 'mlxsw-unified-bridge-conversion-part-6' · 798661c7
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Unified bridge conversion - part 6/6
      
      This is the sixth and final part of the conversion of mlxsw to the
      unified bridge model. It transitions the last bits of functionality that
      were under firmware's responsibility in the legacy model to the driver.
      The last patches flip the driver to the unified bridge model and clean
      up code that was used to make the conversion easier to review.
      
      Patchset overview:
      
      Patch #1 sets the egress VID for known unicast packets. For multicast
      packets, the egress VID is configured using the MPE table. See commit
      8c2da081 ("mlxsw: spectrum_fid: Configure egress VID classification
      for multicast").
      
      Patch #2 configures the VNI to FID classification that is used during
      decapsulation.
      
      Patch #3 configures ingress router interface (RIF) in FID classification
      records, so that when a packet reaches the router block, its ingress RIF
      is known. Care is taken to configure this in all the different flows
      (e.g., RIF set on a FID, {Port, VID} joins a FID that already has a RIF
      etc.).
      
      Patch #4 configures the egress VID for routed packets. For such packets,
      the egress VID is not set by the MPE table or by an FDB record at the
      egress bridge, but instead by a dedicated table that maps {Egress RIF,
      Egress port} to a VID.
      
      Patch #5 removes VID configuration from RIF creation as in the unified
      bridge model firmware no longer needs it.
      
      Patch #6 sets the egress FID to use in RIF configuration so that the
      device knows using which FID to bridge the packet after routing.
      
      Patches #7-#9 add a new 802.1Q family and associated VLAN RIFs. In the
      unified bridge model, we no longer need to emulate 802.1Q FIDs using
      802.1D FIDs as VNI can be associated with both.
      
      Patches #10-#11 finally flip the driver to the unified bridge model.
      
      Patches #12-#13 clean up code that was used to make the conversion
      easier to review.
      
      v2:
      * Fix build failure [1] in patch #1.
      
      [1] https://lore.kernel.org/netdev/20220630201709.6e66a1bb@kernel.org/
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      798661c7
    • Amit Cohen's avatar
      mlxsw: spectrum_fid: Remove '_ub_' indication from structures and defines · 88840d69
      Amit Cohen authored
      Some structures and defines were added with '_ub_' indication, as there
      were equivalent objects for the legacy model.
      
      Now when the legacy model is not used anymore, remove the '_ub_'
      indication.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88840d69
    • Amit Cohen's avatar
      mlxsw: spectrum_fid: Remove flood_index() from FID operation structure · 8928fd47
      Amit Cohen authored
      The flood_index() function is not needed anymore, as in the unified
      bridge model the flood index is calculated using 'mid_base' and
      'fid_offset'.
      
      Remove this function.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8928fd47
    • Amit Cohen's avatar
      mlxsw: Enable unified bridge model · 77b7f83d
      Amit Cohen authored
      After all the preparations for unified bridge model, finally flip mlxsw
      driver to use the new model.
      
      Change config profile, set 'ubridge' to true and remove the configurations
      that are relevant only for the legacy model. Set 'flood_mode' to
      'controlled' as the current mode is not supported with unified bridge
      model.
      
      Remove all the code which is dedicated to the legacy model. Remove
      'struct mlxsw_sp.ubridge' variable which was temporarily added to separate
      configurations between the models.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      77b7f83d
    • Amit Cohen's avatar
      mlxsw: Add ubridge to config profile · e9cf8990
      Amit Cohen authored
      The unified bridge model is enabled via the CONFIG_PROFILE command
      during driver initialization. Add the definition of the relevant fields
      to the command's payload in preparation for unified bridge enablement.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9cf8990
    • Amit Cohen's avatar
      mlxsw: Add support for 802.1Q FID family · bf73904f
      Amit Cohen authored
      Using the legacy bridge model, there is no VID classification at egress
      for 802.1Q FIDs, which means that the VID is maintained.
      
      This behavior cause the limitation that 802.1Q FIDs cannot work with VXLAN.
      This limitation stems from the fact that a decapsulated VXLAN packet should
      not contain a VLAN tag. If such a packet was to egress from a local port
      using a 802.1Q FID, it would "maintain" its VLAN on egress, which is no
      VLAN at all.
      
      Currently 802.1Q FIDs are emulated in mlxsw driver using 802.1D FIDs. Using
      unified bridge model, there is a FID->VID mapping, so it is possible to
      stop emulating 802.1Q FIDs.
      
      The main changes are:
      1. Use 'SFGC.bridge_type' = 0, to separate between 802.1Q FIDs and
         802.1D FIDs.
      2. Use VLAN RIF instead of the emulated one (VLAN_EMU which is emulated
         using FID RIF).
      3. Create VID->FID mapping when the FID is created. Then when a new port
         is mapped to the FID, if it not in virtual mode, no new mapping is
         needed. Save the new port in 'port_vid_list', to be able to update a
         RIF in all {Port, VID}->FID mappings in case that the port will be in
         virtual mode later.
      4. Add a dedicated operation function per FID family to update RIF for
         VID->FID mappings. For 802.1d and rFID families, just return. For
         802.1q family, handle the global mapping which is created for new 802.1q
         FID.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf73904f
    • Amit Cohen's avatar
      mlxsw: Add new FID families for unified bridge model · d4324e31
      Amit Cohen authored
      In the unified bridge model, mlxsw will no longer emulate 802.1Q FIDs
      using 802.1D FIDs. The new FID table will look as follows:
      
           +---------------+
           | 802.1q FIDs   | 4K entries
           | [1..4094]     |
           +---------------+
           | 802.1d FIDs   | 1K entries
           | [4095..5118]  |
           +---------------+
           | Dummy FIDs    | 1 entry
           | [5119..5119]  |
           +---------------+
           | rFIDs         | 11K entries
           | [5120..16383] |
           +---------------+
      
      In order to make the change easier to review, four new temporary FID
      families will be added (e.g., MLXSW_SP_FID_TYPE_8021D_UB) and will not
      be registered with the FID core until mlxsw is flipped to use the unified
      bridge model.
      
      Add .1d, rfid and dummy FID families for unified bridge, the next patch
      will add .1q family separately as it requires more changes.
      
      The following changes are required:
      1. Add 'smpe_index_valid' field to 'struct mlxsw_sp_fid_family' and set
         SFMR.smpe accordingly. SMPE index is reserved for rFIDs, as their
         flooding is handled by firmware, and always reserved in Spectrum-1,
         as it is configured as part of PGT table.
      
      2. Add 'ubridge' field to 'struct mlxsw_sp_fid_family'. This field will
         be removed later, use it in mlxsw_sp_fid_family_{register,unregister}()
         to skip the registration / unregistration of the new families when the
         legacy model is used.
      
      3. Indexes - the start and end indexes of each FID family will need to be
         changed according to the above diagram.
      
      4. Add flood tables for unified bridge model, use 'fid_offset' as table
         type, as in the new model the access to flood tables will be using
         'fid_offset' calculation.
      
      5. FID family operation changes:
         a. rFID supposed to be created using SFMR, as it is not created by
            firmware using unified bridge model.
         b. port_vid_map() should perform SVFA for rFID, as the mapping is not
            created by firmware using unified bridge model.
         c. flood_index() is not aligned to the new model, as this function will
            be removed later.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4324e31
    • Amit Cohen's avatar
      mlxsw: Add support for VLAN RIFs · 662761d8
      Amit Cohen authored
      Router interfaces (RIFs) constructed on top of VLAN-aware bridges are of
      'VLAN' type, whereas RIFs constructed on top of VLAN-unaware bridges are of
      'FID' type.
      
      Currently 802.1Q FIDs are emulated using 802.1D FIDs, therefore VLAN RIFs
      are emulated using FID RIFs. As part of converting the driver to use
      unified bridge model, 802.1Q FIDs and VLAN RIFs will be used.
      
      The egress FID is required for VLAN RIFs in Spectrum-2 and above, but not
      in Spectrum-1, as in Spectrum-1 the mapping for VLAN RIFs is VID->FID,
      while in other ASICs it is FID->FID. The reason for the change is that it
      is more scalable to reuse the FID->FID entry than creating multiple
      {Port, VID}->FID entries for the router port. Use the existing operation
      structure to separate the configuration between different ASICs.
      
      Add support for VLAN RIFs, most of the configurations are same to FID
      RIFs.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      662761d8
    • Amit Cohen's avatar
      mlxsw: Configure egress FID classification after routing · 058de325
      Amit Cohen authored
      After routing, a packet needs to perform an L2 lookup using the DMAC it got
      from the routing and a FID. In unified bridge model, the egress FID
      configuration needs to be performed by software.
      
      It is configured by RITR for both sub-port RIFs and FID RIFs. Currently
      FID RIFs already configure eFID. Add eFID configuration for sub-port RIFs.
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      058de325