Netdev List
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org,
	corbet@lwn.net, vladimir.oltean@nxp.com, willemb@google.com,
	sdf.kernel@gmail.com, ecree.xilinx@gmail.com,
	jesse.brandeburg@intel.com, linux-doc@vger.kernel.org
Subject: Re: [PATCH net-next 06/10] docs: net: refresh netdev feature guidance
Date: Tue, 26 May 2026 15:35:32 -0700	[thread overview]
Message-ID: <20260526153532.7979b43c@kernel.org> (raw)
In-Reply-To: <422219d6-8377-423c-8ccd-641b2fccaa1a@bootlin.com>

On Tue, 26 May 2026 20:41:10 +0200 Maxime Chevallier wrote:
> >   
> >    1. netdev->hw_features set contains features whose state may possibly
> >       be changed (enabled or disabled) for a particular device by user's
> > -    request.  This set should be initialized in ndo_init callback and not
> > -    changed later.
> > +    request.  Drivers normally initialize this set before registration or
> > +    in the ndo_init callback. Changes after registration should be made
> > +    very carefully as other parts of the code may assume hw_features are
> > +    static. At the very least changes must be made under rtnl_lock and
> > +    the netdev instance lock, and followed by netdev_update_features().  
> Feel free to keep this description as-is, but can we get somewhere the
> actual meaning of "hw" in "hw_features" ? I've seen this cause confusion
> before as this is sometimes wrongly interpreted as "Hardware features",
> which isn't correct as the hardware may do stuff without allowing users
> to change that behaviour.
> 
> I vaguely recall something along the lines of "Host-Writeable features",
> but I am not sure at all about that...

Hm. I assumed the hw in hw_features stands for hardware.
The magic behavior of host controllable vs hardwired was
probably added later without renaming the field.

As you indicate the usual confusion is that it's legal to have 
a feature in ->features which is not set in ->hw_features which 
means that features is hardwired "on", it can't be disabled by
the user.

The current text does say this: "features whose state may [..]
be changed [..] by user's request". But perhaps it's not emphatic
enough.

Main question is whether this series should be clarifying
this or our criteria is that the series doesn't _add_ confusion,
even if it doesn't clarify all the potential confusion points? :)

  reply	other threads:[~2026-05-26 22:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 16:01 [PATCH net-next 00/10] docs: net: updates for old and cobwebbed docs Jakub Kicinski
2026-05-26 16:01 ` [PATCH net-next 01/10] docs: net: netdevices: small fixes and clarifications Jakub Kicinski
2026-05-26 22:12   ` Stanislav Fomichev
2026-05-26 16:01 ` [PATCH net-next 02/10] docs: net: fix minor issues with driver guide Jakub Kicinski
2026-05-26 16:01 ` [PATCH net-next 03/10] docs: net: statistics: fix kernel-internal stats list Jakub Kicinski
2026-05-26 16:01 ` [PATCH net-next 04/10] docs: net: update devmem code examples Jakub Kicinski
2026-05-26 22:17   ` Stanislav Fomichev
2026-05-26 16:01 ` [PATCH net-next 05/10] docs: net: fix minor issues with the NAPI guide Jakub Kicinski
2026-05-26 16:01 ` [PATCH net-next 06/10] docs: net: refresh netdev feature guidance Jakub Kicinski
2026-05-26 18:41   ` Maxime Chevallier
2026-05-26 22:35     ` Jakub Kicinski [this message]
2026-05-26 16:01 ` [PATCH net-next 07/10] docs: net: fix minor issues with checksum offloads Jakub Kicinski
2026-05-26 16:01 ` [PATCH net-next 08/10] docs: net: add Rx notes to the checksum guide Jakub Kicinski
2026-05-26 18:56   ` Willem de Bruijn
2026-05-26 16:01 ` [PATCH net-next 09/10] docs: net: render the checksum comment in checksum-offloads.rst Jakub Kicinski
2026-05-26 18:56   ` Willem de Bruijn
2026-05-26 16:01 ` [PATCH net-next 10/10] docs: net: fix minor issues with segmentation offloads Jakub Kicinski
2026-05-26 18:48 ` [PATCH net-next 00/10] docs: net: updates for old and cobwebbed docs Randy Dunlap
2026-05-26 22:37   ` Jakub Kicinski
2026-05-26 22:40     ` Jakub Kicinski
2026-05-27  0:51       ` Randy Dunlap
2026-05-27  1:15         ` Jakub Kicinski
2026-05-27  2:39           ` Randy Dunlap

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=20260526153532.7979b43c@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf.kernel@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=willemb@google.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