Hi Hubert, Richard,

On Tue, 30 Jul 2019 at 19:44, Richard Cochran [off-list ref] wrote:

On Tue, Jul 30, 2019 at 12:04:29PM +0200, Hubert Feurstein wrote:

quoted

diff --git a/drivers/net/dsa/mv88e6xxx/ptp.c b/drivers/net/dsa/mv88e6xxx/ptp.c
index 768d256f7c9f..51cdf4712517 100644
--- a/drivers/net/dsa/mv88e6xxx/ptp.c
+++ b/drivers/net/dsa/mv88e6xxx/ptp.c

@@ -15,11 +15,38 @@
 #include "hwtstamp.h"
 #include "ptp.h"

-/* Raw timestamps are in units of 8-ns clock periods. */
-#define CC_SHIFT     28
-#define CC_MULT              (8 << CC_SHIFT)
-#define CC_MULT_NUM  (1 << 9)
-#define CC_MULT_DEM  15625ULL
+/* The adjfine API clamps ppb between [-32,768,000, 32,768,000], and

That is not true.

I was referring to this:
https://github.com/richardcochran/linuxptp/blob/master/phc.c#L38

/*
* On 32 bit platforms, the PHC driver's maximum adjustment (type
* 'int' in units of ppb) can overflow the timex.freq field (type
* 'long'). So in this case we clamp the maximum to the largest
* possible adjustment that fits into a 32 bit long.
*/
#define BITS_PER_LONG (sizeof(long)*8)
#define MAX_PPB_32 32767999 /* 2^31 - 1 / 65.536 */

Technically it is not "not true".

[snip]

On Tue, 30 Jul 2019 at 21:09, Richard Cochran [off-list ref] wrote:

On Tue, Jul 30, 2019 at 06:20:00PM +0200, Hubert Feurstein wrote:

quoted

quoted

Please don't re-write this logic.  It is written like that for a reason.

I used the sja1105_ptp.c as a reference. So it is also wrong there.

I'll let that driver's author worry about that.

Thanks,
Richard

And what is the reason for the neg_adj thing? Can you give an example
of when does the "normal way" of doing signed arithmetics not work?

Thanks,
-Vladimir