Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763735AbZD3PEh (ORCPT ); Thu, 30 Apr 2009 11:04:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760190AbZD3PEY (ORCPT ); Thu, 30 Apr 2009 11:04:24 -0400 Received: from yw-out-2324.google.com ([74.125.46.31]:42886 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758629AbZD3PEX convert rfc822-to-8bit (ORCPT ); Thu, 30 Apr 2009 11:04:23 -0400 MIME-Version: 1.0 In-Reply-To: <1240388476.17445.10.camel@pasglop> References: <625fc13d0904200529l152b8d75g33c3f940de1b2920@mail.gmail.com> <1240388476.17445.10.camel@pasglop> Date: Thu, 30 Apr 2009 11:04:22 -0400 Message-ID: Subject: Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions) From: Kyle Moffett To: Benjamin Herrenschmidt Cc: Josh Boyer , netdev , "Linux-Kernel@Vger. Kernel. Org" , linuxppc-dev@ozlabs.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2346 Lines: 48 On Wed, Apr 22, 2009 at 4:21 AM, Benjamin Herrenschmidt wrote: > On Mon, 2009-04-20 at 20:10 -0400, Kyle Moffett wrote: >> > IIRC, Ben had some issues with how phylib and the EMAC would need to >> > interact.  Not sure if he has those written down somewhere or not. >> > (CC'd). >> >> Hmm, yeah, I'd be interested to see those.  There's enough similar >> between phylib and the EMAC and sungem drivers that I'm considering a >> series of somewhat-mechanical patches to make EMAC and sungem use the >> "struct phy_device" and "struct mii_bus" from phylib, possibly >> abstracting out some helper functions along the way. > > Yup, emac and sungem predate phylib. > > I had a quick look at what it would take to port at least emac over, the > main issue was that I want to be able to sleep (ie, take a mutex) in my > mdio read/write functions, and back then, phylib wouldn't let me do that > due to spinlock and timer/softirq usage. Ok, I've made some progress in the port, but right now I'm trying to puzzle out what the "gpcs" bits in the code are. From the few publicly available docs and some mailing list posts, the gpcs address appears to be some kind of integrated virtual PHY used when 460GT-ish chips are communicating via an SGMII bus. My current plan of action is to separate the "gpcs" out into a separate PHY device controlled by the emac code. I'm also curious about the intent of the "mdio_instance" pointer (IE: the "mdio-device" property). Is that used when all the PHY devices are attached to the MDIO bus of only one of the (multiple) emac devices? Or is that for when two emac chipsets are connected to the same MDIO bus wire? (or both?) What keeps the emac_instance pointed to by the "mdio_instance" from going away while the other emac chipset is using it? In either case, I plan to have the device actually holding the MDIO bus run the mdiobus_alloc() and mdiobus_register() functions, then the other emac instance will simply take a reference to that MDIO bus (which would also pin down the emac instance that owns it). Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/