[Linuxptp-devel] [PATCH] ptp4l: run on interfaces that don't report their phc_index through SIOCETHTOOL.

[Ivan Oleynikov]

Some network interfaces do not specify PTP clock id that provides interface to
their hardware clock. In this case the interface driver returns -1 in
`ethtool_ts_info` to SIOCETHTOOL. This commit makes linuxptp ignore it instead
of failing with error "PHC device mismatch".

Signed-off-by: Ivan Oleynikov <***@metrotek.spb.ru>
---
port.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/port.c b/port.c
index 161157c..29b2468 100644
--- a/port.c
+++ b/port.c
@@ -2550,7 +2550,8 @@ struct port *port_open(int phc_index,
; /* UDS cannot have a PHC. */
else if (!interface->ts_info.valid)
pr_warning("port %d: get_ts_info not supported", number);
- else if (phc_index >= 0 && phc_index != interface->ts_info.phc_index) {
+ else if (phc_index >= 0 && phc_index != interface->ts_info.phc_index &&
+ interface->ts_info.phc_index >= 0) {
if (p->jbod) {
pr_warning("port %d: just a bunch of devices", number);
p->phc_index = interface->ts_info.phc_index;

[Richard Cochran]

Post by Ivan Oleynikov
Some network interfaces do not specify PTP clock id that provides interface to
their hardware clock. In this case the interface driver returns -1 in
`ethtool_ts_info` to SIOCETHTOOL. This commit makes linuxptp ignore it instead
of failing with error "PHC device mismatch".

What drivers are incorrectly returning -1 in phc_index?

Instead of this workaround, let's get those fixed, please.

Thanks,
Richard

[Ivan Oleynikov]

Post by Richard Cochran

Post by Ivan Oleynikov
Some network interfaces do not specify PTP clock id that provides interface to
their hardware clock. In this case the interface driver returns -1 in
`ethtool_ts_info` to SIOCETHTOOL. This commit makes linuxptp ignore it instead
of failing with error "PHC device mismatch".

What drivers are incorrectly returning -1 in phc_index?

Doing

git clone https://github.com/trovalds/linux.git
cd linux
git grep '\->phc_index.*=.*-1' -- drivers/net/

gave me 13 matches. I've skimmed through a few of them, they usually return
phc_index = -1 when the netdev has no PHC associated with it. I guess this is
expected behaviour.

This is not my case. I'm working on two separate drivers: first one provides
netdev with SOF_TIMESTAMPING_{RX,TX}_HARDWARE support enabled, the second one
provides ptp clock.

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.

Post by Richard Cochran
Instead of this workaround, let's get those fixed, please.

Looks like drivers return phc_index = -1 to specify that this netdevice doesn't
have a phc. 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?

On the other hand if ptp4l supports only those netdevices that report their PHC
device index, what is the purpose of flag -p?

--
Ivan Oleynikov
STC Metrotek
St.Petersburg

[Richard Cochran]

Post by Ivan Oleynikov
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.

Post by Ivan Oleynikov
Looks like drivers return phc_index = -1 to specify that this netdevice doesn't
have a phc.

Yes.

Post by Ivan Oleynikov
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.

Post by Ivan Oleynikov
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