netdev - [RFC net-next 0/9] net: dsa: mv88e6xxx: add RMU support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190521193004.10767-1-vivien.didelot@gmail.com>
Date:   Tue, 21 May 2019 15:29:55 -0400
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     netdev@...r.kernel.org
Cc:     cphealy@...il.com, Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>
Subject: [RFC net-next 0/9] net: dsa: mv88e6xxx: add RMU support

This series is a request for comment for the support for sending
and receiving special management frames between Linux and Ethernet
switch drivers.

The (Marvell) Ethernet switches can respond to special control
frames used to access the internal switch registers. This provides
an alternative control bus for the switches, in addition to SMI. This
is called Remote Management Unit (RMU) and must be activated on
choosen port(s). Here's an illustration of what we may see:

        +-----------+
        |    CPU    +-----+
        +----+ +----+     |             Control path via port 1.
        |eth0| |eth1|     | MDIO        Data path via port port 3.
        +-+--+-+--+-+     |(optional)   eth1 is a dedicated DSA master,
(optional)|       |       |             eth0 is a normal interface,
    +---+-+-+---+-+-+---+ |             doing normal traffic + MGMT.
    | 0 | 1 | 2 | 3 | 4 | | (optional)
    +---+---+---+---+---+ | +--------+  There can also be several
    |  Ethernet Switch  +-+ | EEPROM |  interconnected switches using
    +-----------------+-+   +-+------+  a single control interface.
                      +-------+

Working examples for RMU are the vf610-zii-dev boards where the Control
and Data paths are both using the single DSA master interface wired
to 2 or 3 interconnected switches.

Having access to both SMI and Ethernet busses in the driver is
interesting because they each have specific operations which can
be more efficient in certain scenarios. For example, SMI has an ATU
GetNext operation which is handy to lookup a particular FDB entry,
but is expensive for dumping the whole database. RMU has no ATU
GetNext operation, but a Dump ATU operation allowing to retrieve up
to 48 entries per frame. RMU also has a Wait Bit implementation and
statistics dump operations. Ideally the driver would choose which
bus to use depending on the operation.

This RFC only implements the hooks in DSA to allow a switch driver to
send and receive frames it is interested in, as well as the register
read and write operations through RMU in mv88e6xxx as an illustration.

Please do not spend too much time reviewing the frame crafting itself
(in rmu.c), which currently hardcodes values and must share code with
the (E)DSA taggers. This part will be polished later.

The purpose of this RFC is not to discuss the implementation of RMU
frames in mv88e6xxx, but to discuss the appropriate way to implement
such control bus in the kernel and allow switch drivers to use it.

The master of such Ethernet bus could be any network interface,
doing normal traffic plus control frames for the switch(es) it is
(directly or indirectly) connected to. A proper virtual Ethernet
bus allowing switches to be probed can be implemented, plus DTS
properties to describe which interface to use as a bus master and
on which switch port the remote management must be enabled. In the
meantime, this RFC hooks into DSA.

My concerns are how to properly add hooks to filter frames on the
receive path of any struct net_device (including but not necessarily
a DSA master)? Are there other device drivers out there making use
of multiple control bus at the same time? Is this implementation
sufficient for the moment?


Cheers,

Vivien Didelot (9):
  net: dsa: introduce dsa_master_find_switch
  net: dsa: allow switches to receive frames
  net: dsa: allow switches to transmit frames
  net: dsa: introduce dsa_is_upstream_port
  net: dsa: introduce dsa_to_master
  net: dsa: mv88e6xxx: add default bus operations
  net: dsa: mv88e6xxx: implement RMU enable
  net: dsa: mv88e6xxx: setup RMU port
  net: dsa: mv88e6xxx: setup RMU bus

 drivers/net/dsa/mv88e6xxx/Makefile  |   1 +
 drivers/net/dsa/mv88e6xxx/chip.c    |  43 +++-
 drivers/net/dsa/mv88e6xxx/chip.h    |  14 ++
 drivers/net/dsa/mv88e6xxx/global1.c |  56 +++++
 drivers/net/dsa/mv88e6xxx/global1.h |   2 +
 drivers/net/dsa/mv88e6xxx/rmu.c     | 314 ++++++++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/rmu.h     |  34 +++
 drivers/net/dsa/mv88e6xxx/smi.c     |   3 +
 drivers/net/dsa/mv88e6xxx/smi.h     |  18 --
 include/net/dsa.h                   |  32 +++
 net/dsa/dsa2.c                      |   6 +
 net/dsa/dsa_priv.h                  |  19 +-
 net/dsa/switch.c                    |  15 ++
 net/dsa/tag_dsa.c                   |   6 +
 net/dsa/tag_edsa.c                  |   6 +
 15 files changed, 536 insertions(+), 33 deletions(-)
 create mode 100644 drivers/net/dsa/mv88e6xxx/rmu.c
 create mode 100644 drivers/net/dsa/mv88e6xxx/rmu.h

-- 
2.21.0