Re: [PATCH net 0/16] pull-request: can 2026-09-29

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 01.10.26 12:13, Paolo Abeni wrote:
> On 10/1/26 11:23, Oliver Hartkopp wrote:
>> On 01.10.26 10:40, Paolo Abeni wrote:
>>> On 9/29/26 22:43, Marc Kleine-Budde wrote:
>>>> this is a pull request of 16 patches for net/main.
>>>>
>>>> The first patch is by Vincent Mailhol and drops CAN-XL frames on non
>>>> CAN-XL devices.
>>>>
>>>> A patch by zjamg restores the skb header initialization lost during
>>>> the v7.0 release cycle.
>>>>
>>>> Oliver Hartkopp contributes 3 patches for the CAN net layer, the first
>>>> one fixes the net namespace integration for BCM, ISOTP and the CAN RAW
>>>> protocols. The second one converts the unreliable ARPHRD_CAN type
>>>> check to the robust can_get_ml_priv(). The third one fixes the unique
>>>> skb identifier regression under RPS, introduced in the v7.0 release
>>>> cycle, which causes lost packets.
>>>>
>>>> A patch by Joshua Crofts adds a missing
>>>> pm_runtime_dont_use_autosuspend() to the m_can_pci driver.
>>>>
>>>> Maximilian Zimmermann's patch for the xilinx CAN driver adds the
>>>> setting the ESI and BSR flags in the receive path if they are active.
>>>>
>>>> Jiale Yao's patch for the mcp251xfd driver rejects devices without
>>>> match data.
>>>>
>>>> Ji-Ze Hong fixes a struct size mismatch in the f81604 CAN driver.
>>>>
>>>> The next patch is by me, targets the gs_usb driver and adds
>>>> workarounds for the HScanT USB to CAN adapter.
>>>>
>>>> Cen Zhang fixes a slab-out-of-bounds read access in the kvaser_usb
>>>> driver.
>>>>
>>>> A patch by Stefan Günther targets the peak_usb driver and fixes the
>>>> CAN-ID when reporting CAN errors.
>>>>
>>>> Chris Strong contributes 2 patches, to fix an out of memory and packet
>>>> loss problem in the mcp251xfd CAN driver under sustained receive
>>>> traffic.
>>> Linus has started pushing back on the ever-increasing net RC PRs:
>>>
>>> https://lore.kernel.org/netdev/CAHk- 
>>> =wiSnTE9vBZ=5_v+3EEkdazCCbBM5YABRzRHUAeRdyd4Xw@mail.gmail.com/
>>>
>>> We are trying to defer things to 'next', especially this late
>>> in the cycle.
>>>
>>> I think there are a few patches here eligible for that. i.e.
>>>
>>> can: gs_usb: add workarounds for HScanT USB to CAN adapter
>>
>>
>>> can: remove CAN filters independent from namespace
>>> can: convert unreliable ARPHRD_CAN type checks to robust 
>>> can_get_ml_priv()
>>
>> I would be fine with those two patches.
>> There was unfortunately some new(!) feedback by sashiko-bot on the 
>  > namespace patch and the ml_priv patch is not that urgent.
> FTR I mentioned the HScanT patch because if feels more additional H/W
> enablement than a fix and is also quite largish/invasive. Feel free to
> disagree!

Btw. we need the

can: convert unreliable ARPHRD_CAN type checks to robust can_get_ml_priv()

patch as it is a prerequisite for the urgent

can: fix unique skb identifier regression under RPS

The ml_priv patch is not a big thing and intended for stable too.

> Also, not sure if it's already clear, but the main/more relevant sashiko
> instance for netdev is the nipa one:
> 
> https://netdev-ai.bots.linux.dev/sashiko/#
> 
> It uses more models, and cross-correlates among them and sashiko.dev
> feedback.

Ok. The review on Linux-CAN ML was done with

gemini/gemini-3.1-pro-preview

https://sashiko.dev/#/patchset/20260929163424.16382-1-socketcan%40hartkopp.net

While the PR netdev review was done by

bedrock/us.anthropic.claude-opus-5-5

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260929210700.1183036-1-mkl%40pengutronix.de

@Marc: Can we switch on Linux-CAN Patchwork to Claude Opus too?

Best regards,
Oliver