dakejahl opened a new pull request, #20008:
URL: https://github.com/apache/nuttx/pull/20008

   ## Summary
   
   Two changes to the i.MX RT FlexCAN SocketCAN driver, plus the network-layer 
plumbing the second one needs.
   
   1. `imxrt_txdone_work()` and `imxrt_txtimeout_work()` shared 
`priv->irqwork`. `work_queue()` cancels a pending callback when its `work_s` is 
reused, so whichever was queued second silently replaced the first: deadlines 
left set, `IMASK1` TX bits left off, or expired frames never aborted. Both 
paths now queue one worker, `imxrt_tx_work()`, which retires completions before 
aborting expired mailboxes.
   2. A new `SIOCGCANERRORS` ioctl (`_SIOC(0x0045)`, behind 
`CONFIG_NETDEV_CAN_ERROR_IOCTL`) returns `struct can_ioctl_errors_s`: 
fault-confinement state, TEC, REC, a monotonic bus-error count and the RX 
mailbox overrun count. `SIOCGCANSTATE` reports sleep/operational, not fault 
confinement, so this is a distinct command. The driver counts bus errors by 
sampling the clear-on-read `ESR1` error flags at every driver entry (TX work, 
RX work, the ioctl) instead of enabling `ERRINT`, which fires per error frame 
and storms at bus rate on a dead bus. Frames the CAN socket layer drops for 
want of an IOB now also count as `rx_dropped` in the per-device netdev 
statistics.
   
   ## Impact
   
   - New feature: YES, `SIOCGCANERRORS` and `CONFIG_NETDEV_CAN_ERROR_IOCTL` 
(default n), implemented for i.MX RT FlexCAN only; other SocketCAN drivers 
return `-ENOTTY`.
   - User: NO change for existing applications; the ioctl is opt-in.
   - Build: NO change with the option disabled; `include/net/if.h` gains 
`struct can_ioctl_errors_s` and one union member in `ifreq`/`lifreq`.
   - Hardware: i.MX RT FlexCAN only (the TX worker change affects every i.MX RT 
SocketCAN user).
   - Documentation: NO documentation of the CAN ioctls exists to update.
   - Security: NO.
   - Compatibility: YES, backward compatible; `ifreq` grows by the size of the 
new union member only if it becomes the largest, which it is not.
   
   ## Testing
   
   Build: `imxrt1170-evk:can` with `CONFIG_NETDEV_CAN_ERROR_IOCTL=y`, 
`CONFIG_NETDEV_STATISTICS=y`, `CONFIG_NET_STATISTICS=y`, arm-none-eabi-gcc 
13.2.1, host Linux.
   
   Runtime: i.MX RT1176 (ARK FMU-v6XRT) running PX4 with this change carried on 
the PX4 NuttX fork (PX4/NuttX#401), two DroneCAN nodes, one per FlexCAN 
interface, 1 Mbit/s.
   
   Before (stub `getErrorCount()`, `isInBusOffState()`): an error-passive 
controller is invisible from the socket API; `uavcan status` prints `HW errors: 
0` regardless.
   
   After, unplugging the CAN2 node for 10 s and reading the ioctl every 2 s 
(console) while `ECR`/`ESR1` were read over SWD at 20 Hz:
   
   ```
    64.1s  CAN1 error-active TEC 0 REC 0 hw 0    |  CAN2 error-passive TEC 128 
REC 0 hw 379
    66.8s  CAN1 error-active TEC 0 REC 0 hw 0    |  CAN2 error-passive TEC 128 
REC 0 hw 451
    74.7s  CAN1 error-active TEC 0 REC 0 hw 0    |  CAN2 error-passive TEC 128 
REC 0 hw 637
    77.4s  CAN1 error-active TEC 0 REC 0 hw 0    |  CAN2 error-passive TEC 152 
REC 0 hw 659
    85.3s  CAN1 error-active TEC 0 REC 0 hw 0    |  CAN2 error-active  TEC 17  
REC 0 hw 660
   SWD: CAN2 TXERRCNT 128 from 66.9 s, ESR1 fault confinement error-passive, 
302 samples over 23 s, 259 with ACKERR; CAN1 0 / error-active on all 5932 
samples
   ```
   
   With the two nodes moved to 500 kbit/s while the controller stayed at 1 
Mbit/s, the ioctl reads `error-passive (TEC 0, REC 128)` while the controller 
transmits nothing and `(TEC 128, REC 133)` while it does. With 
`NETDEV_STATISTICS` enabled, `/proc/net/can0` showed `Dropped` advancing (445 
frames in 300 s at 3260 frames/s with a 24-buffer IOB pool), which the global 
CAN statistics alone did not attribute to an interface.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to