Hi devs, Short history: in all the existing socketcan drivers in Nuttx (imxrt, s32k3xx, s32k1xx, stm32h7 and kinetis), the driver-specific implementation of ioctl(...SIOCSCANBITRATE...) calls ifup at the end. Is there a rationale / spec for this?
Long history: In Linux, CAN bitrate is set with netlink, not ioctl, and you need to set a bitrate before bringing the interface up (make sense). In Nuttx, you can begin the interface up (it uses a default bitrate) and then you can change it. My guess is calling ifup at the end is precisely to avoid requiring another ifdown/ifup cycle from app code. SocketCAN is a Linux thing, so we should try to mimic the behaviour. Implementing netlink would be overkill (and moreover, it is common in Linux to use libsocketcan to abstract the netlink internals anyways) but at least we should have similar semantics. In our use case, we have a portable Linux/Nuttx app which uses socketcan, we have a thin compatibility layer for Linux/Nuttx differences (so bitrate setting uses icotl on Nuttx and libsocketcan in Linux) but it is difficult to make such a thin layer accommodate this difference (it would need to store the setting, and only call the ioctl just before bringing the interface up... essentially duplicating the driver functionality). Couldn't we (Nuttx): 1) Make SIOCSCANBITRATE just set the baudrate (and avoid changing interface state)? It could even fail if the interface is already up (AFAIK this is what netlink would do). 2) Provide a slightly more detailed documentation of Nuttx-specific SocketCAN ioctls (like, specifying whether the interface state is changed under the hood) I volunteer to make the change, but this might affect application space so I'd like to know what others' thoughts are. BR Carlos
