linux-kernel - Re: [PATCH 00/21] can: netlink: preparation before introduction of CAN XL step 2/2

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: <88d2836b-2702-481f-b504-20c6efa5cb1a@kernel.org>
Date: Thu, 4 Sep 2025 18:18:21 +0900
From: Vincent Mailhol <mailhol@...nel.org>
To: Oliver Hartkopp <socketcan@...tkopp.net>,
 Vincent Mailhol <mailhol@...nel.org>, Marc Kleine-Budde <mkl@...gutronix.de>
Cc: 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 00/21] can: netlink: preparation before introduction of
 CAN XL step 2/2

On 04/09/2025 at 15:36, Oliver Hartkopp wrote:
> On 03.09.25 11:26, Vincent Mailhol wrote:
>> On 03/09/2025 à 17:49, Vincent Mailhol wrote:
>>
>> (...)
>>
>>> The follow up series which introduces CAN XL is nearly completed but
>>> will be sent only once this one is approved: one thing at a time, I do
>>> not want to overwhelm people (including myself).
>>
>> If you want a preview of the full CAN XL, you can have a look at my work in
>> progress here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/
>> log/?h=b4/canxl-netlink
>> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/iproute2-next.git/
>> log/?h=canxl-netlink
>>
>> The kernel part is nearly completed, but I am still playing some whack-a-mole to
>> find potential gaps in the configuration validation. I also need to rewrite or
>> fine tune the commit description.
>>
>> The iproute2 part is still under development. It has the PWM interface but I
>> have not added all the control modes yet.
>>
> 
> Thanks Vincent!
> 
> The repos are very helpful.
> 
> With "missing" control modes you refer to CAN_CTRLMODE_XL_ERR_SIGNAL,
> CAN_CTRLMODE_XL_RRS and CAN_CTRLMODE_RESTRICTED, right?

Yes, I only added the CAN_CTRLMODE_XL_TMS so far in iproute2. The kernel has all
of the four flags (but because I did not finish testing, I highly suspect that
there are still some bugs somewhere).

Concerning the CAN_CTRLMODE_XL_RRS, I am not sure if that one is needed. I still
have it in my WIP series but I am recently considering to remove it. The reason
is that when reading ISO 11898-1 having RRS configurable looks mandatory to me.

In the logical Link control (LLC) this RRS bit is named FTYP (for Frame Type).
For example, CiA only mentions FTYP in their CAN XL knowledge page:

  https://www.can-cia.org/can-knowledge/can-xl

Contrarily to CAN FD's RRS which is indeed specified as being dominant and which
is just ignored in the LLC, the CAN XL FTYP/RRS is part of the LLC interface and
is meant to be configurable.

Nothing in the standard tells us that this should be a dominant bit. I think
your intention was to add CAN_CTRLMODE_XL_RRS as a quirk for the devices which
expose this flag. But as far as I can see, it seems that a device which does not
expose it is just not compliant.

If some day a device which can not set the FTYP/RRS flag appears in the wild,
then maybe we can add a flag which would specify that RRS is not configurable
(opposite logic as what you suggested). But as long as such a device do not
exist, it is better to add nothing.

Yours sincerely,
Vincent Mailhol