From owner-freebsd-arch@FreeBSD.ORG Sun Jan 29 12:26:02 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8BF8106566C; Sun, 29 Jan 2012 12:26:02 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 915038FC12; Sun, 29 Jan 2012 12:26:02 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id C7D632772C; Sun, 29 Jan 2012 12:26:00 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Sun, 29 Jan 2012 13:26:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <045BA867-B83B-4C2E-AB4F-4D09E49B7F3D@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> To: Juli Mallett X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Aleksandr Rybalko , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 12:26:03 -0000 Am 29.01.2012 um 00:00 schrieb Juli Mallett: > On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko = wrote: >> As I see from your patch, mdio/miiproxy require special bits in MAC >> driver. When I design switch framework, I keeping in mind that >> MAC drivers should be standard as possible >=20 > I don't understand why this is desirable in practice. It's a nice > theory, but it falls down when one thinks in depth about how Ethernet > interfaces are used and administered vs. how switches are used and > administered. What should media report? What should media changes > do? What is link status? Do you show the CPU-to-switch port, or all > switch ports? The main thrust here is to reuse the existing PHY code to be able to = configure the PHYs that are embedded in the switch chips. To confuse = things, one of these PHYs might be connected to the SoCs ethernet = interface via MII, GMII, etc. To confuse things further, these PHYs are = controlled by an MDIO bus that has it's master in the switch chip, while = the switch chip is a slave to the MDIO master in the ethernet = controller. The goal is to be able to configure the switch ports and set media on = one of them, for example. That code path could be entirely independent = from the ethernet infrastructure, if dev/miibus didn't require if_media = and hence a struct ifnet. This discussion is also about how to deal = with this entanglement. The MII connection between the ethernet controller and the switch chip = (usually referred to as the "CPU" port) is hard-coded and has no media = settings, so there's no question what if_media settings should be = presented on the interface. > are a lot of switches out there that don't look or act much like > MII-driven PHYs, but which are connected over MDIO, as I've tried to > stress before. I hope there will be as much separation between the > MII work that is being done and the switch work that is being done as > possible. I think anything else will prove rapidly-obsolete and > perhaps even obstructive as soon as anyone seeks to add support for > more switch chipsets to FreeBSD. >=20 > I suppose the most likely reality, though, is that people simply won't > add switch support to FreeBSD, and will administer them out-of-band > from userland, using gross kernel shims. That is probably true > whether any of the currently-outstanding work is committed or not, > unfortunately :( I just hope we'll end up with something flexible > enough, broad enough in applicability, narrow enough in requirements, > etc., that we'll have feature-rich support for a few chipsets in tree > that work in sufficiently-different manners that they can be models > for other drivers in the future. Which is a valid approach from a vendor's viewpoint. The reason we're = talking is to try and make it easier to write a switch driver for this = framework than roll your own hack. :-) Stefan --=20 Stefan Bethke Fon +49 151 14070811