From: <Arun.Ramadoss@microchip.com>
To: <olteanv@gmail.com>
Cc: <andrew@lunn.ch>, <linux-kernel@vger.kernel.org>,
<UNGLinuxDriver@microchip.com>, <vivien.didelot@gmail.com>,
<linux@armlinux.org.uk>, <ceggers@arri.de>,
<Tristram.Ha@microchip.com>, <f.fainelli@gmail.com>,
<kuba@kernel.org>, <edumazet@google.com>, <pabeni@redhat.com>,
<richardcochran@gmail.com>, <netdev@vger.kernel.org>,
<Woojung.Huh@microchip.com>, <davem@davemloft.net>
Subject: Re: [Patch net-next v1 01/12] net: dsa: microchip: ptp: add the posix clock support
Date: Thu, 1 Dec 2022 10:01:48 +0000 [thread overview]
Message-ID: <a3bb90c4780d491a7194bbf9cea775be5011c45e.camel@microchip.com> (raw)
In-Reply-To: <20221201001746.ha72fty32s6ckvu6@skbuf>
Hi Vladimir,
On Thu, 2022-12-01 at 02:17 +0200, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> On Mon, Nov 28, 2022 at 04:02:16PM +0530, Arun Ramadoss wrote:
> > From: Christian Eggers <ceggers@arri.de>
> >
> > This patch implement routines (adjfine, adjtime, gettime and
> > settime)
> > for manipulating the chip's PTP clock. It registers the ptp caps
> > to posix clock register.
> >
> > Signed-off-by: Christian Eggers <ceggers@arri.de>
> > Co-developed-by: Arun Ramadoss <arun.ramadoss@microchip.com>
> > Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
> >
> > ---
> > RFC v2 -> Patch v1
> > - Repharsed the Kconfig help text
> > - Removed IS_ERR_OR_NULL check in ptp_clock_unregister
> > - Add the check for ptp_data->clock in ksz_ptp_ts_info
> > - Renamed MAX_DRIFT_CORR to KSZ_MAX_DRIFT_CORR
> > - Removed the comments
> > - Variables declaration in reverse christmas tree
> > - Added the ptp_clock_optional
> > ---
> > diff --git a/drivers/net/dsa/microchip/ksz_common.h
> > b/drivers/net/dsa/microchip/ksz_common.h
> > index c6726cbd5465..5a6bfd42c6f9 100644
> > --- a/drivers/net/dsa/microchip/ksz_common.h
> > +++ b/drivers/net/dsa/microchip/ksz_common.h
> > @@ -444,6 +447,19 @@ static inline int ksz_write32(struct
> > ksz_device *dev, u32 reg, u32 value)
> > return ret;
> > }
> >
> > +static inline int ksz_rmw16(struct ksz_device *dev, u32 reg, u16
> > mask,
> > + u16 value)
> > +{
> > + int ret;
> > +
> > + ret = regmap_update_bits(dev->regmap[1], reg, mask, value);
> > + if (ret)
> > + dev_err(dev->dev, "can't rmw 16bit reg: 0x%x %pe\n",
> > reg,
> > + ERR_PTR(ret));
>
> Is the colon misplaced? What do you want to say, "can't rmw 16bit
> reg: 0x0 -EIO",
> or "can't rmw 16bit reg 0x0: -EIO"?
>
> Reminds me of a joke:
> "The inventor of the Oxford comma has died. Tributes have been led by
> J.K. Rowling, his wife and the Queen of England".
Its a copy paste problem. I reused the exisiting inline functions based
on patch *net: dsa: microchip: add support for regmap_access_tables*.
I will move the semicolon after 0x%x:
>
> > +
> > + return ret;
> > +}
> > +
> > static inline int ksz_write64(struct ksz_device *dev, u32 reg, u64
> > value)
> > {
> > u32 val[2];
> > +static int ksz_ptp_settime(struct ptp_clock_info *ptp,
> > + const struct timespec64 *ts)
> > +{
> > + struct ksz_ptp_data *ptp_data = ptp_caps_to_data(ptp);
> > + struct ksz_device *dev = ptp_data_to_ksz_dev(ptp_data);
> > + int ret;
> > +
> > + mutex_lock(&ptp_data->lock);
> > +
> > + /* Write to shadow registers and Load PTP clock */
> > + ret = ksz_write16(dev, REG_PTP_RTC_SUB_NANOSEC__2,
> > PTP_RTC_0NS);
> > + if (ret)
> > + goto error_return;
> > +
> > + ret = ksz_write32(dev, REG_PTP_RTC_NANOSEC, ts->tv_nsec);
> > + if (ret)
> > + goto error_return;
> > +
> + ret = ksz_write32(dev, REG_PTP_RTC_SEC, ts->tv_sec);
> > + if (ret)
> > + goto error_return;
> > +
> > + ret = ksz_rmw16(dev, REG_PTP_CLK_CTRL, PTP_LOAD_TIME,
> > PTP_LOAD_TIME);
> > +
> > +error_return:
>
> I would avoid naming labels with "error_", if the success code path
> is
> also going to run through the code they point to. "goto unlock"
> sounds
> about right.
Ok. I will rename the goto block.
>
> > + mutex_unlock(&ptp_data->lock);
> > +
> > + return ret;
> > +}
> > +
> > +static const struct ptp_clock_info ksz_ptp_caps = {
> > + .owner = THIS_MODULE,
> > + .name = "Microchip Clock",
> > + .max_adj = KSZ_MAX_DRIFT_CORR,
> > + .gettime64 = ksz_ptp_gettime,
> > + .settime64 = ksz_ptp_settime,
> > + .adjfine = ksz_ptp_adjfine,
> > + .adjtime = ksz_ptp_adjtime,
> > +};
>
> Is it a conscious decision to have this structure declared here in
> the
> .rodata section (I think that's where this goes?), when it will only
> be
> used as a blueprint for the implicit memcpy (struct assignment) in
> ksz_ptp_clock_register()?
To reduce number of line in the ksz_ptp_clock_register(), I moved the
structure intialization outside of function. Referred other dsa
implementation found this type in
drivers/net/dsa/ocelot/felix_vsc9959.c, just reused it.
I didn't thought of .rodata section and memcpy overhead.
I will move this initialization within ksz_ptp_clock_register.
>
> Just saying that it would be possible to initialize the fields in
> ptp_data->caps even without resorting to declaring one extra
> structure,
> which consumes space. I'll leave you alone if you ACK that you know
> your
> assignment below is a struct copy and not a pointer assignment.
>
> > +
> > +int ksz_ptp_clock_register(struct dsa_switch *ds)
> > +{
> > + struct ksz_device *dev = ds->priv;
> > + struct ksz_ptp_data *ptp_data;
> > + int ret;
> > +
> > + ptp_data = &dev->ptp_data;
> > + mutex_init(&ptp_data->lock);
> > +
> > + ptp_data->caps = ksz_ptp_caps;
> > +
> > + ret = ksz_ptp_start_clock(dev);
> > + if (ret)
> > + return ret;
> > +
> > + ptp_data->clock = ptp_clock_register(&ptp_data->caps, dev-
> > >dev);
> > + if (IS_ERR_OR_NULL(ptp_data->clock))
> > + return PTR_ERR(ptp_data->clock);
> > +
> > + ret = ksz_rmw16(dev, REG_PTP_MSG_CONF1, PTP_802_1AS,
> > PTP_802_1AS);
> > + if (ret)
> > + goto error_unregister_clock;
>
> Registering a structure with a subsystem generally means that it
> becomes
> immediately accessible to user space, and its (POSIX clock) ops are
> callable.
>
> You haven't explained what PTP_802_1AS does, concretely, even though
> I asked for a comment in the previous patch set.
I overlooked the comment in the previous patch set. Christian also gave
offline comment that, this bit is reserved in KSZ9563 datasheet.
This bit should be set whenever we operate in 802.1AS(gPTP).
When this bit, then all the PTP packets will be forwared to host port
and none to other ports.
After changing my patch to include 1 step timestamping, I think it
should be set only for LAN937x 2 step mode.
> Is it okay for the PTP
> clock to be registered while the PTP_802_1AS bit hasn't been yet
> written?
> The first few operations might take place with it still unset.
>
> I know what 802.1AS is, I just don't know what the register field
> does.
>
> > +
> > + return 0;
> > +
> > +error_unregister_clock:
> > + ptp_clock_unregister(ptp_data->clock);
> > + return ret;
> > +}
next prev parent reply other threads:[~2022-12-01 10:01 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 10:32 [Patch net-next v1 00/12] net: dsa: microchip: add PTP support for KSZ9563/KSZ8563 and LAN937x Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 01/12] net: dsa: microchip: ptp: add the posix clock support Arun Ramadoss
2022-11-28 14:49 ` Pavan Chebbi
2022-11-28 14:56 ` Christian Eggers
2022-11-30 23:05 ` Vladimir Oltean
2022-11-30 4:53 ` Arun.Ramadoss
2022-12-01 0:17 ` Vladimir Oltean
2022-12-01 10:01 ` Arun.Ramadoss [this message]
2022-11-28 10:32 ` [Patch net-next v1 02/12] net: dsa: microchip: ptp: Initial hardware time stamping support Arun Ramadoss
2022-11-29 8:49 ` Pavan Chebbi
2022-11-30 4:32 ` Arun.Ramadoss
2022-12-01 0:39 ` Vladimir Oltean
2022-12-01 10:17 ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 03/12] net: dsa: microchip: ptp: add 4 bytes in tail tag when ptp enabled Arun Ramadoss
2022-12-01 0:52 ` Vladimir Oltean
2022-12-01 10:56 ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 04/12] net: dsa: microchip: ptp: Manipulating absolute time using ptp hw clock Arun Ramadoss
2022-11-29 8:43 ` Pavan Chebbi
2022-11-30 4:22 ` Arun.Ramadoss
2022-11-30 6:11 ` Pavan Chebbi
2022-12-01 1:04 ` Vladimir Oltean
2022-12-02 9:40 ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 05/12] net: dsa: microchip: ptp: enable interrupt for timestamping Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 06/12] net: ptp: add helper for one-step P2P clocks Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 07/12] net: dsa: microchip: ptp: add packet reception timestamping Arun Ramadoss
2022-11-29 0:43 ` kernel test robot
2022-11-28 10:32 ` [Patch net-next v1 08/12] net: dsa: microchip: ptp: add packet transmission timestamping Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 09/12] net: dsa: microchip: ptp: move pdelay_rsp correction field to tail tag Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 10/12] net: dsa: microchip: ptp: add 2 step timestamping for LAN937x Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 11/12] net: dsa: microchip: ptp: add periodic output signal Arun Ramadoss
2022-11-29 8:53 ` Pavan Chebbi
2022-11-29 9:57 ` Pavan Chebbi
2022-11-30 4:48 ` Arun.Ramadoss
2022-11-30 4:41 ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 12/12] net: dsa: microchip: ptp: add support for perout programmable pins Arun Ramadoss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3bb90c4780d491a7194bbf9cea775be5011c45e.camel@microchip.com \
--to=arun.ramadoss@microchip.com \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=andrew@lunn.ch \
--cc=ceggers@arri.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).