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: <7b5a723711c7a3045e68246effd806b0@gaisler.com>
Date: Thu, 11 Dec 2025 10:13:15 +0100
From: Arun Muthusamy <arun.muthusamy@...sler.com>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 mailhol@...nel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-can@...r.kernel.org, Daniel Hellstrom
 <daniel@...sler.com>
Subject: Re: [PATCH 08/10] can: grcan: Add saving and restoring of CAN FD
 baud-rate registers

Thank you for your suggestion.

 From the design point of view, I prefer to retain the "do_set_bittiming" 
callback to maintain flexibility in adjusting baud rates by the 
framework. Since CAN and CANFD configurations differ as they use 
different registers for timing configuration and Specifically, the 
timing configuration is closely tied to the reset logic only in 
scenarios where the baud rate for CANFD is stored in a register. This 
differentiation is not applicable to CAN timing configuration, as CAN 
and CANFD are handled differently.

-- 
BR,

Arun Muthusamy
Software Engineer
Frontgrade Gaisler
T : +46 (0) 700 558 528
arun.muthusamy@...sler.com

Frontgrade Gaisler AB, Kungsgatan 12, SE-411 19 GĂ–TEBORG, Sweden.
+46 (0) 31 775 8650, www.gaisler.com

On 21.11.2025 13:50, Marc Kleine-Budde wrote:
> On 18.11.2025 10:21:13, Arun Muthusamy wrote:
>> From: Daniel Hellstrom <daniel@...sler.com>
>> 
>> While reset the GRCAN baud-rates are preserved, since GRCANFD has the
>> baud-rate in different registers we need to add saving of those
>> registers too.
> 
> What about removing the do_set_bittiming callback
> 
> 	priv->can.do_set_bittiming = grcan_set_bittiming;
> 
> and calling grcan_set_bittiming() explicitly after the reset?
> 
> regards,
> Marc

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ