[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5639053.DvuYhMxLoT@n95hx1g2>
Date: Mon, 28 Nov 2022 15:56:30 +0100
From: Christian Eggers <ceggers@...i.de>
To: Arun Ramadoss <arun.ramadoss@...rochip.com>,
Pavan Chebbi <pavan.chebbi@...adcom.com>
CC: <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<woojung.huh@...rochip.com>, <UNGLinuxDriver@...rochip.com>,
<andrew@...n.ch>, <vivien.didelot@...il.com>,
<f.fainelli@...il.com>, <olteanv@...il.com>, <davem@...emloft.net>,
<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
<linux@...linux.org.uk>, <Tristram.Ha@...rochip.com>,
<richardcochran@...il.com>
Subject: Re: [Patch net-next v1 01/12] net: dsa: microchip: ptp: add the posix clock support
On Monday, 28 November 2022, 15:49:33 CET, Pavan Chebbi wrote:
> On Mon, Nov 28, 2022 at 4:03 PM Arun Ramadoss
> <arun.ramadoss@...rochip.com> wrote:
>
> > diff --git a/drivers/net/dsa/microchip/ksz_ptp_reg.h b/drivers/net/dsa/microchip/ksz_ptp_reg.h
> > new file mode 100644
> > index 000000000000..e578a0006ecf
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/ksz_ptp_reg.h
> > @@ -0,0 +1,57 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Microchip KSZ PTP register definitions
> > + * Copyright (C) 2022 Microchip Technology Inc.
> > + */
> > +
> > +#ifndef __KSZ_PTP_REGS_H
> > +#define __KSZ_PTP_REGS_H
> > +
> > +/* 5 - PTP Clock */
> > +#define REG_PTP_CLK_CTRL 0x0500
> > +
> > +#define PTP_STEP_ADJ BIT(6)
> > +#define PTP_STEP_DIR BIT(5)
> > +#define PTP_READ_TIME BIT(4)
> > +#define PTP_LOAD_TIME BIT(3)
>
> PTP_WRITE_TIME sounds more intuitive than PTP_LOAD_TIME?
PTP_LOAD_TIME has been derived from the data sheet:
-------------8<--------------
PTP Clock Load
--------------
Setting this bit will cause the PTP clock to be loaded with the time value in
registers 0x0502 to 0x050B.
------------->8--------------
I would also prefer PTP_WRITE_TIME. But is it ok to deviate from data sheet?
> Also I see that all the #defines are introduced in this patch, some of
> which are used later. It is a good idea to introduce the #defines in
> the same patches where they are being used for the first time.
> I will be looking at the entire series but am responding to this now.
>
> > +#define PTP_CLK_ADJ_ENABLE BIT(2)
> > +#define PTP_CLK_ENABLE BIT(1)
> > +#define PTP_CLK_RESET BIT(0)
> > +
> > +#define REG_PTP_RTC_SUB_NANOSEC__2 0x0502
> > +
> > +#define PTP_RTC_SUB_NANOSEC_M 0x0007
> > +#define PTP_RTC_0NS 0x00
> > +
> > +#define REG_PTP_RTC_NANOSEC 0x0504
> > +#define REG_PTP_RTC_NANOSEC_H 0x0504
> > +#define REG_PTP_RTC_NANOSEC_L 0x0506
> > +
> > +#define REG_PTP_RTC_SEC 0x0508
> > +#define REG_PTP_RTC_SEC_H 0x0508
> > +#define REG_PTP_RTC_SEC_L 0x050A
> > +
> > +#define REG_PTP_SUBNANOSEC_RATE 0x050C
> > +#define REG_PTP_SUBNANOSEC_RATE_H 0x050C
> > +#define PTP_SUBNANOSEC_M 0x3FFFFFFF
> > +
> > +#define PTP_RATE_DIR BIT(31)
> > +#define PTP_TMP_RATE_ENABLE BIT(30)
> > +
> > +#define REG_PTP_SUBNANOSEC_RATE_L 0x050E
> > +
> > +#define REG_PTP_RATE_DURATION 0x0510
> > +#define REG_PTP_RATE_DURATION_H 0x0510
> > +#define REG_PTP_RATE_DURATION_L 0x0512
> > +
> > +#define REG_PTP_MSG_CONF1 0x0514
> > +
> > +#define PTP_802_1AS BIT(7)
> > +#define PTP_ENABLE BIT(6)
> > +#define PTP_ETH_ENABLE BIT(5)
> > +#define PTP_IPV4_UDP_ENABLE BIT(4)
> > +#define PTP_IPV6_UDP_ENABLE BIT(3)
> > +#define PTP_TC_P2P BIT(2)
> > +#define PTP_MASTER BIT(1)
> > +#define PTP_1STEP BIT(0)
> > +
> > +#endif
> > --
> > 2.36.1
> >
>
Powered by blists - more mailing lists