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: <20170630080906.GA26712@airbook.vandijck-laurijssen.be>
Date:   Fri, 30 Jun 2017 10:09:06 +0200
From:   Kurt Van Dijck <dev.kurt@...dijck-laurijssen.be>
To:     Franklin S Cooper Jr <fcooper@...com>
Cc:     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

> 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'

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