1. 26 Nov, 2023 5 commits
    • David S. Miller's avatar
      Merge branch 'dpaa2-eth-fixes' · ccf49ceb
      David S. Miller authored
      Ioana Ciornei says:
      
      ====================
      dpaa2-eth: various fixes
      
      The first patch fixes a memory corruption issue happening between the Tx
      and Tx confirmation of a packet by making the Tx alignment at 64bytes
      mandatory instead of optional as it was previously.
      
      The second patch fixes the Rx copybreak code path which recycled the
      initial data buffer before all processing was done on the packet.
      
      Changes in v2:
      - squashed patches #1 and #2
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ccf49ceb
    • Ioana Ciornei's avatar
      dpaa2-eth: recycle the RX buffer only after all processing done · beb1930f
      Ioana Ciornei authored
      The blamed commit added support for Rx copybreak. This meant that for
      certain frame sizes, a new skb was allocated and the initial data buffer
      was recycled. Instead of waiting to recycle the Rx buffer only after all
      processing was done on it (like accessing the parse results or timestamp
      information), the code path just went ahead and re-used the buffer right
      away.
      
      This sometimes lead to corrupted HW and SW annotation areas.
      Fix this by delaying the moment when the buffer is recycled.
      
      Fixes: 50f82699 ("dpaa2-eth: add rx copybreak support")
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      beb1930f
    • Ioana Ciornei's avatar
      dpaa2-eth: increase the needed headroom to account for alignment · f422abe3
      Ioana Ciornei authored
      Increase the needed headroom to account for a 64 byte alignment
      restriction which, with this patch, we make mandatory on the Tx path.
      The case in which the amount of headroom needed is not available is
      already handled by the driver which instead sends a S/G frame with the
      first buffer only holding the SW and HW annotation areas.
      
      Without this patch, we can empirically see data corruption happening
      between Tx and Tx confirmation which sometimes leads to the SW
      annotation area being overwritten.
      
      Since this is an old IP where the hardware team cannot help to
      understand the underlying behavior, we make the Tx alignment mandatory
      for all frames to avoid the crash on Tx conf. Also, remove the comment
      that suggested that this is just an optimization.
      
      This patch also sets the needed_headroom net device field to the usual
      value that the driver would need on the Tx path:
      	- 64 bytes for the software annotation area
      	- 64 bytes to account for a 64 byte aligned buffer address
      
      Fixes: 6e2387e8 ("staging: fsl-dpaa2/eth: Add Freescale DPAA2 Ethernet driver")
      Closes: https://lore.kernel.org/netdev/aa784d0c-85eb-4e5d-968b-c8f74fa86be6@gin.de/Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f422abe3
    • Greg Ungerer's avatar
      net: dsa: mv88e6xxx: fix marvell 6350 probe crash · a524eabc
      Greg Ungerer authored
      As of commit b92143d4 ("net: dsa: mv88e6xxx: add infrastructure for
      phylink_pcs") probing of a Marvell 88e6350 switch causes a NULL pointer
      de-reference like this example:
      
          ...
          mv88e6085 d0072004.mdio-mii:11: switch 0x3710 detected: Marvell 88E6350, revision 2
          8<--- cut here ---
          Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
          [00000000] *pgd=00000000
          Internal error: Oops: 5 [#1] ARM
          Modules linked in:
          CPU: 0 PID: 8 Comm: kworker/u2:0 Not tainted 6.7.0-rc2-dirty #26
          Hardware name: Marvell Armada 370/XP (Device Tree)
          Workqueue: events_unbound deferred_probe_work_func
          PC is at mv88e6xxx_port_setup+0x1c/0x44
          LR is at dsa_port_devlink_setup+0x74/0x154
          pc : [<c057ea24>]    lr : [<c0819598>]    psr: a0000013
          sp : c184fce0  ip : c542b8f4  fp : 00000000
          r10: 00000001  r9 : c542a540  r8 : c542bc00
          r7 : c542b838  r6 : c5244580  r5 : 00000005  r4 : c5244580
          r3 : 00000000  r2 : c542b840  r1 : 00000005  r0 : c1a02040
          ...
      
      The Marvell 6350 switch has no SERDES interface and so has no
      corresponding pcs_ops defined for it. But during probing a call is made
      to mv88e6xxx_port_setup() which unconditionally expects pcs_ops to exist -
      though the presence of the pcs_ops->pcs_init function is optional.
      
      Modify code to check for pcs_ops first, before checking for and calling
      pcs_ops->pcs_init. Modify checking and use of pcs_ops->pcs_teardown
      which may potentially suffer the same problem.
      
      Fixes: b92143d4 ("net: dsa: mv88e6xxx: add infrastructure for phylink_pcs")
      Signed-off-by: default avatarGreg Ungerer <gerg@kernel.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a524eabc
    • Greg Ungerer's avatar
      net: dsa: mv88e6xxx: fix marvell 6350 switch probing · b3f1a164
      Greg Ungerer authored
      As of commit de5c9bf4 ("net: phylink: require supported_interfaces to
      be filled") Marvell 88e6350 switches fail to be probed:
      
          ...
          mv88e6085 d0072004.mdio-mii:11: switch 0x3710 detected: Marvell 88E6350, revision 2
          mv88e6085 d0072004.mdio-mii:11: phylink: error: empty supported_interfaces
          error creating PHYLINK: -22
          mv88e6085: probe of d0072004.mdio-mii:11 failed with error -22
          ...
      
      The problem stems from the use of mv88e6185_phylink_get_caps() to get
      the device capabilities. Create a new dedicated phylink_get_caps for the
      6351 family (which the 6350 is one of) to properly support their set of
      capabilities.
      
      According to chip.h the 6351 switch family includes the 6171, 6175, 6350
      and 6351 switches, so update each of these to use the correct
      phylink_get_caps.
      
      Fixes: de5c9bf4 ("net: phylink: require supported_interfaces to be filled")
      Signed-off-by: default avatarGreg Ungerer <gerg@kernel.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3f1a164
  2. 24 Nov, 2023 6 commits
  3. 23 Nov, 2023 19 commits
    • Linus Torvalds's avatar
      Merge tag 'net-6.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · d3fa86b1
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Including fixes from bpf.
      
        Current release - regressions:
      
         - Revert "net: r8169: Disable multicast filter for RTL8168H and
           RTL8107E"
      
         - kselftest: rtnetlink: fix ip route command typo
      
        Current release - new code bugs:
      
         - s390/ism: make sure ism driver implies smc protocol in kconfig
      
         - two build fixes for tools/net
      
        Previous releases - regressions:
      
         - rxrpc: couple of ACK/PING/RTT handling fixes
      
        Previous releases - always broken:
      
         - bpf: verify bpf_loop() callbacks as if they are called unknown
           number of times
      
         - improve stability of auto-bonding with Hyper-V
      
         - account BPF-neigh-redirected traffic in interface statistics
      
        Misc:
      
         - net: fill in some more MODULE_DESCRIPTION()s"
      
      * tag 'net-6.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (58 commits)
        tools: ynl: fix duplicate op name in devlink
        tools: ynl: fix header path for nfsd
        net: ipa: fix one GSI register field width
        tls: fix NULL deref on tls_sw_splice_eof() with empty record
        net: axienet: Fix check for partial TX checksum
        vsock/test: fix SEQPACKET message bounds test
        i40e: Fix adding unsupported cloud filters
        ice: restore timestamp configuration after device reset
        ice: unify logic for programming PFINT_TSYN_MSK
        ice: remove ptp_tx ring parameter flag
        amd-xgbe: propagate the correct speed and duplex status
        amd-xgbe: handle the corner-case during tx completion
        amd-xgbe: handle corner-case during sfp hotplug
        net: veth: fix ethtool stats reporting
        octeontx2-pf: Fix ntuple rule creation to direct packet to VF with higher Rx queue than its PF
        net: usb: qmi_wwan: claim interface 4 for ZTE MF290
        Revert "net: r8169: Disable multicast filter for RTL8168H and RTL8107E"
        net/smc: avoid data corruption caused by decline
        nfc: virtual_ncidev: Add variable to check if ndev is running
        dpll: Fix potential msg memleak when genlmsg_put_reply failed
        ...
      d3fa86b1
    • Jakub Kicinski's avatar
      tools: ynl: fix duplicate op name in devlink · 39f04b14
      Jakub Kicinski authored
      We don't support CRUD-inspired message types in YNL too well.
      One aspect that currently trips us up is the fact that single
      message ID can be used in multiple commands (as the response).
      This leads to duplicate entries in the id-to-string tables:
      
      devlink-user.c:19:34: warning: initialized field overwritten [-Woverride-init]
         19 |         [DEVLINK_CMD_PORT_NEW] = "port-new",
            |                                  ^~~~~~~~~~
      devlink-user.c:19:34: note: (near initialization for ‘devlink_op_strmap[7]’)
      
      Fixes tag points at where the code was generated, the "real" problem
      is that the code generator does not support CRUD.
      
      Fixes: f2f9dd16 ("netlink: specs: devlink: add the remaining command to generate complete split_ops")
      Link: https://lore.kernel.org/r/20231123030558.1611831-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      39f04b14
    • Jakub Kicinski's avatar
      tools: ynl: fix header path for nfsd · 2be35a61
      Jakub Kicinski authored
      The makefile dependency is trying to include the wrong header:
      
      <command-line>: fatal error: ../../../../include/uapi//linux/nfsd.h: No such file or directory
      
      The guard also looks wrong.
      
      Fixes: f14122b2 ("tools: ynl: Add source files for nfsd netlink protocol")
      Reviewed-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Link: https://lore.kernel.org/r/20231123030624.1611925-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2be35a61
    • Alex Elder's avatar
      net: ipa: fix one GSI register field width · 37f02055
      Alex Elder authored
      The width of the R_LENGTH field of the EV_CH_E_CNTXT_1 GSI register
      is 24 bits (not 20 bits) starting with IPA v5.0.  Fix this.
      
      Fixes: faf0678e ("net: ipa: add IPA v5.0 GSI register definitions")
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Link: https://lore.kernel.org/r/20231122231708.896632-1-elder@linaro.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      37f02055
    • Jann Horn's avatar
      tls: fix NULL deref on tls_sw_splice_eof() with empty record · 53f2cb49
      Jann Horn authored
      syzkaller discovered that if tls_sw_splice_eof() is executed as part of
      sendfile() when the plaintext/ciphertext sk_msg are empty, the send path
      gets confused because the empty ciphertext buffer does not have enough
      space for the encryption overhead. This causes tls_push_record() to go on
      the `split = true` path (which is only supposed to be used when interacting
      with an attached BPF program), and then get further confused and hit the
      tls_merge_open_record() path, which then assumes that there must be at
      least one populated buffer element, leading to a NULL deref.
      
      It is possible to have empty plaintext/ciphertext buffers if we previously
      bailed from tls_sw_sendmsg_locked() via the tls_trim_both_msgs() path.
      tls_sw_push_pending_record() already handles this case correctly; let's do
      the same check in tls_sw_splice_eof().
      
      Fixes: df720d28 ("tls/sw: Use splice_eof() to flush")
      Cc: stable@vger.kernel.org
      Reported-by: syzbot+40d43509a099ea756317@syzkaller.appspotmail.com
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Link: https://lore.kernel.org/r/20231122214447.675768-1-jannh@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      53f2cb49
    • Samuel Holland's avatar
      net: axienet: Fix check for partial TX checksum · fd0413bb
      Samuel Holland authored
      Due to a typo, the code checked the RX checksum feature in the TX path.
      
      Fixes: 8a3b7a25 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
      Signed-off-by: default avatarSamuel Holland <samuel.holland@sifive.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarRadhey Shyam Pandey <radhey.shyam.pandey@amd.com>
      Link: https://lore.kernel.org/r/20231122004219.3504219-1-samuel.holland@sifive.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fd0413bb
    • Arseniy Krasnov's avatar
      vsock/test: fix SEQPACKET message bounds test · f0863888
      Arseniy Krasnov authored
      Tune message length calculation to make this test work on machines
      where 'getpagesize()' returns >32KB. Now maximum message length is not
      hardcoded (on machines above it was smaller than 'getpagesize()' return
      value, thus we get negative value and test fails), but calculated at
      runtime and always bigger than 'getpagesize()' result. Reproduced on
      aarch64 with 64KB page size.
      
      Fixes: 5c338112 ("test/vsock: rework message bounds test")
      Signed-off-by: default avatarArseniy Krasnov <avkrasnov@salutedevices.com>
      Reported-by: default avatarBogdan Marcynkov <bmarcynk@redhat.com>
      Reviewed-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Link: https://lore.kernel.org/r/20231121211642.163474-1-avkrasnov@salutedevices.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f0863888
    • Ivan Vecera's avatar
      i40e: Fix adding unsupported cloud filters · 4e20655e
      Ivan Vecera authored
      If a VF tries to add unsupported cloud filter through virtchnl
      then i40e_add_del_cloud_filter(_big_buf) returns -ENOTSUPP but
      this error code is stored in 'ret' instead of 'aq_ret' that
      is used as error code sent back to VF. In this scenario where
      one of the mentioned functions fails the value of 'aq_ret'
      is zero so the VF will incorrectly receive a 'success'.
      
      Use 'aq_ret' to store return value and remove 'ret' local
      variable. Additionally fix the issue when filter allocation
      fails, in this case no notification is sent back to the VF.
      
      Fixes: e284fc28 ("i40e: Add and delete cloud filter")
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Tested-by: default avatarRafal Romanowski <rafal.romanowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Link: https://lore.kernel.org/r/20231121211338.3348677-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4e20655e
    • Paolo Abeni's avatar
      Merge branch 'ice-restore-timestamp-config-after-reset' · e50a8061
      Paolo Abeni authored
      Tony Nguyen says:
      
      ====================
      ice: restore timestamp config after reset
      
      Jake Keller says:
      
      We recently discovered during internal validation that the ice driver has
      not been properly restoring Tx timestamp configuration after a device reset,
      which resulted in application failures after a device reset.
      
      After some digging, it turned out this problem is two-fold. Since the
      introduction of the PTP support the driver has been clobbering the storage
      of the current timestamp configuration during reset. Thus after a reset, the
      driver will no longer perform Tx or Rx timestamps, and will report
      timestamp configuration as disabled if SIOCGHWTSTAMP ioctl is issued.
      
      In addition, the recently merged auxiliary bus support code missed that
      PFINT_TSYN_MSK must be reprogrammed on the clock owner for E822 devices.
      Failure to restore this register configuration results in the driver no
      longer responding to interrupts from other ports. Depending on the traffic
      pattern, this can either result in increased latency responding to
      timestamps on the non-owner ports, or it can result in the driver never
      reporting any timestamps. The configuration of PFINT_TSYN_MSK was only done
      during initialization. Due to this, the Tx timestamp issue persists even if
      userspace reconfigures timestamping.
      
      This series fixes both issues, as well as removes a redundant Tx ring field
      since we can rely on the skb flag as the primary detector for a Tx timestamp
      request.
      
      Note that I don't think this series will directly apply to older stable
      releases (even v6.6) as we recently refactored a lot of the PTP code to
      support auxiliary bus. Patch 2/3 only matters for the post-auxiliary bus
      implementation. The principle of patch 1/3 and 3/3 could apply as far back
      as the initial PTP support, but I don't think it will apply cleanly as-is.
      ====================
      
      Link: https://lore.kernel.org/r/20231121211259.3348630-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      e50a8061
    • Jacob Keller's avatar
      ice: restore timestamp configuration after device reset · 77580179
      Jacob Keller authored
      The driver calls ice_ptp_cfg_timestamp() during ice_ptp_prepare_for_reset()
      to disable timestamping while the device is resetting. This operation
      destroys the user requested configuration. While the driver does call
      ice_ptp_cfg_timestamp in ice_rebuild() to restore some hardware settings
      after a reset, it unconditionally passes true or false, resulting in
      failure to restore previous user space configuration.
      
      This results in a device reset forcibly disabling timestamp configuration
      regardless of current user settings.
      
      This was not detected previously due to a quirk of the LinuxPTP ptp4l
      application. If ptp4l detects a missing timestamp, it enters a fault state
      and performs recovery logic which includes executing SIOCSHWTSTAMP again,
      restoring the now accidentally cleared configuration.
      
      Not every application does this, and for these applications, timestamps
      will mysteriously stop after a PF reset, without being restored until an
      application restart.
      
      Fix this by replacing ice_ptp_cfg_timestamp() with two new functions:
      
      1) ice_ptp_disable_timestamp_mode() which unconditionally disables the
         timestamping logic in ice_ptp_prepare_for_reset() and ice_ptp_release()
      
      2) ice_ptp_restore_timestamp_mode() which calls
         ice_ptp_restore_tx_interrupt() to restore Tx timestamping configuration,
         calls ice_set_rx_tstamp() to restore Rx timestamping configuration, and
         issues an immediate TSYN_TX interrupt to ensure that timestamps which
         may have occurred during the device reset get processed.
      
      Modify the ice_ptp_set_timestamp_mode to directly save the user
      configuration and then call ice_ptp_restore_timestamp_mode. This way, reset
      no longer destroys the saved user configuration.
      
      This obsoletes the ice_set_tx_tstamp() function which can now be safely
      removed.
      
      With this change, all devices should now restore Tx and Rx timestamping
      functionality correctly after a PF reset without application intervention.
      
      Fixes: 77a78115 ("ice: enable receive hardware timestamping")
      Fixes: ea9b847c ("ice: enable transmit timestamps for E810 devices")
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      77580179
    • Jacob Keller's avatar
      ice: unify logic for programming PFINT_TSYN_MSK · 7d606a1e
      Jacob Keller authored
      Commit d938a8cc ("ice: Auxbus devices & driver for E822 TS") modified
      how Tx timestamps are handled for E822 devices. On these devices, only the
      clock owner handles reading the Tx timestamp data from firmware. To do
      this, the PFINT_TSYN_MSK register is modified from the default value to one
      which enables reacting to a Tx timestamp on all PHY ports.
      
      The driver currently programs PFINT_TSYN_MSK in different places depending
      on whether the port is the clock owner or not. For the clock owner, the
      PFINT_TSYN_MSK value is programmed during ice_ptp_init_owner just before
      calling ice_ptp_tx_ena_intr to program the PHY ports.
      
      For the non-clock owner ports, the PFINT_TSYN_MSK is programmed during
      ice_ptp_init_port.
      
      If a large enough device reset occurs, the PFINT_TSYN_MSK register will be
      reset to the default value in which only the PHY associated directly with
      the PF will cause the Tx timestamp interrupt to trigger.
      
      The driver lacks logic to reprogram the PFINT_TSYN_MSK register after a
      device reset. For the E822 device, this results in the PF no longer
      responding to interrupts for other ports. This results in failure to
      deliver Tx timestamps to user space applications.
      
      Rename ice_ptp_configure_tx_tstamp to ice_ptp_cfg_tx_interrupt, and unify
      the logic for programming PFINT_TSYN_MSK and PFINT_OICR_ENA into one place.
      This function will program both registers according to the combination of
      user configuration and device requirements.
      
      This ensures that PFINT_TSYN_MSK is always restored when we configure the
      Tx timestamp interrupt.
      
      Fixes: d938a8cc ("ice: Auxbus devices & driver for E822 TS")
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      7d606a1e
    • Jacob Keller's avatar
      ice: remove ptp_tx ring parameter flag · 0ffb08b1
      Jacob Keller authored
      Before performing a Tx timestamp in ice_stamp(), the driver checks a ptp_tx
      ring variable to see if timestamping is enabled on that ring. This value is
      set for all rings whenever userspace configures Tx timestamping.
      
      Ostensibly this was done to avoid wasting cycles checking other fields when
      timestamping has not been enabled. However, for Tx timestamps we already
      get an individual per-SKB flag indicating whether userspace wants to
      request a timestamp on that packet. We do not gain much by also having
      a separate flag to check for whether timestamping was enabled.
      
      In fact, the driver currently fails to restore the field after a PF reset.
      Because of this, if a PF reset occurs, timestamps will be disabled.
      
      Since this flag doesn't add value in the hotpath, remove it and always
      provide a timestamp if the SKB flag has been set.
      
      A following change will fix the reset path to properly restore user
      timestamping configuration completely.
      
      This went unnoticed for some time because one of the most common
      applications using Tx timestamps, ptp4l, will reconfigure the socket as
      part of its fault recovery logic.
      
      Fixes: ea9b847c ("ice: enable transmit timestamps for E810 devices")
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      0ffb08b1
    • Paolo Abeni's avatar
      Merge branch 'amd-xgbe-fixes-to-handle-corner-cases' · d9775fb6
      Paolo Abeni authored
      Raju Rangoju says:
      
      ====================
      amd-xgbe: fixes to handle corner-cases
      
      This series include bug fixes to amd-xgbe driver.
      ====================
      
      Link: https://lore.kernel.org/r/20231121191435.4049995-1-Raju.Rangoju@amd.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      d9775fb6
    • Raju Rangoju's avatar
      amd-xgbe: propagate the correct speed and duplex status · 7a2323ac
      Raju Rangoju authored
      xgbe_get_link_ksettings() does not propagate correct speed and duplex
      information to ethtool during cable unplug. Due to which ethtool reports
      incorrect values for speed and duplex.
      
      Address this by propagating correct information.
      
      Fixes: 7c12aa08 ("amd-xgbe: Move the PHY support into amd-xgbe")
      Acked-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Signed-off-by: default avatarRaju Rangoju <Raju.Rangoju@amd.com>
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      7a2323ac
    • Raju Rangoju's avatar
      amd-xgbe: handle the corner-case during tx completion · 7121205d
      Raju Rangoju authored
      The existing implementation uses software logic to accumulate tx
      completions until the specified time (1ms) is met and then poll them.
      However, there exists a tiny gap which leads to a race between
      resetting and checking the tx_activate flag. Due to this the tx
      completions are not reported to upper layer and tx queue timeout
      kicks-in restarting the device.
      
      To address this, introduce a tx cleanup mechanism as part of the
      periodic maintenance process.
      
      Fixes: c5aa9e3b ("amd-xgbe: Initial AMD 10GbE platform driver")
      Acked-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Signed-off-by: default avatarRaju Rangoju <Raju.Rangoju@amd.com>
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      7121205d
    • Raju Rangoju's avatar
      amd-xgbe: handle corner-case during sfp hotplug · 676ec538
      Raju Rangoju authored
      Force the mode change for SFI in Fixed PHY configurations. Fixed PHY
      configurations needs PLL to be enabled while doing mode set. When the
      SFP module isn't connected during boot, driver assumes AN is ON and
      attempts auto-negotiation. However, if the connected SFP comes up in
      Fixed PHY configuration the link will not come up as PLL isn't enabled
      while the initial mode set command is issued. So, force the mode change
      for SFI in Fixed PHY configuration to fix link issues.
      
      Fixes: e57f7a3f ("amd-xgbe: Prepare for working with more than one type of phy")
      Acked-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Signed-off-by: default avatarRaju Rangoju <Raju.Rangoju@amd.com>
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      676ec538
    • Lorenzo Bianconi's avatar
      net: veth: fix ethtool stats reporting · 818ad9cc
      Lorenzo Bianconi authored
      Fix a possible misalignment between page_pool stats and tx xdp_stats
      reported in veth_get_ethtool_stats routine.
      The issue can be reproduced configuring the veth pair with the
      following tx/rx queues:
      
      $ip link add v0 numtxqueues 2 numrxqueues 4 type veth peer name v1 \
       numtxqueues 1 numrxqueues 1
      
      and loading a simple XDP program on v0 that just returns XDP_PASS.
      In this case on v0 the page_pool stats overwrites tx xdp_stats for queue 1.
      Fix the issue incrementing pp_idx of dev->real_num_tx_queues * VETH_TQ_STATS_LEN
      since we always report xdp_stats for all tx queues in ethtool.
      
      Fixes: 4fc41805 ("net: veth: add page_pool stats")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Link: https://lore.kernel.org/r/c5b5d0485016836448453f12846c7c4ab75b094a.1700593593.git.lorenzo@kernel.orgSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      818ad9cc
    • Suman Ghosh's avatar
      octeontx2-pf: Fix ntuple rule creation to direct packet to VF with higher Rx queue than its PF · 4aa1d8f8
      Suman Ghosh authored
      It is possible to add a ntuple rule which would like to direct packet to
      a VF whose number of queues are greater/less than its PF's queue numbers.
      For example a PF can have 2 Rx queues but a VF created on that PF can have
      8 Rx queues. As of today, ntuple rule will reject rule because it is
      checking the requested queue number against PF's number of Rx queues.
      As a part of this fix if the action of a ntuple rule is to move a packet
      to a VF's queue then the check is removed. Also, a debug information is
      printed to aware user that it is user's responsibility to cross check if
      the requested queue number on that VF is a valid one.
      
      Fixes: f0a1913f ("octeontx2-pf: Add support for ethtool ntuple filters")
      Signed-off-by: default avatarSuman Ghosh <sumang@marvell.com>
      Reviewed-by: default avatarWojciech Drewek <wojciech.drewek@intel.com>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Link: https://lore.kernel.org/r/20231121165624.3664182-1-sumang@marvell.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      4aa1d8f8
    • Lech Perczak's avatar
      net: usb: qmi_wwan: claim interface 4 for ZTE MF290 · 99360d96
      Lech Perczak authored
      Interface 4 is used by for QMI interface in stock firmware of MF28D, the
      router which uses MF290 modem. Rebind it to qmi_wwan after freeing it up
      from option driver.
      The proper configuration is:
      
      Interface mapping is:
      0: QCDM, 1: (unknown), 2: AT (PCUI), 2: AT (Modem), 4: QMI
      
      T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=19d2 ProdID=0189 Rev= 0.00
      S:  Manufacturer=ZTE, Incorporated
      S:  Product=ZTE LTE Technologies MSM
      C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      
      Cc: Bjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarLech Perczak <lech.perczak@gmail.com>
      Link: https://lore.kernel.org/r/20231117231918.100278-3-lech.perczak@gmail.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      99360d96
  4. 22 Nov, 2023 8 commits
  5. 21 Nov, 2023 2 commits
    • Jakub Kicinski's avatar
      Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · b2d66643
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2023-11-21
      
      We've added 19 non-merge commits during the last 4 day(s) which contain
      a total of 18 files changed, 1043 insertions(+), 416 deletions(-).
      
      The main changes are:
      
      1) Fix BPF verifier to validate callbacks as if they are called an unknown
         number of times in order to fix not detecting some unsafe programs,
         from Eduard Zingerman.
      
      2) Fix bpf_redirect_peer() handling which missed proper stats accounting
         for veth and netkit and also generally fix missing stats for the latter,
         from Peilin Ye, Daniel Borkmann et al.
      
      * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
        selftests/bpf: check if max number of bpf_loop iterations is tracked
        bpf: keep track of max number of bpf_loop callback iterations
        selftests/bpf: test widening for iterating callbacks
        bpf: widening for callback iterators
        selftests/bpf: tests for iterating callbacks
        bpf: verify callbacks as if they are called unknown number of times
        bpf: extract setup_func_entry() utility function
        bpf: extract __check_reg_arg() utility function
        selftests/bpf: fix bpf_loop_bench for new callback verification scheme
        selftests/bpf: track string payload offset as scalar in strobemeta
        selftests/bpf: track tcp payload offset as scalar in xdp_synproxy
        selftests/bpf: Add netkit to tc_redirect selftest
        selftests/bpf: De-veth-ize the tc_redirect test case
        bpf, netkit: Add indirect call wrapper for fetching peer dev
        bpf: Fix dev's rx stats for bpf_redirect_peer traffic
        veth: Use tstats per-CPU traffic counters
        netkit: Add tstats per-CPU traffic counters
        net: Move {l,t,d}stats allocation to core and convert veth & vrf
        net, vrf: Move dstats structure to core
      ====================
      
      Link: https://lore.kernel.org/r/20231121193113.11796-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b2d66643
    • Jakub Kicinski's avatar
      docs: netdev: try to guide people on dealing with silence · 495ec91b
      Jakub Kicinski authored
      There has been more than a few threads which went idle before
      the merge window and now people came back to them and started
      asking about next steps.
      
      We currently tell people to be patient and not to repost too
      often. Our "not too often", however, is still a few orders of
      magnitude faster than other subsystems. Or so I feel after
      hearing people talk about review rates at LPC.
      
      Clarify in the doc that if the discussion went idle for a week
      on netdev, 95% of the time there's no point waiting longer.
      
      Link: https://lore.kernel.org/r/20231120200109.620392-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      495ec91b