All of lore.kernel.org
 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 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.