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]
Message-ID: <20110224112731.2d9bf080@schlenkerla>
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ