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 04/12] net: dsa: microchip: ptp: Manipulating absolute time using ptp hw clock
Date: Fri, 2 Dec 2022 09:40:17 +0000 [thread overview]
Message-ID: <2d36cc5c34a995f680177a52e4659ad07a31ab8f.camel@microchip.com> (raw)
In-Reply-To: <20221201010457.ig6jtrp326xj6ux6@skbuf>
Hi Vladimir,
Thanks for the review comment.
On Thu, 2022-12-01 at 03:04 +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:19PM +0530, Arun Ramadoss wrote:
> > diff --git a/drivers/net/dsa/microchip/ksz_ptp.c
> > b/drivers/net/dsa/microchip/ksz_ptp.c
> > index 184aa57a8489..415522ef4ce9 100644
> > --- a/drivers/net/dsa/microchip/ksz_ptp.c
> > +++ b/drivers/net/dsa/microchip/ksz_ptp.c
> > @@ -200,6 +209,12 @@ static int ksz_ptp_settime(struct
> > ptp_clock_info *ptp,
> > goto error_return;
> >
> > ret = ksz_rmw16(dev, REG_PTP_CLK_CTRL, PTP_LOAD_TIME,
> > PTP_LOAD_TIME);
> > + if (ret)
> > + goto error_return;
> > +
> > + spin_lock_bh(&ptp_data->clock_lock);
>
> Why disable bottom halves? Where is the bottom half that this races
> with?
The interrupts are added in the following patches in the series. During
the deferred packet timestamping, partial timestamps are reconstructed
to absolute time using the ptp_data->clock_time in the bottom halves.
So we need this spin_lock_bh.
>
> > + ptp_data->clock_time = *ts;
> > + spin_unlock_bh(&ptp_data->clock_lock);
> >
> > error_return:
> > mutex_unlock(&ptp_data->lock);
> > }
> >
> > +/* Function is pointer to the do_aux_work in the ptp_clock
> > capability */
> > +static long ksz_ptp_do_aux_work(struct ptp_clock_info *ptp)
> > +{
> > + struct ksz_ptp_data *ptp_data = ptp_caps_to_data(ptp);
> > + struct ksz_device *dev = ptp_data_to_ksz_dev(ptp_data);
> > + struct timespec64 ts;
> > +
> > + mutex_lock(&ptp_data->lock);
> > + _ksz_ptp_gettime(dev, &ts);
> > + mutex_unlock(&ptp_data->lock);
>
> Why don't you call ksz_ptp_gettime(ptp, &ts) directly?
I will use ksz_ptp_gettime directly.
>
> > +
> > + spin_lock_bh(&ptp_data->clock_lock);
> > + ptp_data->clock_time = ts;
> > + spin_unlock_bh(&ptp_data->clock_lock);
> > +
> > + return HZ; /* reschedule in 1 second */
> > +}
> > +
> > static int ksz_ptp_start_clock(struct ksz_device *dev)
> > {
> > - return ksz_rmw16(dev, REG_PTP_CLK_CTRL, PTP_CLK_ENABLE,
> > PTP_CLK_ENABLE);
> > + struct ksz_ptp_data *ptp_data = &dev->ptp_data;
> > + int ret;
> > +
> > + ret = ksz_rmw16(dev, REG_PTP_CLK_CTRL, PTP_CLK_ENABLE,
> > PTP_CLK_ENABLE);
> > + if (ret)
> > + return ret;
> > +
> > + spin_lock_bh(&ptp_data->clock_lock);
> > + ptp_data->clock_time.tv_sec = 0;
> > + ptp_data->clock_time.tv_nsec = 0;
> > + spin_unlock_bh(&ptp_data->clock_lock);
>
> Does ksz_ptp_start_clock() race with anything? The PTP clock has not
> even been registered by the time this has been called. This is
> literally
> an example of the "spin_lock_init(); spin_lock();" antipattern.
Yes, this function is called before PTP clock registeration. I will
remove the spin_lock for here.
>
> > +
> > + return 0;
> > }
next prev parent reply other threads:[~2022-12-02 9:40 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
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 [this message]
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=2d36cc5c34a995f680177a52e4659ad07a31ab8f.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).