[lkml]   [2017]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

On 07/27/2017 01:47 PM, Oliver Hartkopp wrote:
> On 07/26/2017 08:29 PM, Franklin S Cooper Jr wrote:
>> 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
>>> 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.
>> 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

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

 \ /
  Last update: 2017-07-27 23:11    [W:0.084 / U:39.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site