[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250610182545.0b69a06d@kernel.org>
Date: Tue, 10 Jun 2025 18:25:45 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Harshitha Ramamurthy <hramamurthy@...gle.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, jeroendb@...gle.com, andrew+netdev@...n.ch,
willemb@...gle.com, ziweixiao@...gle.com, pkaligineedi@...gle.com,
yyd@...gle.com, joshwash@...gle.com, shailend@...gle.com,
linux@...blig.org, thostet@...gle.com, jfraker@...gle.com,
richardcochran@...il.com, jdamato@...tly.com, vadim.fedorenko@...ux.dev,
horms@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v4 5/8] gve: Add support to query the nic clock
On Mon, 9 Jun 2025 18:40:26 +0000 Harshitha Ramamurthy wrote:
> + priv->nic_ts_report =
> + dma_alloc_coherent(&priv->pdev->dev,
> + sizeof(struct gve_nic_ts_report),
> + &priv->nic_ts_report_bus,
> + GFP_KERNEL);
> + if (!priv->nic_ts_report) {
> + dev_err(&priv->pdev->dev, "%s dma alloc error\n", __func__);
> + err = -ENOMEM;
> + goto release_ptp;
> + }
> +
> + ptp_schedule_worker(priv->ptp->clock, 0);
Given the "very dynamic nature" of the clock I think you need to do the
first refresh synchronously. Otherwise the config path may exit, and
the first packet arrive before the worker had a chance to run and latch
the initial timestamp?
--
pw-bot: cr
Powered by blists - more mailing lists