In the current code, if the user configures a bitrate, a default SJW
value of 1 is used. If the user configures both a bitrate and a SJW
value, can_calc_bittiming() silently limits the SJW value to SJW max
and TSEG2.

We came to the conclusion that if the user provided an invalid SJW
value, it's best to bail out and inform the user [1].

[1] https://lore.kernel.org/all/CAMZ6RqKqhmTgUZiwe5uqUjBDnhhC2iOjZ791+Y845btJYwVDKg@mail.gmail.com

Further the ISO 11898-1:2015 standard mandates that "SJW shall be less
than or equal to the minimum of these two items: Phase_Seg1 and
Phase_Seg2." [2] The current code is missing that check.

[2] https://lore.kernel.org/all/BL3PR11MB64844E3FC13C55433CDD0B3DFB449@BL3PR11MB6484.namprd11.prod.outlook.com

The previous patches introduced
1) can_sjw_set_default() - sets a default value for SJW if unset
2) can_sjw_check() - implements a SJW check against SJW max, Phase
   Seg1 and Phase Seg2. In the error case this function reports the error
   to user space via netlink.

Replace both the open-coded SJW default setting and the open-coded and
insufficient checks of SJW with the helper functions
can_sjw_set_default() and can_sjw_check().

Link: https://lore.kernel.org/all/20230202110854.2318594-16-mkl@pengutronix.de
Link: https://lore.kernel.org/all/CAMZ6RqKqhmTgUZiwe5uqUjBDnhhC2iOjZ791+Y845btJYwVDKg@mail.gmail.com
Link: https://lore.kernel.org/all/BL3PR11MB64844E3FC13C55433CDD0B3DFB449@BL3PR11MB6484.namprd11.prod.outlook.comSuggested-by: NThomas Kopp <Thomas.Kopp@microchip.com>
Suggested-by: NVincent Mailhol <vincent.mailhol@gmail.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

"The (Re-)Synchronization Jump Width (SJW) defines how far a
 resynchronization may move the Sample Point inside the limits defined
 by the Phase Buffer Segments to compensate for edge phase errors." [1]

In other words, this means that the SJW parameter controls the
tolerance of the CAN controller to frequency errors compared to other
CAN controllers.

If the user space does not provide an SJW parameter, the kernel
chooses a default value of 1. This has proven to be a good default
value for classic CAN controllers, but no longer for modern CAN-FD
controllers.

In the past there were CAN controllers like the sja1000 with a rather
limited range of bit timing parameters. For the standard bit rates
this results in the following bit timing parameters:

| Bit timing parameters for sja1000 with 8.000000 MHz ref clock
|                     _----+--------------=> tseg1: 1 …   16
|                    /    /     _---------=> tseg2: 1 …    8
|                   |    |     /    _-----=> sjw:   1 …    4
|                   |    |    |    /    _-=> brp:   1 …   64 (inc: 1)
|                   |    |    |   |    /
|  nominal          |    |    |   |   |     real  Bitrt    nom   real   SampP
|  Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP  Bitrate  Error  SampP  SampP   Error  BTR0 BTR1
|  1000000    125   2    3    2   1   1  1000000   0.0%  75.0%  75.0%   0.0%   0x00 0x14
|   800000    125   3    4    2   1   1   800000   0.0%  80.0%  80.0%   0.0%   0x00 0x16
|   666666    125   4    4    3   1   1   666666   0.0%  80.0%  75.0%   6.2%   0x00 0x27
|   500000    125   6    7    2   1   1   500000   0.0%  87.5%  87.5%   0.0%   0x00 0x1c
|   250000    250   6    7    2   1   2   250000   0.0%  87.5%  87.5%   0.0%   0x01 0x1c
|   125000    500   6    7    2   1   4   125000   0.0%  87.5%  87.5%   0.0%   0x03 0x1c
|   100000    625   6    7    2   1   5   100000   0.0%  87.5%  87.5%   0.0%   0x04 0x1c
|    83333    750   6    7    2   1   6    83333   0.0%  87.5%  87.5%   0.0%   0x05 0x1c
|    50000   1250   6    7    2   1  10    50000   0.0%  87.5%  87.5%   0.0%   0x09 0x1c
|    33333   1875   6    7    2   1  15    33333   0.0%  87.5%  87.5%   0.0%   0x0e 0x1c
|    20000   3125   6    7    2   1  25    20000   0.0%  87.5%  87.5%   0.0%   0x18 0x1c
|    10000   6250   6    7    2   1  50    10000   0.0%  87.5%  87.5%   0.0%   0x31 0x1c

The attentive reader will notice that the SJW is 1 in most cases,
while the Seg2 phase is 2. Both values are given in TQ units, which in
turn is a duration in nanoseconds.

For example the 500 kbit/s configuration:

|  nominal                                  real  Bitrt    nom   real   SampP
|  Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP  Bitrate  Error  SampP  SampP   Error  BTR0 BTR1
|   500000    125   6    7    2   1   1   500000   0.0%  87.5%  87.5%   0.0%   0x00 0x1c

the TQ is 125ns, the Phase Seg2 is "2" (== 250ns), the SJW is "1" (==
125 ns).

Looking at a more modern CAN controller like a mcp2518fd, it has wider
bit timing registers.

| Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock
|                     _----+--------------=> tseg1: 2 …  256
|                    /    /     _---------=> tseg2: 1 …  128
|                   |    |     /    _-----=> sjw:   1 …  128
|                   |    |    |    /    _-=> brp:   1 …  256 (inc: 1)
|                   |    |    |   |    /
|  nominal          |    |    |   |   |     real  Bitrt    nom   real   SampP
|  Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP  Bitrate  Error  SampP  SampP   Error      NBTCFG
|   500000     25  34   35   10   1   1   500000   0.0%  87.5%  87.5%   0.0%   0x00440900

The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "1" (==
25ns).

Since the kernel chooses a default SJW of 1 regardless of the TQ, this
leads to a much smaller SJW and thus much smaller tolerances to
frequency errors.

To maintain the same oscillator tolerances on controllers with wide
bit timing registers, select a default SJW value of Phase Seg2 / 2
unless Phase Seg 1 is less. This results in the following bit timing
parameters:

| Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock
|                     _----+--------------=> tseg1: 2 …  256
|                    /    /     _---------=> tseg2: 1 …  128
|                   |    |     /    _-----=> sjw:   1 …  128
|                   |    |    |    /    _-=> brp:   1 …  256 (inc: 1)
|                   |    |    |   |    /
|  nominal          |    |    |   |   |     real  Bitrt    nom   real   SampP
|  Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP  Bitrate  Error  SampP  SampP   Error      NBTCFG
|   500000     25  34   35   10   5   1   500000   0.0%  87.5%  87.5%   0.0%   0x00440904

The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "5" (==
125ns). Which is the same as on the sja1000 controller.

[1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf

Link: https://lore.kernel.org/all/20230202110854.2318594-15-mkl@pengutronix.de
Cc: Mark Bath <mark@baggywrinkle.co.uk>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

According to "The Configuration of the CAN Bit Timing" [1] the SJW
"may not be longer than either Phase Buffer Segment".

Check SJW against length of both Phase buffers. In case the SJW is
greater, report an error via netlink to user space and bail out.

[1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf

Link: https://lore.kernel.org/all/20230202110854.2318594-14-mkl@pengutronix.deSuggested-by: NVincent Mailhol <vincent.mailhol@gmail.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

If the user space has supplied an invalid SJW value (greater than the
maximum SJW value), report -EINVAL instead of -ERANGE, this better
matches the actual meaning of the error value.

Additionally report an error message via netlink to the user space.

Link: https://lore.kernel.org/all/20230202110854.2318594-13-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Check each bit timing parameter first individually against their
limits and report a meaningful error message via netlink to the user
space.

In case of an error, return -EINVAL instead of -ERANGE, this
corresponds better to the actual meaning of the error value.

Link: https://lore.kernel.org/all/20230202110854.2318594-12-mkl@pengutronix.deSuggested-by: NVincent Mailhol <vincent.mailhol@gmail.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Factor out the functionality of assigning a SJW default value into
can_sjw_set_default() and the checking the SJW limits into
can_sjw_check().

This functions will be improved and called from a different function
in the following patches.

Link: https://lore.kernel.org/all/20230202110854.2318594-11-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This is a preparation patch.

In order to pass warning/error messages during netlink calls back to
user space, pass the extack struct down the callstack of
can_changelink(), the actual error messages will be added in the
following ptaches.

Link: https://lore.kernel.org/all/20230202110854.2318594-10-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Since commit 51c352bd ("netlink: add support for formatted extack
messages") formatted extack messages are supported to inform the user
space or warnings/errors during netlink calls.

Replace the netdev_err() by NL_SET_ERR_MSG_FMT() to better inform the
user about the problem. While there, use %u to print unsigned values
and improve error message a bit.

Link: https://lore.kernel.org/all/20230202110854.2318594-9-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The sample point is a value in tenths of a percent. Meaningful values
are between 0 and 1000. Invalid values are rejected and an error
message is returned to user space via netlink.

Link: https://lore.kernel.org/all/20230202110854.2318594-8-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The CAN driver framework supports either fixed bit rates or bit timing
constants. Bail out during driver registration if both are given.

Link: https://lore.kernel.org/all/20230202110854.2318594-7-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Implement the function can_bittiming_const_valid() to check the
validity of the specified bit timing constant. Call this function from
register_candev() to check the bit timing constants during the
registration of the CAN interface.

Link: https://lore.kernel.org/all/20230202110854.2318594-6-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Clean up the code flow a bit, don't assign err variable but directly
return. Remove the unneeded else, too.

Link: https://lore.kernel.org/all/20230202110854.2318594-5-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The can_fixup_bittiming() function is used to validate the
user-supplied low-level bit timing parameters and calculate the
bitrate prescaler (brp) from the requested time quanta (tq) and the
CAN clock of the controller.

can_fixup_bittiming() selects the best matching integer bit rate
prescaler, which may result in a different time quantum than the value
specified by the user.

Calculate the resulting time quantum and assign it so that the user
sees the effective time quantum.

Link: https://lore.kernel.org/all/20230202110854.2318594-4-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Commit 1c47fa6b ("can: dev: add a helper function to calculate the
duration of one bit") made the constant CAN_SYNC_SEG available in a
header file.

The magic number 1 in can_fixup_bittiming() represents the width of
the sync segment, replace it by CAN_SYNC_SEG to make the code more
readable.

Link: https://lore.kernel.org/all/20230202110854.2318594-3-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Commit 1c47fa6b ("can: dev: add a helper function to calculate the
duration of one bit") added the helper function can_bit_time().

Replace open coded variants of can_bit_time() by the helper function.

Link: https://lore.kernel.org/all/20230202110854.2318594-2-mkl@pengutronix.deSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Lukas Magel <lukas.magel@posteo.net> says:

This series of patches introduces the CAN channel ID for the PEAK USB
CAN interfaces. The id can be read/written via ethtool and is exposed as
a read-only attribute via sysfs. This allows users to set the id via
ethtool and write udev rules to match against the sysfs attribute.

Part of the patches were originally introduced by Stéphane Grosjean and
were modified slightly. See the following threads for the original patches:

* https://lore.kernel.org/linux-can/20220128150157.1222850-1-s.grosjean@peak-system.com
* https://lore.kernel.org/linux-can/20211117150132.37056-1-s.grosjean@peak-system.com

changes since v2: https://lore.kernel.org/all/20221030105939.87658-1-lukas.magel@posteo.net
* Fix the issues raised on netdev
* Rename user device ID to CAN channel ID to make the 1-to-N mapping
  between USB device and exposed CAN channels more obvious

changes since v1: https://lore.kernel.org/all/20221022213535.8495-1-lukas.magel@posteo.net
* Fix type of devid_le in ethtool peak_usb_(get|set)_eeprom
* Fix signed-off tags

Link: https://lore.kernel.org/all/20221213080309.9013-1-lukas.magel@posteo.net
[mkl: added links]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The include directives in all source files are reordered alphabetically
according to the names of the header files.
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-9-lukas.magel@posteo.net
[mkl: move header changes from Patch 3 here]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Previously, the CAN channel ID was printed to the kernel log in decimal
upon connecting a new PEAK device. This behavior is inconsistent with
the hexadecimal format of the CAN channel ID sysfs attribute. This patch
updates the log message to output the id in hexadecimal.
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-8-lukas.magel@posteo.netSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch exports the CAN channel ID as a sysfs attribute. The CAN
channel ID is a user-configurable u8/u32 identifier that can be set
individually for each CAN interface of a PEAK USB device.

Exporting the channel ID as a sysfs attribute allows users to easily read
the ID and to write udev rules that can match against the ID. This is
especially useful for PEAK USB devices that do not export a serial
number at SUB level.
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-7-lukas.magel@posteo.netSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch introduces 3 new functions implementing support for ethtool
access to the CAN channel ID of all USB CAN network interfaces managed by
the driver. With this patch, it is possible to read/write the CAN
channel ID from/to the EEPROM via the ethtool interface.

The CAN channel ID is a user-configurable device identifier that can be
set individually for each CAN interface of a PEAK USB device. Depending on
the device, the identifier has a length of 8 or 32 bit. The identifier
is stored in the non-volatile memory of the device.

The identifier of a CAN interface can be read/written as an 8 or 32 bit
byte string in native (little-endian) byte order, where the length depends
on the device type.
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-6-lukas.magel@posteo.netSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch changes the call to unregister_netdev() in
peak_usb_disconnect() with unregister_candev().
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-5-lukas.magel@posteo.netSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch adds callbacks that allow the user to set a new self-defined
CAN channel ID to all USB - CAN/CANFD interfaces of PEAK-System managed by
this driver, namely:
- PCAN-USB
- PCAN-USB FD
- PCAN-USB Pro FD
- PCAN-USB X6
- PCAN-Chip USB
- PCAN-USB Pro

The callback functions write the CAN channel ID to the non-volatile
memory of the devices.
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-4-lukas.magel@posteo.netSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch adds a new function that allows to read the CAN channel ID
from the non volatile memory of the USB CAN-FD PEAK devices. The CAN
channel ID is a user-configurable u8/u32 identifier value that can be set
individually for each PEAK CAN interface.
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-3-lukas.magel@posteo.netSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The so-called "device id" is a user-defined identifier value that can be
set individually for each CAN interface of a PEAK USB device.
Contrary to a static serial number, the value can be changed by the
user. With this ID, each CAN interface can be uniquely identified even if
the USB device does not export a proper serial number or the USB device
exports multiple CAN interfaces. In order to not confuse it with the
device ID used by the USB core and emphasize the link to the CAN
interface, the functions and variables for reading this user-defined
value are renamed to CAN channel ID.
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NLukas Magel <lukas.magel@posteo.net>
Link: https://lore.kernel.org/all/20230116200932.157769-2-lukas.magel@posteo.netSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> says:

The CPC-PCIe v3 uses an Asix AX99100 instead of the discontinued PLX
PCI9030 bridge chip. This patch series adds support for this card
version and cleans some code styling issues.

v1: https://lore.kernel.org/all/20230119154528.28425-1-uttenthaler@ems-wuensche.com

Link: https://lore.kernel.org/all/20230120112616.6071-1-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Added myself as module author
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-9-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The reset line from the Asix chip to the SJA1000 is asserted after boot up
until it is deasserted by a register write
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-8-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add IRQ enable
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-7-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add CAN controller base registers
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-6-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add functions to read and write SJA1000 registers and also the
post irq routine
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-5-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Fix the base register defines and their usage for all three card versions
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-4-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add Asix AX99100 PCI IDs and add the v3 to the ems_pci_tbl.
Add define for maximum CAN channel count
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-3-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Fix code style complained by checkpatch.pl, add Copyright and
fix email address
Signed-off-by: NGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
Link: https://lore.kernel.org/all/20230120112616.6071-2-uttenthaler@ems-wuensche.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Geert Uytterhoeven <geert+renesas@glider.be> says:

This patch series adds support for the CAN-FD interface on the Renesas
R-Car V4H (R8A779G0) SoC and support for CAN transceivers described as
PHYs to the R-Car CAN-FD driver. It includes several fixes for issues
(some minor) detected while adding the support and during testing.
More details can be found in the individual patches.

This has been tested on the Renesas White-Hawk development board using
cansend, candump, and canfdtest:
  - Channel 0 uses an NXP TJR1443AT CAN transceiver, and works fine,
  - Channels 1-7 use Microchip MCP2558FD-H/SN CAN transceivers (not
    mounted for channels 4-7), which do not need explicit description.
    While channel 1 works fine, channels 2-3 do not seem to work.

Hence despite the new fixes, the test results are similar to what Ulrich
Hecht reported for R-Car V3U on the Falcon development board before,
i.e. only channels 0 and 1 work (FTR, [2] does not help).
Whether this is a CAN-FD driver issue, a pin control issue, an IP core
issue, or an SoC integration issue is still to be seen...

[1] https://lore.kernel.org/all/f53a1bcca637ceeafb04ce3540a605532d3bc34a.1674036164.git.geert+renesas@glider.be
[2] commit e3e5bccc92446048 ("can: rcar_canfd:
    rcar_canfd_configure_afl_rules(): Fix Rx FIFO entry setting") in
    renesas-bsp/v5.10.147/rcar-5.2.0.rc3.

Link: https://lore.kernel.org/all/cover.1674499048.git.geert+renesas@glider.be
[mkl: applying patches 1...11 only]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

rcar_canfd_channel_probe() and rcar_canfd_probe() have many users of
"pdev->dev".  Introduce shorthands to simplify the code.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/all/2965edc7992ab54dc6c862910775f3466fca6b29.1674499048.git.geert+renesas@glider.beSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This may avoid conflicts when adding or removing files in the future.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/all/f7fa8090487c6e05b2c7f89542e0a1bd045356f1.1674499048.git.geert+renesas@glider.beSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

On R-Car Gen4 CAN_FD variants, the Common FIFO TX Message Buffer Link
(CFTML) field in the Common FIFO Configuration / Control Register (CCFC)
register is one bit wider than on older variants.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/all/9c37aaa799a2391be272dbaa474379cf9a7af147.1674499048.git.geert+renesas@glider.beSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

On R-Car Gen4 CAN_FD variants, the Data Bit Rate Resynchronization Jump
Width Control (DSJW) field in the Channel n Data Bitrate Configuration
Register (DCFG) register is one bit wider than on older variants.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/all/c4e8bc220bf87e6c7e375f7a2ce51e2aa89ea8a7.1674499048.git.geert+renesas@glider.beSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Despite the name, R-Car V3U (R8A779A0) was the first member of the R-Car
Gen4 family.  Generalize the support for R-Car V3U to other SoCs in the
R-Car Gen4 family by adding a family-specific compatible value, and by
replacing all references to "V3U" by "Gen4".
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/all/61f6f34eb7bcc62ff604add98f1bcd2d2584187d.1674499048.git.geert+renesas@glider.beSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Abstract the different addresses for the Channel n Data Bitrate
Configuration Register (DCFG) in the definition of the register macro,
like is already done for other register definitions, to simplify code
accessing this register.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/all/13e02d710dac3ddef73aa4be2b995766db9b6b4d.1674499048.git.geert+renesas@glider.beSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>