From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
Vincent Mailhol <mailhol@kernel.org>,
Peter Fink <pfink@christ-es.de>,
Eric Evenchick <eric@evenchick.com>,
Maximilian Schneider <max@schneidersoft.net>,
Wolfgang Grandegger <wg@grandegger.com>
Cc: kernel@pengutronix.de, linux-can@vger.kernel.org,
linux-kernel@vger.kernel.org,
Shuangpeng Bai <shuangpeng.kernel@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH can-next v5 6/6] can: gs_usb: fix hardware timestamp state for mixed channels
Date: Mon, 9 Nov 2026 12:40:14 +0000 [thread overview]
Message-ID: <b2c7d556-a6f2-4b3c-b141-49c3b558da87@linux.dev> (raw)
In-Reply-To: <20261108-gs_usb-fixes-v5-6-d52dd4940d46@pengutronix.de>
On 08/11/2026 20:47, Marc Kleine-Budde wrote:
> From: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>
> For hardware timestamping, the driver manages the
> infrastructure (cyclecounter/timecounter) for the entire USB interface,
> assuming that all channels share a common time base, even though each
> channel individually indicates support for hardware timestamping via the
> GS_CAN_FEATURE_HW_TIMESTAMP flag.
>
> Currently both initialization and shutdown of the HW timestamping
> infrastructure is tied to the flags of the first channel opened
> respectively closed. This leads to problems if the first channel opened
> doesn't have the timestamping feature, but the second channel has.
>
> Keep the initialization of the HW timestamping infrastructure in
> gs_usb_timestamp_init(), and move initial time init and the initial
> scheduling of the delayed worker into gs_usb_timestamp_start().
>
> Initialize the HW timestamping infrastructure in gs_usb_probe() using
> gs_usb_timestamp_init() if at least one channel has the
> GS_CAN_FEATURE_HW_TIMESTAMP flag set.
>
> Extend the functions gs_usb_timestamp_start()/gs_usb_timestamp_stop()
> to track the number of active timestamp channels. Enabling or disabling the
> delayed worker prevents concurrent rescheduling while
> gs_usb_timestamp_stop() is running.
>
> Call gs_usb_timestamp_start()/gs_usb_timestamp_stop() based on the
> channel's GS_CAN_FEATURE_HW_TIMESTAMP flag, rather than relying on the
> number of active channels.
>
> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
> Closes: https://sashiko.dev/#/bug/linux-b39360f9-6cd8-4f47-83bb-f0f78331f308
> Closes: https://sashiko.dev/#/bug/linux-5f8ecd4e-344e-4ceb-9b46-886f4942a5f6
> Fixes: 5886e4d5ecec ("can: gs_usb: fix time stamp counter initialization")
> Cc: stable@vger.kernel.org
> Cc: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
> Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> Signed-off-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
> Co-developed-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
> Changes in v4:
> - switch to enable_delayed_work()/disable_delayed_work_sync()
> - move starting from gs_usb_timestamp_init() into gs_usb_timestamp_start()
> - polish ref-counting/locking
> - Link to v3: https://patch.msgid.link/20260720184042.1712217-1-shuangpeng.kernel@gmail.com/
>
> Changes in v3:
> - Drop Suggested-by tag.
> - Move active_timestamp_channels management into the timestamp init/stop
> helpers.
> - Protect active_timestamp_channels with tc_lock, and keep it zero until
> timecounter_init() has completed.
> - Make RX timestamp conversion and the delayed work skip the timecounter
> while no timestamp-capable channel is active.
> - Initialize the shared timestamp lock and delayed work once during probe.
>
> Changes in v2:
> - Count active timestamp-capable channels instead of tracking only whether
> the shared timestamp worker has been started.
> - Stop the shared timestamp worker when the last timestamp-capable channel
> closes, even if non-timestamp channels remain open.
> - Unwind the timestamp-capable channel count on gs_can_open() failures.
>
> ---
>
> Picking up Shuangpeng Bai's work, I've ported it on top of other fixes for
> problems identified by sashiko.
>
> Marc
> ---
> drivers/net/can/usb/gs_usb.c | 54 +++++++++++++++++++++++++++++++-------------
> 1 file changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
> index 6327069f63c9..0a1cd14c940c 100644
> --- a/drivers/net/can/usb/gs_usb.c
> +++ b/drivers/net/can/usb/gs_usb.c
> @@ -337,6 +337,7 @@ struct gs_usb {
>
> unsigned int hf_size_rx;
> u8 active_channels;
> + u8 active_timestamp_channels;
> u8 channel_cnt;
>
> unsigned int pipe_in;
> @@ -481,18 +482,35 @@ static void gs_usb_timestamp_init(struct gs_usb *parent)
> cc->mult = clocksource_hz2mult(GS_USB_TIMESTAMP_TIMER_HZ, cc->shift);
>
> spin_lock_init(&parent->tc_lock);
> - spin_lock_bh(&parent->tc_lock);
> - timecounter_init(&parent->tc, &parent->cc, ktime_get_real_ns());
> - spin_unlock_bh(&parent->tc_lock);
>
> INIT_DELAYED_WORK(&parent->timestamp, gs_usb_timestamp_work);
> + disable_delayed_work(&parent->timestamp);
> +}
> +
> +static void gs_usb_timestamp_start(struct gs_usb *parent)
> +{
> + scoped_guard(spinlock_bh, &parent->tc_lock) {
> + parent->active_timestamp_channels++;
> + if (parent->active_timestamp_channels > 1)
> + return;
> +
> + timecounter_init(&parent->tc, &parent->cc, ktime_get_real_ns());
> + }
> +
> + enable_delayed_work(&parent->timestamp);
> schedule_delayed_work(&parent->timestamp,
> GS_USB_TIMESTAMP_WORK_DELAY_SEC * HZ);
> }
>
> static void gs_usb_timestamp_stop(struct gs_usb *parent)
> {
> - cancel_delayed_work_sync(&parent->timestamp);
> + scoped_guard(spinlock_bh, &parent->tc_lock) {
> + parent->active_timestamp_channels--;
> + if (parent->active_timestamp_channels > 0)
> + return;
> + }
> +
> + disable_delayed_work_sync(&parent->timestamp);
> }
That's quite defensive code. You have both disable/enable delayed_work
and active_timestamp_channels counter just to be sure to schedule
timestamp worker only once. Just wonder cannot we keep this worker
running regardless of channels?
next prev parent reply other threads:[~2026-11-09 12:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 20:47 [PATCH can-next v5 0/6] gs_usb: fixes Marc Kleine-Budde
2026-11-08 20:47 ` [PATCH can-next v5 1/6] can: gs_usb: gs_make_candev(): check can_rx_offload_add_manual() return value Marc Kleine-Budde
2026-11-08 20:47 ` [PATCH can-next v5 2/6] can: gs_usb: gs_can_start_xmit(): don't leak uninitialized memory over USB Marc Kleine-Budde
2026-11-08 20:47 ` [PATCH can-next v5 3/6] can: gs_usb: gs_usb_probe(): init netdev completely before register_candev() Marc Kleine-Budde
2026-11-08 20:47 ` [PATCH can-next v5 4/6] can: gs_usb: gs_usb_receive_bulk_callback(): check for overflow flag if SKB allocation fails Marc Kleine-Budde
2026-11-08 20:47 ` [PATCH can-next v5 5/6] can: gs_usb: gs_usb_receive_bulk_callback(): add missing call to can_rx_offload_irq_finish Marc Kleine-Budde
2026-11-08 20:47 ` [PATCH can-next v5 6/6] can: gs_usb: fix hardware timestamp state for mixed channels Marc Kleine-Budde
2026-11-08 21:06 ` sashiko-bot
2026-11-09 12:40 ` Vadim Fedorenko [this message]
2026-11-09 12:58 ` Marc Kleine-Budde
2026-11-10 9:52 ` netdev-bot+sashiko
2026-11-10 9:56 ` Marc Kleine-Budde
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=b2c7d556-a6f2-4b3c-b141-49c3b558da87@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=eric@evenchick.com \
--cc=kernel@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=max@schneidersoft.net \
--cc=mkl@pengutronix.de \
--cc=pfink@christ-es.de \
--cc=shuangpeng.kernel@gmail.com \
--cc=stable@vger.kernel.org \
--cc=wg@grandegger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.