[PATCH 1/1] net: fec: ptp: avoid register access when ipg clock is disabled

When accessing the timecounter register on an i.MX8MQ the kernel hangs.
This is only the case when the interface is down. This can be reproduced
by reading with 'phc_ctrl eth0 get'.

Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900
the igp clock is disabled when the interface is down and leads to a
system hang.

So we check if the ptp clock status before reading the timecounter
register.

Signed-off-by: Heiko Thiery <redacted>
---
 drivers/net/ethernet/freescale/fec_ptp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
index 2e344aada4c6..c9882083da02 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c

@@ -377,6 +377,9 @@ static int fec_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
 	u64 ns;
 	unsigned long flags;
 
+	/* Check the ptp clock */
+	if (!adapter->ptp_clk_on)
+		return -EINVAL;
 	spin_lock_irqsave(&adapter->tmreg_lock, flags);
 	ns = timecounter_read(&adapter->tc);
 	spin_unlock_irqrestore(&adapter->tmreg_lock, flags);

-- 
2.30.0

On Sat, 20 Feb 2021 07:56:55 +0100 Heiko Thiery wrote:

When accessing the timecounter register on an i.MX8MQ the kernel hangs.
This is only the case when the interface is down. This can be reproduced
by reading with 'phc_ctrl eth0 get'.

Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900
the igp clock is disabled when the interface is down and leads to a
system hang.

So we check if the ptp clock status before reading the timecounter
register.

Signed-off-by: Heiko Thiery <redacted>

Please widen the CC list, you should CC Richard on PTP patches.

Comment is rather redundant. Drop it or say _when_ ptp_clk_on may not
be true.

+	if (!adapter->ptp_clk_on)
+		return -EINVAL;

Why is the PTP interface registered when it can't be accessed?

Perhaps the driver should unregister the PTP clock when it's brought
down?

 	spin_lock_irqsave(&adapter->tmreg_lock, flags);
 	ns = timecounter_read(&adapter->tc);
 	spin_unlock_irqrestore(&adapter->tmreg_lock, flags);

HI Jakub,

Am Di., 23. Feb. 2021 um 04:00 Uhr schrieb Jakub Kicinski [off-list ref]:

On Sat, 20 Feb 2021 07:56:55 +0100 Heiko Thiery wrote:

quoted

When accessing the timecounter register on an i.MX8MQ the kernel hangs.
This is only the case when the interface is down. This can be reproduced
by reading with 'phc_ctrl eth0 get'.

Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900
the igp clock is disabled when the interface is down and leads to a
system hang.

So we check if the ptp clock status before reading the timecounter
register.

Signed-off-by: Heiko Thiery <redacted>

Please widen the CC list, you should CC Richard on PTP patches.

quoted

diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
index 2e344aada4c6..c9882083da02 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c

@@ -377,6 +377,9 @@ static int fec_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
      u64 ns;
      unsigned long flags;

+     /* Check the ptp clock */

Comment is rather redundant. Drop it or say _when_ ptp_clk_on may not
be true.

I just used the same comment as the one in the fec_ptp_settime() function.

quoted

+     if (!adapter->ptp_clk_on)
+             return -EINVAL;

Why is the PTP interface registered when it can't be accessed?

Perhaps the driver should unregister the PTP clock when it's brought
down?

Good question, but I do not know what happens e.g. with linuxptp when
the device that was opened before will be gone.

Maybe Richard can give a hint.

quoted

      spin_lock_irqsave(&adapter->tmreg_lock, flags);
      ns = timecounter_read(&adapter->tc);
      spin_unlock_irqrestore(&adapter->tmreg_lock, flags);

-- 
Heiko

On Tue, Feb 23, 2021 at 09:00:32AM +0100, Heiko Thiery wrote:

HI Jakub,

Am Di., 23. Feb. 2021 um 04:00 Uhr schrieb Jakub Kicinski [off-list ref]:

quoted

Why is the PTP interface registered when it can't be accessed?

Perhaps the driver should unregister the PTP clock when it's brought
down?

I don't see any reason why a clock should stop ticking just because
the interface is down.  This is a poor driver design, but sadly it
gets copied and even defended.

Good question, but I do not know what happens e.g. with linuxptp when
the device that was opened before will be gone.

If a network interface goes down, ptp4l will notice via rtnl and close
the interface.  Then it re-opens the sockets on rtnl up.  However, the
file descriptor representing the dynamic posix clock stays opened.

Thanks,
Richard

Hi Richard,

Am Di., 23. Feb. 2021 um 15:27 Uhr schrieb Richard Cochran
[off-list ref]:

On Tue, Feb 23, 2021 at 09:00:32AM +0100, Heiko Thiery wrote:

quoted

HI Jakub,

Am Di., 23. Feb. 2021 um 04:00 Uhr schrieb Jakub Kicinski [off-list ref]:

quoted

Why is the PTP interface registered when it can't be accessed?

Perhaps the driver should unregister the PTP clock when it's brought
down?

I don't see any reason why a clock should stop ticking just because
the interface is down.  This is a poor driver design, but sadly it
gets copied and even defended.

It is not only the PHC clock that stops. Rather, it is the entire
ethernet building block in the SOC that is disabled, including the
PHC.

quoted

Good question, but I do not know what happens e.g. with linuxptp when
the device that was opened before will be gone.

If a network interface goes down, ptp4l will notice via rtnl and close
the interface.  Then it re-opens the sockets on rtnl up.  However, the
file descriptor representing the dynamic posix clock stays opened.

Thanks,

-- 
Heiko

On Tue, Feb 23, 2021 at 04:04:16PM +0100, Heiko Thiery wrote:

It is not only the PHC clock that stops. Rather, it is the entire
ethernet building block in the SOC that is disabled, including the
PHC.

Sure, but why does the driver do that?

Thanks,
Richard

Hi Richard,

Am Di., 23. Feb. 2021 um 17:11 Uhr schrieb Richard Cochran
[off-list ref]:

On Tue, Feb 23, 2021 at 04:04:16PM +0100, Heiko Thiery wrote:

quoted

It is not only the PHC clock that stops. Rather, it is the entire
ethernet building block in the SOC that is disabled, including the
PHC.

Sure, but why does the driver do that?

That is a good question. I tried to understand the clock
infrastructure of the imx8 but it looks quite complicated. I cannot
find the point where all the stuff is disabled.

-- 
Heiko

Hi Richard,

Am Do., 25. Feb. 2021 um 14:49 Uhr schrieb Heiko Thiery
[off-list ref]:

Hi Richard,

Am Di., 23. Feb. 2021 um 17:11 Uhr schrieb Richard Cochran
[off-list ref]:

quoted

On Tue, Feb 23, 2021 at 04:04:16PM +0100, Heiko Thiery wrote:

quoted

It is not only the PHC clock that stops. Rather, it is the entire
ethernet building block in the SOC that is disabled, including the
PHC.

Sure, but why does the driver do that?

That is a good question. I tried to understand the clock
infrastructure of the imx8 but it looks quite complicated. I cannot
find the point where all the stuff is disabled.

But the explanation why it is currently disabled that way can be found
in the commit 91c0d987a9788dcc5fe26baafd73bf9242b68900.

-- 
Heiko

On Thu, Feb 25, 2021 at 03:05:32PM +0100, Heiko Thiery wrote:

But the explanation why it is currently disabled that way can be found
in the commit 91c0d987a9788dcc5fe26baafd73bf9242b68900.

Okay, without re-factoring the entire driver, I agree that the gettime
lock up aught to be fixed in a similar way.  I missed the original
patch, but the diff fragment in this thread doesn't appear to take the
mutex as it should.

Thanks,
Richard