mbox series

[net-next,v2,0/4] Add PTP support for CN10K silicon

Message ID 20220730115758.16787-1-naveenm@marvell.com (mailing list archive)
Headers show
Series Add PTP support for CN10K silicon | expand

Message

Naveen Mamindlapalli July 30, 2022, 11:57 a.m. UTC
This patchset adds PTP support for CN10K silicon, specifically
to workaround few hardware issues and to add 1-step mode.

Patchset overview:

Patch #1 returns correct ptp timestamp in nanoseconds captured
         when external timestamp event occurs.

Patch #2 adds 1-step mode support.

Patch #3 implements software workaround to generate PPS output properly.

Patch #4 provides a software workaround for the rollover register default
         value, which causes ptp to return the wrong timestamp.

v2 changes:
  no code changes, added PTP maintainer to CC list.

Hariprasad Kelam (1):
  octeontx2-pf: Add support for ptp 1-step mode on CN10K silicon

Naveen Mamindlapalli (3):
  octeontx2-af: return correct ptp timestamp for CN10K silicon
  octeontx2-af: Add PTP PPS Errata workaround on CN10K silicon
  octeontx2-af: Initialize PTP_SEC_ROLLOVER register properly

 drivers/net/ethernet/marvell/octeontx2/af/mbox.h   |   2 +
 drivers/net/ethernet/marvell/octeontx2/af/ptp.c    | 106 +++++++++++++++++++-
 drivers/net/ethernet/marvell/octeontx2/af/ptp.h    |   3 +
 drivers/net/ethernet/marvell/octeontx2/af/rpm.c    |  19 +++-
 drivers/net/ethernet/marvell/octeontx2/af/rpm.h    |   5 +
 .../net/ethernet/marvell/octeontx2/af/rvu_nix.c    |   8 +-
 .../net/ethernet/marvell/octeontx2/af/rvu_reg.h    |   1 +
 .../ethernet/marvell/octeontx2/nic/otx2_common.h   |  13 +++
 .../ethernet/marvell/octeontx2/nic/otx2_ethtool.c  |   8 +-
 .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c   |  11 +++
 .../net/ethernet/marvell/octeontx2/nic/otx2_ptp.c  | 103 ++++++++++++++-----
 .../ethernet/marvell/octeontx2/nic/otx2_struct.h   |  11 ++-
 .../net/ethernet/marvell/octeontx2/nic/otx2_txrx.c | 110 ++++++++++++++++++++-
 13 files changed, 359 insertions(+), 41 deletions(-)

Comments

Jakub Kicinski Aug. 2, 2022, 7:14 p.m. UTC | #1
On Sat, 30 Jul 2022 17:27:54 +0530 Naveen Mamindlapalli wrote:
> This patchset adds PTP support for CN10K silicon, specifically
> to workaround few hardware issues and to add 1-step mode.

Hi Richard, any thoughts on this one? We have to make a go/no-go
decision on it for 6.0.
Jakub Kicinski Aug. 3, 2022, 4:44 a.m. UTC | #2
On Tue, 2 Aug 2022 12:14:39 -0700 Jakub Kicinski wrote:
> On Sat, 30 Jul 2022 17:27:54 +0530 Naveen Mamindlapalli wrote:
> > This patchset adds PTP support for CN10K silicon, specifically
> > to workaround few hardware issues and to add 1-step mode.  
> 
> Hi Richard, any thoughts on this one? We have to make a go/no-go
> decision on it for 6.0.

Oh, well. These will have to wait until after the merge window then :(
Richard Cochran Aug. 4, 2022, 3:08 a.m. UTC | #3
On Tue, Aug 02, 2022 at 09:44:20PM -0700, Jakub Kicinski wrote:
> On Tue, 2 Aug 2022 12:14:39 -0700 Jakub Kicinski wrote:
> > On Sat, 30 Jul 2022 17:27:54 +0530 Naveen Mamindlapalli wrote:
> > > This patchset adds PTP support for CN10K silicon, specifically
> > > to workaround few hardware issues and to add 1-step mode.  
> > 
> > Hi Richard, any thoughts on this one? We have to make a go/no-go
> > decision on it for 6.0.
> 
> Oh, well. These will have to wait until after the merge window then :(

FWIW - I'm okay with any PTP patches that are about specific hardware
drivers.  When I can, I'll review them for proper use of the core
layer, locking, etc, but at the end of the day, only the people
holding the data sheet know how to talk to the hardware.

Patches that touch the core layer are another story.  These need
careful review by me and other.  (Obviously)

Thanks,
Richard
Jakub Kicinski Aug. 4, 2022, 4:06 p.m. UTC | #4
On Wed, 3 Aug 2022 20:08:50 -0700 Richard Cochran wrote:
> > Oh, well. These will have to wait until after the merge window then :(  
> 
> FWIW - I'm okay with any PTP patches that are about specific hardware
> drivers.  When I can, I'll review them for proper use of the core
> layer, locking, etc, but at the end of the day, only the people
> holding the data sheet know how to talk to the hardware.
> 
> Patches that touch the core layer are another story.  These need
> careful review by me and other.  (Obviously)

I was hoping you could cast an eye over the 1-step implementation here.
Giving the device a random time reference along the packet looks odd.
Unfortunately I don't have much (any?) experience with 1-step myself so
I can't trust my own judgment all that much.