Thread (16 messages) 16 messages, 5 authors, 2017-08-10

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

From: Franklin S Cooper Jr <hidden>
Date: 2017-07-27 21:10:57
Also in: linux-can, lkml, netdev


On 07/27/2017 01:47 PM, Oliver Hartkopp wrote:
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.
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.
Regards,
Oliver
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help