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: <32fc8ebf-1cf5-41b0-b843-1af4821a8ddb@hartkopp.net>
Date: Fri, 5 Sep 2025 13:11:55 +0200
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: 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.25 11:18, Vincent Mailhol wrote:

> 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.

I double checked my XCANB CAN XL controller spec and indeed the RRS bit 
is part of every RX/TX FIFO element and the figures see it as 
configurable element too.

> 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.

Let's see if we will find CAN XL IP cores where the engineers have a 
different view on this. I currently have a discussion on this RRS bit 
with the Vector support because the RRS bit is not visible in the 
CANalyser 19 GUI.

> 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.

ACK. After this discussion I would also vote to omit my glorious patch 
which added the CAN_CTRLMODE_XL_RRS flag. Let's see if we find a CAN XL 
controller that does not support the variable RRS bit in reading and 
writing. And if it shows up we can add this flag to handle it (similar 
to the fd-non-iso feature).

Best regards,
Oliver