At high bit rates, the propagation delay from the TX pin to the RX pin
of the transceiver causes measurement errors: the sample point on the
RX pin might occur on the previous bit.
This issue is addressed in ISO 11898-1 section 11.3.3 "Transmitter
delay compensation" (TDC).
This patch brings command line support to nine TDC parameters which
were recently added to the kernel's CAN netlink interface in order to
implement TDC:
- IFLA_CAN_TDC_TDCV_MIN: Transmitter Delay Compensation Value
minimum value
- IFLA_CAN_TDC_TDCV_MAX: Transmitter Delay Compensation Value
maximum value
- IFLA_CAN_TDC_TDCO_MIN: Transmitter Delay Compensation Offset
minimum value
- IFLA_CAN_TDC_TDCO_MAX: Transmitter Delay Compensation Offset
maximum value
- IFLA_CAN_TDC_TDCF_MIN: Transmitter Delay Compensation Filter
window minimum value
- IFLA_CAN_TDC_TDCF_MAX: Transmitter Delay Compensation Filter
window maximum value
- IFLA_CAN_TDC_TDCV: Transmitter Delay Compensation Value
- IFLA_CAN_TDC_TDCO: Transmitter Delay Compensation Offset
- IFLA_CAN_TDC_TDCF: Transmitter Delay Compensation Filter window
All those new parameters are nested together into the attribute
IFLA_CAN_TDC.
The TDC parameters extend the FD parameters. As such, the TDC
parameters must be specified together the "fd on" flag.
When "fd on" flag is provided, a tdc-mode parameter allows to specify
how to operate. Valid options for tdc-mode are:
* auto: the transmitter dynamically measures TDCV for each of the
transmitted frames. As such, TDCV can not be manually provided. In
this mode, the user must specify TDCO and may also specify TDCF if
supported.
* manual: use a static TDCV provided by the user. In this mode, the
user must specify both TDCV and TDCO and may also specify TDCF if
supported.
* off: TDC is explicitly disabled.
* tdc-mode parameter omitted (default mode): the kernel decides
whether TDC should be enabled or not and if so, it calculates the
TDC values. TDC parameters are an expert option and the average
user is not expected to provide those, thus the presence of this
"default mode".
If the fd flag is omitted, all the FD values (including TDC values)
remain unchanged.
If "fd off" flag is specified, all FD values (including TDC values)
are zeroed.
TDCV is always reported in manual mode. In auto mode, TDCV is reported
only if the value is available. Especially, the TDCV might not be
available if the controller has no feature to report it or if the
value in not yet available (i.e. no data sent yet and measurement did
not occur).
TDCF is reported only if tdcf_max is not zero (i.e. if supported by
the controller).
For reference, here are a few samples of how the output looks like:
| $ ip link set can0 type can bitrate 1000000 dbitrate 8000000 fd on tdco 7 tdcf 8 tdc-mode auto
| $ ip --details link show can0
| 1: can0: <NOARP,ECHO> mtu 72 qdisc noop state DOWN mode DEFAULT group default qlen 10
| link/can promiscuity 0 minmtu 0 maxmtu 0
| can <FD,TDC-AUTO> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
| bitrate 1000000 sample-point 0.750
| tq 12 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1 brp 1
| ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
| dbitrate 8000000 dsample-point 0.700
| dtq 12 dprop-seg 3 dphase-seg1 3 dphase-seg2 3 dsjw 1 dbrp 1
| tdco 7 tdcf 8
| ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 dbrp_inc 1
| tdco 0..127 tdcf 0..127
| clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
| $ ip --details --json --pretty link show can0
| [ {
| "ifindex": 1,
| "ifname": "can0",
| "flags": [ "NOARP","ECHO" ],
| "mtu": 72,
| "qdisc": "noop",
| "operstate": "DOWN",
| "linkmode": "DEFAULT",
| "group": "default",
| "txqlen": 10,
| "link_type": "can",
| "promiscuity": 0,
| "min_mtu": 0,
| "max_mtu": 0,
| "linkinfo": {
| "info_kind": "can",
| "info_data": {
| "ctrlmode": [ "FD","TDC-AUTO" ],
| "state": "STOPPED",
| "berr_counter": {
| "tx": 0,
| "rx": 0
| },
| "restart_ms": 0,
| "bittiming": {
| "bitrate": 1000000,
| "sample_point": "0.750",
| "tq": 12,
| "prop_seg": 29,
| "phase_seg1": 30,
| "phase_seg2": 20,
| "sjw": 1,
| "brp": 1
| },
| "bittiming_const": {
| "name": "ES582.1/ES584.1",
| "tseg1": {
| "min": 2,
| "max": 256
| },
| "tseg2": {
| "min": 2,
| "max": 128
| },
| "sjw": {
| "min": 1,
| "max": 128
| },
| "brp": {
| "min": 1,
| "max": 512
| },
| "brp_inc": 1
| },
| "data_bittiming": {
| "bitrate": 8000000,
| "sample_point": "0.700",
| "tq": 12,
| "prop_seg": 3,
| "phase_seg1": 3,
| "phase_seg2": 3,
| "sjw": 1,
| "brp": 1,
| "tdc": {
| "tdco": 7,
| "tdcf": 8
| }
| },
| "data_bittiming_const": {
| "name": "ES582.1/ES584.1",
| "tseg1": {
| "min": 2,
| "max": 32
| },
| "tseg2": {
| "min": 1,
| "max": 16
| },
| "sjw": {
| "min": 1,
| "max": 8
| },
| "brp": {
| "min": 1,
| "max": 32
| },
| "brp_inc": 1,
| "tdc": {
| "tdco": {
| "min": 0,
| "max": 127
| },
| "tdcf": {
| "min": 0,
| "max": 127
| }
| }
| },
| "clock": 80000000
| }
| },
| "num_tx_queues": 1,
| "num_rx_queues": 1,
| "gso_max_size": 65536,
| "gso_max_segs": 65535
| } ]
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
Report the value of the bit-rate prescaler (brp) for both the nominal
and the data bittiming.
Currently, only the constant brp values (brp_{min,max,inc}) are being
reported. Also, brp is the only member of struct can_bittiming not
being reported.
Noticeably, brp could be calculated by hand from the other bittiming
parameters with below formula:
brp = clock * tq / 1000000000
with clock in hertz and tq in nano second (thus the need of a 1
billion factor to convert it back to second).
But because above formula is not so trivial to remember and is
subjected to rounding errors, it makes sense to directly output
{d,}bpr.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
Current implementation heavily relies on some "if (is_json_context())"
switches to decide the context and then does some print_*(PRINT_JSON,
...) when in json context and some fprintf(...) else.
Furthermore, current implementation uses either print_int() or the
conversion specifier %d to print unsigned integers.
This patch factorizes each pairs of print_*(PRINT_JSON, ...) and
fprintf() into a single print_*(PRINT_ANY, ...) call. While doing this
replacement, it uses proper unsigned function print_uint() as well as
the conversion specifier %u when the parameter is an unsigned integer.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
This patch only does cleanup and do not introduce any functional
changes.
We do some code refactoring of print_ctrlmode() in prevision of the
upcoming patch:
- remove the first argument of print_ctrlmode(). It is a pointer to
FILE and is never used.
- add a new function argument: enum output_type t in order to
specify the output type (i.e. PRINT_{FP,JSON,ANY}).
- add a new function argument: const char *key in order to specify
the name of the json array (e.g. "ctrlmode").
- replace the _PF() macro with the print_flag() function to increase
readability.
- directly return if none of the flags are set (previously, this
check was done before calling the function).
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
The configuration ranges in print_usage() are taken from "Table 8 -
Time segments' minimum configuration ranges" in section 11.3.1.2
"Configuration of the bit time parameters" of ISO 11898-1.
The standard clearly specifies that "implementations may allow time
segments that exceed the minimum required configuration ranges
specified in Table 8".
Because no maximum ranges are given in the standard, all given ranges
{ a..b } are simply replaced with { NUMBER }.
The actual ranges are specific to each device and can be confirmed
doing:
$ ip --details link show can0
1: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
link/can promiscuity 0 minmtu 0 maxmtu 0
can state STOPPED restart-ms 0
ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-inc 1
ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 dbrp-inc 1
clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
Finally, the unit (bps, tq, ns or ms) are given. The rationale to add
the units is that the TDC parameters (that will be introduced in the
upcoming patches) are measured in a different unit than the other
bittiming parameters: clock period (a.k.a. minimum time quantum)
instead of time quantum. Adding the units disambiguates things.
For reference, before the change:
$ ip link set can0 type can help
Usage: ip link set DEVICE type can
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
[ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] |
[ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
[ loopback { on | off } ]
[ listen-only { on | off } ]
[ triple-sampling { on | off } ]
[ one-shot { on | off } ]
[ berr-reporting { on | off } ]
[ fd { on | off } ]
[ fd-non-iso { on | off } ]
[ presume-ack { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
[ termination { 0..65535 } ]
Where: BITRATE := { 1..1000000 }
SAMPLE-POINT := { 0.000..0.999 }
TQ := { NUMBER }
PROP-SEG := { 1..8 }
PHASE-SEG1 := { 1..8 }
PHASE-SEG2 := { 1..8 }
SJW := { 1..4 }
RESTART-MS := { 0 | NUMBER }
...and after it:
$ ip link set can0 type can help
Usage: ip link set DEVICE type can
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
[ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] |
[ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
[ loopback { on | off } ]
[ listen-only { on | off } ]
[ triple-sampling { on | off } ]
[ one-shot { on | off } ]
[ berr-reporting { on | off } ]
[ fd { on | off } ]
[ fd-non-iso { on | off } ]
[ presume-ack { on | off } ]
[ cc-len8-dlc { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
[ termination { 0..65535 } ]
Where: BITRATE := { NUMBER in bps }
SAMPLE-POINT := { 0.000..0.999 }
TQ := { NUMBER in ns }
PROP-SEG := { NUMBER in tq }
PHASE-SEG1 := { NUMBER in tq }
PHASE-SEG2 := { NUMBER in tq }
SJW := { NUMBER in tq }
RESTART-MS := { 0 | NUMBER in ms }
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: David Ahern <dsahern@kernel.org>
The len8_dlc element is filled by the CAN interface driver and used for CAN
frame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is
supported by the driver and enabled via netlink configuration interface.
Add the command line support for cc-len8-dlc for Linux 5.11+
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David Ahern <dsahern@kernel.org>
The command
ip -details link show can0
prints in the last line the value of the clock frequency attached
to the name of the following value "numtxqueues", e.g.
clock 49500000numtxqueues 1 numrxqueues 1 gso_max_size
65536 gso_max_segs 65535
Add the missing space after the clock value.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Previously the CAN state was always printed in human-readable txt format,
resulting in invalid JSON.
Signed-off-by: Martin Jeřábek <martin.jerabek01@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
These are primarily fixes for "string is not string literal" warnings
/ errors (with -Werror -Wformat-nonliteral). This should be a no-op
change. I had to replace couple of print helper functions with the
code they call as it was becoming harder to eliminate these warnings,
however these helpers were used only at couple of places, so no
major change as such.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
can_state_names array contains at most CAN_STATE_MAX fields, so allowing
an index to it to be equal to that number is wrong. While here, also
make sure the array is indeed that big so nothing bad happens if
CAN_STATE_MAX ever increases.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Use the new helper functions rta_getattr_u* instead of direct
cast of RTA_DATA(). Where RTA_DATA() is a structure, then remove
the unnecessary cast since RTA_DATA() is void *
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This big patch was compiled by vimgrepping for memset calls and changing
to C99 initializer if applicable. One notable exception is the
initialization of union bpf_attr in tc/tc_bpf.c: changing it would break
for older gcc versions (at least <=3.4.6).
Calls to memset for struct rtattr pointer fields for parse_rtattr*()
were just dropped since they are not needed.
The changes here allowed the compiler to discover some unused variables,
so get rid of them, too.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
This patch makes CAN_CTRLMODE_FD_NON_ISO netlink feature configurable.
During the CAN FD standardization process within the ISO it turned out that
the failure detection capability has to be improved.
The CAN in Automation organization (CiA) defined the already implemented CAN
FD controllers as 'non-ISO' and the upcoming improved CAN FD controllers as
'ISO' compliant. See at http://www.can-cia.com/index.php?id=1937
Starting with the - currently non-ISO - driver for M_CAN v3.0.1 introduced in
Linux 3.18 this bit needs to be propagated to userspace. In future drivers this
bit will become configurable depending on the CAN FD controllers capabilities.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This patch makes CAN_CTRLMODE_PRESUME_ACK netlink feature configurable.
When enabled, the feature sets CAN controller in mode in which
acknowledgement absence is ignored.
Signed-off-by: Nikita Edward Baruzdin <nebaruzdin@gmail.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Allow to print particular link type usage by:
ip link help [TYPE]
Currently to print usage for some link type it is needed
to use the following way:
ip link { add | del | set } type TYPE help
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
For CAN FD a new set of bittiming configuration and enabling functions for the
data section is provided by the CAN driver infrastructure.
This patch allows to configure the newly introduced CAN FD properties.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When preparing a patch for CAN FD support these white space issues showed up.
Fix it in the current code to be able to provide a proper follow up patch.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This patch improves many error messages as follows:
- For incorrect parameters, show the value of the offending parameter, rather than just say that it is incorrect
- Rephrased messages for clarity
- Rephrased to more `mainstream' english
Signed-off-by: Kees van Reeuwijk <reeuwijk@few.vu.nl>
This patch uses the new features of the kernel's netlink CAN interface
making the bus-error reporting configurable and allowing to retrieve
the CAN TX and RX bus error counters via netlink interface. Here is the
output of my test session showing how to use them:
# ip link set can0 up type can bitrate 500000 berr-reporting on
# ip -d -s link show can0
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can <BERR-REPORTING> state ERROR-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0
CAN bus error counter values ^^^^^^^^^^^
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 54101 0 1 1 0
RX: bytes packets errors dropped overrun mcast
432808 54101 54101 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
# ifconfig can0 down
# ip link set can0 up type can berr-reporting off
# candump -t d any,0:0,#FFFFFFFF
(0.000000) can0 20000004 [8] 00 08 00 00 00 00 60 00 ERRORFRAME
(0.000474) can0 20000004 [8] 00 20 00 00 00 00 80 00 ERRORFRAME
^^ ^^
\ \___ rxerr
\_____ txerr
Furthermore, the missing support for one-shot mode has been added.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>