[PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible

[Cunhao Lu]

Hi Krzysztof,

thanks for the review.

> DT properties have nothing to do here. Are you saying it is fully
> compatible? Then express it properly with fallback.

No, I do not think RK3588v2 is fully compatible with RK3568v2. The RX
FIFO count field uses a different bitfield on RK3588v2, so using
rockchip,rk3568v2-canfd as a fallback would describe a register layout
that does not match the hardware.

Both standard and extended CAN-FD frames worked in my local RK3588v2
testing, but that only confirms CAN-FD functionality on this variant. It
does not make the RK3568v2 register layout a valid fallback for
RK3588v2.

I will reword the commit message in v2 to explain this hardware
difference instead of talking about the DT properties.

> Do not explain what you did. Explain WHY.
>
> Driver is irrelevant here.

Understood. I will remove the driver-focused wording from the binding
patch. The v2 commit message will explain why RK3588v2 needs its own
compatible from the hardware description point of view.

> We do not take anonymous contributions.

I will use my real name in v2.

> So that's just enum with previous entry

I will fold the single-compatible entries into an enum in v2.

> And why is this different from rk3588?

The reason I used rk3588v2 is that this is how the controller identifies
itself at runtime:

  rockchip_canfd fea60000.can can0: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
  rockchip_canfd fea70000.can can1: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found

I also checked Rockchip's vendor kernel 6.1 sources. The RK3588 DTS uses
the binding name "rockchip,can-2.0" for these controllers, while the
upstream driver has SoC-specific compatibles for the Rockchip CAN-FD IP.
That is why I chose the SoC/IP variant name rockchip,rk3588v2-canfd.

If the preferred binding name is rockchip,rk3588-canfd instead, I can
change the compatible in v2.

Thanks,
Cunhao Lu