Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Merge tag 'linux-can-next-for-6.15-20250219' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
Marc Kleine-Budde says:
====================
pull-request: can-next 2025-02-19
this is a pull request of 12 patches for net-next/master.
The first 4 patches are by Krzysztof Kozlowski and simplify the c_can
driver's c_can_plat_probe() function.
Ciprian Marian Costea contributes 3 patches to add S32G2/S32G3 support
to the flexcan driver.
Ruffalo Lavoisier's patch removes a duplicated word from the mcp251xfd
DT bindings documentation.
Oleksij Rempel extends the J1939 documentation.
The next patch is by Oliver Hartkopp and adds access for the Remote
Request Substitution bit in CAN-XL frames.
Henrik Brix Andersen's patch for the gs_usb driver adds support for
the CANnectivity firmware.
The last patch is by Robin van der Gracht and removes a duplicated
setup of RX FIFO in the rockchip_canfd driver.
linux-can-next-for-6.15-20250219
* tag 'linux-can-next-for-6.15-20250219' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
can: rockchip_canfd: rkcanfd_chip_fifo_setup(): remove duplicated setup of RX FIFO
can: gs_usb: add VID/PID for the CANnectivity firmware
can: canxl: support Remote Request Substitution bit access
can: j1939: Extend stack documentation with buffer size behavior
dt-binding: can: mcp251xfd: remove duplicate word
can: flexcan: add NXP S32G2/S32G3 SoC support
can: flexcan: Add quirk to handle separate interrupt lines for mailboxes
dt-bindings: can: fsl,flexcan: add S32G2/S32G3 SoC support
can: c_can: Use syscon_regmap_lookup_by_phandle_args
can: c_can: Use of_property_present() to test existence of DT property
can: c_can: Simplify handling syscon error path
can: c_can: Drop useless final probe failure message
====================
Link: https://patch.msgid.link/20250219113354.529611-1-mkl@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+777
-48
+40
-4
Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
+40
-4
Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
···
10
10
maintainers:
11
11
- Marc Kleine-Budde <mkl@pengutronix.de>
12
12
13
-
allOf:
14
-
- $ref: can-controller.yaml#
15
-
16
13
properties:
17
14
compatible:
18
15
oneOf:
···
25
28
- fsl,vf610-flexcan
26
29
- fsl,ls1021ar2-flexcan
27
30
- fsl,lx2160ar1-flexcan
31
+
- nxp,s32g2-flexcan
28
32
- items:
29
33
- enum:
30
34
- fsl,imx53-flexcan
···
41
43
- enum:
42
44
- fsl,ls1028ar1-flexcan
43
45
- const: fsl,lx2160ar1-flexcan
46
+
- items:
47
+
- enum:
48
+
- nxp,s32g3-flexcan
49
+
- const: nxp,s32g2-flexcan
44
50
45
51
reg:
46
52
maxItems: 1
47
53
48
54
interrupts:
49
-
maxItems: 1
55
+
minItems: 1
56
+
maxItems: 4
57
+
58
+
interrupt-names:
59
+
minItems: 1
60
+
maxItems: 4
50
61
51
62
clocks:
52
63
maxItems: 2
···
142
135
- compatible
143
136
- reg
144
137
- interrupts
138
+
139
+
allOf:
140
+
- $ref: can-controller.yaml#
141
+
- if:
142
+
properties:
143
+
compatible:
144
+
contains:
145
+
const: nxp,s32g2-flexcan
146
+
then:
147
+
properties:
148
+
interrupts:
149
+
items:
150
+
- description: Message Buffer interrupt for mailboxes 0-7 and Enhanced RX FIFO
151
+
- description: Device state change
152
+
- description: Bus Error detection
153
+
- description: Message Buffer interrupt for mailboxes 8-127
154
+
interrupt-names:
155
+
items:
156
+
- const: mb-0
157
+
- const: state
158
+
- const: berr
159
+
- const: mb-1
160
+
required:
161
+
- interrupt-names
162
+
else:
163
+
properties:
164
+
interrupts:
165
+
maxItems: 1
166
+
interrupt-names: false
145
167
146
168
additionalProperties: false
147
169
+1
-1
Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
+1
-1
Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
+675
Documentation/networking/j1939.rst
+675
Documentation/networking/j1939.rst
···
66
66
J1939 concepts
67
67
==============
68
68
69
+
Data Sent to the J1939 Stack
70
+
----------------------------
71
+
72
+
The data buffers sent to the J1939 stack from user space are not CAN frames
73
+
themselves. Instead, they are payloads that the J1939 stack converts into
74
+
proper CAN frames based on the size of the buffer and the type of transfer. The
75
+
size of the buffer influences how the stack processes the data and determines
76
+
the internal code path used for the transfer.
77
+
78
+
**Handling of Different Buffer Sizes:**
79
+
80
+
- **Buffers with a size of 8 bytes or less:**
81
+
82
+
- These are handled as simple sessions internally within the stack.
83
+
84
+
- The stack converts the buffer directly into a single CAN frame without
85
+
fragmentation.
86
+
87
+
- This type of transfer does not require an actual client (receiver) on the
88
+
receiving side.
89
+
90
+
- **Buffers up to 1785 bytes:**
91
+
92
+
- These are automatically handled as J1939 Transport Protocol (TP) transfers.
93
+
94
+
- Internally, the stack splits the buffer into multiple 8-byte CAN frames.
95
+
96
+
- TP transfers can be unicast or broadcast.
97
+
98
+
- **Broadcast TP:** Does not require a receiver on the other side and can be
99
+
used in broadcast scenarios.
100
+
101
+
- **Unicast TP:** Requires an active receiver (client) on the other side to
102
+
acknowledge the transfer.
103
+
104
+
- **Buffers from 1786 bytes up to 111 MiB:**
105
+
106
+
- These are handled as ISO 11783 Extended Transport Protocol (ETP) transfers.
107
+
108
+
- ETP transfers are used for larger payloads and are split into multiple CAN
109
+
frames internally.
110
+
111
+
- **ETP transfers (unicast):** Require a receiver on the other side to
112
+
process the incoming data and acknowledge each step of the transfer.
113
+
114
+
- ETP transfers cannot be broadcast like TP transfers, and always require a
115
+
receiver for operation.
116
+
117
+
**Non-Blocking Operation with `MSG_DONTWAIT`:**
118
+
119
+
The J1939 stack supports non-blocking operation when used in combination with
120
+
the `MSG_DONTWAIT` flag. In this mode, the stack attempts to take as much data
121
+
as the available memory for the socket allows. It returns the amount of data
122
+
that was successfully taken, and it is the responsibility of user space to
123
+
monitor this value and handle partial transfers.
124
+
125
+
- If the stack cannot take the entire buffer, it returns the number of bytes
126
+
successfully taken, and user space should handle the remainder.
127
+
128
+
- **Error handling:** When using `MSG_DONTWAIT`, the user must rely on the
129
+
error queue to detect transfer errors. See the **SO_J1939_ERRQUEUE** section
130
+
for details on how to subscribe to error notifications. Without the error
131
+
queue, there is no other way for user space to be notified of transfer errors
132
+
during non-blocking operations.
133
+
134
+
**Behavior and Requirements:**
135
+
136
+
- **Simple transfers (<= 8 bytes):** Do not require a receiver on the other
137
+
side, making them easy to send without needing address claiming or
138
+
coordination with a destination.
139
+
140
+
- **Unicast TP/ETP:** Requires a receiver on the other side to complete the
141
+
transfer. The receiver must acknowledge the transfer for the session to
142
+
proceed successfully.
143
+
144
+
- **Broadcast TP:** Allows sending data without a receiver, but only works for
145
+
TP transfers. ETP cannot be broadcast and always needs a receiving client.
146
+
147
+
These different behaviors depend heavily on the size of the buffer provided to
148
+
the stack, and the appropriate transport mechanism (TP or ETP) is selected
149
+
based on the payload size. The stack automatically manages the fragmentation
150
+
and reassembly of large payloads and ensures that the correct CAN frames are
151
+
generated and transmitted for each session.
152
+
69
153
PGN
70
154
---
71
155
···
422
338
}
423
339
}
424
340
341
+
setsockopt(2)
342
+
^^^^^^^^^^^^^
343
+
344
+
The ``setsockopt(2)`` function is used to configure various socket-level
345
+
options for J1939 communication. The following options are supported:
346
+
347
+
``SO_J1939_FILTER``
348
+
~~~~~~~~~~~~~~~~~~~
349
+
350
+
The ``SO_J1939_FILTER`` option is essential when the default behavior of
351
+
``bind(2)`` and ``connect(2)`` is insufficient for specific use cases. By
352
+
default, ``bind(2)`` and ``connect(2)`` allow a socket to be associated with a
353
+
single unicast or broadcast address. However, there are scenarios where finer
354
+
control over the incoming messages is required, such as filtering by Parameter
355
+
Group Number (PGN) rather than by addresses.
356
+
357
+
For example, in a system where multiple types of J1939 messages are being
358
+
transmitted, a process might only be interested in a subset of those messages,
359
+
such as specific PGNs, and not want to receive all messages destined for its
360
+
address or broadcast to the bus.
361
+
362
+
By applying the ``SO_J1939_FILTER`` option, you can filter messages based on:
363
+
364
+
- **Source Address (SA)**: Filter messages coming from specific source
365
+
addresses.
366
+
367
+
- **Source Name**: Filter messages coming from ECUs with specific NAME
368
+
identifiers.
369
+
370
+
- **Parameter Group Number (PGN)**: Focus on receiving messages with specific
371
+
PGNs, filtering out irrelevant ones.
372
+
373
+
This filtering mechanism is particularly useful when:
374
+
375
+
- You want to receive a subset of messages based on their PGNs, even if the
376
+
address is the same.
377
+
378
+
- You need to handle both broadcast and unicast messages but only care about
379
+
certain message types or parameters.
380
+
381
+
- The ``bind(2)`` and ``connect(2)`` functions only allow binding to a single
382
+
address, which might not be sufficient if the process needs to handle multiple
383
+
PGNs but does not want to open multiple sockets.
384
+
385
+
To remove existing filters, you can pass ``optval == NULL`` or ``optlen == 0``
386
+
to ``setsockopt(2)``. This will clear all currently set filters. If you want to
387
+
**update** the set of filters, you must pass the updated filter set to
388
+
``setsockopt(2)``, as the new filter set will **replace** the old one entirely.
389
+
This behavior ensures that any previous filter configuration is discarded and
390
+
only the new set is applied.
391
+
392
+
Example of removing all filters:
393
+
394
+
.. code-block:: c
395
+
396
+
setsockopt(sock, SOL_CAN_J1939, SO_J1939_FILTER, NULL, 0);
397
+
398
+
**Maximum number of filters:** The maximum amount of filters that can be
399
+
applied using ``SO_J1939_FILTER`` is defined by ``J1939_FILTER_MAX``, which is
400
+
set to 512. This means you can configure up to 512 individual filters to match
401
+
your specific filtering needs.
402
+
403
+
Practical use case: **Monitoring Address Claiming**
404
+
405
+
One practical use case is monitoring the J1939 address claiming process by
406
+
filtering for specific PGNs related to address claiming. This allows a process
407
+
to monitor and handle address claims without processing unrelated messages.
408
+
409
+
Example:
410
+
411
+
.. code-block:: c
412
+
413
+
struct j1939_filter filt[] = {
414
+
{
415
+
.pgn = J1939_PGN_ADDRESS_CLAIMED,
416
+
.pgn_mask = J1939_PGN_PDU1_MAX,
417
+
}, {
418
+
.pgn = J1939_PGN_REQUEST,
419
+
.pgn_mask = J1939_PGN_PDU1_MAX,
420
+
}, {
421
+
.pgn = J1939_PGN_ADDRESS_COMMANDED,
422
+
.pgn_mask = J1939_PGN_MAX,
423
+
},
424
+
};
425
+
setsockopt(sock, SOL_CAN_J1939, SO_J1939_FILTER, &filt, sizeof(filt));
426
+
427
+
In this example, the socket will only receive messages with the PGNs related to
428
+
address claiming: ``J1939_PGN_ADDRESS_CLAIMED``, ``J1939_PGN_REQUEST``, and
429
+
``J1939_PGN_ADDRESS_COMMANDED``. This is particularly useful in scenarios where
430
+
you want to monitor and process address claims without being overwhelmed by
431
+
other traffic on the J1939 network.
432
+
433
+
``SO_J1939_PROMISC``
434
+
~~~~~~~~~~~~~~~~~~~~
435
+
436
+
The ``SO_J1939_PROMISC`` option enables socket-level promiscuous mode. When
437
+
this option is enabled, the socket will receive all J1939 traffic, regardless
438
+
of any filters set by ``bind()`` or ``connect()``. This is analogous to
439
+
enabling promiscuous mode for an Ethernet interface, where all traffic on the
440
+
network segment is captured.
441
+
442
+
However, **`SO_J1939_FILTER` has a higher priority** compared to
443
+
``SO_J1939_PROMISC``. This means that even in promiscuous mode, you can reduce
444
+
the number of packets received by applying specific filters with
445
+
`SO_J1939_FILTER`. The filters will limit which packets are passed to the
446
+
socket, allowing for more refined traffic selection while promiscuous mode is
447
+
active.
448
+
449
+
The acceptable value size for this option is ``sizeof(int)``, and the value is
450
+
only differentiated between `0` and non-zero. A value of `0` disables
451
+
promiscuous mode, while any non-zero value enables it.
452
+
453
+
This combination can be useful for debugging or monitoring specific types of
454
+
traffic while still capturing a broad set of messages.
455
+
456
+
Example:
457
+
458
+
.. code-block:: c
459
+
460
+
int value = 1;
461
+
setsockopt(sock, SOL_CAN_J1939, SO_J1939_PROMISC, &value, sizeof(value));
462
+
463
+
In this example, setting ``value`` to any non-zero value (e.g., `1`) enables
464
+
promiscuous mode, allowing the socket to receive all J1939 traffic on the
465
+
network.
466
+
467
+
``SO_BROADCAST``
468
+
~~~~~~~~~~~~~~~~
469
+
470
+
The ``SO_BROADCAST`` option enables the sending and receiving of broadcast
471
+
messages. By default, broadcast messages are disabled for J1939 sockets. When
472
+
this option is enabled, the socket will be allowed to send and receive
473
+
broadcast packets on the J1939 network.
474
+
475
+
Due to the nature of the CAN bus as a shared medium, all messages transmitted
476
+
on the bus are visible to all participants. In the context of J1939,
477
+
broadcasting refers to using a specific destination address field, where the
478
+
destination address is set to a value that indicates the message is intended
479
+
for all participants (usually a global address such as 0xFF). Enabling the
480
+
broadcast option allows the socket to send and receive such broadcast messages.
481
+
482
+
The acceptable value size for this option is ``sizeof(int)``, and the value is
483
+
only differentiated between `0` and non-zero. A value of `0` disables the
484
+
ability to send and receive broadcast messages, while any non-zero value
485
+
enables it.
486
+
487
+
Example:
488
+
489
+
.. code-block:: c
490
+
491
+
int value = 1;
492
+
setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &value, sizeof(value));
493
+
494
+
In this example, setting ``value`` to any non-zero value (e.g., `1`) enables
495
+
the socket to send and receive broadcast messages.
496
+
497
+
``SO_J1939_SEND_PRIO``
498
+
~~~~~~~~~~~~~~~~~~~~~~
499
+
500
+
The ``SO_J1939_SEND_PRIO`` option sets the priority of outgoing J1939 messages
501
+
for the socket. In J1939, messages can have different priorities, and lower
502
+
numerical values indicate higher priority. This option allows the user to
503
+
control the priority of messages sent from the socket by adjusting the priority
504
+
bits in the CAN identifier.
505
+
506
+
The acceptable value **size** for this option is ``sizeof(int)``, and the value
507
+
is expected to be in the range of 0 to 7, where `0` is the highest priority,
508
+
and `7` is the lowest. By default, the priority is set to `6` if this option is
509
+
not explicitly configured.
510
+
511
+
Note that the priority values `0` and `1` can only be set if the process has
512
+
the `CAP_NET_ADMIN` capability. These are reserved for high-priority traffic
513
+
and require administrative privileges.
514
+
515
+
Example:
516
+
517
+
.. code-block:: c
518
+
519
+
int prio = 3; // Priority value between 0 (highest) and 7 (lowest)
520
+
setsockopt(sock, SOL_CAN_J1939, SO_J1939_SEND_PRIO, &prio, sizeof(prio));
521
+
522
+
In this example, the priority is set to `3`, meaning the outgoing messages will
523
+
be sent with a moderate priority level.
524
+
525
+
``SO_J1939_ERRQUEUE``
526
+
~~~~~~~~~~~~~~~~~~~~~
527
+
528
+
The ``SO_J1939_ERRQUEUE`` option enables the socket to receive error messages
529
+
from the error queue, providing diagnostic information about transmission
530
+
failures, protocol violations, or other issues that occur during J1939
531
+
communication. Once this option is set, user space is required to handle
532
+
``MSG_ERRQUEUE`` messages.
533
+
534
+
Setting ``SO_J1939_ERRQUEUE`` to ``0`` will purge any currently present error
535
+
messages in the error queue. When enabled, error messages can be retrieved
536
+
using the ``recvmsg(2)`` system call.
537
+
538
+
When subscribing to the error queue, the following error events can be
539
+
accessed:
540
+
541
+
- **``J1939_EE_INFO_TX_ABORT``**: Transmission abort errors.
542
+
- **``J1939_EE_INFO_RX_RTS``**: Reception of RTS (Request to Send) control
543
+
frames.
544
+
- **``J1939_EE_INFO_RX_DPO``**: Reception of data packets with Data Page Offset
545
+
(DPO).
546
+
- **``J1939_EE_INFO_RX_ABORT``**: Reception abort errors.
547
+
548
+
The error queue can be used to correlate errors with specific message transfer
549
+
sessions using the session ID (``tskey``). The session ID is assigned via the
550
+
``SOF_TIMESTAMPING_OPT_ID`` flag, which is set by enabling the
551
+
``SO_TIMESTAMPING`` option.
552
+
553
+
If ``SO_J1939_ERRQUEUE`` is activated, the user is required to pull messages
554
+
from the error queue, meaning that using plain ``recv(2)`` is not sufficient
555
+
anymore. The user must use ``recvmsg(2)`` with appropriate flags to handle
556
+
error messages. Failure to do so can result in the socket becoming blocked with
557
+
unprocessed error messages in the queue.
558
+
559
+
It is **recommended** that ``SO_J1939_ERRQUEUE`` be used in combination with
560
+
``SO_TIMESTAMPING`` in most cases. This enables proper error handling along
561
+
with session tracking and timestamping, providing a more detailed analysis of
562
+
message transfers and errors.
563
+
564
+
The acceptable value **size** for this option is ``sizeof(int)``, and the value
565
+
is only differentiated between ``0`` and non-zero. A value of ``0`` disables
566
+
error queue reception and purges any existing error messages, while any
567
+
non-zero value enables it.
568
+
569
+
Example:
570
+
571
+
.. code-block:: c
572
+
573
+
int enable = 1; // Enable error queue reception
574
+
setsockopt(sock, SOL_CAN_J1939, SO_J1939_ERRQUEUE, &enable, sizeof(enable));
575
+
576
+
// Enable timestamping with session tracking via tskey
577
+
int timestamping = SOF_TIMESTAMPING_OPT_ID | SOF_TIMESTAMPING_TX_ACK |
578
+
SOF_TIMESTAMPING_TX_SCHED |
579
+
SOF_TIMESTAMPING_RX_SOFTWARE | SOF_TIMESTAMPING_OPT_CMSG;
580
+
setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, ×tamping,
581
+
sizeof(timestamping));
582
+
583
+
When enabled, error messages can be retrieved using ``recvmsg(2)``. By
584
+
combining ``SO_J1939_ERRQUEUE`` with ``SO_TIMESTAMPING`` (with
585
+
``SOF_TIMESTAMPING_OPT_ID`` and ``SOF_TIMESTAMPING_OPT_CMSG`` enabled), the
586
+
user can track message transfers, retrieve precise timestamps, and correlate
587
+
errors with specific sessions.
588
+
589
+
For more information on enabling timestamps and session tracking, refer to the
590
+
`SO_TIMESTAMPING` section.
591
+
592
+
``SO_TIMESTAMPING``
593
+
~~~~~~~~~~~~~~~~~~~
594
+
595
+
The ``SO_TIMESTAMPING`` option allows the socket to receive timestamps for
596
+
various events related to message transmissions and receptions in J1939. This
597
+
option is often used in combination with ``SO_J1939_ERRQUEUE`` to provide
598
+
detailed diagnostic information, session tracking, and precise timing data for
599
+
message transfers.
600
+
601
+
In J1939, all payloads provided by user space, regardless of size, are
602
+
processed by the kernel as **sessions**. This includes both single-frame
603
+
messages (up to 8 bytes) and multi-frame protocols such as the Transport
604
+
Protocol (TP) and Extended Transport Protocol (ETP). Even for small,
605
+
single-frame messages, the kernel creates a session to manage the transmission
606
+
and reception. The concept of sessions allows the kernel to manage various
607
+
aspects of the protocol, such as reassembling multi-frame messages and tracking
608
+
the status of transmissions.
609
+
610
+
When receiving extended error messages from the error queue, the error
611
+
information is delivered through a `struct sock_extended_err`, accessible via
612
+
the control message (``cmsg``) retrieved using the ``recvmsg(2)`` system call.
613
+
614
+
There are two typical origins for the extended error messages in J1939:
615
+
616
+
1. ``serr->ee_origin == SO_EE_ORIGIN_TIMESTAMPING``:
617
+
618
+
In this case, the `serr->ee_info` field will contain one of the following
619
+
timestamp types:
620
+
621
+
- ``SCM_TSTAMP_SCHED``: This timestamp is valid for Extended Transport
622
+
Protocol (ETP) transfers and simple transfers (8 bytes or less). It
623
+
indicates when a message or set of frames has been scheduled for
624
+
transmission.
625
+
626
+
- For simple transfers (8 bytes or less), it marks the point when the
627
+
message is queued and ready to be sent onto the CAN bus.
628
+
629
+
- For ETP transfers, it is sent after receiving a CTS (Clear to Send)
630
+
frame on the sender side, indicating that a new set of frames has been
631
+
scheduled for transmission.
632
+
633
+
- The Transport Protocol (TP) case is currently not implemented for this
634
+
timestamp.
635
+
636
+
- On the receiver side, the counterpart to this event for ETP is
637
+
represented by the ``J1939_EE_INFO_RX_DPO`` message, which indicates the
638
+
reception of a Data Page Offset (DPO) control frame.
639
+
640
+
- ``SCM_TSTAMP_ACK``: This timestamp indicates the acknowledgment of the
641
+
message or session.
642
+
643
+
- For simple transfers (8 bytes or less), it marks when the message has
644
+
been sent and an echo confirmation has been received from the CAN
645
+
controller, indicating that the frame was transmitted onto the bus.
646
+
647
+
- For multi-frame transfers (TP or ETP), it signifies that the entire
648
+
session has been acknowledged, typically after receiving the End of
649
+
Message Acknowledgment (EOMA) packet.
650
+
651
+
2. ``serr->ee_origin == SO_EE_ORIGIN_LOCAL``:
652
+
653
+
In this case, the `serr->ee_info` field will contain one of the following
654
+
J1939 stack-specific message types:
655
+
656
+
- ``J1939_EE_INFO_TX_ABORT``: This message indicates that the transmission
657
+
of a message or session was aborted. The cause of the abort can come from
658
+
various sources:
659
+
660
+
- **CAN stack failure**: The J1939 stack was unable to pass the frame to
661
+
the CAN framework for transmission.
662
+
663
+
- **Echo failure**: The J1939 stack did not receive an echo confirmation
664
+
from the CAN controller, meaning the frame may not have been successfully
665
+
transmitted to the CAN bus.
666
+
667
+
- **Protocol-level issues**: For multi-frame transfers (TP/ETP), this
668
+
could include protocol-related errors, such as an abort signaled by the
669
+
receiver or a timeout at the protocol level, which causes the session to
670
+
terminate prematurely.
671
+
672
+
- The corresponding error code is stored in ``serr->ee_data``
673
+
(``session->err`` on kernel side), providing additional details about
674
+
the specific reason for the abort.
675
+
676
+
- ``J1939_EE_INFO_RX_RTS``: This message indicates that the J1939 stack has
677
+
received a Request to Send (RTS) control frame, signaling the start of a
678
+
multi-frame transfer using the Transport Protocol (TP) or Extended
679
+
Transport Protocol (ETP).
680
+
681
+
- It informs the receiver that the sender is ready to transmit a
682
+
multi-frame message and includes details about the total message size
683
+
and the number of frames to be sent.
684
+
685
+
- Statistics such as ``J1939_NLA_TOTAL_SIZE``, ``J1939_NLA_PGN``,
686
+
``J1939_NLA_SRC_NAME``, and ``J1939_NLA_DEST_NAME`` are provided along
687
+
with the ``J1939_EE_INFO_RX_RTS`` message, giving detailed information
688
+
about the incoming transfer.
689
+
690
+
- ``J1939_EE_INFO_RX_DPO``: This message indicates that the J1939 stack has
691
+
received a Data Page Offset (DPO) control frame, which is part of the
692
+
Extended Transport Protocol (ETP).
693
+
694
+
- The DPO frame signals the continuation of an ETP multi-frame message by
695
+
indicating the offset position in the data being transferred. It helps
696
+
the receiver manage large data sets by identifying which portion of the
697
+
message is being received.
698
+
699
+
- It is typically paired with a corresponding ``SCM_TSTAMP_SCHED`` event
700
+
on the sender side, which indicates when the next set of frames is
701
+
scheduled for transmission.
702
+
703
+
- This event includes statistics such as ``J1939_NLA_BYTES_ACKED``, which
704
+
tracks the number of bytes acknowledged up to that point in the session.
705
+
706
+
- ``J1939_EE_INFO_RX_ABORT``: This message indicates that the reception of a
707
+
multi-frame message (Transport Protocol or Extended Transport Protocol) has
708
+
been aborted.
709
+
710
+
- The abort can be triggered by protocol-level errors such as timeouts, an
711
+
unexpected frame, or a specific abort request from the sender.
712
+
713
+
- This message signals that the receiver cannot continue processing the
714
+
transfer, and the session is terminated.
715
+
716
+
- The corresponding error code is stored in ``serr->ee_data``
717
+
(``session->err`` on kernel side ), providing further details about the
718
+
reason for the abort, such as protocol violations or timeouts.
719
+
720
+
- After receiving this message, the receiver discards the partially received
721
+
frames, and the multi-frame session is considered incomplete.
722
+
723
+
In both cases, if ``SOF_TIMESTAMPING_OPT_ID`` is enabled, ``serr->ee_data``
724
+
will be set to the session’s unique identifier (``session->tskey``). This
725
+
allows user space to track message transfers by their session identifier across
726
+
multiple frames or stages.
727
+
728
+
In all other cases, ``serr->ee_errno`` will be set to ``ENOMSG``, except for
729
+
the ``J1939_EE_INFO_TX_ABORT`` and ``J1939_EE_INFO_RX_ABORT`` cases, where the
730
+
kernel sets ``serr->ee_data`` to the error stored in ``session->err``. All
731
+
protocol-specific errors are converted to standard kernel error values and
732
+
stored in ``session->err``. These error values are unified across system calls
733
+
and ``serr->ee_errno``. Some of the known error values are described in the
734
+
`Error Codes in the J1939 Stack` section.
735
+
736
+
When the `J1939_EE_INFO_RX_RTS` message is provided, it will include the
737
+
following statistics for multi-frame messages (TP and ETP):
738
+
739
+
- ``J1939_NLA_TOTAL_SIZE``: Total size of the message in the session.
740
+
- ``J1939_NLA_PGN``: Parameter Group Number (PGN) identifying the message type.
741
+
- ``J1939_NLA_SRC_NAME``: 64-bit name of the source ECU.
742
+
- ``J1939_NLA_DEST_NAME``: 64-bit name of the destination ECU.
743
+
- ``J1939_NLA_SRC_ADDR``: 8-bit source address of the sending ECU.
744
+
- ``J1939_NLA_DEST_ADDR``: 8-bit destination address of the receiving ECU.
745
+
746
+
- For other messages (including single-frame messages), only the following
747
+
statistic is included:
748
+
749
+
- ``J1939_NLA_BYTES_ACKED``: Number of bytes successfully acknowledged in the
750
+
session.
751
+
752
+
The key flags for ``SO_TIMESTAMPING`` include:
753
+
754
+
- ``SOF_TIMESTAMPING_OPT_ID``: Enables the use of a unique session identifier
755
+
(``tskey``) for each transfer. This identifier helps track message transfers
756
+
and errors as distinct sessions in user space. When this option is enabled,
757
+
``serr->ee_data`` will be set to ``session->tskey``.
758
+
759
+
- ``SOF_TIMESTAMPING_OPT_CMSG``: Sends timestamp information through control
760
+
messages (``struct scm_timestamping``), allowing the application to retrieve
761
+
timestamps alongside the data.
762
+
763
+
- ``SOF_TIMESTAMPING_TX_SCHED``: Provides the timestamp for when a message is
764
+
scheduled for transmission (``SCM_TSTAMP_SCHED``).
765
+
766
+
- ``SOF_TIMESTAMPING_TX_ACK``: Provides the timestamp for when a message
767
+
transmission is fully acknowledged (``SCM_TSTAMP_ACK``).
768
+
769
+
- ``SOF_TIMESTAMPING_RX_SOFTWARE``: Provides timestamps for reception-related
770
+
events (e.g., ``J1939_EE_INFO_RX_RTS``, ``J1939_EE_INFO_RX_DPO``,
771
+
``J1939_EE_INFO_RX_ABORT``).
772
+
773
+
These flags enable detailed monitoring of message lifecycles, including
774
+
transmission scheduling, acknowledgments, reception timestamps, and gathering
775
+
detailed statistics about the communication session, especially for multi-frame
776
+
payloads like TP and ETP.
777
+
778
+
Example:
779
+
780
+
.. code-block:: c
781
+
782
+
// Enable timestamping with various options, including session tracking and
783
+
// statistics
784
+
int sock_opt = SOF_TIMESTAMPING_OPT_CMSG |
785
+
SOF_TIMESTAMPING_TX_ACK |
786
+
SOF_TIMESTAMPING_TX_SCHED |
787
+
SOF_TIMESTAMPING_OPT_ID |
788
+
SOF_TIMESTAMPING_RX_SOFTWARE;
789
+
790
+
setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, &sock_opt, sizeof(sock_opt));
791
+
792
+
793
+
425
794
Dynamic Addressing
426
795
------------------
427
796
···
995
458
};
996
459
997
460
sendto(sock, dat, sizeof(dat), 0, (const struct sockaddr *)&saddr, sizeof(saddr));
461
+
462
+
463
+
Error Codes in the J1939 Stack
464
+
------------------------------
465
+
466
+
This section lists all potential kernel error codes that can be exposed to user
467
+
space when interacting with the J1939 stack. It includes both standard error
468
+
codes and those derived from protocol-specific abort codes.
469
+
470
+
- ``EAGAIN``: Operation would block; retry may succeed. One common reason is
471
+
that an active TP or ETP session exists, and an attempt was made to start a
472
+
new overlapping TP or ETP session between the same peers.
473
+
474
+
- ``ENETDOWN``: Network is down. This occurs when the CAN interface is switched
475
+
to the "down" state.
476
+
477
+
- ``ENOBUFS``: No buffer space available. This error occurs when the CAN
478
+
interface's transmit (TX) queue is full, and no more messages can be queued.
479
+
480
+
- ``EOVERFLOW``: Value too large for defined data type. In J1939, this can
481
+
happen if the requested data lies outside of the queued buffer. For example,
482
+
if a CTS (Clear to Send) requests an offset not available in the kernel buffer
483
+
because user space did not provide enough data.
484
+
485
+
- ``EBUSY``: Device or resource is busy. For example, this occurs if an
486
+
identical session is already active and the stack is unable to recover from
487
+
the condition.
488
+
489
+
- ``EACCES``: Permission denied. This error can occur, for example, when
490
+
attempting to send broadcast messages, but the socket is not configured with
491
+
``SO_BROADCAST``.
492
+
493
+
- ``EADDRNOTAVAIL``: Address not available. This error occurs in cases such as:
494
+
495
+
- When attempting to use ``getsockname(2)`` to retrieve the peer's address,
496
+
but the socket is not connected.
497
+
498
+
- When trying to send data to or from a NAME, but address claiming for the
499
+
NAME was not performed or detected by the stack.
500
+
501
+
- ``EBADFD``: File descriptor in bad state. This error can occur if:
502
+
503
+
- Attempting to send data to an unbound socket.
504
+
505
+
- The socket is bound but has no source name, and the source address is
506
+
``J1939_NO_ADDR``.
507
+
508
+
- The ``can_ifindex`` is incorrect.
509
+
510
+
- ``EFAULT``: Bad address. Occurs mostly when the stack can't copy from or to a
511
+
sockptr, when there is insufficient data from user space, or when the buffer
512
+
provided by user space is not large enough for the requested data.
513
+
514
+
- ``EINTR``: A signal occurred before any data was transmitted; see ``signal(7)``.
515
+
516
+
- ``EINVAL``: Invalid argument passed. For example:
517
+
518
+
- ``msg->msg_namelen`` is less than ``J1939_MIN_NAMELEN``.
519
+
520
+
- ``addr->can_family`` is not equal to ``AF_CAN``.
521
+
522
+
- An incorrect PGN was provided.
523
+
524
+
- ``ENODEV``: No such device. This happens when the CAN network device cannot
525
+
be found for the provided ``can_ifindex`` or if ``can_ifindex`` is 0.
526
+
527
+
- ``ENOMEM``: Out of memory. Typically related to issues with memory allocation
528
+
in the stack.
529
+
530
+
- ``ENOPROTOOPT``: Protocol not available. This can occur when using
531
+
``getsockopt(2)`` or ``setsockopt(2)`` if the requested socket option is not
532
+
available.
533
+
534
+
- ``EDESTADDRREQ``: Destination address required. This error occurs:
535
+
536
+
- In the case of ``connect(2)``, if the ``struct sockaddr *uaddr`` is ``NULL``.
537
+
538
+
- In the case of ``send*(2)``, if there is an attempt to send an ETP message
539
+
to a broadcast address.
540
+
541
+
- ``EDOM``: Argument out of domain. This error may happen if attempting to send
542
+
a TP or ETP message to a PGN that is reserved for control PGNs for TP or ETP
543
+
operations.
544
+
545
+
- ``EIO``: I/O error. This can occur if the amount of data provided to the
546
+
socket for a TP or ETP session does not match the announced amount of data for
547
+
the session.
548
+
549
+
- ``ENOENT``: No such file or directory. This can happen when the stack
550
+
attempts to transfer CTS or EOMA but cannot find a matching receiving socket
551
+
anymore.
552
+
553
+
- ``ENOIOCTLCMD``: No ioctls are available for the socket layer.
554
+
555
+
- ``EPERM``: Operation not permitted. For example, this can occur if a
556
+
requested action requires ``CAP_NET_ADMIN`` privileges.
557
+
558
+
- ``ENETUNREACH``: Network unreachable. Most likely, this occurs when frames
559
+
cannot be transmitted to the CAN bus.
560
+
561
+
- ``ETIME``: Timer expired. This can happen if a timeout occurs while
562
+
attempting to send a simple message, for example, when an echo message from
563
+
the controller is not received.
564
+
565
+
- ``EPROTO``: Protocol error.
566
+
567
+
- Used for various protocol-level errors in J1939, including:
568
+
569
+
- Duplicate sequence number.
570
+
571
+
- Unexpected EDPO or ECTS packet.
572
+
573
+
- Invalid PGN or offset in EDPO/ECTS.
574
+
575
+
- Number of EDPO packets exceeded CTS allowance.
576
+
577
+
- Any other protocol-level error.
578
+
579
+
- ``EMSGSIZE``: Message too long.
580
+
581
+
- ``ENOMSG``: No message available.
582
+
583
+
- ``EALREADY``: The ECU is already engaged in one or more connection-managed
584
+
sessions and cannot support another.
585
+
586
+
- ``EHOSTUNREACH``: A timeout occurred, and the session was aborted.
587
+
588
+
- ``EBADMSG``: CTS (Clear to Send) messages were received during an active data
589
+
transfer, causing an abort.
590
+
591
+
- ``ENOTRECOVERABLE``: The maximum retransmission request limit was reached,
592
+
and the session cannot recover.
593
+
594
+
- ``ENOTCONN``: An unexpected data transfer packet was received.
595
+
596
+
- ``EILSEQ``: A bad sequence number was received, and the software could not
597
+
recover.
598
+
+15
-36
drivers/net/can/c_can/c_can_platform.c
+15
-36
drivers/net/can/c_can/c_can_platform.c
···
269
269
270
270
/* get the appropriate clk */
271
271
clk = devm_clk_get(&pdev->dev, NULL);
272
-
if (IS_ERR(clk)) {
273
-
ret = PTR_ERR(clk);
274
-
goto exit;
275
-
}
272
+
if (IS_ERR(clk))
273
+
return PTR_ERR(clk);
276
274
277
275
/* get the platform data */
278
276
irq = platform_get_irq(pdev, 0);
279
-
if (irq < 0) {
280
-
ret = irq;
281
-
goto exit;
282
-
}
277
+
if (irq < 0)
278
+
return irq;
283
279
284
280
addr = devm_platform_get_and_ioremap_resource(pdev, 0, &mem);
285
-
if (IS_ERR(addr)) {
286
-
ret = PTR_ERR(addr);
287
-
goto exit;
288
-
}
281
+
if (IS_ERR(addr))
282
+
return PTR_ERR(addr);
289
283
290
284
/* allocate the c_can device */
291
285
dev = alloc_c_can_dev(drvdata->msg_obj_num);
292
-
if (!dev) {
293
-
ret = -ENOMEM;
294
-
goto exit;
295
-
}
286
+
if (!dev)
287
+
return -ENOMEM;
296
288
297
289
priv = netdev_priv(dev);
298
290
switch (drvdata->id) {
···
316
324
/* Check if we need custom RAMINIT via syscon. Mostly for TI
317
325
* platforms. Only supported with DT boot.
318
326
*/
319
-
if (np && of_property_read_bool(np, "syscon-raminit")) {
327
+
if (np && of_property_present(np, "syscon-raminit")) {
328
+
unsigned int args[2];
320
329
u32 id;
321
330
struct c_can_raminit *raminit = &priv->raminit_sys;
322
331
323
332
ret = -EINVAL;
324
-
raminit->syscon = syscon_regmap_lookup_by_phandle(np,
325
-
"syscon-raminit");
333
+
raminit->syscon = syscon_regmap_lookup_by_phandle_args(np,
334
+
"syscon-raminit",
335
+
2, args);
326
336
if (IS_ERR(raminit->syscon)) {
327
-
/* can fail with -EPROBE_DEFER */
328
337
ret = PTR_ERR(raminit->syscon);
329
-
free_c_can_dev(dev);
330
-
return ret;
331
-
}
332
-
333
-
if (of_property_read_u32_index(np, "syscon-raminit", 1,
334
-
&raminit->reg)) {
335
-
dev_err(&pdev->dev,
336
-
"couldn't get the RAMINIT reg. offset!\n");
337
338
goto exit_free_device;
338
339
}
339
340
340
-
if (of_property_read_u32_index(np, "syscon-raminit", 2,
341
-
&id)) {
342
-
dev_err(&pdev->dev,
343
-
"couldn't get the CAN instance ID\n");
344
-
goto exit_free_device;
345
-
}
341
+
raminit->reg = args[0];
342
+
id = args[1];
346
343
347
344
if (id >= drvdata->raminit_num) {
348
345
dev_err(&pdev->dev,
···
377
396
pm_runtime_disable(priv->device);
378
397
exit_free_device:
379
398
free_c_can_dev(dev);
380
-
exit:
381
-
dev_err(&pdev->dev, "probe failed\n");
382
399
383
400
return ret;
384
401
}
+34
-1
drivers/net/can/flexcan/flexcan-core.c
+34
-1
drivers/net/can/flexcan/flexcan-core.c
···
386
386
FLEXCAN_QUIRK_SUPPORT_RX_MAILBOX_RTR,
387
387
};
388
388
389
+
static const struct flexcan_devtype_data nxp_s32g2_devtype_data = {
390
+
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
391
+
FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_BROKEN_PERR_STATE |
392
+
FLEXCAN_QUIRK_USE_RX_MAILBOX | FLEXCAN_QUIRK_SUPPORT_FD |
393
+
FLEXCAN_QUIRK_SUPPORT_ECC | FLEXCAN_QUIRK_NR_IRQ_3 |
394
+
FLEXCAN_QUIRK_SUPPORT_RX_MAILBOX |
395
+
FLEXCAN_QUIRK_SUPPORT_RX_MAILBOX_RTR |
396
+
FLEXCAN_QUIRK_SECONDARY_MB_IRQ,
397
+
};
398
+
389
399
static const struct can_bittiming_const flexcan_bittiming_const = {
390
400
.name = DRV_NAME,
391
401
.tseg1_min = 4,
···
1772
1762
goto out_free_irq_boff;
1773
1763
}
1774
1764
1765
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
1766
+
err = request_irq(priv->irq_secondary_mb,
1767
+
flexcan_irq, IRQF_SHARED, dev->name, dev);
1768
+
if (err)
1769
+
goto out_free_irq_err;
1770
+
}
1771
+
1775
1772
flexcan_chip_interrupts_enable(dev);
1776
1773
1777
1774
netif_start_queue(dev);
1778
1775
1779
1776
return 0;
1780
1777
1778
+
out_free_irq_err:
1779
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
1780
+
free_irq(priv->irq_err, dev);
1781
1781
out_free_irq_boff:
1782
-
free_irq(priv->irq_boff, dev);
1782
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
1783
+
free_irq(priv->irq_boff, dev);
1783
1784
out_free_irq:
1784
1785
free_irq(dev->irq, dev);
1785
1786
out_can_rx_offload_disable:
···
1814
1793
1815
1794
netif_stop_queue(dev);
1816
1795
flexcan_chip_interrupts_disable(dev);
1796
+
1797
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
1798
+
free_irq(priv->irq_secondary_mb, dev);
1817
1799
1818
1800
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
1819
1801
free_irq(priv->irq_err, dev);
···
2065
2041
{ .compatible = "fsl,vf610-flexcan", .data = &fsl_vf610_devtype_data, },
2066
2042
{ .compatible = "fsl,ls1021ar2-flexcan", .data = &fsl_ls1021a_r2_devtype_data, },
2067
2043
{ .compatible = "fsl,lx2160ar1-flexcan", .data = &fsl_lx2160a_r1_devtype_data, },
2044
+
{ .compatible = "nxp,s32g2-flexcan", .data = &nxp_s32g2_devtype_data, },
2068
2045
{ /* sentinel */ },
2069
2046
};
2070
2047
MODULE_DEVICE_TABLE(of, flexcan_of_match);
···
2208
2183
priv->irq_err = platform_get_irq(pdev, 2);
2209
2184
if (priv->irq_err < 0) {
2210
2185
err = priv->irq_err;
2186
+
goto failed_platform_get_irq;
2187
+
}
2188
+
}
2189
+
2190
+
if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
2191
+
priv->irq_secondary_mb = platform_get_irq_byname(pdev, "mb-1");
2192
+
if (priv->irq_secondary_mb < 0) {
2193
+
err = priv->irq_secondary_mb;
2211
2194
goto failed_platform_get_irq;
2212
2195
}
2213
2196
}
+5
drivers/net/can/flexcan/flexcan.h
+5
drivers/net/can/flexcan/flexcan.h
···
70
70
#define FLEXCAN_QUIRK_SUPPORT_RX_FIFO BIT(16)
71
71
/* Setup stop mode with ATF SCMI protocol to support wakeup */
72
72
#define FLEXCAN_QUIRK_SETUP_STOP_MODE_SCMI BIT(17)
73
+
/* Device has two separate interrupt lines for two mailbox ranges, which
74
+
* both need to have an interrupt handler registered.
75
+
*/
76
+
#define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
73
77
74
78
struct flexcan_devtype_data {
75
79
u32 quirks; /* quirks needed for different IP cores */
···
111
107
112
108
int irq_boff;
113
109
int irq_err;
110
+
int irq_secondary_mb;
114
111
115
112
/* IPC handle when setup stop mode by System Controller firmware(scfw) */
116
113
struct imx_sc_ipc *sc_ipc_handle;
-5
drivers/net/can/rockchip/rockchip_canfd-core.c
-5
drivers/net/can/rockchip/rockchip_canfd-core.c
···
236
236
{
237
237
u32 reg;
238
238
239
-
/* TXE FIFO */
240
-
reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
241
-
reg |= RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE;
242
-
rkcanfd_write(priv, RKCANFD_REG_RX_FIFO_CTRL, reg);
243
-
244
239
/* RX FIFO */
245
240
reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
246
241
reg |= RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE;
+5
drivers/net/can/usb/gs_usb.c
+5
drivers/net/can/usb/gs_usb.c
···
43
43
#define USB_XYLANTA_SAINT3_VENDOR_ID 0x16d0
44
44
#define USB_XYLANTA_SAINT3_PRODUCT_ID 0x0f30
45
45
46
+
#define USB_CANNECTIVITY_VENDOR_ID 0x1209
47
+
#define USB_CANNECTIVITY_PRODUCT_ID 0xca01
48
+
46
49
/* Timestamp 32 bit timer runs at 1 MHz (1 µs tick). Worker accounts
47
50
* for timer overflow (will be after ~71 minutes)
48
51
*/
···
1549
1546
USB_ABE_CANDEBUGGER_FD_PRODUCT_ID, 0) },
1550
1547
{ USB_DEVICE_INTERFACE_NUMBER(USB_XYLANTA_SAINT3_VENDOR_ID,
1551
1548
USB_XYLANTA_SAINT3_PRODUCT_ID, 0) },
1549
+
{ USB_DEVICE_INTERFACE_NUMBER(USB_CANNECTIVITY_VENDOR_ID,
1550
+
USB_CANNECTIVITY_PRODUCT_ID, 0) },
1552
1551
{} /* Terminating entry */
1553
1552
};
1554
1553
+2
-1
include/uapi/linux/can.h
+2
-1
include/uapi/linux/can.h
···
182
182
/*
183
183
* defined bits for canxl_frame.flags
184
184
*
185
-
* The canxl_frame.flags element contains two bits CANXL_XLF and CANXL_SEC
185
+
* The canxl_frame.flags element contains three bits CANXL_[XLF|SEC|RRS]
186
186
* and shares the relative position of the struct can[fd]_frame.len element.
187
187
* The CANXL_XLF bit ALWAYS needs to be set to indicate a valid CAN XL frame.
188
188
* As a side effect setting this bit intentionally breaks the length checks
···
192
192
*/
193
193
#define CANXL_XLF 0x80 /* mandatory CAN XL frame flag (must always be set!) */
194
194
#define CANXL_SEC 0x01 /* Simple Extended Content (security/segmentation) */
195
+
#define CANXL_RRS 0x02 /* Remote Request Substitution */
195
196
196
197
/* the 8-bit VCID is optionally placed in the canxl_frame.prio element */
197
198
#define CANXL_VCID_OFFSET 16 /* bit offset of VCID in prio element */