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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 25 Aug 2015 07:40:26 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	Netdev <netdev@...r.kernel.org>, "andrew@...n.ch" <andrew@...n.ch>,
	Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
	Guenter Roeck <linux@...ck-us.net>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 1/2] Documentation: networking: add a DSA document

On Tue, Aug 25, 2015 at 6:50 AM, Florian Fainelli <f.fainelli@...il.com> wrote:
> Describe how the DSA subsystem works, its design principles,
> limitations, and describe in details how to implement a DSA switch
> driver.
>
> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>

[cut]

> +Interactions with other subsystems
> +==================================
> +
> +DSA currently leverages the following subsystems:
> +
> +- MDIO/PHY library: drivers/net/phy/phy.c, mdio_bus.c
> +- Switchdev: net/switchdev/*
> +- Device Tree for various of_* functions
> +- HWMON: drivers/hwmon/*
> +
> +MDIO/PHY library
> +----------------
> +
> +Slave network devices exposed by DSA may or may not be interfacing with PHY
> +devices (struct phy_device as defined in include/linux/phy.h), but the DSA
> +subsystem deals with all possible combinations:
> +
> +- internal PHY devices, built into the Ethernet switch hardware
> +- external PHY devices, connected via an internal or external MDIO bus
> +- internal PHY devices, connected vian an internal MDIO bus
> +- special, non-autonegotiated or non MDIO-managed PHY devices: SFPs, MoCA; aka
> +  fixed PHYs
> +
> +The PHY configuration is done by the dsa_slave_phy_setup() function and the
> +logic basically looks like this:
> +
> +- if Device Tree is used, the PHY device is looked up using the standard
> +  "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
> +  the definition of a non-MDIO managed PHY as defined in
> +  Documentation/devicetree/binding/net/fixed-link.txt, the PHY is the registered
> +  and connected to using the special fixed MDIO bus driver transparently
> +
> +- finally, if the PHY is built into the switch, as is very common with
> +  standalone switch packages, the PHY is probed using the slave MII bus created
> +  by DSA
> +
> +
> +SWITCHDEV
> +---------
> +
> +DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and more
> +specifically with its VLAN filtering portion when configuring VLANs on top of
> +per-port slave network devices. Since DSA primarily deals with MDIO-connected
> +switch, although not exclusively, SWITCHDEV's commit/prepare/ phase
> +

Missing rest of sentence.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ