netdev - Re: [PATCH net-next 1/3] ptp: Allow reassigning calibration pin function

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] [day] [month] [year] [list]

Date:	Thu, 26 Jun 2014 16:57:20 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	Christian Riesch <christian.riesch@...cron.at>
Cc:	Stefan Sørensen 
	<stefan.sorensen@...ctralink.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] ptp: Allow reassigning calibration pin
 function

On Thu, Jun 26, 2014 at 08:14:58AM +0200, Christian Riesch wrote:
> On Thu, Jun 26, 2014 at 7:21 AM, Richard Cochran <richardcochran@...il.com> wrote:
> > Reassigning the calibration function never makes sense, because it is
> > only used in the driver probe method.
> 
> Yes, indeed, but isn't that a bug? I think the calibration should be
> done again whenever the clock is loaded with a new value, i.e. in
> ptp_dp83640_settime. See section 3.1 in [1]: "All subsequent settings
> should use a step
> adjustment or temporary rate adjustment, which should occur at each
> PHY without introducing any error." This means, whenever we do
> something else (directly write to the clock register), we must
> recalibrate.

When we write the time, we use the broadcast address, and so the PHYs
receive the data at exactly the same time on the MDIO bus. But maybe
they would still need a new, fine calibration. Can you test this?

(I don't have a board with two phys.)

Thanks,
Richard
--
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