1
0
Fork 0
alistair23-linux/drivers/staging/fsl-dpaa2/ethsw
Linus Torvalds eafdca4d70 Staging/IIO patches for 4.18-rc1
Here is the big staging and IIO driver update for 4.18-rc1.
 
 It was delayed as I wanted to make sure the final driver deletions did
 not cause any major merge issues, and all now looks good.
 
 There are a lot of patches here, just over 1000.  The diffstat summary
 shows the major changes here:
 	1007 files changed, 16828 insertions(+), 227770 deletions(-)
 Because of this, we might be close to shrinking the overall kernel
 source code size for two releases in a row.
 
 There was loads of work in this release cycle, primarily:
 	- tons of ks7010 driver cleanups
 	- lots of mt7621 driver fixes and cleanups
 	- most driver cleanups
 	- wilc1000 fixes and cleanups
 	- lots and lots of IIO driver cleanups and new additions
 	- debugfs cleanups for all staging drivers
 	- lots of other staging driver cleanups and fixes, the shortlog
 	  has the full details.
 
 but the big user-visable things here are the removal of 3 chunks of
 code:
 	- ncpfs and ipx were removed on schedule, no one has cared about
 	  this code since it moved to staging last year, and if it needs
 	  to come back, it can be reverted.
 	- lustre file system is removed.  I've ranted at the lustre
 	  developers about once a year for the past 5 years, with no
 	  real forward progress at all to clean things up and get the
 	  code into the "real" part of the kernel.  Given that the
 	  lustre developers continue to work on an external tree and try
 	  to port those changes to the in-kernel tree every once in a
 	  while, this whole thing really really is not working out at
 	  all.  So I'm deleting it so that the developers can spend the
 	  time working in their out-of-tree location and get things
 	  cleaned up properly to get merged into the tree correctly at a
 	  later date.
 
 Because of these file removals, you will have merge issues on some of
 these files (2 in the ipx code, 1 in the ncpfs code, and 1 in the
 atomisp driver).  Just delete those files, it's a simple merge :)
 
 All of this has been in linux-next for a while with no reported
 problems.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 
 iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWxvjGQ8cZ3JlZ0Brcm9h
 aC5jb20ACgkQMUfUDdst+ymoEwCbBYnyUl3cwCszIJ3L3/zvUWpmqIgAn1DDsAim
 dM4lmKg6HX/JBSV4GAN0
 =zdta
 -----END PGP SIGNATURE-----

Merge tag 'staging-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

Pull staging/IIO updates from Greg KH:
 "Here is the big staging and IIO driver update for 4.18-rc1.

  It was delayed as I wanted to make sure the final driver deletions did
  not cause any major merge issues, and all now looks good.

  There are a lot of patches here, just over 1000. The diffstat summary
  shows the major changes here:

	1007 files changed, 16828 insertions(+), 227770 deletions(-)

  Because of this, we might be close to shrinking the overall kernel
  source code size for two releases in a row.

  There was loads of work in this release cycle, primarily:

   - tons of ks7010 driver cleanups

   - lots of mt7621 driver fixes and cleanups

   - most driver cleanups

   - wilc1000 fixes and cleanups

   - lots and lots of IIO driver cleanups and new additions

   - debugfs cleanups for all staging drivers

   - lots of other staging driver cleanups and fixes, the shortlog has
     the full details.

  but the big user-visable things here are the removal of 3 chunks of
  code:

   - ncpfs and ipx were removed on schedule, no one has cared about this
     code since it moved to staging last year, and if it needs to come
     back, it can be reverted.

   - lustre file system is removed.

     I've ranted at the lustre developers about once a year for the past
     5 years, with no real forward progress at all to clean things up
     and get the code into the "real" part of the kernel.

     Given that the lustre developers continue to work on an external
     tree and try to port those changes to the in-kernel tree every once
     in a while, this whole thing really really is not working out at
     all. So I'm deleting it so that the developers can spend the time
     working in their out-of-tree location and get things cleaned up
     properly to get merged into the tree correctly at a later date.

  Because of these file removals, you will have merge issues on some of
  these files (2 in the ipx code, 1 in the ncpfs code, and 1 in the
  atomisp driver). Just delete those files, it's a simple merge :)

  All of this has been in linux-next for a while with no reported
  problems"

* tag 'staging-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (1011 commits)
  staging: ipx: delete it from the tree
  ncpfs: remove uapi .h files
  ncpfs: remove Documentation
  ncpfs: remove compat functionality
  staging: ncpfs: delete it
  staging: lustre: delete the filesystem from the tree.
  staging: vc04_services: no need to save the log debufs dentries
  staging: vc04_services: vchiq_debugfs_log_entry can be a void *
  staging: vc04_services: remove struct vchiq_debugfs_info
  staging: vc04_services: move client dbg directory into static variable
  staging: vc04_services: remove odd vchiq_debugfs_top() wrapper
  staging: vc04_services: no need to check debugfs return values
  staging: mt7621-gpio: reorder includes alphabetically
  staging: mt7621-gpio: change gc_map to don't use pointers
  staging: mt7621-gpio: use GPIOF_DIR_OUT and GPIOF_DIR_IN macros instead of custom values
  staging: mt7621-gpio: change 'to_mediatek_gpio' to make just a one line return
  staging: mt7621-gpio: dt-bindings: update documentation for #interrupt-cells property
  staging: mt7621-gpio: update #interrupt-cells for the gpio node
  staging: mt7621-gpio: dt-bindings: complete documentation for the gpio
  staging: mt7621-dts: add missing properties to gpio node
  ...
2018-06-09 10:32:39 -07:00
..
Makefile staging: fsl-dpaa2/ethsw: Add ethtool support 2018-03-14 17:36:09 +01:00
README staging: fsl-dpaa2/ethsw: Add README 2018-03-14 17:36:10 +01:00
TODO staging: fsl-dpaa2/ethsw: Add TODO 2018-03-14 17:36:10 +01:00
dpsw-cmd.h staging: fsl-dpaa2/ethsw: Fix tag control information value overwrite 2018-04-23 10:49:14 +02:00
dpsw.c staging: fsl-dpaa2/ethsw: Fix tag control information value overwrite 2018-04-23 10:49:14 +02:00
dpsw.h staging: fsl-dpaa2/ethsw: Fix tag control information value overwrite 2018-04-23 10:49:14 +02:00
ethsw-ethtool.c staging: fsl-dpaa2/ethsw: Add ethtool support 2018-03-14 17:36:09 +01:00
ethsw.c Staging/IIO patches for 4.18-rc1 2018-06-09 10:32:39 -07:00
ethsw.h staging: fsl-dpaa2/ethsw: Add ethtool support 2018-03-14 17:36:09 +01:00

README

DPAA2 Ethernet Switch driver
============================

This file provides documentation for the DPAA2 Ethernet Switch driver


Contents
========
	Supported Platforms
	Architecture Overview
	Creating an Ethernet Switch
	Features


	Supported Platforms
===================
This driver provides networking support for Freescale LS2085A, LS2088A
DPAA2 SoCs.


Architecture Overview
=====================
The Ethernet Switch in the DPAA2 architecture consists of several hardware
resources that provide the functionality. These are allocated and
configured via the Management Complex (MC) portals. MC abstracts most of
these resources as DPAA2 objects and exposes ABIs through which they can
be configured and controlled.

For a more detailed description of the DPAA2 architecture and its object
abstractions see:
	drivers/staging/fsl-mc/README.txt

The Ethernet Switch is built on top of a Datapath Switch (DPSW) object.

Configuration interface:

          ---------------------
         | DPAA2 Switch driver |
          ---------------------
                   .
                   .
              ----------
             | DPSW API |
              ----------
                   .           software
 ================= . ==============
                   .           hardware
          ---------------------
         | MC hardware portals |
          ---------------------
                   .
                   .
                 ------
                | DPSW |
                 ------

Driver uses the switch device driver model and exposes each switch port as
a network interface, which can be included in a bridge. Traffic switched
between ports is offloaded into the hardware. Exposed network interfaces
are not used for I/O, they are used just for configuration. This
limitation is going to be addressed in the future.

The DPSW can have ports connected to DPNIs or to PHYs via DPMACs.


 [ethA]     [ethB]     [ethC]     [ethD]     [ethE]     [ethF]
    :          :          :          :          :          :
    :          :          :          :          :          :
[eth drv]  [eth drv]  [                ethsw drv              ]
    :          :          :          :          :          :        kernel
========================================================================
    :          :          :          :          :          :        hardware
 [DPNI]      [DPNI]     [============= DPSW =================]
    |          |          |          |          |          |
    |           ----------           |       [DPMAC]    [DPMAC]
     -------------------------------            |          |
                                                |          |
                                              [PHY]      [PHY]

For a more detailed description of the Ethernet switch device driver model
see:
	Documentation/networking/switchdev.txt

Creating an Ethernet Switch
===========================
A device is created for the switch objects probed on the MC bus. Each DPSW
has a number of properties which determine the configuration options and
associated hardware resources.

A DPSW object (and the other DPAA2 objects needed for a DPAA2 switch) can
be added to a container on the MC bus in one of two ways: statically,
through a Datapath Layout Binary file (DPL) that is parsed by MC at boot
time; or created dynamically at runtime, via the DPAA2 objects APIs.

Features
========
Driver configures DPSW to perform hardware switching offload of
unicast/multicast/broadcast (VLAN tagged or untagged) traffic between its
ports.

It allows configuration of hardware learning, flooding, multicast groups,
port VLAN configuration and STP state.

Static entries can be added/removed from the FDB.

Hardware statistics for each port are provided through ethtool -S option.