All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Marc Kleine-Budde" <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	"Vincent Mailhol" <mailhol@kernel.org>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>
Subject: Re: [PATCH can-next v7 5/6] can: gs_usb: fix hardware timestamp state for mixed channels
Date: Sat, 14 Nov 2026 15:31:01 +0000	[thread overview]
Message-ID: <sashiko-outbox-214713@kernel.org> (raw)
In-Reply-To: <20261114-gs_usb-fixes-v7-5-58b6341b1c08@pengutronix.de>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] can: gs_usb: invalid context-analysis lock annotations in
  timestamp helpers
--

commit ac918b2b251bb4e9c64c17ed5a99e1135d686016
Author: Shuangpeng Bai <shuangpeng.kernel@gmail.com>

can: gs_usb: fix hardware timestamp state for mixed channels

This commit initializes the hardware timestamping infrastructure during probe
whenever any channel supports GS_CAN_FEATURE_HW_TIMESTAMP, and starts or stops
it when the first or last channel is opened or closed.

> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
> index 980c4a748c946..b7780a23eff3b 100644
> --- a/drivers/net/can/usb/gs_usb.c
> +++ b/drivers/net/can/usb/gs_usb.c

[ ... ]

> @@ -405,6 +411,7 @@ static int gs_cmd_reset(struct gs_can *dev)
>  
>  static inline int gs_usb_get_timestamp(const struct gs_usb *parent,
>  				       u32 *timestamp_p)
> +	__must_not_hold(parent->tc_lock)
>  {
>  	__le32 timestamp;
>  	int rc;
> @@ -423,7 +430,16 @@ static inline int gs_usb_get_timestamp(const struct gs_usb *parent,
>  	return 0;
>  }
>  
> -static u64 gs_usb_timestamp_read(struct cyclecounter *cc) __must_hold(&dev->tc_lock)
> +static u64 gs_usb_timestamp_read_initial(struct cyclecounter *cc)
> +	__must_hold(&container_of(cc, struct gs_usb, cc)->tc_lock)
> +{
> +	const struct gs_usb *parent = container_of(cc, struct gs_usb, cc);
> +
> +	return parent->timestamp_initial;
> +}
> +
> +static u64 gs_usb_timestamp_read(struct cyclecounter *cc)
> +	__must_hold(&container_of(cc, struct gs_usb, cc)->tc_lock)

[Severity: Low]
Does building with CONFIG_WARN_CONTEXT_ANALYSIS_ALL=y fail on these lock
annotations?

When WARN_CONTEXT_ANALYSIS is enabled, __must_hold() expands to a Clang
requires_capability attribute on the function declarator at file scope, where
the statement expression inside container_of() is rejected as a compile error.
Calling lockdep_assert_held(&parent->tc_lock) inside the function body avoids
this, and gs_usb_get_timestamp() also needs a pointer
(__must_not_hold(&parent->tc_lock)) rather than passing parent->tc_lock by
value.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261114-gs_usb-fixes-v7-0-58b6341b1c08@pengutronix.de?part=5

  reply	other threads:[~2026-11-14 15:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 15:17 [PATCH can-next v7 0/6] gs_usb: fixes Marc Kleine-Budde
2026-11-14 15:17 ` [PATCH can-next v7 1/6] can: gs_usb: gs_make_candev(): check can_rx_offload_add_manual() return value Marc Kleine-Budde
2026-11-14 15:17 ` [PATCH can-next v7 2/6] can: gs_usb: gs_usb_probe(): init netdev completely before register_candev() Marc Kleine-Budde
2026-11-14 15:17 ` [PATCH can-next v7 3/6] can: gs_usb: gs_usb_receive_bulk_callback(): check for overflow flag if SKB allocation fails Marc Kleine-Budde
2026-11-14 15:17 ` [PATCH can-next v7 4/6] can: gs_usb: gs_usb_receive_bulk_callback(): add missing call to can_rx_offload_irq_finish Marc Kleine-Budde
2026-11-14 15:17 ` [PATCH can-next v7 5/6] can: gs_usb: fix hardware timestamp state for mixed channels Marc Kleine-Budde
2026-11-14 15:31   ` sashiko-bot [this message]
2026-11-14 15:17 ` [PATCH can-next v7 6/6] can: gs_usb: properly shut down timestamp worker 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=sashiko-outbox-214713@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=o.rempel@pengutronix.de \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=socketcan@hartkopp.net \
    /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.