All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can <linux-can@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Oliver Hartkopp <socketcan@hartkopp.net>
Subject: Re: [PATCH v2 2/2] can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)
Date: Wed, 16 Jun 2021 22:53:02 +0900	[thread overview]
Message-ID: <CAMZ6RqLj59+3PrQwTCfK_bVebRBHE=HqCfRb31MU9pRDBPxG8w@mail.gmail.com> (raw)
In-Reply-To: <20210616094633.fwg6rsyxyvm2zc6d@pengutronix.de>

On Wed. 16 Jun 2021 at 18:46, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 04.06.2021 00:15:50, Vincent Mailhol wrote:
> [...]
>
> > +static size_t can_tdc_get_size(const struct net_device *dev)
> > +{
> > +     struct can_priv *priv = netdev_priv(dev);
> > +     size_t size;
> > +
> > +     if (!priv->tdc_const)
> > +             return 0;
> > +
> > +     size = nla_total_size(0);                       /* nest IFLA_CAN_TDC */
> > +     size += nla_total_size(sizeof(u32));            /* IFLA_CAN_TDCV_MAX */
> > +     size += nla_total_size(sizeof(u32));            /* IFLA_CAN_TDCO_MAX */
> > +     size += nla_total_size(sizeof(u32));            /* IFLA_CAN_TDCF_MAX */
> > +
> > +     if (priv->tdc.tdco) {
>
> Naively I'd say, iff the device has tdc_const give the user space the
> tdc parameters, regardless if some value is 0 or not.
>
> What do you think?

I thought about that.
The first important remark is that if tdc.tdco is zero, then TDC
is off (c.f. documentation of struct can_tdc::tdco).

Let me illustrate my vision through examples.


** Case 1: link is not configured at all. **
Here, only the constant values are displayed.

# ip --details link show can0
1:  can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
      ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
      ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 brp_inc 1
      tdcv_max 0 tdco_max 127 tdcf_max 127
      clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535


** Case 2: only the nominal bitrate is configured. **
The data bittiming variables (including TDC) are not shown.

# ip --details link show can0
1:  can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group
default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
      bitrate 500000 sample-point 0.875
      tq 12 prop-seg 69 phase-seg1 70phase-seg2 20  sjw 1
      ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
      ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 brp_inc 1
      tdcv_max 0 tdco_max 127 tdcf_max 127
      clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535


** Case 3: both nominal and data bitrates are configured (but not TDC). **
Only the TDC variables are not shown.

# ip --details link show can0
1:  can0: <NOARP,ECHO> mtu 72 qdisc noop state DOWN mode DEFAULT group
default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can <FD> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
      bitrate 500000 sample-point 0.875
      tq 12 prop-seg 69 phase-seg1 70phase-seg2 20  sjw 1
      ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
      dbitrate 2000000 dsample-point 0.750
      dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1
      ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 brp_inc 1
      tdcv_max 0 tdco_max 127 tdcf_max 127
      clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535


** Case 4: nominal and data bitrates and TDC are configured. **
Everything is shown.

# ip --details link show can0
1:  can0: <NOARP,ECHO> mtu 72 qdisc noop state DOWN mode DEFAULT group
default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0
    can <FD> state STOPPED (berr-counter tx 0 rx 0) restart-ms 0
      bitrate 1000000 sample-point 0.750
      tq 12 prop-seg 29 phase-seg1 30phase-seg2 20  sjw 1
      ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp_inc 1
      dbitrate 5000000 dsample-point 0.750
      dtq 12 dprop-seg 5 dphase-seg1 6 dphase-seg2 4 dsjw 1
      tdcv 0 tdco 12 tdcf 0
      ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 brp_inc 1
      tdcv_max 0 tdco_max 127 tdcf_max 127
      clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535


I think that we can agree on Cases 1, 2 (it would not make sense
to display TDC without the data bittiming variables) and 4.

The edge case is Case 3. It depends if we consider the TDC as a
separate set or not. It is not silly to display the TDC whenever
fd is on. I prefer to keep it the way I did it. But I would not
object to changing this if you insist. That would mean:
-     if (priv->tdc.tdco) {
+     if (priv->data_bittiming.bitrate) {


Finally, I have one side comment. It seems to me that you did not
understand that the intent of
|     if (priv->tdc.tdco)
was to actually check whether TDC was on or off. In other words, my
code was unclear.

I am now thinking to introduce an helper macro:
static bool can_tdc_is_enabled(const struct can_priv *priv)
|{
|    return !!priv->tdc.tdco;
|}

The code would look more clear like that.
-     if (priv->tdc.tdco) {
+     if (can_tdc_is_enabled(priv) {


Yours sincerely,
Vincent

  reply	other threads:[~2021-06-16 13:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 15:15 [PATCH v2 0/2] add the netlink interface for CAN-FD Transmitter Delay Compensation (TDC) Vincent Mailhol
2021-06-03 15:15 ` [PATCH v2 1/2] can: netlink: remove redundant check in can_validate() Vincent Mailhol
2021-06-03 15:15 ` [PATCH v2 2/2] can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC) Vincent Mailhol
2021-06-16  9:46   ` Marc Kleine-Budde
2021-06-16 13:53     ` Vincent MAILHOL [this message]
2021-06-16 14:29       ` Marc Kleine-Budde
2021-06-16 14:43         ` Vincent MAILHOL
2021-06-16 14:46           ` Marc Kleine-Budde
2021-06-16 15:44             ` Vincent MAILHOL
2021-06-17 11:38               ` Marc Kleine-Budde
2021-06-18  9:34   ` Marc Kleine-Budde
2021-06-18 10:23     ` Vincent MAILHOL
2021-06-18 11:17       ` Vincent MAILHOL
2021-06-18 12:44         ` CAN-FD Transmitter Delay Compensation (TDC) on mcp2518fd Marc Kleine-Budde
2021-06-18 14:27           ` Vincent MAILHOL
2021-06-18 15:55             ` Stefan Mätje
2021-06-19 12:34               ` Vincent MAILHOL
2021-06-21 18:42                 ` Stefan Mätje
2021-06-21 23:52                   ` Vincent MAILHOL
2021-06-22  0:04                     ` Vincent MAILHOL

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='CAMZ6RqLj59+3PrQwTCfK_bVebRBHE=HqCfRb31MU9pRDBPxG8w@mail.gmail.com' \
    --to=mailhol.vincent@wanadoo.fr \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    /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.