linux-kernel - Re: [PATCH net-next] net: ethernet: ti: am65-cpts: adjust estf following ptp changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1dddf2d3-ea82-732b-ffaa-7e59f8617a7b@kernel.org>
Date:   Tue, 21 Mar 2023 11:25:32 +0200
From:   Roger Quadros <rogerq@...nel.org>
To:     Siddharth Vadapalli <s-vadapalli@...com>, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        jacob.e.keller@...el.com, richardcochran@...il.com, leon@...nel.org
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, srk@...com
Subject: Re: [PATCH net-next] net: ethernet: ti: am65-cpts: adjust estf
 following ptp changes



On 21/03/2023 08:26, Siddharth Vadapalli wrote:
> From: Grygorii Strashko <grygorii.strashko@...com>
> 
> When the CPTS clock is synced/adjusted by running linuxptp (ptp4l/phc2sys),
> it will cause the TSN EST schedule to drift away over time. This is because
> the schedule is driven by the EstF periodic counter whose pulse length is
> defined in ref_clk cycles and it does not automatically sync to CPTS clock.
>    _______
>  _|
>   ^
>   expected cycle start time boundary
>    _______________
>  _|_|___|_|
>   ^
>   EstF drifted away -> direction
> 
> To fix it, the same PPM adjustment has to be applied to EstF as done to the
> PHC CPTS clock, in order to correct the TSN EST cycle length and keep them
> in sync.
> 
> Drifted cycle:
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230373377017
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230373877017
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230374377017
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230374877017
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230375377017
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230375877023
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230376377018
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230376877018
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230377377018
> 
> Stable cycle:
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863193375473
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863193875473
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863194375473
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863194875473
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863195375473
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863195875473
> AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863196375473
> 
> Signed-off-by: Grygorii Strashko <grygorii.strashko@...com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@...com>

Reviewed-by: Roger Quadros <rogerq@...nel.org>