From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 13:52:34 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6802C106564A for ; Sun, 8 May 2011 13:52:34 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ED5978FC08 for ; Sun, 8 May 2011 13:52:33 +0000 (UTC) Received: by wwc33 with SMTP id 33so4573512wwc.31 for ; Sun, 08 May 2011 06:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=fXu9E7Gqdp0eOA9XPiUKH6S6pWkAjpe2tXmbAvLGTAo=; b=SifSsF8gLC/Dl+QfJz1yF6+MD7BwCOy8uQeeVYgjyoItlf90uf8GtRNfdTrNHHFOFI +ZTbVMhax0zDOfU0DDdzQNWzrbwBz6B3hUem2ioU8dHF66SFlrEJ3ByADwlG0aSaRhjn Dqoqt4oOsuAWkftf7UHnr0/iOSCm18kW5QGUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=g0di/7p34EZ+wnQcIpLfjYb01A310R5IZLDaVEGeMurSVLtckUft18ljR0DeZq5hdi 8TFzME4YscQ61bZoeVhbkOxYZarXAN+krkS3aO7Vhe8r3tXPywpl1Vl4fpsLMuUJY6LD hrGdp8uGmyh8sYTqLjTEoKmvKEENi4sQ/rLfY= Received: by 10.227.42.130 with SMTP id s2mr6151848wbe.103.1304862752723; Sun, 08 May 2011 06:52:32 -0700 (PDT) Received: from [192.168.123.4] (cpe-109-60-66-194.zg3.cable.xnet.hr [109.60.66.194]) by mx.google.com with ESMTPS id w25sm1853350wbd.22.2011.05.08.06.52.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 06:52:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damjan Marion In-Reply-To: <20110508131643.GA23650@alchemy.franken.de> Date: Sun, 8 May 2011 15:52:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 13:52:34 -0000 On May 8, 2011, at 3:16 PM, Marius Strobl wrote: > On Sat, May 07, 2011 at 07:22:23PM +0200, Damjan Marion wrote: >>=20 >> Hi, >>=20 >>=20 >> I would like to implement support for embedded switch on WRT350Nv2 = router which is based on 88F5181L SoC (ARM). FreeBSD already have = support for embedded gigabit card (if_mge) but in case if this router = MAC is connected directly to 8-port ethernet chip (88E6131). If I use = MII_PHY_ANY scan founds following PHYs on miibus: >>=20 >> mge0: mem 0xf1072000-0xf1073fff = irq 18,19,20,21,22 on simplebus0 >> miibus0: on mge0 >> e1000phy0: PHY 12 on miibus0 >> e1000phy0: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy1: PHY 13 on miibus0 >> e1000phy1: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy2: PHY 14 on miibus0 >> e1000phy2: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy3: PHY 15 on miibus0 >> e1000phy3: id1=3D0x0141, id2=3D0x0c00=20 >> ukphy0: PHY 20 on miibus0 >> ukphy0: =20 >> ukphy1: PHY 21 on miibus0 >> ukphy1: =20 >> ukphy2: PHY 22 on miibus0 >> ukphy2: =20 >> ukphy3: PHY 23 on miibus0 >>=20 >> if_mge MAC is connected to port 3 of E6131 and port 3 acts in = reverse-GMII mode to simulate PHY side. >>=20 >> Reason for output above is that E6131 uses non-standard registers on = multiple device addresses and on some of them mii_attach fails, and on = another it false detects PHY (20-23 above). >=20 > Well, if the switch responds on these addresses then from a MII point > of view there's nothing wrong about this when using MII_PHY_ANY. If > you want only one of these to attach than use that address instead of > MII_PHY_ANY. By calling mii_attach() multiple times with different > addresses you can also attach a subset. Yes, my initial idea is to attach manually only to one PHY, but problem=20= is that either i can attach to PHY12-15 which is reporting wrong ID2=20 belonging to different PHY driver or to attach on PHY20-23 where ID1 and = ID2=20 registers doesn't exist, but luckily some values are at that address and=20= they are recognized as unknown PHY. In both cases it sounds like a workaround more than a proper solution, = so=20 I was wondering if there is some better way to detect PHY, not only by=20= ID1 and ID2 values. In case of this device there is another register = which=20 contains product identifier, and that is what linux driver probes. >=20 >>=20 >> I would like to hear form more experienced people how to implement = this properly, as it is obvious that it cannot be addressed with = existing routines. >=20 > Depends on what you understand by properly. One idea I particularly > like is to handle switch ports as pseudo-interfaces hanging off of the > the MAC driver parent roughly similar to vlan(4). That way you'd have > per port link status and could configure the media. >=20 > What you can do now without changing mii(4) is to just attach the > the PHY side, i.e. port 3, and configure/handle the ports in a > special PHY driver, either by hardcoding their configuration like > rlswitch(4) does or by providing SYSCTLs as Adrian already said. > If we had a way to access the PHY registers from userland similar > to what pci(4)/pciconf(8) allows, which is another thing I'd like > to see in order to provide miitool-like functionality, one could > also easily handle the port configuration from userland instead > of putting everything into the kernel. That probably also would > have its merits as in reality there are probably a lot of quirks > like unconnected ports etc. Agree, I will try to code something and then I will ask wider audience = to comment on.