On Fri, Jul 01, 2016 at 08:30:56PM +0300, Ivan Oleynikov wrote:
> Actual devices are implemented in FPGA and can be present or not in the
> current
> firmware independent of each other. I want the the same from drivers: to know
> nothing about each other. Thus making user explicitly define (ptp4l -p) what
> ptp
> clock to use.
Ok, so we're talking about out of tree drivers. You are free to do
anything you want with your drivers, of course, but here is how
mainline drivers work...
If the PHC is present and connected to a network interface, then the
index of the PHC must appear in the ethtool info. There are a number
of ways you can make your separate drivers share that information,
like device tree for example.
If your drivers conform to this rule, then everything will "just
work":
(index >= 0) PHC present, ptp4l will automatically use the right one
and detect a misconfigured Boundary Clock setup.
(index == -1) No PHC is present, ptp4l only runs with the
"free_running 1" option.
> Looks like drivers return phc_index = -1 to specify that this netdevice
> doesn't
> have a phc.
Yes.
> Is there something that I can return to show that my netdevice knows
> nothing about its PHC and is ready to synchronize with whatever PTP clock user
> wants?
No.
> On the other hand if ptp4l supports only those netdevices that report their
> PHC
> device index, what is the purpose of flag -p?
The '-p' is a legacy interface to support kernels 3.0 to 3.4.
Thanks,
Richard
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
