On Wed, Apr 16, 2025 at 3:53 PM Peter van der Perk <peter.vanderp...@nxp.com> wrote:
> can_ioctl_data_s is in a 32-bit union. > > https://github.com/apache/nuttx/blob/40c6af6dec0d769ac57f69e89709f9d6310ee0c6/include/net/if.h#L299 > Making it 64-bit would break that union. > > but lifr_ifru doesn't require its member size to be less than 64-bit, why not align can_ioctl_data_s with Linux definition. Hence back then it was chosen to use kHz instead. > > Yours sincerely, > > Peter van der Perk > > -----Original Message----- > From: Carlos Sanchez <carlossanc...@geotab.com.INVALID> > Sent: Wednesday, April 16, 2025 9:37 AM > To: dev@nuttx.apache.org > Subject: CAN ioctl units (WAS: socketcan ioctl(...SIOCSCANBITRATE...) > brings the interface up) > > > > > I was going to propose another global CAN change, removing the 1000 > > > factor from bitrate thus making bitrate calls use units in Hz > > > instead of kHz, so we can discuss that and (if agreed) I make the > > > change on the same PR to avoid creating so a tiny one. > > > What's the unit used on Linux? we need to align the interface with Linux. > > Units in linux are Hz, according to > > https://docs.kernel.org/networking/can.html#the-can-network-device-driver-interface > > One problem with using kHz is Single Wire Can (SAE J2411) uses bitrates of > 33333 bps (83333 bps in high speed mode) so representing this in kbps > causes a timing error which can be significant in some cases. > > The change would require modifying arbi_bitrate and data_bitrate fields on > struct can_ioctl_data_s from uint16_t to uint32_t, otherwise usual bitrates > cannot be represented. > > Carlos >
