1. 06 Jan, 2020 13 commits
    • Vinicius Costa Gomes's avatar
      igc: Add support for TX timestamping · 2c344ae2
      Vinicius Costa Gomes authored
      This adds support for timestamping packets being transmitted.
      
      Based on the code from i210. The basic differences is that i225 has 4
      registers to store the transmit timestamps (i210 has one). Right now,
      we only support retrieving from one register, support for using the
      other registers will be added later.
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2c344ae2
    • Vinicius Costa Gomes's avatar
      igc: Add support for RX timestamping · 81b05520
      Vinicius Costa Gomes authored
      This adds support for timestamping received packets.
      
      It is based on the i210, as many features of i225 work the same way.
      The main difference from i210 is that i225 has support for choosing
      the timer register to use when timestamping packets. Right now, we
      only support using timer 0. The other difference is that i225 stores
      two timestamps in the receive descriptor, right now, we only retrieve
      one.
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      81b05520
    • Vinicius Costa Gomes's avatar
      igc: Add basic skeleton for PTP · 5f295805
      Vinicius Costa Gomes authored
      This allows the creation of the /dev/ptpX device for i225, and reading
      and writing the time.
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5f295805
    • David S. Miller's avatar
      Merge branch 'Convert-Felix-DSA-switch-to-PHYLINK' · df2c2ba8
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Convert Felix DSA switch to PHYLINK
      
      Unlike most other conversions, this one is not by far a trivial one, and should
      be seen as "Layerscape PCS meets PHYLINK". Actually, the PCS doesn't
      need a lot of hand-holding and most of our other devices 'just work'
      (this one included) without any sort of operating system awareness, just
      an initialization procedure done typically in the bootloader.
      Our issues start when the PCS stops from "just working", and that is
      where PHYLINK comes in handy.
      
      The PCS is not specific to the Vitesse / Microsemi / Microchip switching core
      at all. Variations of this SerDes/PCS design can also be found on DPAA1 and
      DPAA2 hardware.
      
      The main idea of the abstraction provided is that the PCS looks so much like a
      PHY device, that we model it as an actual PHY device and run the generic PHY
      functions on it, where appropriate.
      
      The 4xSGMII, QSGMII and QSXGMII modes are fairly straightforward.
      
      The SerDes protocol which the driver calls 2500Base-X mode (a misnomer) is more
      interesting. There is a description of how it works and what can be done with
      it in patch 9/9 (in a comment above vsc9959_pcs_init_2500basex).
      In short, it is a fixed speed protocol with no auto-negotiation whatsoever.
      From my research of the SGMII-2500 patent [1], it has nothing to do with
      SGMII-2500. That one:
      * does not define any change to the AN base page compared to plain 10/100/1000
        SGMII. This implies that the 2500 speed is not negotiable, but the other
        speeds are. In our case, when the SerDes is configured for this protocol it's
        configured for good, there's no going back to SGMII.
      * runs at a higher base frequency than regular SGMII. So SGMII-2500 operating
        at 1000 Mbps wouldn't interoperate with plain SGMII at 1000 Mbps. Strange,
        but ok..
      * Emulates lower link speeds than 2500 by duplicating the codewords twice, then
        thrice, then twice again etc (2.5/25/250 times on average). The Layerscape
        PCS doesn't do that (it is fixed at 2500 Mbaud).
      
      But on the other hand it isn't completely compatible with Base-X either,
      since it doesn't do 802.3z / clause 37 auto negotiation (flow control,
      local/remote fault etc). It is compatible with 2500Base-X without
      in-band AN, and that is exactly how we decided to expose it (this is
      actually similar to what others do).
      
      For SGMII and USXGMII, the driver is using the PHYLINK 'managed =
      "in-band-status"' DTS binding to figure out whether in-band AN is
      expected to be enabled in the PCS or not. It is expected that the
      attached PHY follows suite, but there is a gap here: the PHY driver does
      not react to this setting, so only one of "AN on" and "AN off" works on
      any particular PHY, even though that PHY might support bypassing the
      SGMII AN process, as is the case on the VSC8514 PHY present on the
      LS1028A-RDB board. A separate series will be sent to propose a way to
      deal with that.
      
      I dropped the Ocelot PHYLINK conversion because:
      * I don't have VSC7514 hardware anyway
      * The hardware is so different in this regard that there's almost nothing to
        share anyway.
      
      Changes in v5:
      
      - Added the register write to DEV_CLOCK_CFG back in
        felix_phylink_mac_config in patch 9/9.
      
      Changes in v4:
      
      - This is mostly a resend of v3, with the only notable change that I've
        dropped the PHY core patches for in_band_autoneg and I'll propose them
        independently.
      
      v1 series:
      https://www.spinics.net/lists/netdev/msg613869.html
      
      RFC v2 series:
      https://www.spinics.net/lists/netdev/msg620128.html
      
      v3 series:
      https://www.spinics.net/lists/netdev/msg622060.html
      
      v4 series:
      https://www.spinics.net/lists/netdev/msg622606.html
      
      [0]: https://www.spinics.net/lists/netdev/msg613869.html
      [1]: https://patents.google.com/patent/US7356047B1/en
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df2c2ba8
    • Vladimir Oltean's avatar
      net: dsa: felix: Add PCS operations for PHYLINK · bdeced75
      Vladimir Oltean authored
      Layerscape SoCs traditionally expose the SerDes configuration/status for
      Ethernet protocols (PCS for SGMII/USXGMII/10GBase-R etc etc) in a register
      format that is compatible with clause 22 or clause 45 (depending on
      SerDes protocol). Each MAC has its own internal MDIO bus on which there
      is one or more of these PCS's, responding to commands at a configurable
      PHY address. The per-port internal MDIO bus (which is just for PCSs) is
      totally separate and has nothing to do with the dedicated external MDIO
      controller (which is just for PHYs), but the register map for the MDIO
      controller is the same.
      
      The VSC9959 (Felix) switch instantiated in the LS1028A is integrated
      in hardware with the ENETC PCS of its DSA master, and reuses its MDIO
      controller driver, so Felix has been made to depend on it in Kconfig.
      
       +------------------------------------------------------------------------+
       |                   +--------+ GMII (typically disabled via RCW)         |
       | ENETC PCI         |  ENETC |--------------------------+                |
       | Root Complex      | port 3 |-----------------------+  |                |
       | Integrated        +--------+                       |  |                |
       | Endpoint                                           |  |                |
       |                   +--------+ 2.5G GMII             |  |                |
       |                   |  ENETC |--------------+        |  |                |
       |                   | port 2 |-----------+  |        |  |                |
       |                   +--------+           |  |        |  |                |
       |                                     +--------+  +--------+             |
       |                                     |  Felix |  |  Felix |             |
       |                                     | port 4 |  | port 5 |             |
       |                                     +--------+  +--------+             |
       |                                                                        |
       | +--------+  +--------+  +--------+  +--------+  +--------+  +--------+ |
       | |  ENETC |  |  ENETC |  |  Felix |  |  Felix |  |  Felix |  |  Felix | |
       | | port 0 |  | port 1 |  | port 0 |  | port 1 |  | port 2 |  | port 3 | |
       +------------------------------------------------------------------------+
       |    ||||  SerDes |          ||||        ||||        ||||        ||||    |
       | +--------+block |       +--------------------------------------------+ |
       | |  ENETC |      |       |       ENETC port 2 internal MDIO bus       | |
       | | port 0 |      |       |  PCS         PCS          PCS        PCS   | |
       | |   PCS  |      |       |   0           1            2          3    | |
       +-----------------|------------------------------------------------------+
              v          v           v           v            v          v
           SGMII/      RGMII    QSGMII/QSXGMII/4xSGMII/4x1000Base-X/4x2500Base-X
          USXGMII/   (bypasses
        1000Base-X/   SerDes)
        2500Base-X
      
      In the LS1028A SoC described above, the VSC9959 Felix switch is PF5 of
      the ENETC root complex, and has 2 BARs:
      - BAR 4: the switch's effective registers
      - BAR 0: the MDIO controller register map lended from ENETC port 2
               (PF2), for accessing its associated PCS's.
      
      This explanation is necessary because the patch does some renaming
      "pci_bar" -> "switch_pci_bar" for clarity, which would otherwise appear
      a bit obtuse.
      
      The fact that the internal MDIO bus is "borrowed" is relevant because
      the register map is found in PF5 (the switch) but it triggers an access
      fault if PF2 (the ENETC DSA master) is not enabled. This is not treated
      in any way (and I don't think it can be treated).
      
      All of this is so SoC-specific, that it was contained as much as
      possible in the platform-integration file felix_vsc9959.c.
      
      We need to parse and pre-validate the device tree because of 2 reasons:
      - The PHY mode (SerDes protocol) cannot change at runtime due to SoC
        design.
      - There is a circular dependency in that we need to know what clause the
        PCS speaks in order to find it on the internal MDIO bus. But the
        clause of the PCS depends on what phy-mode it is configured for.
      
      The goal of this patch is to make steps towards removing the bootloader
      dependency for SGMII PCS pre-configuration, as well as to add support
      for monitoring the in-band SGMII AN between the PCS and the system-side
      link partner (PHY or other MAC).
      
      In practice the bootloader dependency is not completely removed. U-Boot
      pre-programs the PHY address at which each PCS can be found on the
      internal MDIO bus (MDEV_PORT). This is needed because the PCS of each
      port has the same out-of-reset PHY address of zero. The SerDes register
      for changing MDEV_PORT is pretty deep in the SoC (outside the addresses
      of the ENETC PCI BARs) and therefore inaccessible to us from here.
      
      Felix VSC9959 and Ocelot VSC7514 are integrated very differently in
      their respective SoCs, and for that reason Felix does not use the Ocelot
      core library for PHYLINK. On one hand we don't want to impose the
      fixed phy-mode limitation to Ocelot, and on the other hand Felix doesn't
      need to force the MAC link speed the way Ocelot does, since the MAC is
      connected to the PCS through a fixed GMII, and the PCS is the one who
      does the rate adaptation at lower link speeds, which the MAC does not
      even need to know about. In fact changing the GMII speed for Felix
      irrecoverably breaks transmission through that port until a reset.
      
      The pair with ENETC port 3 and Felix port 5 is optional and doesn't
      support tagging. When we enable it, swp5 is a regular slave port, albeit
      an internal one. The trouble is that it doesn't work, and that is
      because the DSA PHYLIB adaptation layer doesn't treat fixed-link slave
      ports. So that is yet another reason for wanting to convert Felix to the
      native PHYLINK API.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bdeced75
    • Vladimir Oltean's avatar
      net: mscc: ocelot: export ANA, DEV and QSYS registers to include/soc/mscc · 964ee5c8
      Vladimir Oltean authored
      Since the Felix DSA driver is implementing its own PHYLINK instance due
      to SoC differences, it needs access to the few registers that are
      common, mainly for flow control.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      964ee5c8
    • Vladimir Oltean's avatar
      net: mscc: ocelot: make phy_mode a member of the common struct ocelot_port · ee50d07c
      Vladimir Oltean authored
      The Ocelot switchdev driver and the Felix DSA one need it for different
      reasons. Felix (or at least the VSC9959 instantiation in NXP LS1028A) is
      integrated with the traditional NXP Layerscape PCS design which does not
      support runtime configuration of SerDes protocol. So it needs to
      pre-validate the phy-mode from the device tree and prevent PHYLINK from
      attempting to change it. For this, it needs to cache it in a private
      variable.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee50d07c
    • Vladimir Oltean's avatar
      enetc: Set MDIO_CFG_HOLD to the recommended value of 2 · d79d3032
      Vladimir Oltean authored
      This increases the MDIO hold time to 5 enet_clk cycles from the previous
      value of 0. This is actually the out-of-reset value, that the driver was
      previously overwriting with 0. Zero worked for the external MDIO, but
      breaks communication with the internal MDIO buses on which the PCS of
      ENETC SI's and Felix switch are found.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d79d3032
    • Claudiu Manoil's avatar
      enetc: Make MDIO accessors more generic and export to include/linux/fsl · 6517798d
      Claudiu Manoil authored
      Within the LS1028A SoC, the register map for the ENETC MDIO controller
      is instantiated a few times: for the central (external) MDIO controller,
      for the internal bus of each standalone ENETC port, and for the internal
      bus of the Felix switch.
      
      Refactoring is needed to support multiple MDIO buses from multiple
      drivers. The enetc_hw structure is made an opaque type and a smaller
      enetc_mdio_priv is created.
      
      'mdio_base' - MDIO registers base address - is being parameterized, to
      be able to work with different MDIO register bases.
      
      The ENETC MDIO bus operations are exported from the fsl-enetc-mdio
      kernel object, the same that registers the central MDIO controller (the
      dedicated PF). The ENETC main driver has been changed to select it, and
      use its exported helpers to further register its private MDIO bus. The
      DSA Felix driver will do the same.
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6517798d
    • Vladimir Oltean's avatar
      net: dsa: Pass pcs_poll flag from driver to PHYLINK · 787cac3f
      Vladimir Oltean authored
      The DSA drivers that implement .phylink_mac_link_state should normally
      register an interrupt for the PCS, from which they should call
      phylink_mac_change(). However not all switches implement this, and those
      who don't should set this flag in dsa_switch in the .setup callback, so
      that PHYLINK will poll for a few ms until the in-band AN link timer
      expires and the PCS state settles.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      787cac3f
    • Vladimir Oltean's avatar
      net: phylink: add support for polling MAC PCS · 1511ed0a
      Vladimir Oltean authored
      Some MAC PCS blocks are unable to provide interrupts when their status
      changes. As we already have support in phylink for polling status, use
      this to provide a hook for MACs to enable polling mode.
      
      The patch idea was picked up from Russell King's suggestion on the macb
      phylink patch thread here [0] but the implementation was changed.
      Instead of introducing a new phylink_start_poll() function, which would
      make the implementation cumbersome for common PHYLINK implementations
      for multiple types of devices, like DSA, just add a boolean property to
      the phylink_config structure, which is just as backwards-compatible.
      
      https://lkml.org/lkml/2019/12/16/603Suggested-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1511ed0a
    • Vladimir Oltean's avatar
      net: phylink: make QSGMII a valid PHY mode for in-band AN · 3a68ba6f
      Vladimir Oltean authored
      QSGMII is a SerDes protocol clocked at 5 Gbaud (4 times higher than
      SGMII which is clocked at 1.25 Gbaud), with the same 8b/10b encoding and
      some extra symbols for synchronization. Logically it offers 4 SGMII
      interfaces multiplexed onto the same physical lanes. Each MAC PCS has
      its own in-band AN process with the system side of the QSGMII PHY, which
      is identical to the regular SGMII AN process.
      
      So allow QSGMII as a valid in-band AN mode, since it is no different
      from software perspective from regular SGMII.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a68ba6f
    • Vladimir Oltean's avatar
      mii: Add helpers for parsing SGMII auto-negotiation · 6c930994
      Vladimir Oltean authored
      Typically a MAC PCS auto-configures itself after it receives the
      negotiated copper-side link settings from the PHY, but some MAC devices
      are more special and need manual interpretation of the SGMII AN result.
      
      In other cases, the PCS exposes the entire tx_config_reg base page as it
      is transmitted on the wire during auto-negotiation, so it makes sense to
      be able to decode the equivalent lp_advertised bit mask from the raw u16
      (of course, "lp" considering the PCS to be the local PHY).
      
      Therefore, add the bit definitions for the SGMII registers 4 and 5
      (local device ability, link partner ability), as well as a link_mode
      conversion helper that can be used to feed the AN results into
      phy_resolve_aneg_linkmode.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c930994
  2. 05 Jan, 2020 27 commits
    • David S. Miller's avatar
      Merge branch 'dsa-deferred-xmit' · de1b23b9
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Improvements to the DSA deferred xmit
      
      After the feedback received on v1:
      https://www.spinics.net/lists/netdev/msg622617.html
      
      I've decided to move the deferred xmit implementation completely within
      the sja1105 driver.
      
      The executive summary for this series is the same as it was for v1
      (better for everybody):
      
      - For those who don't use it, thanks to one less assignment in the
        hotpath (and now also thanks to less code in the DSA core)
      - For those who do, by making its scheduling more amenable and moving it
        outside the generic workqueue (since it still deals with packet
        hotpath, after all)
      
      There are some simplification (1/3) and cosmetic (3/3) patches in the
      areas next to the code touched by the main patch (2/3).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de1b23b9
    • Vladimir Oltean's avatar
      net: dsa: tag_sja1105: Slightly improve the Xmas tree in sja1105_xmit · 2821d50f
      Vladimir Oltean authored
      This is a cosmetic patch that makes the dp, tx_vid, queue_mapping and
      pcp local variable definitions a bit closer in length, so they don't
      look like an eyesore as much.
      
      The 'ds' variable is not used otherwise, except for ds->dp.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2821d50f
    • Vladimir Oltean's avatar
      net: dsa: Make deferred_xmit private to sja1105 · a68578c2
      Vladimir Oltean authored
      There are 3 things that are wrong with the DSA deferred xmit mechanism:
      
      1. Its introduction has made the DSA hotpath ever so slightly more
         inefficient for everybody, since DSA_SKB_CB(skb)->deferred_xmit needs
         to be initialized to false for every transmitted frame, in order to
         figure out whether the driver requested deferral or not (a very rare
         occasion, rare even for the only driver that does use this mechanism:
         sja1105). That was necessary to avoid kfree_skb from freeing the skb.
      
      2. Because L2 PTP is a link-local protocol like STP, it requires
         management routes and deferred xmit with this switch. But as opposed
         to STP, the deferred work mechanism needs to schedule the packet
         rather quickly for the TX timstamp to be collected in time and sent
         to user space. But there is no provision for controlling the
         scheduling priority of this deferred xmit workqueue. Too bad this is
         a rather specific requirement for a feature that nobody else uses
         (more below).
      
      3. Perhaps most importantly, it makes the DSA core adhere a bit too
         much to the NXP company-wide policy "Innovate Where It Doesn't
         Matter". The sja1105 is probably the only DSA switch that requires
         some frames sent from the CPU to be routed to the slave port via an
         out-of-band configuration (register write) rather than in-band (DSA
         tag). And there are indeed very good reasons to not want to do that:
         if that out-of-band register is at the other end of a slow bus such
         as SPI, then you limit that Ethernet flow's throughput to effectively
         the throughput of the SPI bus. So hardware vendors should definitely
         not be encouraged to design this way. We do _not_ want more
         widespread use of this mechanism.
      
      Luckily we have a solution for each of the 3 issues:
      
      For 1, we can just remove that variable in the skb->cb and counteract
      the effect of kfree_skb with skb_get, much to the same effect. The
      advantage, of course, being that anybody who doesn't use deferred xmit
      doesn't need to do any extra operation in the hotpath.
      
      For 2, we can create a kernel thread for each port's deferred xmit work.
      If the user switch ports are named swp0, swp1, swp2, the kernel threads
      will be named swp0_xmit, swp1_xmit, swp2_xmit (there appears to be a 15
      character length limit on kernel thread names). With this, the user can
      change the scheduling priority with chrt $(pidof swp2_xmit).
      
      For 3, we can actually move the entire implementation to the sja1105
      driver.
      
      So this patch deletes the generic implementation from the DSA core and
      adds a new one, more adequate to the requirements of PTP TX
      timestamping, in sja1105_main.c.
      Suggested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a68578c2
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Always send through management routes in slot 0 · 0a51826c
      Vladimir Oltean authored
      I finally found out how the 4 management route slots are supposed to
      be used, but.. it's not worth it.
      
      The description from the comment I've just deleted in this commit is
      still true: when more than 1 management slot is active at the same time,
      the switch will match frames incoming [from the CPU port] on the lowest
      numbered management slot that matches the frame's DMAC.
      
      My issue was that one was not supposed to statically assign each port a
      slot. Yes, there are 4 slots and also 4 non-CPU ports, but that is a
      mere coincidence.
      
      Instead, the switch can be used like this: every management frame gets a
      slot at the right of the most recently assigned slot:
      
      Send mgmt frame 1 through S0:    S0 x  x  x
      Send mgmt frame 2 through S1:    S0 S1 x  x
      Send mgmt frame 3 through S2:    S0 S1 S2 x
      Send mgmt frame 4 through S3:    S0 S1 S2 S3
      
      The difference compared to the old usage is that the transmission of
      frames 1-4 doesn't need to wait until the completion of the management
      route. It is safe to use a slot to the right of the most recently used
      one, because by protocol nobody will program a slot to your left and
      "steal" your route towards the correct egress port.
      
      So there is a potential throughput benefit here.
      
      But mgmt frame 5 has no more free slot to use, so it has to wait until
      _all_ of S0, S1, S2, S3 are full, in order to use S0 again.
      
      And that's actually exactly the problem: I was looking for something
      that would bring more predictable transmission latency, but this is
      exactly the opposite: 3 out of 4 frames would be transmitted quicker,
      but the 4th would draw the short straw and have a worse worst-case
      latency than before.
      
      Useless.
      
      Things are made even worse by PTP TX timestamping, which is something I
      won't go deeply into here. Suffice to say that the fact there is a
      driver-level lock on the SPI bus offsets any potential throughput gains
      that parallelism might bring.
      
      So there's no going back to the multi-slot scheme, remove the
      "mgmt_slot" variable from sja1105_port and the dummy static assignment
      made at probe time.
      
      While passing by, also remove the assignment to casc_port altogether.
      Don't pretend that we support cascaded setups.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a51826c
    • David S. Miller's avatar
      Merge branch 'Fix-10G-PHY-interface-types' · 8bd17dc6
      David S. Miller authored
      Russell King says:
      
      ====================
      Fix 10G PHY interface types
      
      Recent discussion has revealed that our current usage of the 10GKR
      phy_interface_t is not correct. This is based on a misunderstanding
      caused in part by the various specifications being difficult to
      obtain. Now that a better understanding has been reached, we ought
      to correct this.
      
      This series introduce PHY_INTERFACE_MODE_10GBASER to replace the
      existing usage of 10GKR mode, and document their differences in the
      phylib documentation. Then switch PHY, SFP/phylink, the Marvell
      PP2 network driver, and its associated comphy driver over to use
      the correct interface mode. None of the existing platform usage
      was actually using 10GBASE-KR.
      
      In order to maintain compatibility with existing DT files, arrange
      for the Marvell PP2 driver to rewrite the phy interface mode; this
      allows other drivers to adopt correct behaviour w.r.t whether the
      10G connection conforms to the backplane 10GBASE-KR protocol vs
      normal 10GBASE-R protocol.
      
      After applying these locally to net-next I've validated that the
      only places which mention the old PHY_INTERFACE_MODE_10GKR
      definition are:
      
      Documentation/networking/phy.rst:``PHY_INTERFACE_MODE_10GKR``
      drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:        if (phy_mode == PHY_INTERFACE_MODE_10GKR)
      drivers/net/phy/aquantia_main.c:                phydev->interface = PHY_INTERFACE_MODE_10GKR;
      drivers/net/phy/aquantia_main.c:            phydev->interface != PHY_INTERFACE_MODE_10GKR &&
      include/linux/phy.h:    PHY_INTERFACE_MODE_10GKR,
      include/linux/phy.h:    case PHY_INTERFACE_MODE_10GKR:
      
      which is as expected.  The only users of "10gbase-kr" in DT are:
      
      arch/arm64/boot/dts/marvell/armada-7040-db.dts: phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts:     phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/armada-8040-db.dts: phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts:   phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts:   phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts:      phy-mode = "10gbase-kr";arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts:      phy-mode = "10gbase-kr";arch/arm64/boot/dts/marvell/cn9130-db.dts:      phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/cn9131-db.dts:      phy-mode = "10gbase-kr";
      arch/arm64/boot/dts/marvell/cn9132-db.dts:      phy-mode = "10gbase-kr";
      
      which all use the mvpp2 driver, and these will be updated in a
      separate patch to be submitted in the following kernel cycle.
      
      v2: add comment to mvpp2 driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8bd17dc6
    • Russell King's avatar
      net: switch to using PHY_INTERFACE_MODE_10GBASER rather than 10GKR · e0f909bc
      Russell King authored
      Switch network drivers, phy drivers, and SFP/phylink over to use the
      more correct 10GBASE-R, rather than 10GBASE-KR. 10GBASE-KR is backplane
      ethernet, which is 10GBASE-R with autonegotiation on top, which our
      current usage on the affected platforms does not have.
      
      The only remaining user of PHY_INTERFACE_MODE_10GKR is the Aquantia
      PHY, which has a separate mode for 10GBASE-KR.
      
      For Marvell mvpp2, we detect 10GBASE-KR, and rewrite it to 10GBASE-R
      for compatibility with existing DT - this is the only network driver
      at present that makes use of PHY_INTERFACE_MODE_10GKR.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0f909bc
    • Russell King's avatar
      net: phy: add PHY_INTERFACE_MODE_10GBASER · c114574e
      Russell King authored
      Recent discussion has revealed that the use of PHY_INTERFACE_MODE_10GKR
      is incorrect. Add a 10GBASE-R definition, document both the -R and -KR
      versions, and the fact that 10GKR was used incorrectly.
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c114574e
    • David S. Miller's avatar
      Merge branch 'ionic-add-sriov-support' · aea6a1eb
      David S. Miller authored
      Shannon Nelson says:
      
      ====================
      ionic: add sriov support
      
      Set up the basic support for enabling SR-IOV devices in the
      ionic driver.  Since most of the management work happens in
      the NIC firmware, the driver becomes mostly a pass-through
      for the network stack commands that want to control and
      configure the VFs.
      
      v4:	changed "vf too big" checks to use pci_num_vf()
      	changed from vf[] array of pointers of individually allocated
      	  vf structs to single allocated vfs[] array of vf structs
      	added clean up of vfs[] on probe fail
      	added setup for vf stats dma
      
      v3:	added check in probe for pre-existing VFs
      	split out the alloc and dealloc of vf structs to better deal
      	  with pre-existing VFs (left enabled on remove)
      	restored the checks for vf too big because of a potential
      	  case where VFs are already enabled but driver failed to
      	  alloc the vf structs
      
      v2:	use pci_num_vf() and kcalloc()
      	remove checks for vf too big
      	add locking for the VF operations
      	disable VFs in ionic_remove() if they are still running
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aea6a1eb
    • Shannon Nelson's avatar
      ionic: support sr-iov operations · fbb39807
      Shannon Nelson authored
      Add the netdev ops for managing VFs.  Since most of the
      management work happens in the NIC firmware, the driver becomes
      mostly a pass-through for the network stack commands that want
      to control and configure the VFs.
      
      We also tweak ionic_station_set() a little to allow for
      the VFs that start off with a zero'd mac address.
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbb39807
    • Shannon Nelson's avatar
      ionic: ionic_if bits for sr-iov support · 3d462ce2
      Shannon Nelson authored
      Adds new AdminQ calls and their related structs for
      supporting PF controls on VFs:
          CMD_OPCODE_VF_GETATTR
          CMD_OPCODE_VF_SETATTR
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d462ce2
    • Krzysztof Kozlowski's avatar
      net: ethernet: sxgbe: Rename Samsung to lowercase · 14a65084
      Krzysztof Kozlowski authored
      Fix up inconsistent usage of upper and lowercase letters in "Samsung"
      name.
      
      "SAMSUNG" is not an abbreviation but a regular trademarked name.
      Therefore it should be written with lowercase letters starting with
      capital letter.
      
      Although advertisement materials usually use uppercase "SAMSUNG", the
      lowercase version is used in all legal aspects (e.g. on Wikipedia and in
      privacy/legal statements on
      https://www.samsung.com/semiconductor/privacy-global/).
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      14a65084
    • David S. Miller's avatar
      Merge branch 'net-phy-switch-to-using-fwnode_gpiod_get_index' · 675a3176
      David S. Miller authored
      Dmitry Torokhov says:
      
      ====================
      net: phy: switch to using fwnode_gpiod_get_index
      
      This series switches phy drivers form using fwnode_get_named_gpiod() and
      gpiod_get_from_of_node() that are scheduled to be removed in favor
      of fwnode_gpiod_get_index() that behaves more like standard
      gpiod_get_index() and will potentially handle secondary software
      nodes in cases we need to augment platform firmware.
      
      Now that the dependencies have been merged into networking tree the
      patches can be applied there as well.
      
      v3:
              - rebased on top of net-next
      
      v2:
              - rebased on top of Linus' W devel branch
              - added David's ACKs
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      675a3176
    • Dmitry Torokhov's avatar
      net: phy: fixed_phy: switch to using fwnode_gpiod_get_index · 5ffcc858
      Dmitry Torokhov authored
      gpiod_get_from_of_node() is being retired in favor of
      [devm_]fwnode_gpiod_get_index(), that behaves similar to
      [devm_]gpiod_get_index(), but can work with arbitrary firmware node. It
      will also be able to support secondary software nodes.
      
      Let's switch this driver over.
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ffcc858
    • Dmitry Torokhov's avatar
      net: phy: fixed_phy: fix use-after-free when checking link GPIO · d266f19f
      Dmitry Torokhov authored
      If we fail to locate GPIO for any reason other than deferral or
      not-found-GPIO, we try to print device tree node info, however if might
      be freed already as we called of_node_put() on it.
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d266f19f
    • Dmitry Torokhov's avatar
      net: phylink: switch to using fwnode_gpiod_get_index() · b605c9ab
      Dmitry Torokhov authored
      Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
      the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), but
      works with arbitrary firmware node.
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b605c9ab
    • Florian Fainelli's avatar
      net: dsa: vsc73xx: Remove dependency on CONFIG_OF · aa1d54c6
      Florian Fainelli authored
      There is no build time dependency on CONFIG_OF, but we do need to make
      sure we gate the initialization of the gpio_chip::of_node member with a
      proper check on CONFIG_OF_GPIO. This enables the driver to build on
      platforms that do not have CONFIG_OF enabled.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aa1d54c6
    • David S. Miller's avatar
      Merge branch 'WireGuard-bug-fixes-and-cleanups' · 704a0afb
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      WireGuard bug fixes and cleanups
      
      I've been working through some personal notes and also the whole git
      repo history of the out-of-tree module, looking for places where
      tradeoffs were made (and subsequently forgotten about) for old kernels.
      The first two patches in this series clean up those. The first one does
      so in the self-tests and self-test harness, where we're now able to
      expand test coverage by a bit, and we're now cooking away tests on every
      commit to both the wireguard-linux repo and to net-next. The second one
      removes a workaround for a skbuff.h bug that was fixed long ago.
      Finally, the last patch in the series fixes in a bug unearthed by newer
      Qualcomm chipsets running the rmnet_perf driver, which does UDP GRO.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      704a0afb
    • Jason A. Donenfeld's avatar
      wireguard: socket: mark skbs as not on list when receiving via gro · 736775d0
      Jason A. Donenfeld authored
      Certain drivers will pass gro skbs to udp, at which point the udp driver
      simply iterates through them and passes them off to encap_rcv, which is
      where we pick up. At the moment, we're not attempting to coalesce these
      into bundles, but we also don't want to wind up having cascaded lists of
      skbs treated separately. The right behavior here, then, is to just mark
      each incoming one as not on a list. This can be seen in practice, for
      example, with Qualcomm's rmnet_perf driver.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Tested-by: default avatarYaroslav Furman <yaro330@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      736775d0
    • Jason A. Donenfeld's avatar
      wireguard: queueing: do not account for pfmemalloc when clearing skb header · 04d2ea92
      Jason A. Donenfeld authored
      Before 8b700862 ("net: Don't copy pfmemalloc flag in __copy_skb_
      header()"), the pfmemalloc flag used to be between headers_start and
      headers_end, which is a region we clear when preparing the packet for
      encryption/decryption. This is a parameter we certainly want to
      preserve, which is why 8b700862 moved it out of there. The code here
      was written in a world before 8b700862, though, where we had to
      manually account for it. This commit brings things up to speed.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04d2ea92
    • Jason A. Donenfeld's avatar
      wireguard: selftests: remove ancient kernel compatibility code · 9a69a4c8
      Jason A. Donenfeld authored
      Quite a bit of the test suite was designed to work with ancient kernels.
      Thankfully we no longer have to deal with this. This commit updates
      things that we can finally update and removes things that we can finally
      remove, to avoid the build-up of the last several years as a result of
      having to support ancient kernels. We can finally rely on suppress_
      prefixlength being available. On the build side of things, the no-PIE
      hack is no longer required, and we can bump some of the tools, repair
      our m68k and i686-kvm support, and get better coverage of the static
      branches used in the crypto lib and in udp_tunnel.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a69a4c8
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 3b477d6c
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      1GbE Intel Wired LAN Driver Updates 2020-01-04
      
      This series contains updates to the igc driver only.
      
      Sasha does some housekeeping on the igc driver to remove forward
      declarations that are not needed after re-arranging several functions.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b477d6c
    • Sasha Neftin's avatar
      igc: Remove no need declaration of the igc_sw_init · 63c92c9d
      Sasha Neftin authored
      We want to avoid forward-declarations of function if possible.
      Rearrange the igc_sw_init function implementation.
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      63c92c9d
    • Sasha Neftin's avatar
      igc: Remove no need declaration of the igc_write_itr · 55cd7386
      Sasha Neftin authored
      We want to avoid forward-declarations of function if possible.
      Rearrange the igc_write_itr function implementation.
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      55cd7386
    • Sasha Neftin's avatar
      igc: Remove no need declaration of the igc_assign_vector · f817fa05
      Sasha Neftin authored
      We want to avoid forward-declarations of function if possible.
      Rearrange the igc_assign_vector function implementation.
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f817fa05
    • Sasha Neftin's avatar
      igc: Remove no need declaration of the igc_free_q_vector · f7bcca5d
      Sasha Neftin authored
      We want to avoid forward-declarations of function if possible.
      Rearrange the igc_free_q_vector function implementation.
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f7bcca5d
    • Sasha Neftin's avatar
      igc: Remove no need declaration of the igc_free_q_vectors · a8c4873b
      Sasha Neftin authored
      We want to avoid forward-declarations of function if possible.
      Rearrange the igc_free_q_vectors function implementation.
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a8c4873b
    • Sasha Neftin's avatar
      igc: Remove no need declaration of the igc_irq_disable · 35f9a78a
      Sasha Neftin authored
      We want to avoid forward-declarations of function if possible.
      Rearrange the igc_irq_disable function implementation.
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      35f9a78a