linux-kernel - Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

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: <832feb2d-3712-c394-805a-1ddabd89890e@pengutronix.de>
Date:   Thu, 19 Oct 2017 11:21:29 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Ramesh Shanmugasundaram <ramesh.shanmugasundaram@...renesas.com>,
        Sekhar Nori <nsekhar@...com>,
        Franklin S Cooper Jr <fcooper@...com>,
        Mario Hüttel <mario.huettel@....net>,
        "Yang, Wenyou" <Wenyou.Yang@...rochip.com>,
        "wg@...ndegger.com" <wg@...ndegger.com>,
        "socketcan@...tkopp.net" <socketcan@...tkopp.net>,
        "quentin.schulz@...e-electrons.com" 
        <quentin.schulz@...e-electrons.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     Wenyou Yang <wenyou.yang@...el.com>,
        Dong Aisheng <b29396@...escale.com>,
        "Quadros, Roger" <rogerq@...com>
Subject: Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

On 10/19/2017 10:04 AM, Ramesh Shanmugasundaram wrote:
>>> Sounds reasonable. What's the status of this series?
>>
>> I have had some offline discussions with Franklin on this, and I am not
>> fully convinced that DT is the way to go here (although I don't have the
>> agreement with Franklin there).
>>
>> There are two components in configuring the secondary sample point. It is
>> the transceiver loopback delay and an offset (example half of the bit time
>> in data phase).
>>
>> While the transceiver loopback delay is pretty board dependent (and thus
>> amenable to DT encoding), I am not quite sure the offset can be configured
>> in DT because its not really board dependent.
>>
>> Unfortunately, offset calculation does not seem to be an exact science.
>> There are recommendations ranging from using 50% of bit time to making it
>> same as the sample point configured. This means users who need to change
>> the SSP due to offset variations need to change  their DT even without
>> anything changing on their board.
>>
>> Since we have a netlink socket interface to configure sample point, I
>> wonder if that should be extended to configure SSP too (or at least the
>> offset part of SSP)?
> 
> +1
> > I also wonder how a default TDCO setting in DT would help.

For a given board with a given transceiver and layout and proper values
in the supplied DT the higher bitrates would work out of the box.

> Is the driver going to hard code the Tq settings as well for the
> most commonly used bitrate?

What's Tq in this context. Time Quanta?

> A link up start-up script (using netlink) would help setting a
> default TDCO along with other params if this is the main concern.

There are various ways to setup these values. Plain old start-up scripts
are one of them, systemd-networkd or network manager are others.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)