1. 10 May, 2022 7 commits
    • Gerhard Engleder's avatar
      ptp: Add cycles support for virtual clocks · 42704b26
      Gerhard Engleder authored
      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: default avatarGerhard Engleder <gerhard@engleder-embedded.com>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      42704b26
    • Jakub Kicinski's avatar
      eth: dpaa2-mac: remove a dead-code NULL check on fwnode parent · b3552d6a
      Jakub Kicinski authored
      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: default avatarJakub Kicinski <kuba@kernel.org>
      Link: https://lore.kernel.org/r/20220506200029.852310-1-kuba@kernel.orgSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      b3552d6a
    • Jakub Kicinski's avatar
      Merge branch 'nfp-support-corigine-pcie-vendor-id' · 9eab75d4
      Jakub Kicinski authored
      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: default avatarJakub Kicinski <kuba@kernel.org>
      9eab75d4
    • Yu Xiao's avatar
      nfp: support Corigine PCIE vendor ID · 299ba7a3
      Yu Xiao authored
      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: default avatarYu Xiao <yu.xiao@corigine.com>
      Signed-off-by: default avatarYinjun Zhang <yinjun.zhang@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      299ba7a3
    • Yu Xiao's avatar
      nfp: vendor neutral strings for chip and Corigne in strings for driver · 34e244ea
      Yu Xiao authored
      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: default avatarYu Xiao <yu.xiao@corigine.com>
      Signed-off-by: default avatarYinjun Zhang <yinjun.zhang@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      34e244ea
    • Jakub Kicinski's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · 5bcfeb6e
      Jakub Kicinski authored
      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: default avatarJakub Kicinski <kuba@kernel.org>
      5bcfeb6e
    • Jiapeng Chong's avatar
      ROSE: Remove unused code and clean up some inconsistent indenting · eef0dc7e
      Jiapeng Chong authored
      Eliminate the follow smatch warning:
      
      net/rose/rose_route.c:1136 rose_node_show() warn: inconsistent
      indenting.
      Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: default avatarJiapeng Chong <jiapeng.chong@linux.alibaba.com>
      Link: https://lore.kernel.org/r/20220507034207.18651-1-jiapeng.chong@linux.alibaba.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      eef0dc7e
  2. 09 May, 2022 33 commits