From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: CAN-FD Transceiver Limitations Date: Thu, 29 Jun 2017 17:41:39 +0200 Message-ID: <20170629154139.GC13221@lunn.ch> References: <20170629142142.GF9244@lunn.ch> <5d4f2bcf-bd0f-4fa1-5d5a-d7b4a83cbc5e@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from vps0.lunn.ch ([178.209.37.122]:39421 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753299AbdF2Plm (ORCPT ); Thu, 29 Jun 2017 11:41:42 -0400 Content-Disposition: inline In-Reply-To: <5d4f2bcf-bd0f-4fa1-5d5a-d7b4a83cbc5e@ti.com> Sender: linux-can-owner@vger.kernel.org List-ID: To: Franklin S Cooper Jr Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org, wg@grandegger.com, mkl@pengutronix.de > 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