Linux CAN drivers development
 help / color / mirror / Atom feed
From: Vincent Mailhol <mailhol@kernel.org>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
	Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] can: automate IFF_ECHO flag for generic echo skbs
Date: Wed, 5 Aug 2026 09:25:15 +0200	[thread overview]
Message-ID: <6800934d-2da2-4eeb-8514-3978f4c7b307@kernel.org> (raw)
In-Reply-To: <395d9b68-2527-47d6-a6a0-74569d27b734@hartkopp.net>

On 05/08/2026 at 08:29, Oliver Hartkopp wrote:
> On 04.08.26 21:55, Vincent Mailhol wrote:
>> Most CAN drivers allocate echo skb slots through alloc_candev() or
>> alloc_candev_mqs(), but still have to manually set IFF_ECHO to tell
>> PF_CAN that the driver handles local echo itself. This creates
>> boilerplate and makes it easy for drivers to forget one half of the
>> setup.
> 
> No one ever "forgot" this flag.
> 
>> A recent example is commit c77bfbdd6aac ("can: dummy_can:
>> dummy_can_init(): fix packet statistics"), where dummy_can was already
>> using the generic echo skb helpers but needed an explicit IFF_ECHO
>> assignment to make tx_bytes accounting work.
> 
> But you (ok us) :-D

Yes, this is the hidden motivation of this series. I did this mistake
and I was thinking if there were any way to prevent this from happening
again in the future.

But has a matter of fact, I am not the only one as the ucan driver also
omitted to set its IFF_ECHO (c.f. the note in Patch #3 message). And no
one noticed this one.

> To me this patch set does not really bring an improvement.
> You are now hiding the setting of this bit.
> 
> Today it is very transparent visible inside each drivers initialization
> section whether it supports IFF_ECHO or not. And e.g. vcan.c can also
> switch this feature with a module parameter.
> 
> I prefer this conscious setting in the driver setup. We should better
> add proper comments in drivers that do not set the flag, e.g. in slcan.c
> there's no hint that the af_can.c echo feature is used.

Then, what about setting IFF_ECHO for *all* drivers by default in
can_setup() and let the ones which have a special need to opt-out:

  dev->flags &= ~IFF_ECHO;

This way it remains transparent which one support IFF_ECHO or not. It is
also more important to highlight when things are done differently
(IFF_ECHO off) than when things go the normal case (IFF_ECHO on).

And this is more aligned with IFF_NOARP (c.f. you other message) in the
sense that both flags would now be set by default by the framework. It
looks odd to me that IFF_NOARP should be set by default by the framework
but not IFF_ECHO.


Yours sincerely,
Vincent Mailhol


  reply	other threads:[~2026-08-05  7:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 19:55 [PATCH 0/4] can: automate IFF_ECHO flag for generic echo skbs Vincent Mailhol
2026-08-04 19:55 ` [PATCH 1/4] can: slcan: do not allocate unused echo skb Vincent Mailhol
2026-08-04 19:55 ` [PATCH 2/4] can: fix IFF_ECHO example in documentation Vincent Mailhol
2026-08-05  6:08   ` Oliver Hartkopp
2026-08-04 19:55 ` [PATCH 3/4] can: dev: set IFF_ECHO when allocating echo skbs Vincent Mailhol
2026-08-04 19:55 ` [PATCH 4/4] can: treewide: remove redundant IFF_ECHO assignments Vincent Mailhol
2026-08-05  6:29 ` [PATCH 0/4] can: automate IFF_ECHO flag for generic echo skbs Oliver Hartkopp
2026-08-05  7:25   ` Vincent Mailhol [this message]
2026-08-05 16:17     ` Oliver Hartkopp
2026-08-05 21:06       ` Vincent Mailhol
2026-08-06 12:01         ` Oliver Hartkopp
2026-08-06 20:55           ` Vincent Mailhol
2026-08-07 10:56             ` Oliver Hartkopp
2026-08-07 11:52               ` Vincent Mailhol
2026-08-10 18:07                 ` Oliver Hartkopp

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=6800934d-2da2-4eeb-8514-3978f4c7b307@kernel.org \
    --to=mailhol@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox