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: <6799c8a7-cc0e-4df0-aa08-10b948b58c4d@kernel.org>
Date: Fri, 5 Sep 2025 23:58:50 +0900
From: Vincent Mailhol <mailhol@...nel.org>
To: Oliver Hartkopp <socketcan@...tkopp.net>,
 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 05/09/2025 at 20:11, Oliver Hartkopp wrote:
> 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).

OK. Good that we reached out to the same conclusion :)

Because I already implemented all the logic, I will save the current RRS patch
somewhere in case we need to resurrect it some days.


Yours sincerely,
Vincent Mailhol