1. 24 Mar, 2020 8 commits
  2. 23 Mar, 2020 3 commits
  3. 22 Mar, 2020 23 commits
  4. 20 Mar, 2020 6 commits
    • David S. Miller's avatar
      Merge tag 'mac80211-next-for-net-next-2020-03-20' of... · 0d7043f3
      David S. Miller authored
      Merge tag 'mac80211-next-for-net-next-2020-03-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
      
      Johannes Berg says:
      
      ====================
      Another set of changes:
       * HE ranging (fine timing measurement) API support
       * hwsim gets virtio support, for use with wmediumd,
         to be able to simulate with multiple machines
       * eapol-over-nl80211 improvements to exclude preauth
       * IBSS reset support, to recover connections from
         userspace
       * and various others.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d7043f3
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Add support for the SGMII port · ffe10e67
      Vladimir Oltean authored
      SJA1105 switches R and S have one SerDes port with an 802.3z
      quasi-compatible PCS, hardwired on port 4. The other ports are still
      MII/RMII/RGMII. The PCS performs rate adaptation to lower link speeds;
      the MAC on this port is hardwired at gigabit. Only full duplex is
      supported.
      
      The SGMII port can be configured as part of the static config tables, as
      well as through a dedicated SPI address region for its pseudo-clause-22
      registers. However it looks like the static configuration is not
      able to change some out-of-reset values (like the value of MII_BMCR), so
      at the end of the day, having code for it is utterly pointless. We are
      just going to use the pseudo-C22 interface.
      
      Because the PCS gets reset when the switch resets, we have to add even
      more restoration logic to sja1105_static_config_reload, otherwise the
      SGMII port breaks after operations such as enabling PTP timestamping
      which require a switch reset.
      
      >From PHYLINK perspective, the switch supports *only* SGMII (it doesn't
      support 1000Base-X). It also doesn't expose access to the raw config
      word for in-band AN in registers MII_ADV/MII_LPA.
      It is able to work in the following modes:
       - Forced speed
       - SGMII in-band AN slave (speed received from PHY)
       - SGMII in-band AN master (acting as a PHY)
      
      The latter mode is not supported by this patch. It is even unclear to me
      how that would be described. There is some code for it left in the
      patch, but 'an_master' is always passed as false.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ffe10e67
    • David S. Miller's avatar
      Merge branch 'net-bridge-vlan-options-nest-the-tunnel-options' · f6e94ff4
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      net: bridge: vlan options: nest the tunnel options
      
      After a discussion with Roopa about the new tunnel vlan option, she
      suggested that we'll be adding more tunnel options and attributes, so
      it'd be better to have them all grouped together under one main vlan
      entry tunnel attribute instead of making them all main attributes. Since
      the tunnel code was added in this net-next cycle and still hasn't been
      released we can easily nest the BRIDGE_VLANDB_ENTRY_TUNNEL_ID attribute
      in BRIDGE_VLANDB_ENTRY_TUNNEL_INFO and allow for any new tunnel
      attributes to be added there. In addition one positive side-effect is
      that we can remove the outside vlan info flag which controlled the
      operation (setlink/dellink) and move it under a new nested attribute so
      user-space can specify it explicitly.
      
      Thus the vlan tunnel format becomes:
       [BRIDGE_VLANDB_ENTRY]
           [BRIDGE_VLANDB_ENTRY_TUNNEL_INFO]
               [BRIDGE_VLANDB_TINFO_ID]
               [BRIDGE_VLANDB_TINFO_CMD]
               ...
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6e94ff4
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan options: move the tunnel command to the nested attribute · c443758b
      Nikolay Aleksandrov authored
      Now that we have a nested tunnel info attribute we can add a separate
      one for the tunnel command and require it explicitly from user-space. It
      must be one of RTM_SETLINK/DELLINK. Only RTM_SETLINK requires a valid
      tunnel id, DELLINK just removes it if it was set before. This allows us
      to have all tunnel attributes and control in one place, thus removing
      the need for an outside vlan info flag.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c443758b
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan options: nest the tunnel id into a tunnel info attribute · fa388f29
      Nikolay Aleksandrov authored
      While discussing the new API, Roopa mentioned that we'll be adding more
      tunnel attributes and options in the future, so it's better to make it a
      nested attribute, since this is still in net-next we can easily change it
      and nest the tunnel id attribute under BRIDGE_VLANDB_ENTRY_TUNNEL_INFO.
      
      The new format is:
       [BRIDGE_VLANDB_ENTRY]
           [BRIDGE_VLANDB_ENTRY_TUNNEL_INFO]
               [BRIDGE_VLANDB_TINFO_ID]
      
      Any new tunnel attributes can be nested under
      BRIDGE_VLANDB_ENTRY_TUNNEL_INFO.
      Suggested-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa388f29
    • Yan-Hsuan Chuang's avatar
      mac80211: driver can remain on channel if not using chan_ctx · 8fa180bb
      Yan-Hsuan Chuang authored
      Some of the drivers are not using channel context, but let the
      stack to control/switch channels instead. For such cases, driver
      can still remain on channel because the mac80211 stack actually
      supports it.
      
      The stack will check if the driver is using chan_ctx and has
      ops->remain_on_channel been hooked. Otherwise it will start its
      ROC work to remain on channel. So, even if the driver is not
      using chan_ctx, the driver is still capable of doing remain on
      channel.
      Signed-off-by: default avatarYan-Hsuan Chuang <yhchuang@realtek.com>
      Link: https://lore.kernel.org/r/20200312074337.16198-1-yhchuang@realtek.comSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8fa180bb