netdev - Re: ctucanfd: possible coding error in ctucan_set_secondary_sample

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: <CAOprWov+j6V8XmtQD-K6pBj+7CVP_QJM0ODbJxtPZqG=y2RW3w@mail.gmail.com>
Date: Tue, 23 Dec 2025 01:57:15 +0800
From: Andrea Daoud <andreadaoud6@...il.com>
To: Ondrej Ille <ondrej.ille@...il.com>
Cc: Pavel Pisa <pisa@....felk.cvut.cz>, Marc Kleine-Budde <mkl@...gutronix.de>, linux-can@...r.kernel.org, 
	Wolfgang Grandegger <wg@...ndegger.com>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Christophe JAILLET <christophe.jaillet@...adoo.fr>, netdev@...r.kernel.org
Subject: Re: ctucanfd: possible coding error in ctucan_set_secondary_sample_point
 causing SSP not enabled

Thanks for your reply!

On Mon, Dec 22, 2025 at 11:51 PM Ondrej Ille <ondrej.ille@...il.com> wrote:
>
> Hello Andrea,
>
> yes, your thinking is correct, there is a bug there.
>
> This was pointed to by another user right in the CTU CAN FD repository where the Linux driver also lives:
> https://github.com/Blebowski/CTU-CAN-FD/pull/2
>
> It is as you say, it should be:
>
> -- ssp_cfg |= FIELD_PREP(REG_TRV_DELAY_SSP_SRC, 0x1);
> ++ ssp_cfg |= FIELD_PREP(REG_TRV_DELAY_SSP_SRC, 0x0);
>
> Unfortunately, we have not processed this in the CTU CAN FD repo either.
> I can send it as a patch, but TBH, I have never done this before (the driver was contributed to Kernel by Pavel Pisa, he is the maintainer).
> If you point me in the right direction to the steps I should follow, I will be glad to do so.
>
> With Regards
> Ondrej Ille
>
> PS: The changes are dummy enough that they will likely not cause a large review, so it seems like an ideal case for trying to contribute for the first time.

Unfortunately I do not have an environment right now to make patches
sent, so it would be better if someone else can send the patch.

> PPS: I will go on and fix it in CTU CAN FD repo too. However, ATM I don't have a setup where to really test this.

I have tested it on my setup. I run this core on a FPGA, with PCIe
connected to Linux host. After changing this to zero, I can see the
relative phase of sample_sec has changed to a more ideal phase in the
received bit.

>
> On Mon, Dec 22, 2025 at 3:17 PM Andrea Daoud <andreadaoud6@...il.com> wrote:
>>
>> Hi,
>>
>> In ctucan_set_secondary_sample_point(), there's a line which runs when
>> data bitrate is >1Mbps:
>>
>> ssp_cfg |= FIELD_PREP(REG_TRV_DELAY_SSP_SRC, 0x1);
>>
>> In the datasheet [1] of ctucanfd, we can see the meaning of SSP_SRC:
>>
>> SSP_SRC: Source of Secondary sampling point.
>> 0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY (Measured
>> Transmitter delay) + SSP_OFFSET.
>> 0b01 - SSP_SRC_NO_SSP - SSP is not used. Transmitter uses regular
>> Sampling Point during data bit rate.
>> 0b10 - SSP_SRC_OFFSET - SSP position = SSP_OFFSET. Measured
>> Transmitter delay value is ignored.
>>
>> Therefore, setting it to 1 disables SSP (NO_SSP). We should probably
>> set it to 0 (MEAS_N_OFFSET).
>>
>> Is this correct? Would like to hear some inputs.
>>
>> Regards,
>>
>> Andrea
>>
>> [1]: https://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/doc/Datasheet.pdf