linux-kernel - Re: [PATCH] can: canxl: add CANXL

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: <d2610541-ba04-4a80-b3e6-c9c75bb1a486@kernel.org>
Date: Wed, 30 Jul 2025 23:15:55 +0900
From: Vincent Mailhol <mailhol@...nel.org>
To: Oliver Hartkopp <socketcan@...tkopp.net>
Cc: Robert Nawrath <mbro1689@...il.com>, linux-can@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Stéphane Grosjean <stephane.grosjean@...-networks.com>,
 Marc Kleine-Budde <mkl@...gutronix.de>
Subject: Re: [PATCH] can: canxl: add CANXL_PMS flag

On Tue. 29 Jul. 2025 at 03:20, Oliver Hartkopp <socketcan@...tkopp.net> wrote:

(...)

>> My gut felling is that the TMS is intended to work in a similar
>> fashion as the CAN FD's BRS. In CAN FD, we do not have a
>> CAN_CTRLMODE_FD_BRS to tell that FD should operate only using the
>> nominal bittiming. And so, I do not get why CAN XL should be different
>> and have a CAN_CTRLMODE_XL_TMS (or CAN_CTRLMODE_XL_TRX).
>>
>> Stéphane and Oliver: maybe the datasheet of your CAN XL board have
>> some additional insights? Did you see a register allowing to globally
>> deactivate the TMS (i.e. not only at the frame level)?
> 
> You can take a look at the XCAN manual https://github.com/linux-can/can-doc/
> blob/master/x_can/xcan_user_manual_v350.pdf
> 
> And I have a XCANB specification which is a simple (non-DMA) CAN XL controller.
> 
> The TMS switching is only possible in netlink level and there's no TMS-style bit
> in the CAN XL frame layout that is pushed into the controller to send a CAN XL
> frame => there is not TMS-bit analogue to the BRS-bit your were searching for.
> 
> Therefore this patch is obsolete.

OK. I re-re-read the standard. It turns out that the CAN XL SIC is only able to
differentiate between the *nominal* NRZ and the PWM on the fly. The frequency of
data bitrate NRZ is already too high to differentiate using the 200 ns threshold.

So indeed the PMS is set once for all when the bus is inactive. And that switch
tells the controller whether it should use NRZ or PWM for the data phase. That
on the fly detection logic really confused me, but now I finally understand.

Thanks for the explanations!

> Btw. while we are at it: I would suggest for a name change of
> 
> CAN_CTRLMODE_XL_TRX
> 
> to
> 
> CAN_CTRLMODE_XL_TMS
> 
> as it makes clear how the controller should manage the PWM mode.
> 
> "CAN_CTRLMODE_XL_TRX" would mean "there is a CAN XL PWM enabled transceiver"
> available which tells nothing about whether the PWM mode is used or not.

Ack. I have the same opinion.


Yours sincerely,
Vincent Mailhol