From: Scott Wood <scottwood@freescale.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Mike Frysinger <vapier@gentoo.org>,
Christoph Lameter <cl@linux.com>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
Peter Zijlstra <peterz@infradead.org>,
linux-api@vger.kernel.org,
Richard Cochran <richardcochran@gmail.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
David Miller <davem@davemloft.net>,
Paul Mackerras <paulus@samba.org>,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Rodolfo Giometti <giometti@linux.it>,
devicetree-discuss@lists.ozlabs.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Krzysztof Halasa <khc@pm.waw.pl>
Subject: Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
Date: Wed, 23 Feb 2011 11:26:12 -0600 [thread overview]
Message-ID: <20110223112612.30071995@schlenkerla> (raw)
In-Reply-To: <20110223165058.GE14597@angua.secretlab.ca>
On Wed, 23 Feb 2011 09:50:58 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Feb 23, 2011 at 11:38:17AM +0100, Richard Cochran wrote:
> > +
> > +* Gianfar PTP clock nodes
> > +
> > +General Properties:
> > +
> > + - compatible Should be "fsl,etsec-ptp"
>
> Should specify an *exact* part; ie: "fsl,mpc8313-etsec-ptp" instead of
> trying to define a generic catchall. The reason is that the same
> marketing name can end up getting applied to a wide range of parts.
>
> Instead, choose one specific device to stand in as the 'common'
> implementation and get all parts with the same core to claim
> compatibility with it. ie: a p2020 might have:
>
> compatible = "fsl,mpc2020-etsec-ptp", "fsl,mpc8313-etsec-ptp";
eTSEC is versioned, that's more reliable than the chip name since chips
have revisions (rev 2.1 of mpc8313 has eTSEC 1.6, not sure about previous
revs of mpc8313). Logic blocks can be and have been uprevved between one
revision of a chip to the next. I think "fsl,mpc8313rev2.1-etsec-ptp"
would be taking things a bit too far (and there could be board-level bugs
too...).
If you really need to know the exact SoC you're on, look in SVR (which
will provide revision info as well). Isn't the device tree for things that
can't be probed?
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.
Insisting on an explicit chip also encourages people to claim compatibility
with that chip without ensuring that it really is fully compatible.
-Scott
next prev parent reply other threads:[~2011-02-23 17:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 10:37 [PATCH V11 0/4] ptp: IEEE 1588 hardware clock support Richard Cochran
2011-02-23 10:37 ` [PATCH V11 1/4] ptp: Added a brand new class driver for ptp clocks Richard Cochran
2011-02-23 10:38 ` [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx Richard Cochran
2011-02-23 16:50 ` Grant Likely
2011-02-23 17:26 ` Scott Wood [this message]
2011-02-23 17:54 ` Grant Likely
2011-02-23 19:24 ` Scott Wood
2011-02-24 16:50 ` Richard Cochran
2011-02-24 17:27 ` Scott Wood
2011-02-25 7:53 ` Richard Cochran
2011-03-17 19:21 ` Grant Likely
2011-02-24 16:39 ` Richard Cochran
2011-02-24 17:08 ` Scott Wood
2011-02-24 17:26 ` Richard Cochran
2011-02-23 10:38 ` [PATCH V11 3/4] ptp: Added a clock driver for the IXP46x Richard Cochran
2011-02-23 10:38 ` [PATCH V11 4/4] ptp: Added a clock driver for the National Semiconductor PHYTER Richard Cochran
2011-02-23 10:50 ` [PATCH V11 0/4] ptp: IEEE 1588 hardware clock support Richard Cochran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110223112612.30071995@schlenkerla \
--to=scottwood@freescale.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=giometti@linux.it \
--cc=grant.likely@secretlab.ca \
--cc=john.stultz@linaro.org \
--cc=khc@pm.waw.pl \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=richardcochran@gmail.com \
--cc=tglx@linutronix.de \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).