From owner-freebsd-arch@FreeBSD.ORG Sat Feb 11 12:46:25 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 0BABE106566C; Sat, 11 Feb 2012 12:46:25 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1276F8FC0A; Sat, 11 Feb 2012 12:46:23 +0000 (UTC) Received: by eekb47 with SMTP id b47so1427427eek.13 for ; Sat, 11 Feb 2012 04:46:23 -0800 (PST) Received: by 10.213.31.208 with SMTP id z16mr945102ebc.47.1328964382860; Sat, 11 Feb 2012 04:46:22 -0800 (PST) Received: from rnote.ddteam.net (85-184-133-95.pool.ukrtel.net. [95.133.184.85]) by mx.google.com with ESMTPS id v51sm34903556eef.2.2012.02.11.04.46.18 (version=SSLv3 cipher=OTHER); Sat, 11 Feb 2012 04:46:21 -0800 (PST) Date: Sat, 11 Feb 2012 14:45:44 +0200 From: Aleksandr Rybalko To: Marius Strobl Message-Id: <20120211144544.c91701d9.ray@ddteam.net> In-Reply-To: <20120211111731.GE39861@alchemy.franken.de> References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <20120211111731.GE39861@alchemy.franken.de> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlOyQVFBf+IcEOh8w4ZoETADHmn4Rda+ARIIVlwQyVt4LzmQFtQRcniQMVJbe8XmdJjtYiS Cc: Juli Mallett , Adrian Chadd , FreeBSD-arch , Aleksandr Rybalko , Stefan Bethke Subject: Re: Extending sys/dev/mii 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: Sat, 11 Feb 2012 12:46:25 -0000 Good day hackers! On Sat, 11 Feb 2012 12:17:31 +0100 Marius Strobl wrote: > On Fri, Feb 10, 2012 at 09:23:21PM -0800, Adrian Chadd wrote: > > Hi all, > > > > So where'd we get to with this? > > > > I'd like to finalise a unified proposal for this. > > > > I still like the idea of tidying up the miibus/mdiobus stuff (ie, > > miibus really is an mdiobus for speaking to things, along with some > > methods to do MII stuff like media change, media set, MAC PLL/type > > set, etc) but I agree with ray@ that things begin to look a _lot_ > > more complicated when we start trying to handle alternate methods > > of how switches are connected. > > > > So I'd like to not lose interest on this. > > > > If we can't come to some kind of consensus, I'll just commit ray@'s > > work (and cop the flak) then work with stb@ to tidy up the newbus > > bits to hopefully be better for the long term. > > > > In summary - I'm fed up that we're this close to having _something_ > > that looks like a workable switch API and working code but it's not > > in the tree. So I'm happy stirring up trouble and copping the flak > > from things if it means it Just Gets Done. > > > > I haven't seen ray@'s work (where is it?) There is thread about it: http://lists.freebsd.org/pipermail/freebsd-net/2012-January/031132.html > but the general approach > sounds backwards to me. As you say the whole picture of how switches > are connected in reality is complicated. Therefore I'd like to see a > proposal for a framework first that can handle the various ways of > taking to a switch (GPIO, I2C, MDIO etc or combinations thereof) Currently framework handle OBIO(memory attached) and MDIO, but designed to handle various bus attachment. And as i see GPIO variant must use some bus attached to GPIO (f.e. gpiospi, gpioiic), the switch framework attach to it. When i design framework core, i was keep in mind that: 1. some switches can be controlled with many ways (BCM53115 can be controlled by MDIO and SPI). 2. MAC driver must not be modified, as long as possible. if_arge was modified only to clear special bits like phymask from it. > separately from a MAC (as there may be no MAC associated with the > switch to begin with). The stuff proposed so far (again, I haven't > looked at ray@'s current work) only dealt with the more or less > low hanging fruit in that picture with discussions how we may hack > some more scenarios into working. Getting _something_ in at this > stage just for the sake that there's something in the tree really > asks for one of two typical things happening: > o it sticks as-is forever as nobody really wants to do the work > to get it right and in the end the supposedly generic framework > is ignored and people implement their own local stuff to get what > they need, or > o there actually are some brave souls working on getting it right > over time but requiring API and ABI breakages over and over again > to get there. I think second is near to be true :), but last time i add methods to manipulate Port based VLANs on BCM53115, and 1) i'm not add anything to ioctl definitions (switch_ioctl.h), 2) most of newbus methods have defaults, so adding new feature to some driver, will not break other drivers. Updated work accessible here: http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/switch/ > > Marius > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" -- Aleksandr Rybalko