On Thu, Aug 27, 2015 at 12:45 AM, Andrew Lunn <and...@lunn.ch> wrote: >> I don't know about how this overlaps with DSA platform_class. Florian? > > There is some overlap with DSA, but the current DSA model, with > respect to probing, is broken. So this might be interesting as a way > towards fix that. > > One thing to keep in mind is the D in DSA. You talk about switch, > singular. DSA has a number of switches in a cluster. We currently > export a single switchdev interface for the cluster, but there are > some properties which are per switch, e.g. temperature, eeprom > contents, statistics, power management etc.
Export a single 'switchdev' or 'netdev' for the cluster? I hope that was a typo. With switchdev device class, you'd instantiate one per phy switch, and have per-switch props (temp, eeprom, etc) thru each switchdev instance. The cluster netdev would stay a netdev which spans the switches. > > Although ethtool does have options for these, it is not always a > natural fit. ethtool --eeprom-dump on a switch port dumps the switch > EEPROM, and all ports on the switch can be used. --register-dump on a > port is good for showing the per ports registers, but there is no > natural interface for showing the global switch registers. Florian's > resent L2 interface patch shows we have issues getting access to the > 'cpu' port, the port which interfaces to the host. > > We need to be careful that any new interfaces we add are better at > representing the true structure of the hardware, which includes there > being multiple physical switches below a switchdev, and they are > connected together by ports which are currently not visible as > netdevs. Right. I'm thinking one switchdev instance (based on the new switchdev class) per phy switch. Port netdevs for switch ports worth exposing (for user interaction). And cluster netdev for dsa tagging encap/decap. Do I have this right? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
