1. 10 5月, 2022 12 次提交
    • G
      tsnep: Add free running cycle counter support · 0abb62b6
      Gerhard Engleder 提交于
      The TSN endpoint Ethernet MAC supports a free running counter
      additionally to its clock. This free running counter can be read and
      hardware timestamps are supported. As the name implies, this counter
      cannot be set and its frequency cannot be adjusted.
      
      Add free running cycle counter support based on this free running
      counter to physical clock. This also requires hardware time stamps
      based on that free running counter.
      Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
      Acked-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      0abb62b6
    • G
      ptp: Speed up vclock lookup · fcf308e5
      Gerhard Engleder 提交于
      ptp_convert_timestamp() is called in the RX path of network messages.
      The current implementation takes ~5000ns on 1.2GHz A53. This is too much
      for the hot path of packet processing.
      
      Introduce hash table for fast vclock lookup in ptp_convert_timestamp().
      The execution time of ptp_convert_timestamp() is reduced to ~700ns on
      1.2GHz A53.
      Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      fcf308e5
    • G
      ptp: Support late timestamp determination · 97dc7cd9
      Gerhard Engleder 提交于
      If a physical clock supports a free running cycle counter, then
      timestamps shall be based on this time too. For TX it is known in
      advance before the transmission if a timestamp based on the free running
      cycle counter is needed. For RX it is impossible to know which timestamp
      is needed before the packet is received and assigned to a socket.
      
      Support late timestamp determination by a network device. Therefore, an
      address/cookie is stored within the new netdev_data field of struct
      skb_shared_hwtstamps. This address/cookie is provided to a new network
      device function called ndo_get_tstamp(), which returns a timestamp based
      on the normal/adjustable time or based on the free running cycle
      counter. If function is not supported, then timestamp handling is not
      changed.
      
      This mechanism is intended for RX, but TX use is also possible.
      Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
      Acked-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      97dc7cd9
    • G
      ptp: Pass hwtstamp to ptp_convert_timestamp() · d58809d8
      Gerhard Engleder 提交于
      ptp_convert_timestamp() converts only the timestamp hwtstamp, which is
      a field of the argument with the type struct skb_shared_hwtstamps *. So
      a pointer to the hwtstamp field of this structure is sufficient.
      
      Rework ptp_convert_timestamp() to use an argument of type ktime_t *.
      This allows to add additional timestamp manipulation stages before the
      call of ptp_convert_timestamp().
      Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      d58809d8
    • G
      ptp: Request cycles for TX timestamp · 51eb7492
      Gerhard Engleder 提交于
      The free running cycle counter of physical clocks called cycles shall be
      used for hardware timestamps to enable synchronisation.
      
      Introduce new flag SKBTX_HW_TSTAMP_USE_CYCLES, which signals driver to
      provide a TX timestamp based on cycles if cycles are supported.
      Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      51eb7492
    • G
      ptp: Add cycles support for virtual clocks · 42704b26
      Gerhard Engleder 提交于
      ptp vclocks require a free running time for their timecounter.
      Currently only a physical clock forced to free running is supported.
      If vclocks are used, then the physical clock cannot be synchronized
      anymore. The synchronized time is not available in hardware in this
      case. As a result, timed transmission with TAPRIO hardware support
      is not possible anymore.
      
      If hardware would support a free running time additionally to the
      physical clock, then the physical clock does not need to be forced to
      free running. Thus, the physical clocks can still be synchronized
      while vclocks are in use.
      
      The physical clock could be used to synchronize the time domain of the
      TSN network and trigger TAPRIO. In parallel vclocks can be used to
      synchronize other time domains.
      
      Introduce support for a free running cycle counter called cycles to
      physical clocks. Rework ptp vclocks to use this free running cycle
      counter. Default implementation is based on time of physical clock.
      Thus, behavior of ptp vclocks based on physical clocks without free
      running cycle counter is identical to previous behavior.
      Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      42704b26
    • J
      eth: dpaa2-mac: remove a dead-code NULL check on fwnode parent · b3552d6a
      Jakub Kicinski 提交于
      Since commit 4e30e98c ("dpaa2-mac: return -EPROBE_DEFER from dpaa2_mac_open in case the fwnode is not set")
      @parent can't be NULL after the if. It's either the address
      of the ->fwnode of @dpmacs or @fwnode in case of ACPI.
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      Link: https://lore.kernel.org/r/20220506200029.852310-1-kuba@kernel.orgSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      b3552d6a
    • J
      Merge branch 'nfp-support-corigine-pcie-vendor-id' · 9eab75d4
      Jakub Kicinski 提交于
      Simon Horman says:
      
      ====================
      nfp: support Corigine PCIE vendor ID
      
      Historically the nfp driver has supported NFP chips with Netronome's
      PCIE vendor ID. This patch extends the driver to also support NFP
      chips, which at this point are assumed to be otherwise identical from
      a software perspective, that have Corigine's PCIE vendor ID (0x1da8).
      
      This patchset begins by cleaning up strings to make them:
      * Vendor neutral for the NFP chip
      * Relate to Corigine for the driver itself
      
      It then adds support to the driver for the Corigine's PCIE vendor ID
      ====================
      
      Link: https://lore.kernel.org/r/20220508173816.476357-1-simon.horman@corigine.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      9eab75d4
    • Y
      nfp: support Corigine PCIE vendor ID · 299ba7a3
      Yu Xiao 提交于
      Historically the nfp driver has supported NFP chips with Netronome's
      PCIE vendor ID. This patch extends the driver to also support NFP
      chips, which at this point are assumed to be otherwise identical from
      a software perspective, that have Corigine's PCIE vendor ID (0x1da8).
      
      Also, Rename the macro definitions PCI_DEVICE_ID_NERTONEOME_NFPXXXX
      to PCI_DEVICE_ID_NFPXXXX, as they are now used in conjunction with two
      PCIE vendor IDs.
      Signed-off-by: NYu Xiao <yu.xiao@corigine.com>
      Signed-off-by: NYinjun Zhang <yinjun.zhang@corigine.com>
      Signed-off-by: NSimon Horman <simon.horman@corigine.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      299ba7a3
    • Y
      nfp: vendor neutral strings for chip and Corigne in strings for driver · 34e244ea
      Yu Xiao 提交于
      Historically the nfp driver has supported NFP chips with Netronome's
      PCIE vendor ID. In preparation for extending the to also support NFP
      chips that have Corigine's PCIE vendor ID (0x1da8) make printk statements
      relating to the chip vendor neutral.
      
      An alternate approach is to set the string based on the PCI vendor ID.
      In our judgement this proved to cumbersome so we have taken this simpler
      approach.
      
      Update strings relating to the driver to use Corigine, who have taken
      over maintenance of the driver.
      Signed-off-by: NYu Xiao <yu.xiao@corigine.com>
      Signed-off-by: NYinjun Zhang <yinjun.zhang@corigine.com>
      Signed-off-by: NSimon Horman <simon.horman@corigine.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      34e244ea
    • J
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · 5bcfeb6e
      Jakub Kicinski 提交于
      Tony Nguyen says:
      
      ====================
      100GbE Intel Wired LAN Driver Updates 2022-05-06
      
      Marcin Szycik says:
      
      This patchset adds support for systemd defined naming scheme for port
      representors, as well as re-enables displaying PCI bus-info in ethtool.
      
      bus-info information has previously been removed from ethtool for port
      representors, as a workaround for a bug in lshw tool, where the tool would
      sometimes display wrong descriptions for port representors/PF. Now the bug
      has been fixed in lshw tool [1].
      
      Removing the workaround can be considered a regression (user might be
      running an older, unpatched version of lshw) (see [2] for discussion).
      However, calling SET_NETDEV_DEV also produces the same effect as removing
      the workaround, i.e. lshw is able to access PCI bus-info (this time not
      via ethtool, but in some other way) and the bug can occur.
      
      Adding SET_NETDEV_DEV is important, as it greatly improves netdev naming -
      - port representors are named based on PF name. Currently port representors
      are named "ethX", which might be confusing, especially when spawning VFs on
      multiple PFs. Furthermore, it's currently harder to determine to which PF
      does a particular port representor belong, as bus-info is not shown in
      ethtool.
      
      Consider the following three cases:
      
      Case 1: current code - driver workaround in place, no SET_NETDEV_DEV,
      lshw with or without fix. Port representors are not displayed because they
      don't have bus-info (the workaround), PFs are labelled correctly:
      
      $ sudo ./lshw -c net -businfo
      Bus info          Device      Class          Description
      ========================================================
      pci@0000:02:00.0  ens6f0      network        Ethernet Controller E810-XXV for SFP <-- PF
      pci@0000:02:00.1  ens6f1      network        Ethernet Controller E810-XXV for SFP
      pci@0000:02:01.0  ens6f0v0    network        Ethernet Adaptive Virtual Function <-- VF
      pci@0000:02:01.1  ens6f0v1    network        Ethernet Adaptive Virtual Function
      ...
      
      Case 2: driver workaround in place, SET_NETDEV_DEV, no lshw fix. Port
      representors have predictable names. lshw is able to get bus-info because
      of SET_NETDEV_DEV and netdevs CAN be mislabelled:
      
      $ sudo ./lshw -c net -businfo
      Bus info          Device           Class          Description
      =============================================================
      pci@0000:02:00.0  ens6f0npf0vf60   network        Ethernet Controller E810-XXV for SFP <-- mislabeled port representor
      pci@0000:02:00.1  ens6f1           network        Ethernet Controller E810-XXV for SFP
      pci@0000:02:01.0  ens6f0v0         network        Ethernet Adaptive Virtual Function
      pci@0000:02:01.1  ens6f0v1         network        Ethernet Adaptive Virtual Function
      ...
      pci@0000:02:00.0  ens6f0npf0vf26   network        Ethernet interface
      pci@0000:02:00.0  ens6f0           network        Ethernet interface <-- mislabeled PF
      pci@0000:02:00.0  ens6f0npf0vf81   network        Ethernet interface
      ...
      $ sudo ethtool -i ens6f0npf0vf60
      driver: ice
      ...
      bus-info:
      ...
      
      Output of lshw would be the same with workaround removed; it does not
      change the fact that lshw labels netdevs incorrectly, while at the same
      time it prevents ethtool from displaying potentially useful data
      (bus-info).
      
      Case 3: workaround removed, SET_NETDEV_DEV, lshw fix:
      
      $ sudo ./lshw -c net -businfo
      Bus info          Device           Class          Description
      =============================================================
      pci@0000:02:00.0  ens6f0npf0vf73   network        Ethernet Controller E810-XXV for SFP
      pci@0000:02:00.1  ens6f1           network        Ethernet Controller E810-XXV for SFP
      pci@0000:02:01.0  ens6f0v0         network        Ethernet Adaptive Virtual Function
      pci@0000:02:01.1  ens6f0v1         network        Ethernet Adaptive Virtual Function
      ...
      pci@0000:02:00.0  ens6f0npf0vf5    network        Ethernet Controller E810-XXV for SFP
      pci@0000:02:00.0  ens6f0           network        Ethernet Controller E810-XXV for SFP
      pci@0000:02:00.0  ens6f0npf0vf60   network        Ethernet Controller E810-XXV for SFP
      ...
      $ sudo ethtool -i ens6f0npf0vf73
      driver: ice
      ...
      bus-info: 0000:02:00.0
      ...
      
      In this case poort representors have predictable names, netdevs are not
      mislabelled in lshw, and bus-info is shown in ethtool.
      
      [1] https://ezix.org/src/pkg/lshw/commit/9bf4e4c9c1
      [2] https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20220321144731.3935-1-marcin.szycik@linux.intel.com
      
      * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
        Revert "ice: Hide bus-info in ethtool for PRs in switchdev mode"
        ice: link representors to PCI device
      ====================
      
      Link: https://lore.kernel.org/r/20220506180052.5256-1-anthony.l.nguyen@intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      5bcfeb6e
    • J
      ROSE: Remove unused code and clean up some inconsistent indenting · eef0dc7e
      Jiapeng Chong 提交于
      Eliminate the follow smatch warning:
      
      net/rose/rose_route.c:1136 rose_node_show() warn: inconsistent
      indenting.
      Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
      Link: https://lore.kernel.org/r/20220507034207.18651-1-jiapeng.chong@linux.alibaba.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      eef0dc7e
  2. 09 5月, 2022 28 次提交