From: Andrew Lunn <andrew@lunn.ch>
To: Franklin S Cooper Jr <fcooper@ti.com>
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
wg@grandegger.com, mkl@pengutronix.de
Subject: Re: CAN-FD Transceiver Limitations
Date: Thu, 29 Jun 2017 17:41:39 +0200 [thread overview]
Message-ID: <20170629154139.GC13221@lunn.ch> (raw)
In-Reply-To: <5d4f2bcf-bd0f-4fa1-5d5a-d7b4a83cbc5e@ti.com>
> Transceivers for CAN are not apart of any model. Traditional CAN didn't
> have a problem because all transceivers from my understanding supported
> the maximum speed of 1 Mbps defined by the spec. However, with the
> introduction of CAN Flexible Datarate mode it seems that for
> transceivers that supported CAN-FD the maximum supported speeds vary.
So transceivers are dumb devices, nothing to configure, so no need to
have a driver for them.
> Now that I think of it
> you also can't determine if the transceiver supports CAN-FD in the first
> place. IP that supports CAN-FD is backwards compatible with standard
> CAN. Therefore, its feasible that you may even use a transceiver that
> doesn't support CAN-FD. So I would think something like the below would
> be needed.
>
> mcan@0 {
> ...
> fixed-transceiver {
> max-canfd-speed = <2000>
> };
> ...
> };
Are there likely to be other transceiver properties? Adding a subnode
may not make sense if this is going to be the only property.
Also, 2KHz is not very fast :-)
Taking a quick look in Documentation/devicetree/bindings/net/can, it
seems a bit of a wild west. No standardization, no central binding
which CAN drivers are expected to support, etc. This sounds like a
generic problem, not an mcan problem. So document this property
centrally, implement the parsing of it centrally, etc, to encourage
other CAN drivers to use it, rather than re-invent the wheel.
Andrew
next prev parent reply other threads:[~2017-06-29 15:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 22:14 CAN-FD Transceiver Limitations Franklin S Cooper Jr
2017-06-28 22:14 ` Franklin S Cooper Jr
2017-06-29 14:21 ` Andrew Lunn
2017-06-29 14:49 ` Franklin S Cooper Jr
2017-06-29 14:49 ` Franklin S Cooper Jr
2017-06-29 15:41 ` Andrew Lunn [this message]
2017-06-29 16:36 ` Franklin S Cooper Jr
2017-06-29 16:36 ` Franklin S Cooper Jr
2017-06-29 17:19 ` Andrew Lunn
2017-06-29 22:36 ` Kurt Van Dijck
[not found] ` <20170629223551.GA6568-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org>
2017-06-29 23:14 ` Franklin S Cooper Jr
2017-06-29 23:14 ` Franklin S Cooper Jr
[not found] ` <d5c2e2f2-8b74-58e1-0cc8-727ba39bd14c-l0cyMroinI0@public.gmane.org>
2017-06-30 8:09 ` Kurt Van Dijck
[not found] ` <20170630080906.GA26712-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org>
2017-06-30 17:51 ` Franklin S Cooper Jr
2017-06-30 17:51 ` Franklin S Cooper Jr
2017-07-10 14:58 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170629154139.GC13221@lunn.ch \
--to=andrew@lunn.ch \
--cc=fcooper@ti.com \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=wg@grandegger.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.