[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250818213104.34351-1-antoine@gagniere.dev>
Date: Mon, 18 Aug 2025 23:31:04 +0200
From: Antoine Gagniere <antoine@...niere.dev>
To: vadim.fedorenko@...ux.dev
Cc: antoine@...niere.dev,
jonathan.lemon@...il.com,
kuba@...nel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH] ptp: ocp: Fix PCI delay estimation
>> static void
>> ptp_ocp_estimate_pci_timing(struct ptp_ocp *bp)
>> {
>> - ktime_t start, end, delay = U64_MAX;
>> + ktime_t start, end;
>> + s64 delay_ns = U32_MAX; /* 4.29 seconds is high enough */
>> u32 ctrl;
>> int i;
>>
>> @@ -1568,15 +1569,16 @@ ptp_ocp_estimate_pci_timing(struct ptp_ocp *bp)
>>
>> iowrite32(ctrl, &bp->reg->ctrl);
>>
>> - start = ktime_get_raw_ns();
>> + start = ktime_get_raw();
>>
>> ctrl = ioread32(&bp->reg->ctrl);
>>
>> - end = ktime_get_raw_ns();
>> + end = ktime_get_raw();
>>
>> - delay = min(delay, end - start);
>> + delay_ns = min(delay_ns, ktime_to_ns(end - start));
>> }
>> - bp->ts_window_adjust = (delay >> 5) * 3;
>> + delay_ns = max(0, delay_ns);0
>
> I don't believe we can get a negative value from
> ktime_to_ns(end - start), and that means that delay_ns will always be
> positive and there is no need for the last max().
You are correct, ktime is monotonic, this was an excess of zeal
on my part.
> JFYI, for the next version could you please organize the commit message
> to fit into 80 chars per line and specify net tree as well as patch
> which you believe introduced the problem using Fixes tag.
>
> More details on formatting can be found at
> https://docs.kernel.org/process/submitting-patches.html#submittingpatches
Thanks for the link, I was looking for such documentation but somehow missed this page
Will attempt a v2 later this week
Powered by blists - more mailing lists