Skip to content
  1. Sep 25, 2020
  2. Sep 24, 2020
    • David S. Miller's avatar
      Merge branch 'net-dsa-b53-Configure-VLANs-while-not-filtering' · e4a85c54
      David S. Miller authored
      
      
      Florian Fainelli says:
      
      ====================
      net: dsa: b53: Configure VLANs while not filtering
      
      These two patches allow the b53 driver which always configures its CPU
      port as egress tagged to behave correctly with VLANs being always
      configured whenever a port is added to a bridge.
      
      Vladimir provides a patch that aligns the bridge with vlan_filtering=0
      receive path to behave the same as vlan_filtering=1. Per discussion with
      Nikolay, this behavior is deemed to be too DSA specific to be done in
      the bridge proper.
      
      This is a preliminary series for Vladimir to make
      configure_vlan_while_filtering the default behavior for all DSA drivers
      in the future.
      
      Thanks!
      
      Changes in v3:
      
      - added Vladimir's Acked-by tag to patch #2
      - removed unnecessary if_vlan.h inclusion in patch #2
      - reworded commit message to be accurate with the code changes
      
      Changes in v2:
      
      - moved the call to dsa_untag_bridge_pvid() into net/dsa/tag_brcm.c
        since we have a single user for now
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e4a85c54
    • Florian Fainelli's avatar
      net: dsa: b53: Configure VLANs while not filtering · ed409f3b
      Florian Fainelli authored
      
      
      Update the B53 driver to support VLANs while not filtering. This
      requires us to enable VLAN globally within the switch upon driver
      initial configuration (dev->vlan_enabled).
      
      We also need to remove the code that dealt with PVID re-configuration in
      b53_vlan_filtering() since that function worked under the assumption
      that it would only be called to make a bridge VLAN filtering, or not
      filtering, and we would attempt to move the port's PVID accordingly.
      
      Now that VLANs are programmed all the time, even in the case of a
      non-VLAN filtering bridge, we would be programming a default_pvid for
      the bridged switch ports.
      
      We need the DSA receive path to pop the VLAN tag if it is the bridge's
      default_pvid because the CPU port is always programmed tagged in the
      programmed VLANs. In order to do so we utilize the
      dsa_untag_bridge_pvid() helper introduced in the commit before within
      net/dsa/tag_brcm.c.
      
      Acked-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed409f3b
    • Vladimir Oltean's avatar
      net: dsa: untag the bridge pvid from rx skbs · 412a1526
      Vladimir Oltean authored
      
      
      Currently the bridge untags VLANs present in its VLAN groups in
      __allowed_ingress() only when VLAN filtering is enabled.
      
      But when a skb is seen on the RX path as tagged with the bridge's pvid,
      and that bridge has vlan_filtering=0, and there isn't any 8021q upper
      with that VLAN either, then we have a problem. The bridge will not untag
      it (since it is supposed to remain VLAN-unaware), and pvid-tagged
      communication will be broken.
      
      There are 2 situations where we can end up like that:
      
      1. When installing a pvid in egress-tagged mode, like this:
      
      ip link add dev br0 type bridge vlan_filtering 0
      ip link set swp0 master br0
      bridge vlan del dev swp0 vid 1
      bridge vlan add dev swp0 vid 1 pvid
      
      This happens because DSA configures the VLAN membership of the CPU port
      using the same flags as swp0 (in this case "pvid and not untagged"), in
      an attempt to copy the frame as-is from ingress to the CPU.
      
      However, in this case, the packet may arrive untagged on ingress, it
      will be pvid-tagged by the ingress port, and will be sent as
      egress-tagged towards the CPU. Otherwise stated, the CPU will see a VLAN
      tag where there was none to speak of on ingress.
      
      When vlan_filtering is 1, this is not a problem, as stated in the first
      paragraph, because __allowed_ingress() will pop it. But currently, when
      vlan_filtering is 0 and we have such a VLAN configuration, we need an
      8021q upper (br0.1) to be able to ping over that VLAN, which is not
      symmetrical with the vlan_filtering=1 case, and therefore, confusing for
      users.
      
      Basically what DSA attempts to do is simply an approximation: try to
      copy the skb with (or without) the same VLAN all the way up to the CPU.
      But DSA drivers treat CPU port VLAN membership in various ways (which is
      a good segue into situation 2). And some of those drivers simply tell
      the CPU port to copy the frame unmodified, which is the golden standard
      when it comes to VLAN processing (therefore, any driver which can
      configure the hardware to do that, should do that, and discard the VLAN
      flags requested by DSA on the CPU port).
      
      2. Some DSA drivers always configure the CPU port as egress-tagged, in
      an attempt to recover the classified VLAN from the skb. These drivers
      cannot work at all with untagged traffic when bridged in
      vlan_filtering=0 mode. And they can't go for the easy "just keep the
      pvid as egress-untagged towards the CPU" route, because each front port
      can have its own pvid, and that might require conflicting VLAN
      membership settings on the CPU port (swp1 is pvid for VID 1 and
      egress-tagged for VID 2; swp2 is egress-taggeed for VID 1 and pvid for
      VID 2; with this simplistic approach, the CPU port, which is really a
      separate hardware entity and has its own VLAN membership settings, would
      end up being egress-untagged in both VID 1 and VID 2, therefore losing
      the VLAN tags of ingress traffic).
      
      So the only thing we can do is to create a helper function for resolving
      the problematic case (that is, a function which untags the bridge pvid
      when that is in vlan_filtering=0 mode), which taggers in need should
      call. It isn't called from the generic DSA receive path because there
      are drivers that fall neither in the first nor second category.
      
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      412a1526
    • David S. Miller's avatar
      Merge branch 'PHY-subsystem-kernel-doc' · e0da7430
      David S. Miller authored
      
      
      Andrew Lunn says:
      
      ====================
      PHY subsystem kernel doc
      
      The first patches fix existing warnings in the kerneldoc for the PHY
      subsystem, and then the 2nd extend the kernel documentation for the
      major structures and functions in the PHY subsystem.
      
      v2:
      Drop the other fixes which have already been merged.
      s/phy/PHY/g
      TBI
      TypOs
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0da7430
    • Andrew Lunn's avatar
      net: phy: Document core PHY structures · 4069a572
      Andrew Lunn authored
      
      
      Add kerneldoc for the core PHY data structures, a few inline functions
      and exported functions which are not already documented.
      
      v2
      Typos
      g/phy/PHY/s
      
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4069a572
    • Andrew Lunn's avatar
      net: phy: Fixup kernel doc · 39097ab6
      Andrew Lunn authored
      
      
      Add missing parameter documentation, or fixup wrong parameter names.
      
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39097ab6
    • David S. Miller's avatar
      Merge branch 'net-dsa-bcm_sf2-Additional-DT-changes' · 3fc826f1
      David S. Miller authored
      
      
      Florian Fainelli says:
      
      ====================
      net: dsa: bcm_sf2: Additional DT changes
      
      This patch series includes some additional changes to the bcm_sf2 in
      order to support the Device Tree firmwares provided on such platforms.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3fc826f1
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Include address 0 for MDIO diversion · 0fa45ee3
      Florian Fainelli authored
      
      
      We need to include MDIO address 0, which is how our Device Tree blobs
      indicate where to find the external BCM53125 switches.
      
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fa45ee3
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Disallow port 5 to be a DSA CPU port · 8c280440
      Florian Fainelli authored
      
      
      While the switch driver is written such that port 5 or 8 could be CPU
      ports, the use case on Broadcom STB chips is to use port 8 exclusively.
      The platform firmware does make port 5 comply to a proper DSA CPU port
      binding by specifiying an "ethernet" phandle. This is undesirable for
      now until we have an user-space configuration mechanism (such as
      devlink) which could support dynamically changing the port flavor at
      run time.
      
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c280440
    • David S. Miller's avatar
      Merge branch 'octeontx2-Add-support-for-VLAN-based-flow-distribution' · 9d33ffaa
      David S. Miller authored
      
      
      George Cherian says:
      
      ====================
      octeontx2: Add support for VLAN based flow distribution
      
      This series add support for VLAN based flow distribution for octeontx2
      netdev driver. This adds support for configuring the same via ethtool.
      
      Following tests have been done.
      	- Multi VLAN flow with same SD
      	- Multi VLAN flow with same SDFN
      	- Single VLAN flow with multi SD
      	- Single VLAN flow with multi SDFN
      All tests done for udp/tcp both v4 and v6
      ====================
      
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d33ffaa
    • George Cherian's avatar
      octeontx2-pf: Support to change VLAN based RSS hash options via ethtool · a55ff8ef
      George Cherian authored
      
      
      Add support to control rx-flow-hash based on VLAN.
      By default VLAN plus 4-tuple based hashing is enabled.
      Changes can be done runtime using ethtool
      
      To enable 2-tuple plus VLAN based flow distribution
        # ethtool -N <intf> rx-flow-hash <prot> sdv
      To enable 4-tuple plus VLAN based flow distribution
        # ethtool -N <intf> rx-flow-hash <prot> sdfnv
      
      Signed-off-by: default avatarGeorge Cherian <george.cherian@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a55ff8ef
    • George Cherian's avatar
      octeontx2-af: Add support for VLAN based RSS hashing · 8f900363
      George Cherian authored
      
      
      Added support for PF/VF drivers to choose RSS flow key algorithm
      with VLAN tag included in hashing input data. Only CTAG is considered.
      
      Signed-off-by: default avatarGeorge Cherian <george.cherian@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f900363
    • Mauro Carvalho Chehab's avatar
      net: fix a new kernel-doc warning at dev.c · de2b541b
      Mauro Carvalho Chehab authored
      kernel-doc expects the function prototype to be just after
      the kernel-doc markup, as otherwise it will get it all wrong:
      
      	./net/core/dev.c:10036: warning: Excess function parameter 'dev' description in 'WAIT_REFS_MIN_MSECS'
      
      Fixes: 0e4be9e5
      
       ("net: use exponential backoff in netdev_wait_allrefs")
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Reviewed-by: default avatarFrancesco Ruggeri <fruggeri@arista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de2b541b
    • David S. Miller's avatar
      Merge branch 'net-mdio-ipq4019-add-Clause-45-support' · 774e9ea6
      David S. Miller authored
      
      
      Robert Marko says:
      
      ====================
      net: mdio-ipq4019: add Clause 45 support
      
      This patch series adds support for Clause 45 to the driver.
      
      While at it also change some defines to upper case to match rest of the driver.
      
      Changes since v4:
      * Rebase onto net-next.git
      
      Changes since v1:
      * Drop clock patches, these need further investigation and
      no user for non default configuration has been found
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      774e9ea6
    • Robert Marko's avatar
      net: mdio-ipq4019: add Clause 45 support · 06fb5606
      Robert Marko authored
      
      
      While up-streaming the IPQ4019 driver it was thought that the controller had no Clause 45 support,
      but it actually does and its activated by writing a bit to the mode register.
      
      So lets add it as newer SoC-s use the same controller and Clause 45 compliant PHY-s.
      
      Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
      Cc: Luka Perkov <luka.perkov@sartura.hr>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06fb5606
    • Robert Marko's avatar
      net: mdio-ipq4019: change defines to upper case · b840ec1e
      Robert Marko authored
      
      
      In the commit adding the IPQ4019 MDIO driver, defines for timeout and sleep partially used lower case.
      Lets change it to upper case in line with the rest of driver defines.
      
      Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
      Cc: Luka Perkov <luka.perkov@sartura.hr>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b840ec1e
    • David S. Miller's avatar
      Merge branch 'Introduce-mbox-tracepoints-for-Octeontx2' · 35e3dbfa
      David S. Miller authored
      
      
      Subbaraya Sundeep says:
      
      ====================
      Introduce mbox tracepoints for Octeontx2
      
      This patchset adds tracepoints support for mailbox.
      In Octeontx2, PFs and VFs need to communicate with AF
      for allocating and freeing resources. Once all the
      configuration is done by AF for a PF/VF then packet I/O
      can happen on PF/VF queues. When an interface
      is brought up many mailbox messages are sent
      to AF for initializing queues. Say a VF is brought up
      then each message is sent to PF and PF forwards to
      AF and response also traverses from AF to PF and then VF.
      To aid debugging, tracepoints are added at places where
      messages are allocated, sent and message interrupts.
      Below is the trace of one of the messages from VF to AF
      and AF response back to VF:
      
      ~ # echo 1 > /sys/kernel/tracing/events/rvu/enable
      ~ # ifconfig eth20 up
      [  279.379559] eth20 NIC Link is UP 10000 Mbps Full duplex
      ~ # cat /sys/kernel/tracing/trace
              ifconfig-171   [000] ....   275.753345: otx2_msg_alloc: [0002:02:00.1] msg:(0x400) size:40
      
              ifconfig-171   [000] ...1   275.753347: otx2_msg_send: [0002:02:00.1] sent 1 msg(s) of size:48
      
                <idle>-0     [001] dNh1   275.753356: otx2_msg_interrupt: [0002:02:00.0] mbox interrupt VF(s) to PF (0x1)
      
          kworker/u9:1-90    [001] ...1   275.753364: otx2_msg_send: [0002:02:00.0] sent 1 msg(s) of size:48
      
          kworker/u9:1-90    [001] d.h.   275.753367: otx2_msg_interrupt: [0002:01:00.0] mbox interrupt PF(s) to AF (0x2)
      
          kworker/u9:2-167   [002] ....   275.753535: otx2_msg_process: [0002:01:00.0] msg:(0x400) error:0
      
          kworker/u9:2-167   [002] ...1   275.753537: otx2_msg_send: [0002:01:00.0] sent 1 msg(s) of size:32
      
                <idle>-0     [003] d.h1   275.753543: otx2_msg_interrupt: [0002:02:00.0] mbox interrupt AF to PF (0x1)
      
                <idle>-0     [001] d.h2   275.754376: otx2_msg_interrupt: [0002:02:00.1] mbox interrupt PF to VF (0x1)
      
      v3 changes:
       Removed EXPORT_TRACEPOINT_SYMBOLS of otx2_msg_send and otx2_msg_check
       since they are called locally only
      
      v2 changes:
       Removed otx2_msg_err tracepoint since it is similar to devlink_hwerr
       and it will be used instead when devlink supported is added.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35e3dbfa
    • Subbaraya Sundeep's avatar
      octeontx2-pf: Add tracepoints for PF/VF mailbox · 31a97460
      Subbaraya Sundeep authored
      
      
      With tracepoints support present in the mailbox
      code this patch adds tracepoints in PF and VF drivers
      at places where mailbox messages are allocated,
      sent and at message interrupts.
      
      Signed-off-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31a97460