Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756394Ab1BXQlv (ORCPT ); Thu, 24 Feb 2011 11:41:51 -0500 Received: from mail-fx0-f46.google.com ([209.85.161.46]:57069 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756349Ab1BXQls (ORCPT ); Thu, 24 Feb 2011 11:41:48 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=gtR3sYbuEHeqw/0bApVgIzBOMHGqRR4XKDTFAkS8q8UavNgBnitWf249G8FzHzi7g2 COdOUJGSE19g0qUOdWlENa+moUp4z39Ojy7IITcZND2Dk6GuSa3SP70JDG7jKaLccLSq xKELzviAWtVN8IL7w4MOMVhedu+0pR0aF7wU8= Date: Thu, 24 Feb 2011 17:39:44 +0100 From: Richard Cochran To: Grant Likely Cc: Scott Wood , Thomas Gleixner , Rodolfo Giometti , Arnd Bergmann , Peter Zijlstra , linux-api@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org, Russell King , Paul Mackerras , John Stultz , Alan Cox , netdev@vger.kernel.org, Mike Frysinger , Christoph Lameter , linuxppc-dev@lists.ozlabs.org, David Miller , linux-arm-kernel@lists.infradead.org, Krzysztof Halasa Subject: Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx. Message-ID: <20110224163944.GA15234@riccoc20.at.omicron.at> References: <20110223165058.GE14597@angua.secretlab.ca> <20110223112612.30071995@schlenkerla> <20110223175459.GH14597@angua.secretlab.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110223175459.GH14597@angua.secretlab.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1415 Lines: 35 On Wed, Feb 23, 2011 at 10:54:59AM -0700, Grant Likely wrote: > On Wed, Feb 23, 2011 at 11:26:12AM -0600, Scott Wood wrote: > > The eTSEC revision is probeable as well, but due the way PTP is described as > > a separate node, the driver doesn't have straightforward access to those > > registers. > > Ignorant question: Should the ptp be described as a separate node? Well, the PTP Hardware Clock function is logically separate from the MAC function. PHCs can be implemented in the MAC, in the PHY, or in between in an FPGA on MII bus. If the PHC is in the MAC, then it might be wise to implement one driver that offers both the MAC and the PHC. In the case of gianfar, it is not really necessary to combine the PHC into the gianfar driver, since the registers are pretty well separated. Also, given the size and complexity (and churn over time) of the gianfar driver, I decided to keep the PHC separate. Right now, the driver correctly handles all the clock revisions in the boards that I have (mpc8313, mpc8572, p2020ds, p2020rdb). If checking the revision becomes important, then we can always export a function from gianfar to provide this. Thanks, Richard -- 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/