Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

  phy-mode:

    $ref: "#/properties/phy-connection-type"

  pcs-handle:

    $ref: /schemas/types.yaml#/definitions/phandle

    description:

      Specifies a reference to a node representing a PCS PHY device on a MDIO

      bus to link with an external PHY (phy-handle) if exists.

  phy-handle:

    $ref: /schemas/types.yaml#/definitions/phandle

    description:

	In fiber mode, auto-negotiation is disabled and the PHY can only work in

	100base-fx (full and half duplex) modes.

 - lan8814,ignore-ts: If present the PHY will not support timestamping.

	This option acts as check whether Timestamping is supported by

	hardware or not. LAN8814 phy support hardware tmestamping.

 - lan8814,latency_rx_10: Configures Latency value of phy in ingress at 10 Mbps.

 - lan8814,latency_tx_10: Configures Latency value of phy in egress at 10 Mbps.

 - lan8814,latency_rx_100: Configures Latency value of phy in ingress at 100 Mbps.

 - lan8814,latency_tx_100: Configures Latency value of phy in egress at 100 Mbps.

 - lan8814,latency_rx_1000: Configures Latency value of phy in ingress at 1000 Mbps.

 - lan8814,latency_tx_1000: Configures Latency value of phy in egress at 1000 Mbps.

		  specified, the TX/RX DMA interrupts should be on that node

		  instead, and only the Ethernet core interrupt is optionally

		  specified here.

- phy-handle	: Should point to the external phy device.

- phy-handle	: Should point to the external phy device if exists. Pointing

		  this to the PCS/PMA PHY is deprecated and should be avoided.

		  See ethernet.txt file in the same directory.

- xlnx,rxmem	: Set to allocated memory buffer for Rx/Tx in the hardware

		  required through the core's MDIO interface (i.e. always,

		  unless the PHY is accessed through a different bus).

 - pcs-handle: 	  Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X

		  modes, where "pcs-handle" should be used to point

		  to the PCS/PMA PHY, and "phy-handle" should point to an

		  external PHY if exists.

Example:

	axi_ethernet_eth: ethernet@40c00000 {

		compatible = "xlnx,axi-ethernet-1.00.a";

Design principles

=================

The Distributed Switch Architecture is a subsystem which was primarily designed

to support Marvell Ethernet switches (MV88E6xxx, a.k.a Linkstreet product line)

using Linux, but has since evolved to support other vendors as well.

The Distributed Switch Architecture subsystem was primarily designed to

support Marvell Ethernet switches (MV88E6xxx, a.k.a. Link Street product

line) using Linux, but has since evolved to support other vendors as well.

The original philosophy behind this design was to be able to use unmodified

Linux tools such as bridge, iproute2, ifconfig to work transparently whether

they configured/queried a switch port network device or a regular network

device.

An Ethernet switch is typically comprised of multiple front-panel ports, and one

or more CPU or management port. The DSA subsystem currently relies on the

An Ethernet switch typically comprises multiple front-panel ports and one

or more CPU or management ports. The DSA subsystem currently relies on the

presence of a management port connected to an Ethernet controller capable of

receiving Ethernet frames from the switch. This is a very common setup for all

kinds of Ethernet switches found in Small Home and Office products: routers,

gateways, or even top-of-the rack switches. This host Ethernet controller will

gateways, or even top-of-rack switches. This host Ethernet controller will

be later referred to as "master" and "cpu" in DSA terminology and code.

The D in DSA stands for Distributed, because the subsystem has been designed

ports are referred to as "dsa" ports in DSA terminology and code. A collection

of multiple switches connected to each other is called a "switch tree".

For each front-panel port, DSA will create specialized network devices which are

For each front-panel port, DSA creates specialized network devices which are

used as controlling and data-flowing endpoints for use by the Linux networking

stack. These specialized network interfaces are referred to as "slave" network

interfaces in DSA terminology and code.

The ideal case for using DSA is when an Ethernet switch supports a "switch tag"

which is a hardware feature making the switch insert a specific tag for each

Ethernet frames it received to/from specific ports to help the management

Ethernet frame it receives to/from specific ports to help the management

interface figure out:

- what port is this frame coming from

ports must decapsulate the packet.

Note that in certain cases, it might be the case that the tagging format used

by a leaf switch (not connected directly to the CPU) to not be the same as what

by a leaf switch (not connected directly to the CPU) is not the same as what

the network stack sees. This can be seen with Marvell switch trees, where the

CPU port can be configured to use either the DSA or the Ethertype DSA (EDSA)

format, but the DSA links are configured to use the shorter (without Ethertype)

  to/from specific switch ports

- query the switch for ethtool operations: statistics, link state,

  Wake-on-LAN, register dumps...

- external/internal PHY management: link, auto-negotiation etc.

- manage external/internal PHY: link, auto-negotiation, etc.

These slave network devices have custom net_device_ops and ethtool_ops function

pointers which allow DSA to introduce a level of layering between the networking

stack/ethtool, and the switch driver implementation.

stack/ethtool and the switch driver implementation.

Upon frame transmission from these slave network devices, DSA will look up which

switch tagging protocol is currently registered with these network devices, and

switch tagging protocol is currently registered with these network devices and

invoke a specific transmit routine which takes care of adding the relevant

switch tag in the Ethernet frames.

These frames are then queued for transmission using the master network device

``ndo_start_xmit()`` function, since they contain the appropriate switch tag, the

``ndo_start_xmit()`` function. Since they contain the appropriate switch tag, the

Ethernet switch will be able to process these incoming frames from the

management interface and delivers these frames to the physical switch port.

management interface and deliver them to the physical switch port.

Graphical representation

------------------------

switches, these functions would utilize direct or indirect PHY addressing mode

to return standard MII registers from the switch builtin PHYs, allowing the PHY

library and/or to return link status, link partner pages, auto-negotiation

results etc..

results, etc.

For Ethernet switches which have both external and internal MDIO busses, the

For Ethernet switches which have both external and internal MDIO buses, the

slave MII bus can be utilized to mux/demux MDIO reads and writes towards either

internal or external MDIO devices this switch might be connected to: internal

PHYs, external PHYs, or even external switches.

  table indication (when cascading switches)

- ``dsa_platform_data``: platform device configuration data which can reference

  a collection of dsa_chip_data structure if multiples switches are cascaded,

  a collection of dsa_chip_data structures if multiple switches are cascaded,

  the master network device this switch tree is attached to needs to be

  referenced

  "phy-handle" property, if found, this PHY device is created and registered

  using ``of_phy_connect()``

- if Device Tree is used, and the PHY device is "fixed", that is, conforms to

- if Device Tree is used and the PHY device is "fixed", that is, conforms to

  the definition of a non-MDIO managed PHY as defined in

  ``Documentation/devicetree/bindings/net/fixed-link.txt``, the PHY is registered

  and connected transparently using the special fixed MDIO bus driver

DSA features a standardized binding which is documented in

``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper

functions such as ``of_get_phy_mode()``, ``of_phy_connect()`` are also used to query

per-port PHY specific details: interface connection, MDIO bus location etc..

per-port PHY specific details: interface connection, MDIO bus location, etc.

Driver development

==================

- ``setup``: setup function for the switch, this function is responsible for setting

  up the ``dsa_switch_ops`` private structure with all it needs: register maps,

  interrupts, mutexes, locks etc.. This function is also expected to properly

  interrupts, mutexes, locks, etc. This function is also expected to properly

  configure the switch to separate all network interfaces from each other, that

  is, they should be isolated by the switch hardware itself, typically by creating

  a Port-based VLAN ID for each port and allowing only the CPU port and the

- ``get_phy_flags``: Some switches are interfaced to various kinds of Ethernet PHYs,

  if the PHY library PHY driver needs to know about information it cannot obtain

  on its own (e.g.: coming from switch memory mapped registers), this function

  should return a 32-bits bitmask of "flags", that is private between the switch

  should return a 32-bit bitmask of "flags" that is private between the switch

  driver and the Ethernet PHY driver in ``drivers/net/phy/\*``.

- ``phy_read``: Function invoked by the DSA slave MDIO bus when attempting to read

  the switch port MDIO registers. If unavailable, return 0xffff for each read.

  For builtin switch Ethernet PHYs, this function should allow reading the link

  status, auto-negotiation results, link partner pages etc..

  status, auto-negotiation results, link partner pages, etc.

- ``phy_write``: Function invoked by the DSA slave MDIO bus when attempting to write

  to the switch port MDIO registers. If unavailable return a negative error

------------------

- ``get_strings``: ethtool function used to query the driver's strings, will

  typically return statistics strings, private flags strings etc.

  typically return statistics strings, private flags strings, etc.

- ``get_ethtool_stats``: ethtool function used to query per-port statistics and

  return their values. DSA overlays slave network devices general statistics:

- ``get_sset_count``: ethtool function used to query the number of statistics items

- ``get_wol``: ethtool function used to obtain Wake-on-LAN settings per-port, this

  function may, for certain implementations also query the master network device

  function may for certain implementations also query the master network device

  Wake-on-LAN settings if this interface needs to participate in Wake-on-LAN

- ``set_wol``: ethtool function used to configure Wake-on-LAN settings per-port,

  in a fully active state

- ``port_enable``: function invoked by the DSA slave network device ndo_open

  function when a port is administratively brought up, this function should be

  fully enabling a given switch port. DSA takes care of marking the port with

  function when a port is administratively brought up, this function should

  fully enable a given switch port. DSA takes care of marking the port with

  ``BR_STATE_BLOCKING`` if the port is a bridge member, or ``BR_STATE_FORWARDING`` if it

  was not, and propagating these changes down to the hardware

- ``port_disable``: function invoked by the DSA slave network device ndo_close

  function when a port is administratively brought down, this function should be

  fully disabling a given switch port. DSA takes care of marking the port with

  function when a port is administratively brought down, this function should

  fully disable a given switch port. DSA takes care of marking the port with

  ``BR_STATE_DISABLED`` and propagating changes to the hardware if this port is

  disabled while being a bridge member

------------

- ``port_bridge_join``: bridge layer function invoked when a given switch port is

  added to a bridge, this function should be doing the necessary at the switch

  level to permit the joining port from being added to the relevant logical

  added to a bridge, this function should do what's necessary at the switch

  level to permit the joining port to be added to the relevant logical

  domain for it to ingress/egress traffic with other members of the bridge.

- ``port_bridge_leave``: bridge layer function invoked when a given switch port is

  removed from a bridge, this function should be doing the necessary at the

  removed from a bridge, this function should do what's necessary at the

  switch level to deny the leaving port from ingress/egress traffic from the

  remaining bridge members. When the port leaves the bridge, it should be aged

  out at the switch hardware for the switch to (re) learn MAC addresses behind

  point for drivers that need to configure the hardware for enabling this

  feature.

- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoken when a driver

- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoked when a driver

  leaves a bridge port which had the TX forwarding offload feature enabled.

Bridge VLAN filtering

	struct saved_msr *end = msr + ctxt->saved_msrs.num;

	while (msr < end) {

		msr->valid = !rdmsrl_safe(msr->info.msr_no, &msr->info.reg.q);

		if (msr->valid)

			rdmsrl(msr->info.msr_no, msr->info.reg.q);

		msr++;

	}

}

	}

	for (i = saved_msrs->num, j = 0; i < total_num; i++, j++) {

		u64 dummy;

		msr_array[i].info.msr_no	= msr_id[j];

		msr_array[i].valid		= false;

		msr_array[i].valid		= !rdmsrl_safe(msr_id[j], &dummy);

		msr_array[i].info.reg.q		= 0;

	}

	saved_msrs->num   = total_num;

	return ret;

}

static void pm_save_spec_msr(void)

{

	u32 spec_msr_id[] = {

		MSR_IA32_SPEC_CTRL,

		MSR_IA32_TSX_CTRL,

		MSR_TSX_FORCE_ABORT,

		MSR_IA32_MCU_OPT_CTRL,

		MSR_AMD64_LS_CFG,

	};

	msr_build_context(spec_msr_id, ARRAY_SIZE(spec_msr_id));

}

static int pm_check_save_msr(void)

{

	dmi_check_system(msr_save_dmi_table);

	pm_cpu_check(msr_save_cpu_table);

	pm_save_spec_msr();

	return 0;

}