From: Franklin S Cooper Jr <fcooper@ti.com> To: Oliver Hartkopp <socketcan@hartkopp.net>, Andrew Lunn <andrew@lunn.ch> Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-can@vger.kernel.org, wg@grandegger.com, mkl@pengutronix.de, robh+dt@kernel.org, quentin.schulz@free-electrons.com, dev.kurt@vandijck-laurijssen.be, sergei.shtylyov@cogentembedded.com Subject: Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings Date: Thu, 27 Jul 2017 16:10:14 -0500 [thread overview] Message-ID: <932602fe-d06a-7a17-5a0c-24265cf2e643@ti.com> (raw) In-Reply-To: <fe99189e-d077-ba65-4dfc-a4d8beee62b3@hartkopp.net> On 07/27/2017 01:47 PM, Oliver Hartkopp wrote: > On 07/26/2017 08:29 PM, Franklin S Cooper Jr wrote: >> > >> I'm fine with switching to using bitrate instead of speed. Kurk was >> originally the one that suggested to use the term arbitration and data >> since thats how the spec refers to it. Which I do agree with. But your >> right that in the drivers (struct can_priv) we just use bittiming and >> data_bittiming (CAN-FD timings). I don't think adding "fd" into the >> property name makes sense unless we are calling it something like >> "max-canfd-bitrate" which I would agree is the easiest to understand. >> >> So what is the preference if we end up sticking with two properties? >> Option 1 or 2? >> >> 1) >> max-bitrate >> max-data-bitrate >> >> 2) >> max-bitrate >> max-canfd-bitrate >> >> > > 1 > >>> A CAN transceiver is limited in bandwidth. But you only have one RX and >>> one TX line between the CAN controller and the CAN transceiver. The >>> transceiver does not know about CAN FD - it has just a physical(!) layer >>> with a limited bandwidth. This is ONE limitation. >>> >>> So I tend to specify only ONE 'max-bitrate' property for the >>> fixed-transceiver binding. >>> >>> The fact whether the CAN controller is CAN FD capable or not is provided >>> by the netlink configuration interface for CAN controllers. >> >> Part of the reasoning to have two properties is to indicate that you >> don't support CAN FD while limiting the "arbitration" bit rate. > > ?? > > It's a physical layer device which only has a bandwidth limitation. > The transceiver does not know about CAN FD. > >> With one >> property you can not determine this and end up having to make some >> assumptions that can quickly end up biting people. > > Despite the fact that the transceiver does not know anything about ISO > layer 2 (CAN/CAN FD) the properties should look like > > max-bitrate > canfd-capable > > then. > > But when the tranceiver is 'canfd-capable' agnostic, why provide a > property for it? > > Maybe I'm wrong but I still can't follow your argumentation ideas. Your right. I spoke to our CAN transceiver team and I finally get your points. So yes using "max-bitrate" alone is all we need. Sorry for the confusion and I'll create a new rev using this approach. > > Regards, > Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Franklin S Cooper Jr <fcooper@ti.com> To: Oliver Hartkopp <socketcan@hartkopp.net>, Andrew Lunn <andrew@lunn.ch> Cc: <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, <netdev@vger.kernel.org>, <linux-can@vger.kernel.org>, <wg@grandegger.com>, <mkl@pengutronix.de>, <robh+dt@kernel.org>, <quentin.schulz@free-electrons.com>, <dev.kurt@vandijck-laurijssen.be>, <sergei.shtylyov@cogentembedded.com> Subject: Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings Date: Thu, 27 Jul 2017 16:10:14 -0500 [thread overview] Message-ID: <932602fe-d06a-7a17-5a0c-24265cf2e643@ti.com> (raw) In-Reply-To: <fe99189e-d077-ba65-4dfc-a4d8beee62b3@hartkopp.net> On 07/27/2017 01:47 PM, Oliver Hartkopp wrote: > On 07/26/2017 08:29 PM, Franklin S Cooper Jr wrote: >> > >> I'm fine with switching to using bitrate instead of speed. Kurk was >> originally the one that suggested to use the term arbitration and data >> since thats how the spec refers to it. Which I do agree with. But your >> right that in the drivers (struct can_priv) we just use bittiming and >> data_bittiming (CAN-FD timings). I don't think adding "fd" into the >> property name makes sense unless we are calling it something like >> "max-canfd-bitrate" which I would agree is the easiest to understand. >> >> So what is the preference if we end up sticking with two properties? >> Option 1 or 2? >> >> 1) >> max-bitrate >> max-data-bitrate >> >> 2) >> max-bitrate >> max-canfd-bitrate >> >> > > 1 > >>> A CAN transceiver is limited in bandwidth. But you only have one RX and >>> one TX line between the CAN controller and the CAN transceiver. The >>> transceiver does not know about CAN FD - it has just a physical(!) layer >>> with a limited bandwidth. This is ONE limitation. >>> >>> So I tend to specify only ONE 'max-bitrate' property for the >>> fixed-transceiver binding. >>> >>> The fact whether the CAN controller is CAN FD capable or not is provided >>> by the netlink configuration interface for CAN controllers. >> >> Part of the reasoning to have two properties is to indicate that you >> don't support CAN FD while limiting the "arbitration" bit rate. > > ?? > > It's a physical layer device which only has a bandwidth limitation. > The transceiver does not know about CAN FD. > >> With one >> property you can not determine this and end up having to make some >> assumptions that can quickly end up biting people. > > Despite the fact that the transceiver does not know anything about ISO > layer 2 (CAN/CAN FD) the properties should look like > > max-bitrate > canfd-capable > > then. > > But when the tranceiver is 'canfd-capable' agnostic, why provide a > property for it? > > Maybe I'm wrong but I still can't follow your argumentation ideas. Your right. I spoke to our CAN transceiver team and I finally get your points. So yes using "max-bitrate" alone is all we need. Sorry for the confusion and I'll create a new rev using this approach. > > Regards, > Oliver
next prev parent reply other threads:[~2017-07-27 21:10 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-24 23:05 [PATCH v2 0/4] can: Add new binding to limit bit rate used Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-07-24 23:05 ` [PATCH v2 1/4] can: dev: Add support for limiting configured bitrate Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-07-24 23:05 ` [PATCH v2 3/4] can: m_can: Update documentation to mention new fixed transceiver binding Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-08-03 17:07 ` Rob Herring 2017-08-10 1:02 ` Franklin S Cooper Jr 2017-08-10 1:02 ` Franklin S Cooper Jr [not found] ` <20170724230521.1436-1-fcooper-l0cyMroinI0@public.gmane.org> 2017-07-24 23:05 ` [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-07-25 16:32 ` Oliver Hartkopp [not found] ` <29df7e04-01c6-a09b-491e-1354dab98cd0-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> 2017-07-25 18:14 ` Franklin S Cooper Jr 2017-07-25 18:14 ` Franklin S Cooper Jr 2017-07-25 18:14 ` Franklin S Cooper Jr 2017-07-26 16:41 ` Andrew Lunn 2017-07-26 17:05 ` Oliver Hartkopp [not found] ` <355b90b3-97ce-1057-6617-d5d709449c48-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> 2017-07-26 18:29 ` Franklin S Cooper Jr 2017-07-26 18:29 ` Franklin S Cooper Jr 2017-07-26 18:29 ` Franklin S Cooper Jr [not found] ` <a77fe395-33c7-9405-b51a-5d3372e5c58b-l0cyMroinI0@public.gmane.org> 2017-07-27 18:47 ` Oliver Hartkopp 2017-07-27 18:47 ` Oliver Hartkopp 2017-07-27 21:10 ` Franklin S Cooper Jr [this message] 2017-07-27 21:10 ` Franklin S Cooper Jr 2017-07-28 4:57 ` Kurt Van Dijck 2017-07-28 8:41 ` Oliver Hartkopp 2017-07-24 23:05 ` [PATCH v2 4/4] can: m_can: Add call to of_can_transceiver_fixed Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-07-24 23:05 ` Franklin S Cooper Jr 2017-07-28 13:02 [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings Kurt Van Dijck 2017-07-28 18:33 ` Oliver Hartkopp 2017-07-28 18:53 ` Franklin S Cooper Jr 2017-07-28 18:53 ` Franklin S Cooper Jr 2017-07-28 19:41 ` Kurt Van Dijck 2017-07-31 17:03 ` Oliver Hartkopp 2017-08-01 7:12 ` Kurt Van Dijck
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=932602fe-d06a-7a17-5a0c-24265cf2e643@ti.com \ --to=fcooper@ti.com \ --cc=andrew@lunn.ch \ --cc=dev.kurt@vandijck-laurijssen.be \ --cc=devicetree@vger.kernel.org \ --cc=linux-can@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mkl@pengutronix.de \ --cc=netdev@vger.kernel.org \ --cc=quentin.schulz@free-electrons.com \ --cc=robh+dt@kernel.org \ --cc=sergei.shtylyov@cogentembedded.com \ --cc=socketcan@hartkopp.net \ --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: linkBe 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.