netdev - Re: [PATCH 2/2] docs: can: update SocketCAN documentation for 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] [day] [month] [year] [list]

Message-ID: <6a99ce41-2200-49d7-9a6c-29e9311b46ab@hartkopp.net>
Date: Sun, 18 Jan 2026 19:23:22 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Rakuram Eswaran <rakuram.e96@...il.com>
Cc: corbet@....net, linux-can@...r.kernel.org, linux-doc@...r.kernel.org,
 mailhol@...nel.org, mkl@...gutronix.de, netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] docs: can: update SocketCAN documentation for CAN XL


On 18.01.26 15:41, Rakuram Eswaran wrote:
> On Tue, 13 Jan 2026 at 21:45, Oliver Hartkopp <socketcan@...tkopp.net> wrote:
>>

>>>    The length of the two CAN(FD) frame structures define the maximum transfer
>>>    unit (MTU) of the CAN(FD) network interface and skbuff data length. Two
>>> -definitions are specified for CAN specific MTUs in include/linux/can.h:
>>> +definitions are specified for CAN specific MTUs in include/uapi/linux/can.h:
>>
>> No.
>>   From the user perspective he has to include include/linux/can.h
>>
>> Better "MTUs in the linux/can.h include file:"
>>
> 
> Can I just incude linux/can.h or include/linux/can.h? As in the current
> document include/linux/can.h is used.
> 

If you look into the code you need e.g.

#include <linux/can.h>
#include <linux/can/raw.h>

So I would name it the linux/can.h include file.

>>
>> What about the PWM settings here?
>> When TMS is "on" the PWM values can be automatically calculated or set
>> manually. There's also no CAN XL TDC when TMS=on as the TDC is a
>> mixed-mode requirement for non-TMS transceivers.
>>
> 
> Can I add the PWM settings under new heading (CAN XL PWM) or is it fine
> to keep the content under the same heading (CAN XL TDC)?
> 

Yes. I would propose a new section

CAN XL TMS (Transceiver Mode Setting / PWM)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Transceiver Mode Setting (TMS) switches the RX/TX lines between the 
CAN XL controller and the CAN XL transceiver into the "Fast Mode" by 
enabling a PWM protocol.

In the Fast Mode a different sample point is used and the PWM ratio is 
calculated automatically or can be set manually.

>> There's one big difference between CC/FD and XL frames when you
>> read/write it to CAN_RAW sockets:
>>
>> For CAN CC and CAN FD you write struct can(fd)_frame's with CAN_MTU
>> resp. CANFD_MTU lengths - no matter about the data length (cf->len).
>>
>> When you read/write CAN XL frames you are reading and writing the
>> CANXL_HDR_SIZE + the length of the data.
>>
>> So only in the case of writing 2048 byte data, you write 2060 bytes.
>>
>> The minimum size for read/write is CANXL_HDR_SIZE + CANXL_MIN_DLEN == 13
>>
> 
> Good point! I will add this information along with an example. I will go
> through your code and decide what to add. Does the example code should
> focus only on CAN XL frames or also on CC/FD frames?

When the CAN_RAW socket enables the CAN XL support you have to deal with 
all kind of CAN frames. IMO is makes sense to show an example that deals 
with all three types of frames.

>> Here is an example that I've been implemented recently that shows a good
>> example how to handle CC/FD/XL frames, when they are all enabled on the
>> CAN_RAW socket:
>>
>> https://github.com/hartkopp/can-utils/commit/bf0cae218af9b1c1f5eabad7f3704b88ab642e00
>>
>> Feel free to pick the code for some example.
>>
>> But please do not reference the commit as it is in my private repo and
>> not yet integrated in the official can-utils repo.
>>

Best regards,
Oliver