linux-kernel - Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Feb 2011 11:27:31 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	Richard Cochran <richardcochran@...il.com>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Thomas Gleixner <tglx@...utronix.de>,
	Rodolfo Giometti <giometti@...ux.it>,
	Arnd Bergmann <arnd@...db.de>,
	Peter Zijlstra <peterz@...radead.org>,
	<linux-api@...r.kernel.org>, <devicetree-discuss@...ts.ozlabs.org>,
	<linux-kernel@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Paul Mackerras <paulus@...ba.org>,
	John Stultz <john.stultz@...aro.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, <netdev@...r.kernel.org>,
	Mike Frysinger <vapier@...too.org>,
	Christoph Lameter <cl@...ux.com>,
	<linuxppc-dev@...ts.ozlabs.org>,
	David Miller <davem@...emloft.net>,
	<linux-arm-kernel@...ts.infradead.org>,
	Krzysztof Halasa <khc@...waw.pl>
Subject: Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on
 the MPC85xx.

On Thu, 24 Feb 2011 17:50:04 +0100
Richard Cochran <richardcochran@...il.com> wrote:

> On Wed, Feb 23, 2011 at 01:24:44PM -0600, Scott Wood wrote:
> > Whatever string is used should be written into a binding document.
> > 
> > fsl,etsec-v1.6-ptp seems like it would be just as good for that purpose.
> > 
> > Even just fsl,etsec-ptp will identify the binding, though it's lacking in
> > identifying the hardware (in the absence of access to the eTSEC ID
> > registers).
> 
> I read the conversation, and I don't mind admitting that I do not
> understand what you both are arguing/discussing about.
> 
> How should I set the strings?  Like this?
> 
> arch/powerpc/boot/dts/mpc8313erdb.dts:
> 	ptp_clock@...00 {
> 		compatible = "fsl,mpc8313-etsec-ptp";
> 	}
> arch/powerpc/boot/dts/mpc8572ds.dts:
> 	ptp_clock@...00 {
> 		compatible = "fsl,mpc8572-etsec-ptp";
> 	} 
> arch/powerpc/boot/dts/p2020ds.dts:
> 	ptp_clock@...00 {
> 		compatible = "fsl,p2020ds-etsec-ptp";
> 	} 
> arch/powerpc/boot/dts/p2020rdb.dts:
> 	ptp_clock@...00 {
> 		compatible = "fsl,p2020rdb-etsec-ptp";
> 	} 
> 
> drivers/net/gianfar_ptp.c:
> 
> static struct of_device_id match_table[] = {
> 	{ .compatible = "fsl,mpc8313-etsec-ptp" },
> 	{ .compatible = "fsl,mpc8572-etsec-ptp" },
> 	{ .compatible = "fsl,p2020ds-etsec-ptp" },
> 	{ .compatible = "fsl,p2020rdb-etsec-ptp" },
> 	{},
> };

Those last two are boards, not chips.  I don't think even Grant is asking
to take things that far.

My vote, if it goes in a separate node at all, is "fsl,etsec-ptp", and let
the driver use SVR.  Even encoding an etsec version in the compatible
string would be difficult, unless fixed up by u-boot, as it appears to
differ based on chip revision (and the chip manuals seem to often not match
the hardware regarding the advertised eTSEC revision) and we don't normally
have separate dts files for different revisions of the same chip.  Plus,
our docs (at least the public ones) don't seem to be very helpful in
determining what version of eTSEC implies what.

If you want to use chip-based compatibles instead, then use the actual name
of the chip.  You'll need to verify 100% compatibility if you want to claim
compatibility with another chip; it's probably easier/safer to just list
every single Freescale chip that has this type of PTP in a huge compatible
table, like PCI drivers do.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/