From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTP id DE3DEDDEE0 for ; Tue, 17 Apr 2007 01:47:31 +1000 (EST) In-Reply-To: References: <20070413012542.343eb848.kim.phillips@freescale.com> <95a9680c565aa196a4ef78964ef9dee1@kernel.crashing.org> <20070416102533.0f87396f.kim.phillips@freescale.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Segher Boessenkool Subject: Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties Date: Mon, 16 Apr 2007 17:47:18 +0200 To: Kumar Gala Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>>> Since ucc_geth is being migrated to use the phylib, the existing >>>> (undocumented) 'interface' property is being deprecated in favour >>>> of unconjoined variations 'max-speed' and 'interface-type'. >>> >>> Again, please explain why this information shouldn't >>> be in the PHY node instead? >>> >> >> Strictly speaking, it should be neither in the UCC node nor the PHY >> node, as it describes the connection between the two, but.. Connections are never described with separate nodes in the device tree. >> the UCC driver utilizes the data itself; the UCC, unlike other network >> controllers, does not provide interface data in its programming model. I have no idea what this means? >> the phy drivers are not of_ drivers. Porting phylib drivers to be of_ >> drivers would break phylib for non-OF arches, e.g. x86. > > Nothing stops the code in the UCC driver from grabbing the phy device > node and pulling the information out if it. Quite so. This isn't "bad style" either, it is a perfectly normal thing to do. > I believe the question is about where the information should truly > live. Yeah. > It would seem to be more of a property of the phy than of the enet > controller. Yep. The whole reason why any property is wanted here is to say what type the PHY is, as the enet controller can be attached to several kinds. And what type the PHY is belongs in the PHY node, obviously. In its "compatible" property to be exact. Segher