[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <25a83e83-46d1-4a16-9383-6d492cb37c7a@intel.com>
Date: Thu, 11 Dec 2025 14:06:27 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>, Mina Almasry
<almasrymina@...gle.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
<przemyslaw.kitszel@...el.com>, Andrew Lunn <andrew+netdev@...n.ch>, "David
S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, "Jakub
Kicinski" <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Richard Cochran
<richardcochran@...il.com>, "Rizzo, Luigi" <lrizzo@...gle.com>,
"namangulati@...gle.com" <namangulati@...gle.com>, "willemb@...gle.com"
<willemb@...gle.com>, "intel-wired-lan@...ts.osuosl.org"
<intel-wired-lan@...ts.osuosl.org>, "Olech, Milena" <milena.olech@...el.com>,
Shachar Raindel <shacharr@...gle.com>
Subject: Re: [Intel-wired-lan] [PATCH net v1] idpf: read lower clock bits
inside the time sandwich
On 12/11/2025 2:37 AM, Loktionov, Aleksandr wrote:
>
>
>> -----Original Message-----
>> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf
>> Of Mina Almasry
>> Sent: Thursday, December 11, 2025 11:19 AM
>> To: netdev@...r.kernel.org; linux-kernel@...r.kernel.org
>> Cc: Mina Almasry <almasrymina@...gle.com>; Nguyen, Anthony L
>> <anthony.l.nguyen@...el.com>; Kitszel, Przemyslaw
>> <przemyslaw.kitszel@...el.com>; Andrew Lunn <andrew+netdev@...n.ch>;
>> David S. Miller <davem@...emloft.net>; Eric Dumazet
>> <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>; Paolo Abeni
>> <pabeni@...hat.com>; Richard Cochran <richardcochran@...il.com>;
>> Rizzo, Luigi <lrizzo@...gle.com>; namangulati@...gle.com;
>> willemb@...gle.com; intel-wired-lan@...ts.osuosl.org; Olech, Milena
>> <milena.olech@...el.com>; Keller, Jacob E <jacob.e.keller@...el.com>;
>> Shachar Raindel <shacharr@...gle.com>
>> Subject: [Intel-wired-lan] [PATCH net v1] idpf: read lower clock bits
>> inside the time sandwich
>>
>> PCIe reads need to be done inside the time sandwich because PCIe
>> writes may get buffered in the PCIe fabric and posted to the device
>> after the _postts completes. Doing the PCIe read inside the time
>> sandwich guarantees that the write gets flushed before the _postts
>> timestamp is taken.
>>
>> Cc: lrizzo@...gle.com
>> Cc: namangulati@...gle.com
>> Cc: willemb@...gle.com
>> Cc: intel-wired-lan@...ts.osuosl.org
>> Cc: milena.olech@...el.com
>> Cc: jacob.e.keller@...el.com
>>
>> Fixes: 5cb8805d2366 ("idpf: negotiate PTP capabilities and get PTP
>> clock")
>> Suggested-by: Shachar Raindel <shacharr@...gle.com>
>> Signed-off-by: Mina Almasry <almasrymina@...gle.com>
>> ---
>> drivers/net/ethernet/intel/idpf/idpf_ptp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
>> b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
>> index 3e1052d070cf..0a8b50350b86 100644
>> --- a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
>> +++ b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
>> @@ -108,11 +108,11 @@ static u64
>> idpf_ptp_read_src_clk_reg_direct(struct idpf_adapter *adapter,
>> ptp_read_system_prets(sts);
>>
>> idpf_ptp_enable_shtime(adapter);
>> + lo = readl(ptp->dev_clk_regs.dev_clk_ns_l);
> The high 32 bits (hi) are still read outside the time sandwich (after ptp_read_system_postts()),
> which defeats the stated purpose of ensuring PCIe write flush before timestamp capture.
> /* I think he "time sandwich" is defined by the region between ptp_read_system_prets(sts) and ptp_read_system_postts(sts) */ Isn't it?
>
>
Any read will cause writes to flush, so we don't need to move both
registers.
The point here is that we write to the shadow register to snapshot time,
and it won't guarantee to be flushed to the device until a read. By
moving a single read in side the time sandwhich, we ensure that its
actually complete before the time snapshot is taken. We don't need to
wait for both registers because of the snapshot behavior.
I think the patch is fine-as-is.
Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
Thanks,
Jake
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists