<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/Kconfig, branch v7.0-rc7</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0-rc7</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0-rc7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-02-17T12:04:20+00:00</updated>
<entry>
<title>printk: add CONFIG_PRINTK dependency for netconsole</title>
<updated>2026-02-17T12:04:20+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2026-02-13T07:44:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=636fd32d401572f6cfe89ba17df4eb251020c10f'/>
<id>urn:sha1:636fd32d401572f6cfe89ba17df4eb251020c10f</id>
<content type='text'>
The 'select PRINTK_EXECUTION_CTX' line now causes a harmless warning
when NETCONSOLE_DYNAMIC is enabled but PRINTK is not:

WARNING: unmet direct dependencies detected for PRINTK_EXECUTION_CTX
  Depends on [n]: PRINTK [=n]
  Selected by [y]:
  - NETCONSOLE_DYNAMIC [=y] &amp;&amp; NETDEVICES [=y] &amp;&amp; NET_CORE [=y] &amp;&amp; NETCONSOLE [=y] &amp;&amp; SYSFS [=y] &amp;&amp; CONFIGFS_FS [=y] &amp;&amp; (NETCONSOLE [=y]!=y [=y] || CONFIGFS_FS [=y]!=m [=m])

In that configuration, the netconsole driver is useless anyway, so
avoid this with an added dependency that prevents CONFIG_NETCONSOLE
to be enabled without CONFIG_PRINTK.

Fixes: 60325c27d3cf ("printk: Add execution context (task name/CPU) to printk_info")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260213074431.1729627-1-arnd@kernel.org
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
<entry>
<title>printk: Add execution context (task name/CPU) to printk_info</title>
<updated>2026-02-11T03:51:56+00:00</updated>
<author>
<name>Breno Leitao</name>
<email>leitao@debian.org</email>
</author>
<published>2026-02-06T12:45:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=60325c27d3cfe13466f6d6aa882b11bdd1c58cc8'/>
<id>urn:sha1:60325c27d3cfe13466f6d6aa882b11bdd1c58cc8</id>
<content type='text'>
Extend struct printk_info to include the task name, pid, and CPU
number where printk messages originate. This information is captured
at vprintk_store() time and propagated through printk_message to
nbcon_write_context, making it available to nbcon console drivers.

This is useful for consoles like netconsole that want to include
execution context in their output, allowing correlation of messages
with specific tasks and CPUs regardless of where the console driver
actually runs.

The feature is controlled by CONFIG_PRINTK_EXECUTION_CTX, which is
automatically selected by CONFIG_NETCONSOLE_DYNAMIC. When disabled,
the helper functions compile to no-ops with no overhead.

Suggested-by: John Ogness &lt;john.ogness@linutronix.de&gt;
Signed-off-by: Petr Mladek &lt;pmladek@suse.com&gt;
Reviewed-by: Petr Mladek &lt;pmladek@suse.com&gt;
Signed-off-by: Breno Leitao &lt;leitao@debian.org&gt;
Reviewed-by: John Ogness &lt;john.ogness@linutronix.de&gt;
Link: https://patch.msgid.link/20260206-nbcon-v7-1-62bda69b1b41@debian.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: remove HIPPI support and RoadRunner HIPPI driver</title>
<updated>2026-01-21T03:12:06+00:00</updated>
<author>
<name>Ethan Nelson-Moore</name>
<email>enelsonmoore@gmail.com</email>
</author>
<published>2026-01-19T02:24:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d8f87aa5fa0a4276491fa8ef436cd22605a3f9ba'/>
<id>urn:sha1:d8f87aa5fa0a4276491fa8ef436cd22605a3f9ba</id>
<content type='text'>
HIPPI has not been relevant for over two decades. It was rapidly
eclipsed by Fibre Channel, and even when it was new, it was
confined to very high-end hardware. The HIPPI code has only
received tree-wide changes and fixes by inspection in the entire
Git history. Remove HIPPI support and the rrunner HIPPI driver,
and move the former maintainer to the CREDITS file. Keep the
include/uapi/linux/if_hippi.h header because it is used by the TUN
code, and to avoid breaking userspace, however unlikely that may be.

Signed-off-by: Ethan Nelson-Moore &lt;enelsonmoore@gmail.com&gt;
Link: https://patch.msgid.link/20260119022451.22344-1-enelsonmoore@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>wireguard: kconfig: simplify crypto kconfig selections</title>
<updated>2025-09-08T16:44:08+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2025-09-06T21:35:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54e7bb6ade8acd3fb1c486c9f3e2c0dfdc18f84e'/>
<id>urn:sha1:54e7bb6ade8acd3fb1c486c9f3e2c0dfdc18f84e</id>
<content type='text'>
Simplify the kconfig entry for WIREGUARD:

- Drop the selections of the arch-optimized ChaCha20, Poly1305, BLAKE2s,
  and Curve25519 code.  These options no longer exist, as lib/crypto/
  now enables the arch-optimized code automatically.

- Drop the selection of CRYPTO.  This was needed only to make the
  arch-optimized options visible.  lib/crypto/ now handles these options
  internally, without any dependency on CRYPTO.

- Drop the dependency on !KMSAN.  This was needed only to avoid
  selecting arch-optimized code that isn't compatible with KMSAN.
  lib/crypto/ now handles the !KMSAN dependencies internally.

- Add a selection of CRYPTO_LIB_UTILS, since WireGuard directly calls
  crypto_memneq().  This gets selected indirectly by
  CRYPTO_LIB_CURVE25519 and CRYPTO_LIB_CHACHA20POLY1305 anyway, but it's
  best to make this dependency explicit.

Link: https://lore.kernel.org/r/20250906213523.84915-13-ebiggers@kernel.org
Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
</content>
</entry>
<entry>
<title>ovpn: implement TCP transport</title>
<updated>2025-04-17T10:30:03+00:00</updated>
<author>
<name>Antonio Quartulli</name>
<email>antonio@openvpn.net</email>
</author>
<published>2025-04-15T11:17:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=11851cbd60ea1e5abbd97619d69845ead99303d6'/>
<id>urn:sha1:11851cbd60ea1e5abbd97619d69845ead99303d6</id>
<content type='text'>
With this change ovpn is allowed to communicate to peers also via TCP.
Parsing of incoming messages is implemented through the strparser API.

Note that ovpn redefines sk_prot and sk_socket-&gt;ops for the TCP socket
used to communicate with the peer.
For this reason it needs to access inet6_stream_ops, which is declared
as extern in the IPv6 module, but it is not fully exported.

Therefore this patch is also adding EXPORT_SYMBOL_GPL(inet6_stream_ops)
to net/ipv6/af_inet6.c.

Cc: David Ahern &lt;dsahern@kernel.org&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Jakub Kicinski &lt;kuba@kernel.org&gt;
Cc: Paolo Abeni &lt;pabeni@redhat.com&gt;
Cc: Simon Horman &lt;horms@kernel.org&gt;
Signed-off-by: Antonio Quartulli &lt;antonio@openvpn.net&gt;
Link: https://patch.msgid.link/20250415-b4-ovpn-v26-11-577f6097b964@openvpn.net
Reviewed-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>ovpn: implement packet processing</title>
<updated>2025-04-17T10:30:02+00:00</updated>
<author>
<name>Antonio Quartulli</name>
<email>antonio@openvpn.net</email>
</author>
<published>2025-04-15T11:17:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8534731dbf2d52a539b94defd06d2a8d3514aacb'/>
<id>urn:sha1:8534731dbf2d52a539b94defd06d2a8d3514aacb</id>
<content type='text'>
This change implements encryption/decryption and
encapsulation/decapsulation of OpenVPN packets.

Support for generic crypto state is added along with
a wrapper for the AEAD crypto kernel API.

Signed-off-by: Antonio Quartulli &lt;antonio@openvpn.net&gt;
Link: https://patch.msgid.link/20250415-b4-ovpn-v26-9-577f6097b964@openvpn.net
Reviewed-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>ovpn: implement basic TX path (UDP)</title>
<updated>2025-04-17T10:30:02+00:00</updated>
<author>
<name>Antonio Quartulli</name>
<email>antonio@openvpn.net</email>
</author>
<published>2025-04-15T11:17:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=08857b5ec5d91d83e69e40a36554a8c7557b7301'/>
<id>urn:sha1:08857b5ec5d91d83e69e40a36554a8c7557b7301</id>
<content type='text'>
Packets sent over the ovpn interface are processed and transmitted to the
connected peer, if any.

Implementation is UDP only. TCP will be added by a later patch.

Note: no crypto/encapsulation exists yet. Packets are just captured and
sent.

Signed-off-by: Antonio Quartulli &lt;antonio@openvpn.net&gt;
Link: https://patch.msgid.link/20250415-b4-ovpn-v26-7-577f6097b964@openvpn.net
Reviewed-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>ovpn: introduce the ovpn_peer object</title>
<updated>2025-04-17T10:30:02+00:00</updated>
<author>
<name>Antonio Quartulli</name>
<email>antonio@openvpn.net</email>
</author>
<published>2025-04-15T11:17:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80747caef33d77f5c1b3d24644e6d7dae69066b5'/>
<id>urn:sha1:80747caef33d77f5c1b3d24644e6d7dae69066b5</id>
<content type='text'>
An ovpn_peer object holds the whole status of a remote peer
(regardless whether it is a server or a client).

This includes status for crypto, tx/rx buffers, napi, etc.

Only support for one peer is introduced (P2P mode).
Multi peer support is introduced with a later patch.

Along with the ovpn_peer, also the ovpn_bind object is introcued
as the two are strictly related.
An ovpn_bind object wraps a sockaddr representing the local
coordinates being used to talk to a specific peer.

Signed-off-by: Antonio Quartulli &lt;antonio@openvpn.net&gt;
Link: https://patch.msgid.link/20250415-b4-ovpn-v26-5-577f6097b964@openvpn.net
Reviewed-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: introduce OpenVPN Data Channel Offload (ovpn)</title>
<updated>2025-04-17T10:30:02+00:00</updated>
<author>
<name>Antonio Quartulli</name>
<email>antonio@openvpn.net</email>
</author>
<published>2025-04-15T11:17:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9f23d943eb6b55990acc45ea1e130b20a44c76ce'/>
<id>urn:sha1:9f23d943eb6b55990acc45ea1e130b20a44c76ce</id>
<content type='text'>
OpenVPN is a userspace software existing since around 2005 that allows
users to create secure tunnels.

So far OpenVPN has implemented all operations in userspace, which
implies several back and forth between kernel and user land in order to
process packets (encapsulate/decapsulate, encrypt/decrypt, rerouting..).

With `ovpn` we intend to move the fast path (data channel) entirely
in kernel space and thus improve user measured throughput over the
tunnel.

`ovpn` is implemented as a simple virtual network device driver, that
can be manipulated by means of the standard RTNL APIs. A device of kind
`ovpn` allows only IPv4/6 traffic and can be of type:
* P2P (peer-to-peer): any packet sent over the interface will be
  encapsulated and transmitted to the other side (typical OpenVPN
  client or peer-to-peer behaviour);
* P2MP (point-to-multipoint): packets sent over the interface are
  transmitted to peers based on existing routes (typical OpenVPN
  server behaviour).

After the interface has been created, OpenVPN in userspace can
configure it using a new Netlink API. Specifically it is possible
to manage peers and their keys.

The OpenVPN control channel is multiplexed over the same transport
socket by means of OP codes. Anything that is not DATA_V2 (OpenVPN
OP code for data traffic) is sent to userspace and handled there.
This way the `ovpn` codebase is kept as compact as possible while
focusing on handling data traffic only (fast path).

Any OpenVPN control feature (like cipher negotiation, TLS handshake,
rekeying, etc.) is still fully handled by the userspace process.

When userspace establishes a new connection with a peer, it first
performs the handshake and then passes the socket to the `ovpn` kernel
module, which takes ownership. From this moment on `ovpn` will handle
data traffic for the new peer.
When control packets are received on the link, they are forwarded to
userspace through the same transport socket they were received on, as
userspace is still listening to them.

Some events (like peer deletion) are sent to a Netlink multicast group.

Although it wasn't easy to convince the community, `ovpn` implements
only a limited number of the data-channel features supported by the
userspace program.

Each feature that made it to `ovpn` was attentively vetted to
avoid carrying too much legacy along with us (and to give a clear cut to
old and probalby-not-so-useful features).

Notably, only encryption using AEAD ciphers (specifically
ChaCha20Poly1305 and AES-GCM) was implemented. Supporting any other
cipher out there was not deemed useful.

Both UDP and TCP sockets are supported.

As explained above, in case of P2MP mode, OpenVPN will use the main system
routing table to decide which packet goes to which peer. This implies
that no routing table was re-implemented in the `ovpn` kernel module.

This kernel module can be enabled by selecting the CONFIG_OVPN entry
in the networking drivers section.

NOTE: this first patch introduces the very basic framework only.
Features are then added patch by patch, however, although each patch
will compile and possibly not break at runtime, only after having
applied the full set it is expected to see the ovpn module fully working.

Cc: steffen.klassert@secunet.com
Cc: antony.antony@secunet.com
Signed-off-by: Antonio Quartulli &lt;antonio@openvpn.net&gt;
Link: https://patch.msgid.link/20250415-b4-ovpn-v26-1-577f6097b964@openvpn.net
Reviewed-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>net: remove sb1000 cable modem driver</title>
<updated>2025-03-21T16:11:54+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2025-03-12T08:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3fed9fda150d393d3f3f91a5631dab1e0c15d582'/>
<id>urn:sha1:3fed9fda150d393d3f3f91a5631dab1e0c15d582</id>
<content type='text'>
This one is hilariously outdated, it provided a faster downlink over
TV cable for users of analog modems in the 1990s, through an ISA card.

The web page for the userspace tools has been broken for 25 years, and
the driver has only ever seen mechanical updates.

Link: http://web.archive.org/web/20000611165545/http://home.adelphia.net:80/~siglercm/sb1000.html
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20250312085236.2531870-1-arnd@kernel.org
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
</feed>
