All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
To: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>,
	Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org,
	mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
	dev.kurt-yI9piX4KPfawT/RRk36CISFp6vIno51x@public.gmane.org,
	sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org
Subject: Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings
Date: Thu, 27 Jul 2017 20:47:37 +0200	[thread overview]
Message-ID: <fe99189e-d077-ba65-4dfc-a4d8beee62b3@hartkopp.net> (raw)
In-Reply-To: <a77fe395-33c7-9405-b51a-5d3372e5c58b-l0cyMroinI0@public.gmane.org>

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.

Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Franklin S Cooper Jr <fcooper@ti.com>, 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 20:47:37 +0200	[thread overview]
Message-ID: <fe99189e-d077-ba65-4dfc-a4d8beee62b3@hartkopp.net> (raw)
In-Reply-To: <a77fe395-33c7-9405-b51a-5d3372e5c58b@ti.com>

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.

Regards,
Oliver

  parent reply	other threads:[~2017-07-27 18:47 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 [this message]
2017-07-27 18:47                 ` Oliver Hartkopp
2017-07-27 21:10                 ` Franklin S Cooper Jr
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=fe99189e-d077-ba65-4dfc-a4d8beee62b3@hartkopp.net \
    --to=socketcan-fj+pqtutwrtk1umjsbkqmq@public.gmane.org \
    --cc=andrew-g2DYL2Zd6BY@public.gmane.org \
    --cc=dev.kurt-yI9piX4KPfawT/RRk36CISFp6vIno51x@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=fcooper-l0cyMroinI0@public.gmane.org \
    --cc=linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org \
    --cc=wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org \
    /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.