linux-kernel - Re: [PATCH 0/9] can: netlink: add CAN XL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <913f6723-a8be-4bce-9a57-0b5c7f2348ef@kernel.org>
Date: Sat, 18 Oct 2025 01:20:31 +0900
From: Vincent Mailhol <mailhol@...nel.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Oliver Hartkopp <socketcan@...tkopp.net>,
 Stéphane Grosjean <stephane.grosjean@...-networks.com>,
 Robert Nawrath <mbro1689@...il.com>, Minh Le <minh.le.aj@...esas.com>,
 Duy Nguyen <duy.nguyen.rh@...esas.com>, linux-can@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] can: netlink: add CAN XL

On 18/10/2025 at 01:02, Marc Kleine-Budde wrote:
> On 18.10.2025 00:40:22, Vincent Mailhol wrote:
>> On 17/10/2025 at 22:53, Marc Kleine-Budde wrote:
>>> On 13.10.2025 20:01:22, Vincent Mailhol wrote:
>>>> Following all the refactoring on the CAN netlink done in series [1],
>>>> [2] and [3], this is now time to finally introduce the CAN XL netlink
>>>> interface.
>>>>
>>>> Similarly to how CAN FD reuses the bittiming logic of Classical CAN,
>>>> CAN XL also reuses the entirety of CAN FD features, and, on top of
>>>> that, adds new features which are specific to CAN XL.
>>>>
>>>> Patch #1 adds a check in can_dev_dropped_skb() to drop CAN FD frames
>>>> when CAN FD is turned off.
>>>>
>>>> Patch #2 adds CAN_CTRLMODE_RESTRICTED. Note that contrary to the other
>>>> CAN_CTRL_MODE_XL_* that are introduced in the later patches, this
>>>> control mode is not specific to CAN XL. The nuance is that because
>>>> this restricted mode was only added in ISO 11898-1:2024, it is made
>>>> mandatory for CAN XL devices but optional for other protocols. This is
>>>> why this patch is added as a preparation before introducing the core
>>>> CAN XL logic.
>>>
>>> What about merging patches 1+2 now?
>>
>> If patch 1 had to be squashed,
> 
> Sorry - I was offering you to take patches 1+2 into can-next-testing
> now.

Ah! This makes more sense. Sorry for misreading you.

Yes, you can pick those two. But could you just push your
can-next-testing branch to git.kernel.org after picking those? This
way, I can rebase my series on top of it instead of dealing with some
complex dependencies.

 
Yours sincerely,
Vincent Mailhol