1. 19 Aug, 2022 2 commits
  2. 18 Aug, 2022 6 commits
    • Jakub Kicinski's avatar
      Merge branch 'add-dt-property-to-disable-hibernation-mode' · aa447a87
      Jakub Kicinski authored
      Wei Fang says:
      
      ====================
      Add DT property to disable hibernation mode
      
      The patches add the ability to disable the hibernation mode of AR803x
      PHYs. Hibernation mode defaults to enabled after hardware reset on
      these PHYs. If the AR803x PHYs enter hibernation mode, they will not
      provide any clock. For some MACs, they might need the clocks which
      provided by the PHYs to support their own hardware logic.
      So, the patches add the support to disable hibernation mode by adding
      a boolean:
      
              qca,disable-hibernation-mode
      
      If one wished to disable hibernation mode to better match with the
      specifical MAC, just add this property in the phy node of DT.
      ====================
      
      Link: https://lore.kernel.org/r/20220818030054.1010660-1-wei.fang@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      aa447a87
    • Wei Fang's avatar
      net: phy: at803x: add disable hibernation mode support · 9ecf0401
      Wei Fang authored
      When the cable is unplugged, the Atheros AR803x PHYs will enter
      hibernation mode after about 10 seconds if the hibernation mode
      is enabled and will not provide any clock to the MAC. But for
      some MACs, this feature might cause unexpected issues due to the
      logic of MACs.
      Taking SYNP MAC (stmmac) as an example, if the cable is unplugged
      and the "eth0" interface is down, the AR803x PHY will enter
      hibernation mode. Then perform the "ifconfig eth0 up" operation,
      the stmmac can't be able to complete the software reset operation
      and fail to init it's own DMA. Therefore, the "eth0" interface is
      failed to ifconfig up. Why does it cause this issue? The truth is
      that the software reset operation of the stmmac is designed to
      depend on the RX_CLK of PHY.
      So, this patch offers an option for the user to determine whether
      to disable the hibernation mode of AR803x PHYs.
      Signed-off-by: default avatarWei Fang <wei.fang@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9ecf0401
    • Wei Fang's avatar
      dt-bindings: net: ar803x: add disable-hibernation-mode propetry · 2e7f0899
      Wei Fang authored
      The hibernation mode of Atheros AR803x PHYs defaults to be
      enabled after hardware reset. When the cable is unplugged,
      the PHY will enter hibernation mode after about 10 seconds
      and the PHY clocks will be stopped to save power.
      However, some MACs need the phy output clock for proper
      functioning of their logic. For instance, stmmac needs the
      RX_CLK of PHY for software reset to complete.
      Therefore, add a DT property to configure the PHY to disable
      this hardware hibernation mode.
      Signed-off-by: default avatarWei Fang <wei.fang@nxp.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2e7f0899
    • Maxime Chevallier's avatar
      net: ethernet: altera: Add use of ethtool_op_get_ts_info · fb8d784b
      Maxime Chevallier authored
      Add the ethtool_op_get_ts_info() callback to ethtool ops, so that we can
      at least use software timestamping.
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Link: https://lore.kernel.org/r/20220817095725.97444-1-maxime.chevallier@bootlin.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fb8d784b
    • Wong Vee Khee's avatar
      stmmac: intel: remove unused 'has_crossts' flag · e34cfee6
      Wong Vee Khee authored
      The 'has_crossts' flag was not used anywhere in the stmmac driver,
      removing it from both header file and dwmac-intel driver.
      Signed-off-by: default avatarWong Vee Khee <veekhee@apple.com>
      Reviewed-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Link: https://lore.kernel.org/r/20220817064324.10025-1-veekhee@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e34cfee6
    • Jakub Kicinski's avatar
      Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · 3f5f728a
      Jakub Kicinski authored
      Andrii Nakryiko says:
      
      ====================
      bpf-next 2022-08-17
      
      We've added 45 non-merge commits during the last 14 day(s) which contain
      a total of 61 files changed, 986 insertions(+), 372 deletions(-).
      
      The main changes are:
      
      1) New bpf_ktime_get_tai_ns() BPF helper to access CLOCK_TAI, from Kurt
         Kanzenbach and Jesper Dangaard Brouer.
      
      2) Few clean ups and improvements for libbpf 1.0, from Andrii Nakryiko.
      
      3) Expose crash_kexec() as kfunc for BPF programs, from Artem Savkov.
      
      4) Add ability to define sleepable-only kfuncs, from Benjamin Tissoires.
      
      5) Teach libbpf's bpf_prog_load() and bpf_map_create() to gracefully handle
         unsupported names on old kernels, from Hangbin Liu.
      
      6) Allow opting out from auto-attaching BPF programs by libbpf's BPF skeleton,
         from Hao Luo.
      
      7) Relax libbpf's requirement for shared libs to be marked executable, from
         Henqgi Chen.
      
      8) Improve bpf_iter internals handling of error returns, from Hao Luo.
      
      9) Few accommodations in libbpf to support GCC-BPF quirks, from James Hilliard.
      
      10) Fix BPF verifier logic around tracking dynptr ref_obj_id, from Joanne Koong.
      
      11) bpftool improvements to handle full BPF program names better, from Manu
          Bretelle.
      
      12) bpftool fixes around libcap use, from Quentin Monnet.
      
      13) BPF map internals clean ups and improvements around memory allocations,
          from Yafang Shao.
      
      14) Allow to use cgroup_get_from_file() on cgroupv1, allowing BPF cgroup
          iterator to work on cgroupv1, from Yosry Ahmed.
      
      15) BPF verifier internal clean ups, from Dave Marchevsky and Joanne Koong.
      
      16) Various fixes and clean ups for selftests/bpf and vmtest.sh, from Daniel
          Xu, Artem Savkov, Joanne Koong, Andrii Nakryiko, Shibin Koikkara Reeny.
      
      * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (45 commits)
        selftests/bpf: Few fixes for selftests/bpf built in release mode
        libbpf: Clean up deprecated and legacy aliases
        libbpf: Streamline bpf_attr and perf_event_attr initialization
        libbpf: Fix potential NULL dereference when parsing ELF
        selftests/bpf: Tests libbpf autoattach APIs
        libbpf: Allows disabling auto attach
        selftests/bpf: Fix attach point for non-x86 arches in test_progs/lsm
        libbpf: Making bpf_prog_load() ignore name if kernel doesn't support
        selftests/bpf: Update CI kconfig
        selftests/bpf: Add connmark read test
        selftests/bpf: Add existing connection bpf_*_ct_lookup() test
        bpftool: Clear errno after libcap's checks
        bpf: Clear up confusion in bpf_skb_adjust_room()'s documentation
        bpftool: Fix a typo in a comment
        libbpf: Add names for auxiliary maps
        bpf: Use bpf_map_area_alloc consistently on bpf map creation
        bpf: Make __GFP_NOWARN consistent in bpf map creation
        bpf: Use bpf_map_area_free instread of kvfree
        bpf: Remove unneeded memset in queue_stack_map creation
        libbpf: preserve errno across pr_warn/pr_info/pr_debug
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20220817215656.1180215-1-andrii@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3f5f728a
  3. 17 Aug, 2022 23 commits
  4. 16 Aug, 2022 7 commits
    • Artem Savkov's avatar
      selftests/bpf: Fix attach point for non-x86 arches in test_progs/lsm · 807662ca
      Artem Savkov authored
      Use SYS_PREFIX macro from bpf_misc.h instead of hard-coded '__x64_'
      prefix for sys_setdomainname attach point in lsm test.
      Signed-off-by: default avatarArtem Savkov <asavkov@redhat.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220816055231.717006-1-asavkov@redhat.com
      807662ca
    • Jacob Keller's avatar
      ice: introduce ice_ptp_reset_cached_phctime function · b1a582e6
      Jacob Keller authored
      If the PTP hardware clock is adjusted, the ice driver must update the
      cached PHC timestamp. This is required in order to perform timestamp
      extension on the shorter timestamps captured by the PHY.
      
      Currently, we simply call ice_ptp_update_cached_phctime in the settime and
      adjtime callbacks. This has a few issues:
      
      1) if ICE_CFG_BUSY is set because another thread is updating the Rx rings,
         we will exit with an error. This is not checked, and the functions do
         not re-schedule the update. This could leave the cached timestamp
         incorrect until the next scheduled work item execution.
      
      2) even if we did handle an update, any currently outstanding Tx timestamp
         would be extended using the wrong cached PHC time. This would produce
         incorrect results.
      
      To fix these issues, introduce a new ice_ptp_reset_cached_phctime function.
      This function calls the ice_ptp_update_cached_phctime, and discards
      outstanding Tx timestamps.
      
      If the ice_ptp_update_cached_phctime function fails because ICE_CFG_BUSY is
      set, we log a warning and schedule the thread to execute soon. The update
      function is modified so that it always updates the cached copy in the PF
      regardless. This ensures we have the most up to date values possible and
      minimizes the risk of a packet timestamp being extended with the wrong
      value.
      
      It would be nice if we could skip reporting Rx timestamps until the cached
      values are up to date. However, we can't access the Rx rings while
      ICE_CFG_BUSY is set because they are actively being updated by another
      thread.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b1a582e6
    • Jacob Keller's avatar
      ice: re-arrange some static functions in ice_ptp.c · 4b1251bd
      Jacob Keller authored
      A following change is going to want to make use of ice_ptp_flush_tx_tracker
      earlier in the ice_ptp.c file. To make this work, move the Tx timestamp
      tracking functions higher up in the file, and pull the
      ice_ptp_update_cached_timestamp function below them. This should have no
      functional change.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      4b1251bd
    • Jacob Keller's avatar
      ice: track and warn when PHC update is late · cd25507a
      Jacob Keller authored
      The ice driver requires a cached copy of the PHC time in order to perform
      timestamp extension on Tx and Rx hardware timestamp values. This cached PHC
      time must always be updated at least once every 2 seconds. Otherwise, the
      math used to perform the extension would produce invalid results.
      
      The updates are supposed to occur periodically in the PTP kthread work
      item, which is scheduled to run every half second. Thus, we do not expect
      an update to be delayed for so long. However, there are error conditions
      which can cause the update to be delayed.
      
      Track this situation by using jiffies to determine approximately how long
      ago the last update occurred. Add a new statistic and a dev_warn when we
      have failed to update the cached PHC time. This makes the error case more
      obvious.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      cd25507a
    • Jacob Keller's avatar
      ice: track Tx timestamp stats similar to other Intel drivers · f020481b
      Jacob Keller authored
      Several Intel networking drivers which support PTP track when Tx timestamps
      are skipped or when they timeout without a timestamp from hardware. The
      conditions which could cause these events are rare, but it can be useful to
      know when and how often they occur.
      
      Implement similar statistics for the ice driver, tx_hwtstamp_skipped,
      tx_hwtstamp_timeouts, and tx_hwtstamp_flushed.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      f020481b
    • Jacob Keller's avatar
      ice: initialize cached_phctime when creating Rx rings · cf6b82fd
      Jacob Keller authored
      When we create new Rx rings, the cached_phctime field is zero initialized.
      This could result in incorrect timestamp reporting due to the cached value
      not yet being updated. Although a background task will periodically update
      the cached value, ensure it matches the existing cached value in the PF
      structure at ring initialization.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      cf6b82fd
    • Jacob Keller's avatar
      ice: set tx_tstamps when creating new Tx rings via ethtool · b3b17374
      Jacob Keller authored
      When the user changes the number of queues via ethtool, the driver
      allocates new rings. This allocation did not initialize tx_tstamps. This
      results in the tx_tstamps field being zero (due to kcalloc allocation), and
      would result in a NULL pointer dereference when attempting a transmit
      timestamp on the new ring.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b3b17374
  5. 15 Aug, 2022 2 commits