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

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]

Date:   Mon, 31 Jul 2017 19:03:38 +0200
From:   Oliver Hartkopp <socketcan@...tkopp.net>
To:     Franklin S Cooper Jr <fcooper@...com>,
        Andrew Lunn <andrew@...n.ch>, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, netdev@...r.kernel.org,
        linux-can@...r.kernel.org, wg@...ndegger.com, mkl@...gutronix.de,
        robh+dt@...nel.org, quentin.schulz@...e-electrons.com,
        sergei.shtylyov@...entembedded.com
Subject: Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN
 fixed transceiver bindings

Hi Kurt,

On 07/28/2017 09:41 PM, Kurt Van Dijck wrote:

>> The transceiver is an analog device that needs to support faster
>> switching frequency (FETs) including minimizing delay to support CAN-FD
>> ie higher bitrate. From the transceiver perspective the bits for
>> "arbitration" and "data" look exactly the same. Since it can't
>> differentiate between the two (at the physical layer) then the actual
>> limit isn't specific to which part/type of the CAN message is being
>> sent. Rather its just a single overall max bitrate limit.
> 
> I must disagree here.
> The transceiver is an analog device that performs 2 functions:
> propagate tx bits to CAN wire, and propagate CAN wire state
> (dominant/recesive) to rx bits.
> 
> I'll rephrase the above explanation to fit your argument:
> During arbitration, both directions are required, and needs to propagate
> within 1 bit time. The transceiver doesn't know, it just performs to
> best effort.
> During data, the round-trip timing requirement of layer2 is relaxed.
> The transceiver still doesn't know, it still performs to best effort.
> Due to the relaxed round-trip timing requirement, the same transceiver
> can suddenly allow higher bitrates. The transceiver didn't change, the
> requirement did change.
> This is what I meant earlier with "layer2 has been adapted to circumvent
> layer1 limitations"
> 
> Was I successfull in transcoding my thoughts onto email :-) ?

Yes. But it's not relevant.

I talked to our CAN transceiver & CAN physical layer specialist who was 
involved in the ISO activities too.

We just need ONE value: max-bitrate

The CAN transceiver is qualified to provide this bitrate. That's it.
There's nothing special with the arbitration bitrate - we don't even 
need to outline any CAN FD capability.

The other things like 'loop delay compensation' are done in the CAN 
controller. The better the transceiver get's the bits 'in shape' the 
higher it can be qualified. But from the SoC/Controller/Linux view we 
only need the max-bitrate value to double check with the CAN controllers 
bitrate configuration request (which was Franklins intention).

Best regards,
Oliver