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>
Subject: Re: [PATCH 1/2] can: netlink: clear data_bittiming if fd is turned off
Date: Fri, 18 Jun 2021 18:58:28 +0900	[thread overview]
Message-ID: <CAMZ6RqJY5+UOGY8gBEQ76H8h09jeRaBkXRx6G4AhesLEM3Uoag@mail.gmail.com> (raw)
In-Reply-To: <20210618091015.kioemxe3j3cbx6qg@pengutronix.de>

On Fri. 18 juin 2021 at 18:10, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>
> On 18.06.2021 17:19:03, Vincent Mailhol wrote:
> > When the FD is turned off through the netlink interface, the value
>
> values
>
> > still remain in data_bittiming and are displayed despite of the
> > feature being disabled.
> >
> > Example:
> >
> > $ ip link set can0 type can bitrate 500000 dbitrate 2000000 fd on
> > $ ip --details link show can0
> > 1:  can0: <NOARP,ECHO> mtu 72 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
> >     link/can  promiscuity 0 minmtu 0 maxmtu 0
> >     can <FD> state STOPPED restart-ms 0
> >         bitrate 500000 sample-point 0.875
> >         tq 12 prop-seg 69 phase-seg1 70 phase-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 dbrp-inc 1
> >         clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> >
> > $ ip link set can0 type can bitrate 500000 fd off
> > $ ip --details link show can0
> > 1:  can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
> >     link/can  promiscuity 0 minmtu 0 maxmtu 0
> >     can state STOPPED restart-ms 0
> >         bitrate 500000 sample-point 0.875
> >         tq 12 prop-seg 69 phase-seg1 70 phase-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 dbrp-inc 1
> >         clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> >
> > Remark: once FD is turned off, it is not possible to just turn fd back
> > on and reuse the previously input data bittiming values:
>
> > $ ip link set can0 type can bitrate 500000 fd on
> > RTNETLINK answers: Operation not supported
> >
> > This means that the user will need to overwrite data bittiming with
>                                         ^^^^^^^^^
> set
>
> At least with your change it's more a "set again" than to overwrite.
>
> > fresh values in order to turn fd on again.
> >
> > Because old data bittiming values can not be reused, this patch just
> > clears priv->data_bittiming whenever FD is turned off. This way, the
> > data bittiming variables are not displayed anymore.
> >
> > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
> > ---
> > Hi Marc,
> >
> > I suggest to rebase this patch before the netlink TDC series.
>
> makes sense - If you're OK with the changes, I'll add them while
> applying.

I am OK with the changes.

> Your patch makes the interface consistent, another option would be to
> allow FD mode if the data bit timing values have been set before.
> Opinions?

One part of me says it would make sense but let's also try to be
realistic. The only reason I spotted this issue is because I was
actively trying to find defects while testing my TDC
implementation. Under normal usage, I never had have such needs.

How many people will need to set fd on, then off, then on again?
Too few I think. Let's force those few people to always provide
the data bittiming values. The overhead which would be needed to
implement this in drivers/net/can/dev/netlink.c is just not worth it.

> Marc
>
> --
> Pengutronix e.K.                 | Marc Kleine-Budde           |
> Embedded Linux                   | https://www.pengutronix.de  |
> Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2021-06-18  9:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18  8:19 [PATCH 0/2] Stop showing data bittiming if FD is turned off Vincent Mailhol
2021-06-18  8:19 ` [PATCH 1/2] can: netlink: clear data_bittiming if fd " Vincent Mailhol
2021-06-18  9:10   ` Marc Kleine-Budde
2021-06-18  9:58     ` Vincent MAILHOL [this message]
2021-06-18  8:19 ` [PATCH 2/2] can: netlink: clear tdc " Vincent Mailhol
2021-06-18  9:11   ` 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=CAMZ6RqJY5+UOGY8gBEQ76H8h09jeRaBkXRx6G4AhesLEM3Uoag@mail.gmail.com \
    --to=mailhol.vincent@wanadoo.fr \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    /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.