mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: s.grosjean@peak-system.fr
Cc: mkl@pengutronix.de, mailhol@kernel.org, wg@grandegger.com,
	error27@gmail.com, lukas.magel@posteo.net,
	linux-can@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, kuba@kernel.org
Subject: Re: [PATCH v6 03/13] can: peak_usb: sort ctrlmode_supported flags
Date: Sat, 24 Oct 2026 03:58:51 +0000	[thread overview]
Message-ID: <179281433115.3130.15136732593858786026@kernel.org> (raw)
In-Reply-To: <20261022-canfd_check_channel_idx-v6-3-197704231551@peak-system.fr>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message says the patch orders the CAN_CTRLMODE_* flags
  in ctrlmode_supported by numerical value.

--

can: peak_usb: sort ctrlmode_supported flags

This commit reorders the CAN_CTRLMODE_* flags in the static
ctrlmode_supported initializers of the peak_usb adapters so that they
follow their numerical values. It is described as a cosmetic change with
no behavior change.

> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb.c b/drivers/net/can/usb/peak_usb/pcan_usb.c
> index 785224e00c4e9..169c00d93463c 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
> @@ -1016,7 +1016,8 @@ const struct peak_usb_adapter pcan_usb = {
>  	.name = "PCAN-USB",
>  	.device_id = PCAN_USB_PRODUCT_ID,
>  	.ctrl_count = 1,
> -	.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES | CAN_CTRLMODE_LISTENONLY |
> +	.ctrlmode_supported = CAN_CTRLMODE_LISTENONLY |
> +			      CAN_CTRLMODE_3_SAMPLES |
>  			      CAN_CTRLMODE_CC_LEN8_DLC,

[Severity: Low]
This isn't a bug, but the runtime ctrlmode_supported update in
pcan_usb_init() in the same file was not reordered:

drivers/net/can/usb/peak_usb/pcan_usb.c:pcan_usb_init() {
    ...
	if (dev->device_rev >= 41) {
		struct can_priv *priv = netdev_priv(dev->netdev);

		priv->ctrlmode_supported |= CAN_CTRLMODE_ONE_SHOT |
					    CAN_CTRLMODE_LOOPBACK;
    ...
}

CAN_CTRLMODE_LOOPBACK is 0x01 and CAN_CTRLMODE_ONE_SHOT is 0x08, so by
the ordering described in the commit message LOOPBACK would come first.

The commit message says:

  "Order the CAN_CTRLMODE_* flags in ctrlmode_supported according to
  their numerical values."

It doesn't limit this to the static initializers. Should this line be
reordered too, for consistency? No later patch in the series appears to
change it.

As the commit message says, the resulting bitmask is identical either
way.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261022-canfd_check_channel_idx-v6-0-197704231551%40peak-system.fr

  reply	other threads:[~2026-10-24  3:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 14:27 [PATCH v6 00/13] can: peak_usb: fixes, cleanup and input validation hardening Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 01/13] can: peak_usb: fix missing CAN_ERR_FLAG when reporting error counters Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 02/13] can: peak_usb: add missing includes Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 03/13] can: peak_usb: sort ctrlmode_supported flags Stéphane Grosjean via B4 Relay
2026-10-24  3:58   ` netdev-bot+sashiko [this message]
2026-10-22 14:27 ` [PATCH v6 04/13] can: peak_usb: harden PCAN-USB message validation Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 05/13] can: peak_usb: replace open-coded bitmask operations with bitops Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 06/13] can: peak_usb: harden channel handling in PCAN-USB FD Stéphane Grosjean via B4 Relay
2026-10-24  3:58   ` netdev-bot+sashiko
2026-10-22 14:27 ` [PATCH v6 07/13] can: peak_usb: fix RX cursor desync for self-received RTR frames with SRR Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 08/13] can: peak_usb: reject records for unset channels in PCAN-USB Pro Stéphane Grosjean via B4 Relay
2026-10-24  3:58   ` netdev-bot+sashiko
2026-10-22 14:27 ` [PATCH v6 09/13] can: peak_usb: register the netdevs only once all channels are set up Stéphane Grosjean via B4 Relay
2026-10-24  3:58   ` netdev-bot+sashiko
2026-10-22 14:27 ` [PATCH v6 10/13] can: peak_usb: validate the data length of PCAN-USB Pro CAN records Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 11/13] can: peak_usb: don't read past the message in PCAN-USB Pro decoders Stéphane Grosjean via B4 Relay
2026-10-24  3:58   ` netdev-bot+sashiko
2026-10-22 14:27 ` [PATCH v6 12/13] can: peak_usb: dump undecodable URBs once and rate limit decode errors Stéphane Grosjean via B4 Relay
2026-10-22 14:27 ` [PATCH v6 13/13] can: peak_usb: don't return an uninitialized PCAN-USB CAN channel ID Stéphane Grosjean via B4 Relay

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=179281433115.3130.15136732593858786026@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=error27@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.magel@posteo.net \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=s.grosjean@peak-system.fr \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®