1. 16 Oct, 2018 3 commits
    • Maciej W. Rozycki's avatar
      FDDI: defza: Support capturing outgoing SMT traffic · 9f9a742d
      Maciej W. Rozycki authored
      DEC FDDIcontroller 700 (DEFZA) uses a Tx/Rx queue pair to communicate
      SMT frames with adapter's firmware.  Any SMT frame received from the RMC
      via the Rx queue is queued back by the driver to the SMT Rx queue for
      the firmware to process.  Similarly the firmware uses the SMT Tx queue
      to supply the driver with SMT frames which are queued back to the Tx
      queue for the RMC to send to the ring.
      
      When a network tap is attached to an FDDI interface handled by `defza'
      any incoming SMT frames captured are queued to our usual processing of
      network data received, which in turn delivers them to any listening
      taps.
      
      However the outgoing SMT frames produced by the firmware bypass our
      network protocol stack and are therefore not delivered to taps.  This in
      turn means that taps are missing a part of network traffic sent by the
      adapter, which may make it more difficult to track down network problems
      or do general traffic analysis.
      
      Call `dev_queue_xmit_nit' then in the SMT Tx path, having checked that
      a network tap is attached, with a newly-created `dev_nit_active' helper
      wrapping the usual condition used in the transmit path.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f9a742d
    • Maciej W. Rozycki's avatar
      FDDI: defza: Add support for DEC FDDIcontroller 700 TURBOchannel adapter · 61414f5e
      Maciej W. Rozycki authored
      Add support for the DEC FDDIcontroller 700 (DEFZA), Digital Equipment
      Corporation's first-generation FDDI network interface adapter, made for
      TURBOchannel and based on a discrete version of what eventually became
      Motorola's widely used CAMEL chipset.
      
      The CAMEL chipset is present for example in the DEC FDDIcontroller
      TURBOchannel, EISA and PCI adapters (DEFTA/DEFEA/DEFPA) that we support
      with the `defxx' driver, however the host bus interface logic and the
      firmware API are different in the DEFZA and hence a separate driver is
      required.
      
      There isn't much to say about the driver except that it works, but there
      is one peculiarity to mention.  The adapter implements two Tx/Rx queue
      pairs.
      
      Of these one pair is the usual network Tx/Rx queue pair, in this case
      used by the adapter to exchange frames with the ring, via the RMC (Ring
      Memory Controller) chip.  The Tx queue is handled directly by the RMC
      chip and resides in onboard packet memory.  The Rx queue is maintained
      via DMA in host memory by adapter's firmware copying received data
      stored by the RMC in onboard packet memory.
      
      The other pair is used to communicate SMT frames with adapter's
      firmware.  Any SMT frame received from the RMC via the Rx queue must be
      queued back by the driver to the SMT Rx queue for the firmware to
      process.  Similarly the firmware uses the SMT Tx queue to supply the
      driver with SMT frames that must be queued back to the Tx queue for the
      RMC to send to the ring.
      
      This solution was chosen because the designers ran out of PCB space and
      could not squeeze in more logic onto the board that would be required to
      handle this SMT frame traffic without the need to involve the driver, as
      with the later DEFTA/DEFEA/DEFPA adapters.
      
      Finally the driver does some Frame Control byte decoding, so to avoid
      magic numbers some macros are added to <linux/if_fddi.h>.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61414f5e
    • Serhey Popovych's avatar
      tun: Consistently configure generic netdev params via rtnetlink · df52eab2
      Serhey Popovych authored
      Configuring generic network device parameters on tun will fail in
      presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute
      since tun_validate() always return failure.
      
      This can be visualized with following ip-link(8) command sequences:
      
        # ip link set dev tun0 group 100
        # ip link set dev tun0 group 100 type tun
        RTNETLINK answers: Invalid argument
      
      with contrast to dummy and veth drivers:
      
        # ip link set dev dummy0 group 100
        # ip link set dev dummy0 type dummy
      
        # ip link set dev veth0 group 100
        # ip link set dev veth0 group 100 type veth
      
      Fix by returning zero in tun_validate() when @data is NULL that is
      always in case since rtnl_link_ops->maxtype is zero in tun driver.
      
      Fixes: f019a7a5 ("tun: Implement ip link del tunXXX")
      Signed-off-by: default avatarSerhey Popovych <serhe.popovych@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df52eab2
  2. 14 Oct, 2018 3 commits
  3. 13 Oct, 2018 34 commits