1. 09 3月, 2021 3 次提交
  2. 24 2月, 2021 4 次提交
  3. 22 2月, 2021 2 次提交
    • S
      Revert "ath9k: fix ath_tx_process_buffer() potential null ptr dereference" · 14ebaeef
      Shuah Khan 提交于
      This reverts commit a56c14bb.
      
      ath_tx_process_buffer() doesn't dereference or check sta and passes it
      to ath_tx_complete_aggr() and ath_tx_complete_buf().
      
      ath_tx_complete_aggr() checks the pointer before use. No problem here.
      
      ath_tx_complete_buf() doesn't check or dereference sta and passes it on
      to ath_tx_complete(). ath_tx_complete() doesn't check or dereference sta,
      but assigns it to tx_info->status.status_driver_data[0]
      
      ath_tx_complete_buf() is called from ath_tx_complete_aggr() passing
      null ieee80211_sta pointer.
      
      There is a potential for dereference later on, if and when the
      tx_info->status.status_driver_data[0]is referenced. In addition, the
      rcu read lock might be released before referencing the contents.
      
      ath_tx_complete_buf() should be fixed to check sta perhaps? Worth
      looking into.
      
      Reverting this patch because it doesn't solve the problem and introduces
      memory leak by skipping buffer completion if the pointer (sta) is NULL.
      
      Fixes: a56c14bb ("ath9k: fix ath_tx_process_buffer() potential null ptr dereference")
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20210217211801.22540-1-skhan@linuxfoundation.org
      14ebaeef
    • K
      ath11k: print hardware name and version during initialisation · 6b7abacb
      Kalle Valo 提交于
      This way it's easy for the user to find what device is actually installed. This
      also helps reporting bugs.
      
      Screenshot:
      
      [  459.988812] ath11k_pci 0000:06:00.0: BAR 0: assigned [mem 0xdb000000-0xdbffffff 64bit]
      [  459.988867] ath11k_pci 0000:06:00.0: enabling device (0000 -> 0002)
      [  459.997048] ath11k_pci 0000:06:00.0: qca6390 hw2.0
      [  460.058093] mhi mhi0: Requested to power ON
      [  460.059741] mhi mhi0: Power on setup success
      [  460.476924] ath11k_pci 0000:06:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
      [  460.477032] ath11k_pci 0000:06:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id
      
      Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/1613589400-18891-1-git-send-email-kvalo@codeaurora.org
      6b7abacb
  4. 18 2月, 2021 2 次提交
  5. 17 2月, 2021 11 次提交
  6. 16 2月, 2021 2 次提交
  7. 13 2月, 2021 16 次提交
    • R
      net: axienet: Support dynamic switching between 1000BaseX and SGMII · 6c8f06bb
      Robert Hancock 提交于
      Newer versions of the Xilinx AXI Ethernet core (specifically version 7.2 or
      later) allow the core to be configured with a PHY interface mode of "Both",
      allowing either 1000BaseX or SGMII modes to be selected at runtime. Add
      support for this in the driver to allow better support for applications
      which can use both fiber and copper SFP modules.
      Signed-off-by: NRobert Hancock <robert.hancock@calian.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c8f06bb
    • R
      net: axienet: hook up nway_reset ethtool operation · 66b51663
      Robert Hancock 提交于
      Hook up the nway_reset ethtool operation to the corresponding phylink
      function so that "ethtool -r" can be supported.
      Signed-off-by: NRobert Hancock <robert.hancock@calian.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66b51663
    • V
      net: dsa: sja1105: offload bridge port flags to device · 4d942354
      Vladimir Oltean 提交于
      The chip can configure unicast flooding, broadcast flooding and learning.
      Learning is per port, while flooding is per {ingress, egress} port pair
      and we need to configure the same value for all possible ingress ports
      towards the requested one.
      
      While multicast flooding is not officially supported, we can hack it by
      using a feature of the second generation (P/Q/R/S) devices, which is that
      FDB entries are maskable, and multicast addresses always have an odd
      first octet. So by putting a match-all for 00:01:00:00:00:00 addr and
      00:01:00:00:00:00 mask at the end of the FDB, we make sure that it is
      always checked last, and does not take precedence in front of any other
      MDB. So it behaves effectively as an unknown multicast entry.
      
      For the first generation switches, this feature is not available, so
      unknown multicast will always be treated the same as unknown unicast.
      So the only thing we can do is request the user to offload the settings
      for these 2 flags in tandem, i.e.
      
      ip link set swp2 type bridge_slave flood off
      Error: sja1105: This chip cannot configure multicast flooding independently of unicast.
      ip link set swp2 type bridge_slave flood off mcast_flood off
      ip link set swp2 type bridge_slave mcast_flood on
      Error: sja1105: This chip cannot configure multicast flooding independently of unicast.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d942354
    • V
      net: mscc: ocelot: offload bridge port flags to device · 421741ea
      Vladimir Oltean 提交于
      We should not be unconditionally enabling address learning, since doing
      that is actively detrimential when a port is standalone and not offloading
      a bridge. Namely, if a port in the switch is standalone and others are
      offloading the bridge, then we could enter a situation where we learn an
      address towards the standalone port, but the bridged ports could not
      forward the packet there, because the CPU is the only path between the
      standalone and the bridged ports. The solution of course is to not
      enable address learning unless the bridge asks for it.
      
      We need to set up the initial port flags for no learning and flooding
      everything, and also when the port joins and leaves the bridge.
      The flood configuration was already configured ok for standalone mode
      in ocelot_init, we just need to disable learning in ocelot_init_port.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      421741ea
    • V
      net: mscc: ocelot: use separate flooding PGID for broadcast · b360d94f
      Vladimir Oltean 提交于
      In preparation of offloading the bridge port flags which have
      independent settings for unknown multicast and for broadcast, we should
      also start reserving one destination Port Group ID for the flooding of
      broadcast packets, to allow configuring it individually.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b360d94f
    • V
      net: dsa: felix: restore multicast flood to CPU when NPI tagger reinitializes · 6edb9e8d
      Vladimir Oltean 提交于
      ocelot_init sets up PGID_MC to include the CPU port module, and that is
      fine, but the ocelot-8021q tagger removes the CPU port module from the
      unknown multicast replicator. So after a transition from the default
      ocelot tagger towards ocelot-8021q and then again towards ocelot,
      multicast flooding towards the CPU port module will be disabled.
      
      Fixes: e21268ef ("net: dsa: felix: perform switch setup for tag_8021q")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6edb9e8d
    • V
      net: dsa: act as passthrough for bridge port flags · a8b659e7
      Vladimir Oltean 提交于
      There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be
      expressed by the bridge through switchdev, and not all of them can be
      emulated by DSA mid-layer API at the same time.
      
      One possible configuration is when the bridge offloads the port flags
      using a mask that has a single bit set - therefore only one feature
      should change. However, DSA currently groups together unicast and
      multicast flooding in the .port_egress_floods method, which limits our
      options when we try to add support for turning off broadcast flooding:
      do we extend .port_egress_floods with a third parameter which b53 and
      mv88e6xxx will ignore? But that means that the DSA layer, which
      currently implements the PRE_BRIDGE_FLAGS attribute all by itself, will
      see that .port_egress_floods is implemented, and will report that all 3
      types of flooding are supported - not necessarily true.
      
      Another configuration is when the user specifies more than one flag at
      the same time, in the same netlink message. If we were to create one
      individual function per offloadable bridge port flag, we would limit the
      expressiveness of the switch driver of refusing certain combinations of
      flag values. For example, a switch may not have an explicit knob for
      flooding of unknown multicast, just for flooding in general. In that
      case, the only correct thing to do is to allow changes to BR_FLOOD and
      BR_MCAST_FLOOD in tandem, and never allow mismatched values. But having
      a separate .port_set_unicast_flood and .port_set_multicast_flood would
      not allow the driver to possibly reject that.
      
      Also, DSA doesn't consider it necessary to inform the driver that a
      SWITCHDEV_ATTR_ID_BRIDGE_MROUTER attribute was offloaded, because it
      just calls .port_egress_floods for the CPU port. When we'll add support
      for the plain SWITCHDEV_ATTR_ID_PORT_MROUTER, that will become a real
      problem because the flood settings will need to be held statefully in
      the DSA middle layer, otherwise changing the mrouter port attribute will
      impact the flooding attribute. And that's _assuming_ that the underlying
      hardware doesn't have anything else to do when a multicast router
      attaches to a port than flood unknown traffic to it.  If it does, there
      will need to be a dedicated .port_set_mrouter anyway.
      
      So we need to let the DSA drivers see the exact form that the bridge
      passes this switchdev attribute in, otherwise we are standing in the
      way. Therefore we also need to use this form of language when
      communicating to the driver that it needs to configure its initial
      (before bridge join) and final (after bridge leave) port flags.
      
      The b53 and mv88e6xxx drivers are converted to the passthrough API and
      their implementation of .port_egress_floods is split into two: a
      function that configures unicast flooding and another for multicast.
      The mv88e6xxx implementation is quite hairy, and it turns out that
      the implementations of unknown unicast flooding are actually the same
      for 6185 and for 6352:
      
      behind the confusing names actually lie two individual bits:
      NO_UNKNOWN_MC -> FLOOD_UC = 0x4 = BIT(2)
      NO_UNKNOWN_UC -> FLOOD_MC = 0x8 = BIT(3)
      
      so there was no reason to entangle them in the first place.
      
      Whereas the 6185 writes to MV88E6185_PORT_CTL0_FORWARD_UNKNOWN of
      PORT_CTL0, which has the exact same bit index. I have left the
      implementations separate though, for the only reason that the names are
      different enough to confuse me, since I am not able to double-check with
      a user manual. The multicast flooding setting for 6185 is in a different
      register than for 6352 though.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8b659e7
    • V
      net: switchdev: pass flags and mask to both {PRE_,}BRIDGE_FLAGS attributes · e18f4c18
      Vladimir Oltean 提交于
      This switchdev attribute offers a counterproductive API for a driver
      writer, because although br_switchdev_set_port_flag gets passed a
      "flags" and a "mask", those are passed piecemeal to the driver, so while
      the PRE_BRIDGE_FLAGS listener knows what changed because it has the
      "mask", the BRIDGE_FLAGS listener doesn't, because it only has the final
      value. But certain drivers can offload only certain combinations of
      settings, like for example they cannot change unicast flooding
      independently of multicast flooding - they must be both on or both off.
      The way the information is passed to switchdev makes drivers not
      expressive enough, and unable to reject this request ahead of time, in
      the PRE_BRIDGE_FLAGS notifier, so they are forced to reject it during
      the deferred BRIDGE_FLAGS attribute, where the rejection is currently
      ignored.
      
      This patch also changes drivers to make use of the "mask" field for edge
      detection when possible.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e18f4c18
    • V
      net: switchdev: propagate extack to port attributes · 4c08c586
      Vladimir Oltean 提交于
      When a struct switchdev_attr is notified through switchdev, there is no
      way to report informational messages, unlike for struct switchdev_obj.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c08c586
    • D
      octeontx2: Fix condition. · b0aae0bd
      David S. Miller 提交于
      Fixes: 93efb0c6 ("octeontx2-pf: Fix out-of-bounds read in otx2_get_fecparam()")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0aae0bd
    • A
      net: ipa: introduce gsi_channel_initialized() · 6170b6da
      Alex Elder 提交于
      Create a simple helper function that indicates whether a channel has
      been initialized.  This abstacts/hides the details of how this is
      determined.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6170b6da
    • A
      net: ipa: introduce ipa_table_hash_support() · a266ad6b
      Alex Elder 提交于
      Introduce a new function to abstract the knowledge of whether hashed
      routing and filter tables are supported for a given IPA instance.
      
      IPA v4.2 is the only one that doesn't support hashed tables (now
      and for the foreseeable future), but the name of the helper function
      is better for explaining what's going on.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a266ad6b
    • A
      net: ipa: fix register write command validation · 2d65ed76
      Alex Elder 提交于
      In ipa_cmd_register_write_valid() we verify that values we will
      supply to a REGISTER_WRITE IPA immediate command will fit in
      the fields that need to hold them.  This patch fixes some issues
      in that function and ipa_cmd_register_write_offset_valid().
      
      The dev_err() call in ipa_cmd_register_write_offset_valid() has
      some printf format errors:
        - The name of the register (corresponding to the string format
          specifier) was not supplied.
        - The IPA base offset and offset need to be supplied separately to
          match the other format specifiers.
      Also make the ~0 constant used there to compute the maximum
      supported offset value explicitly unsigned.
      
      There are two other issues in ipa_cmd_register_write_valid():
        - There's no need to check the hash flush register for platforms
          (like IPA v4.2) that do not support hashed tables
        - The highest possible endpoint number, whose status register
          offset is computed, is COUNT - 1, not COUNT.
      
      Fix these problems, and add some additional commentary.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d65ed76
    • A
      net: ipa: use dev_err_probe() in ipa_clock.c · 4c7ccfcd
      Alex Elder 提交于
      When initializing the IPA core clock and interconnects, it's
      possible we'll get an EPROBE_DEFER error.  This isn't really an
      error, it's just means we need to be re-probed later.
      
      Use dev_err_probe() to report the error rather than dev_err().
      This avoids polluting the log with these "error" messages.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c7ccfcd
    • A
      net: ipa: use a separate pointer for adjusted GSI memory · 571b1e7e
      Alex Elder 提交于
      This patch actually fixes a bug, though it doesn't affect the two
      platforms supported currently.  The fix implements GSI memory
      pointers a bit differently.
      
      For IPA version 4.5 and above, the address space for almost all GSI
      registers is adjusted downward by a fixed amount.  This is currently
      handled by adjusting the I/O virtual address pointer after it has
      been mapped.  The bug is that the pointer is not "de-adjusted" as it
      should be when it's unmapped.
      
      This patch fixes that error, but it does so by maintaining one "raw"
      pointer for the mapped memory range.  This is assigned when the
      memory is mapped and used to unmap the memory.  This pointer is also
      used to access the two registers that do *not* sit in the "adjusted"
      memory space.
      
      Rather than adjusting *that* pointer, we maintain a separate pointer
      that's an adjusted copy of the "raw" pointer, and that is used for
      most GSI register accesses.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      571b1e7e
    • G
      octeontx2-pf: Fix out-of-bounds read in otx2_get_fecparam() · 93efb0c6
      Gustavo A. R. Silva 提交于
      Code at line 967 implies that rsp->fwdata.supported_fec may be up to 4:
      
       967: if (rsp->fwdata.supported_fec <= FEC_MAX_INDEX)
      
      If rsp->fwdata.supported_fec evaluates to 4, then there is an
      out-of-bounds read at line 971 because fec is an array with
      a maximum of 4 elements:
      
       954         const int fec[] = {
       955                 ETHTOOL_FEC_OFF,
       956                 ETHTOOL_FEC_BASER,
       957                 ETHTOOL_FEC_RS,
       958                 ETHTOOL_FEC_BASER | ETHTOOL_FEC_RS};
       959 #define FEC_MAX_INDEX 4
      
       971: fecparam->fec = fec[rsp->fwdata.supported_fec];
      
      Fix this by properly indexing fec[] with rsp->fwdata.supported_fec - 1.
      In this case the proper indexes 0 to 3 are used when
      rsp->fwdata.supported_fec evaluates to a range of 1 to 4, correspondingly.
      
      Fixes: d0cf9503 ("octeontx2-pf: ethtool fec mode support")
      Addresses-Coverity-ID: 1501722 ("Out-of-bounds read")
      Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93efb0c6