netdev - Re: CAN-FD Transceiver Limitations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7883a83f-6af7-3ac8-a5ab-449ca1ab889a@ti.com>
Date:   Fri, 30 Jun 2017 12:51:31 -0500
From:   Franklin S Cooper Jr <fcooper@...com>
To:     Andrew Lunn <andrew@...n.ch>, <linux-can@...r.kernel.org>,
        <netdev@...r.kernel.org>, <wg@...ndegger.com>,
        <mkl@...gutronix.de>, <devicetree@...r.kernel.org>
Subject: Re: CAN-FD Transceiver Limitations

Hi Kurt,

On 06/30/2017 03:09 AM, Kurt Van Dijck wrote:
>> On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
>>>>>>
>>>>>> mcan@0 {
>>>>>> 	...
>>>>>> 	fixed-transceiver {
>>>>>> 	      max-canfd-speed = <2000>
>>>>>> 	};
>>>>>> 	...
>>>>>> };
>>>
>>> Since when would a transceiver support different speeds for CAN & CANFD?
>>
>> When I say CAN I'm referring to CAN 2.0 specification which mentioned
>> speeds upto 1 Mbit/s. While CAN FD supports higher bitrates.
> 
> linux-can is not necessarily restricted to CAN 2.0B?
> 
>>
>>> No transceivers were available, but they are now.
>>> I see no datalink problem applying 2MBit for regular CAN with apropriate
>>> physical layer, and CAN does not predefine the physical layer
>>> (advise != define).
>>>
>>> IMHO,
>>> 	fixed-transceiver {
>>> 		max-arbitration-speed = <2000000>
>>> 		max-data-speed = <4000000>
>>> 	};
>>> is way better to describe the hardware.
>>> Regular CAN chips would not consider max-data-speed...
>>
>> What is arbitration speed?
> 
> CANFD remains similar during the arbitration phase (when the CAN id is
> sent on the wire), and after that allows to switch to a higher 'data'
> speed because the round-trip wire restrictions during arbitration
> don't apply anymore.
> 
>>
>> Also if I understand you correctly then I agree drivers for traditional
>> CAN wouldn't care about this subnode. Although it may be helpful for
>> max-data-speed to become max-canfd-speed or something along those lines.
>> Just so the property's purpose is clear.
> 
> Transceivers exist that don't support 1MB either.
> naming the speeds max-arbitration-speed and max-data-speed makes this
> OF nodes usable for that kind of CAN 2.0 restrtications too.
> 
> Of course, CAN 2.0 chips only consider max-arbitration-speed as that
> applies to the whole wire bitstream, where as CANFD considers both.
> 
> What I understand of your proposal is that max-arbitration-speed is
> 'fixed to 1MB anyway', and that assumption has been proven not
> universally applicable with CAN2.0 transceivers already.
> 
> I found the name 'max-canfd-speed' a bit dubious as CANFD relies on
> 'flexible datarate'. transceivers may not necessarily support the same
> speed for both arbitration and data.
> So I propose to replace it with 'max-data-speed'

Thanks for the explanation. Makes sense.
> 
> Kind regards,
> Kurt
> 
>>>
>>> Kind regards,
>>> Kurt
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html