[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251222-kickass-oyster-of-sorcery-c39bb7-mkl@pengutronix.de>
Date: Mon, 22 Dec 2025 17:20:49 +0100
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Ondrej Ille <ondrej.ille@...il.com>
Cc: Andrea Daoud <andreadaoud6@...il.com>,
Pavel Pisa <pisa@....felk.cvut.cz>, 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
On 22.12.2025 16:51:07, Ondrej Ille wrote:
> 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);
This statement has no effect, as 'ssp_cfg |= 0x0' is still 'ssp_cfg'.
IMHO it's better to add a comment that says, why you don't set
REG_TRV_DELAY_SSP_SRC. Another option is to add create a define that
replaces 0x1 and 0x0 for REG_TRV_DELAY_SSP_SRC with a speaking name.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists