On 07/27/2017 01:47 PM, Oliver Hartkopp wrote:

quoted

On 07/26/2017 08:29 PM, Franklin S Cooper Jr wrote:

quoted

quoted

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

1

quoted

quoted

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.

??

It's a physical layer device which only has a bandwidth limitation.
The transceiver does not know about CAN FD.

quoted

With one
property you can not determine this and end up having to make some
assumptions that can quickly end up biting people.

Despite the fact that the transceiver does not know anything about ISO
layer 2 (CAN/CAN FD) the properties should look like

    max-bitrate
    canfd-capable

then.

But when the tranceiver is 'canfd-capable' agnostic, why provide a
property for it?

Maybe I'm wrong but I still can't follow your argumentation ideas.

The transceiver does not know about CAN FD, but CAN FD uses
the different restrictions of the arbitration & data phase in the CAN
frame, i.e. during arbitration, the RX must indicate the wire
(dominant/recessive) within 1 bit time, during data in CAN FD, this is
not necessary.

So while _a_ transceiver may be spec'd to 1MBit during arbitration,
CAN FD packets may IMHO exceed that speed during data phase.
That was the whole point of CAN FD: exceed the limits required for
correct arbitration on transceiver & wire.

So I do not agree on the single bandwidth limitation.

The word 'max-arbitration-bitrate' makes the difference very clear.

Your right. I spoke to our CAN transceiver team and I finally get your
points.

So yes using "max-bitrate" alone is all we need. Sorry for the confusion
and I'll create a new rev using this approach.

quoted

Regards,
Oliver

Kind regards,
Kurt