Re: [PATCH v7 13/13] can: peak_usb: don't return an uninitialized PCAN-USB CAN channel ID

[Stéphane Grosjean]

On 01/11/2026 03:15, netdev-bot+sashiko@xxxxxxxxxx wrote:
[...]
> [Severity: Medium]
> Is the same ETHTOOL_GEEPROM disconnect window still open for the PCAN-USB
> Pro? It goes through the same peak_usb_get_eeprom() handler.
[...]
> Would passing an explicit 0 as the second argument to pcan_msg_add_rec()
> in pcan_usb_pro_get_can_channel_id() fix the Pro adapter? That could go
> in a separate follow-up patch.

Good catch, thanks. GETDEVID shares its case with SETDEVID in
pcan_msg_add_rec(), which reads a dev_num argument that
pcan_usb_pro_get_can_channel_id() never passes. v8 adds a patch that
passes 0.

> [Severity: Low]
> This isn't a bug introduced by this patch, but pcan_usb_wait_rsp() ignores
> actual_length from the CMDIN usb_bulk_msg(). It also doesn't check that
> cmd_buf[PCAN_USB_CMD_FUNC] and cmd_buf[PCAN_USB_CMD_NUM] match the
> request:

Right, pre-existing. I'll leave it for a later hardening series, since
this one is already long enough.

> [Severity: Medium]
> This is a pre-existing issue, but two setters in this file have the same
> uninitialized args[] problem on the transmit side.
[...]
> Could these two args[] arrays get the same {} initializer?

Yes, v8 adds a patch for this too.

Thanks!

Stéphane

pw-bot: cr