I'm fine with switching to using bitrate instead of speed. Kurk was
originally the one that suggested to use the term arbitration and data
since thats how the spec refers to it. Which I do agree with. But your
right that in the drivers (struct can_priv) we just use bittiming and
data_bittiming (CAN-FD timings). I don't think adding "fd" into the
property name makes sense unless we are calling it something like
"max-canfd-bitrate" which I would agree is the easiest to understand.
So what is the preference if we end up sticking with two properties?
Option 1 or 2?
1)
max-bitrate
max-data-bitrate
2)
max-bitrate
max-canfd-bitrate
A CAN transceiver is limited in bandwidth. But you only have one RX and
one TX line between the CAN controller and the CAN transceiver. The
transceiver does not know about CAN FD - it has just a physical(!) layer
with a limited bandwidth. This is ONE limitation.
So I tend to specify only ONE 'max-bitrate' property for the
fixed-transceiver binding.
The fact whether the CAN controller is CAN FD capable or not is provided
by the netlink configuration interface for CAN controllers.
Part of the reasoning to have two properties is to indicate that you
don't support CAN FD while limiting the "arbitration" bit rate.
With one
property you can not determine this and end up having to make some
assumptions that can quickly end up biting people.