linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc: linux-can <linux-can@vger.kernel.org>,
	Oliver Hartkopp <socketcan@hartkopp.net>,
	Wolfgang Grandegger <wg@grandegger.com>
Subject: Re: [PATCH v2 4/5] can: add netlink interface for CAN-FD Transmitter Delay Compensation (TDC)
Date: Wed, 7 Apr 2021 10:15:57 +0200	[thread overview]
Message-ID: <20210407081557.m3sotnepbgasarri@pengutronix.de> (raw)
In-Reply-To: <CAMZ6Rq+ET3V3EQDVe9xYF8=Sv7N1WHZCLy2XTvqVXuNEyKg6VQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]

On 05.04.2021 11:29:31, Vincent MAILHOL wrote:
> Hi Marc,
> 
> On Wed. 17 Mar 2021 at 00:29, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> > On 17.03.2021 00:16:01, Vincent MAILHOL wrote:
> > > > I just had a look at the ethtool-netlink interface:
> > > >
> > > > | Documentation/networking/ethtool-netlink.rst
> > > >
> > > > this is much better designed than the CAN netlink interface. It was done
> > > > by the pros and much later than CAN. :D So I'd like to have a similar
> > > > structure for new CAN netlink stuff.
> > > >
> > > > So I think I'll remove this patch for now from can-next-testing. The
> > > > kernel internal interface to tdc is still OK, we can leave it as is and
> > > > change it if needed. But netlink is user space and I'd like to have it
> > > > properly designed.
> > >
> > > Understood. However, I will need more time to read and understand
> > > the ethtool-netlink interface. The new patch will come later, I
> > > do not know when.
> >
> > No Problem
> 
> I started to look at Ethtool netlink, but as far as my understanding
> goes, this seems purely restricted to the ethtool application (i.e.
> not to iproute2). I double checked the latest versions of iproute2
> but there isn’t a single #include <linux/ethtool_netlink.h> nor
> anything else related to that new API.
> 
> Please let me know if I missed the point.

For example have a look at the RINGS_GET of ethtool-netlink.rst:

| RINGS_GET
| =========
| 
| Gets ring sizes like ``ETHTOOL_GRINGPARAM`` ioctl request.
| 
| Request contents:
| 
|   ====================================  ======  ==========================
|   ``ETHTOOL_A_RINGS_HEADER``            nested  request header
|   ====================================  ======  ==========================
| 
| Kernel response contents:
| 
|   ====================================  ======  ==========================
|   ``ETHTOOL_A_RINGS_HEADER``            nested  reply header
|   ``ETHTOOL_A_RINGS_RX_MAX``            u32     max size of RX ring
|   ``ETHTOOL_A_RINGS_RX_MINI_MAX``       u32     max size of RX mini ring
|   ``ETHTOOL_A_RINGS_RX_JUMBO_MAX``      u32     max size of RX jumbo ring
|   ``ETHTOOL_A_RINGS_TX_MAX``            u32     max size of TX ring
|   ``ETHTOOL_A_RINGS_RX``                u32     size of RX ring
|   ``ETHTOOL_A_RINGS_RX_MINI``           u32     size of RX mini ring
|   ``ETHTOOL_A_RINGS_RX_JUMBO``          u32     size of RX jumbo ring
|   ``ETHTOOL_A_RINGS_TX``                u32     size of TX ring
|   ====================================  ======  ==========================

The response consists of a header and several nested values. This looks
to me to be the netlink way to serialize a C-struct. If I understand
your code correctly it was just the values without the nested header.

| RINGS_SET
| =========
| 
| Sets ring sizes like ``ETHTOOL_SRINGPARAM`` ioctl request.
| 
| Request contents:
| 
|   ====================================  ======  ==========================
|   ``ETHTOOL_A_RINGS_HEADER``            nested  reply header
|   ``ETHTOOL_A_RINGS_RX``                u32     size of RX ring
|   ``ETHTOOL_A_RINGS_RX_MINI``           u32     size of RX mini ring
|   ``ETHTOOL_A_RINGS_RX_JUMBO``          u32     size of RX jumbo ring
|   ``ETHTOOL_A_RINGS_TX``                u32     size of TX ring
|   ====================================  ======  ==========================
| 
| Kernel checks that requested ring sizes do not exceed limits reported by
| driver. Driver may impose additional constraints and may not suspport all
| attributes.

regards,
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 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-04-07  8:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24  0:20 [PATCH v2 0/5] Introducing new CAN FD bittiming parameters: Transmission Delay Compensation (TDC) Vincent Mailhol
2021-02-24  0:20 ` [PATCH v2 1/5] can: add new CAN FD bittiming parameters: Transmitter " Vincent Mailhol
2021-02-24  7:31   ` Marc Kleine-Budde
2021-03-09  8:30     ` Jimmy Assarsson
2021-03-09  8:34       ` Marc Kleine-Budde
2021-03-09  9:09         ` Jimmy Assarsson
2021-06-16  9:54   ` Marc Kleine-Budde
2021-06-16 12:44     ` Vincent MAILHOL
2021-02-24  0:20 ` [PATCH v2 2/5] can: dev: reorder struct can_priv members for better packing Vincent Mailhol
2021-02-24  0:20 ` [PATCH v2 3/5] can: netlink: move '=' operators back to previous line (checkpatch fix) Vincent Mailhol
2021-02-24  0:20 ` [PATCH v2 4/5] can: add netlink interface for CAN-FD Transmitter Delay Compensation (TDC) Vincent Mailhol
2021-03-09 13:16   ` Vincent MAILHOL
2021-03-09 13:19     ` Marc Kleine-Budde
2021-03-15 15:59   ` Marc Kleine-Budde
2021-03-16 15:16     ` Vincent MAILHOL
2021-03-16 15:29       ` Marc Kleine-Budde
2021-04-05  2:29         ` Vincent MAILHOL
2021-04-07  8:15           ` Marc Kleine-Budde [this message]
2021-02-24  0:20 ` [PATCH v2 5/5] can: bittiming: add calculation for CAN FD " 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=20210407081557.m3sotnepbgasarri@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).