+cc: Oliver On Thu. 31 Oct. 2024 at 20:55, Robert Nawrath <mbro1689@xxxxxxxxx> wrote: > Hi, > I'm working on a kernel module for CAN-XL device. I can see in > /linux/can/dev.h that there are structures and methods for setting > bittiming and data_bittiming. The bittiming refers to CAN nominal bit > time, data_bittiming refers to CAN data bit time (using ISO/FDIS > 11898-1:2024 nomenclature). But in CAN-XL the data bit rate has two > values: FD data bit rate and XL data bit rate. This values are > different and the device shall have separate configuration register > sets for them. So for separate configuration registers there shall be > separate methods and structs. > Am I right that the current implementation in kernel is incomplete? Or > am I missing something? Yes, you are right. There is not yet a netlink interface for CAN XL, mostly because there is not yet a CAN XL driver in linux-can and because, before you, no one manifested a need for this. @Oliver, in this message: https://lore.kernel.org/linux-can/2540406e-8da3-4cb8-bd1a-30271dd6cc67@xxxxxxxxxxxx/ you mentioned that you were working on the bitrate configuration. Any update? Seems that this is time to make this live! I did some work on the netlink and the iproute2 tool in the past when I added the TDC, so eventually, I can help a bit if needed. @Robert, out of curiosity, what is the name of your CAN XL device? Yours sincerely, Vincent Mailhol Le jeu. 31 oct. 2024 à 20:55, Robert Nawrath <mbro1689@xxxxxxxxx> a écrit : > > Hi, > I'm working on a kernel module for CAN-XL device. I can see in > /linux/can/dev.h that there are structures and methods for setting > bittiming and data_bittiming. The bittiming refers to CAN nominal bit > time, data_bittiming refers to CAN data bit time (using ISO/FDIS > 11898-1:2024 nomenclature). But in CAN-XL the data bit rate has two > values: FD data bit rate and XL data bit rate. This values are > different and the device shall have separate configuration register > sets for them. So for separate configuration registers there shall be > separate methods and structs. > Am I right that the current implementation in kernel is incomplete? Or > am I missing something? > Robert >
