* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Maciek Machnikowski @ 2026-05-05 16:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, vadim.fedorenko, horms
In-Reply-To: <9c7eecee-f0c2-4ee3-95cf-ae9965191902@lunn.ch>
On 05/05/2026 14:22, Andrew Lunn wrote:
> On Tue, May 05, 2026 at 09:36:30AM +0200, Maciek Machnikowski wrote:
>>
>>
>> On 04/05/2026 19:07, Jakub Kicinski wrote:
>>> On Sun, 3 May 2026 09:47:47 +0200 Maciek Machnikowski wrote:
>>>> Add PTP synchronization test using ptp4l and netdevsim.
>>>>
>>>> The test creates two netdevsim adapters, links them together
>>>> and runs the ptp4l leader and ptp4l follower on two ends
>>>> of the netdevsim link and waits for the follower to report the
>>>> synchronized state (s2) in its output log.
>>>>
>>>> This implementation runs the test runs over IPv4 link.
>>>
>>> Doesn't seem to pass on netdevsim for us:
>>>
>>> # 41.13 [+40.95] # ptp4l follower did not reach locked state (s2) within 40s
>>> # 41.13 [+0.00] # Follower log (last 10 lines): ptp4l[2179.605]: ioctl SIOCETHTOOL failed: Operation not supported | ptp4l[2179.607]: interface 'eth0' does not support requested timestamping mode | failed to create a clock
>>> # 41.15 [+0.02] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 173, in ptp_sync_test:
>>> # 41.15 [+0.01] # Check| _run_ptp4l_wait_sync(nsimsv.ifname, nsimcl.ifname, nssv.name, nscl.name)
>>> # 41.16 [+0.01] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 99, in _run_ptp4l_wait_sync:
>>> # 41.17 [+0.01] # Check| ksft_true(False, "PTP sync timeout")
>>> # 41.17 [+0.00] # Check failed False does not eval to True PTP sync timeout
>>> # 41.32 [+0.16] not ok 1 ptp.ptp_sync_test
>>> # 41.33 [+0.00] # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
>>>
>>> Anything we need to do?
>>
>> Can you share the config file you used? Seems the PTP clock was not
>> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
>
> Shouldn't the configuration file be part of the test?
>
> Andrew
I meant the kernel config. The PTP emulation requires PTP Mock to be
enabled, as that's the backbone for generating timestamps. If it's
disabled - netdevsim netdevs will report no timestamping support, as in
the example above.
- Maciek
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: remove unused .port_max_speed_mode()
From: Alexander Lobakin @ 2026-05-05 16:15 UTC (permalink / raw)
To: Marek Behún
Cc: Andrew Lunn, Vladimir Oltean, Russell King (Oracle),
Vivien Didelot, Tobias Waldekranz, netdev
In-Reply-To: <20260504152653.1389394-1-kabel@kernel.org>
From: Marek Behún <kabel@kernel.org>
Date: Mon, 4 May 2026 17:26:53 +0200
> The .port_max_speed_mode() method is not used anymore since commit
> 40da0c32c3fc ("net: dsa: mv88e6xxx: remove handling for DSA and CPU ports").
> Drop it.
>
> Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 9 -------
> drivers/net/dsa/mv88e6xxx/chip.h | 4 ----
> drivers/net/dsa/mv88e6xxx/port.c | 40 --------------------------------
> drivers/net/dsa/mv88e6xxx/port.h | 9 -------
> 4 files changed, 62 deletions(-)
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH RFC net-next v3] hsr: Allow to send a specific port and with HSR header
From: Willem de Bruijn @ 2026-05-05 16:14 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Willem de Bruijn
Cc: netdev, Andrew Lunn, Chintan Vankar, Danish Anwar, Daolin Qiu,
David S. Miller, Eric Dumazet, Felix Maurer, Jakub Kicinski,
Neelima Muralidharan, Paolo Abeni, Praneeth Bajjuri,
Pratheesh Gangadhar TK, Richard Cochran, Simon Horman,
Vignesh Raghavendra
In-Reply-To: <20260505095216.T02Z4R1T@linutronix.de>
Sebastian Andrzej Siewior wrote:
> On 2026-05-04 13:08:04 [-0400], Willem de Bruijn wrote:
> > > > > +#define HSR_INLINE_HDR 0xaf485352
> > > > > +struct hsr_inline_header {
> > > > > + uint8_t tx_port;
> > > > > + uint8_t hsr_hdr;
> > > > > + uint8_t __pad0[4];
> > > > > + uint32_t magic;
> > > > > + uint8_t __pad1[2];
> > > > > + uint16_t eth_type;
> > > > > +} __packed;
> > > > > +
> > > >
> > > > No specific need to make this header ethhdr like?
> > >
> > > What do you mean? eth_type is at the same spot or do you mean it should
> > > be named h_proto?
> >
> > I mean there is no reason your fake header needs to be 14B or
> > or otherwise resemble an Ethernet header.
> >
> > That ties into my last comment to use sizeof(struct hsr_inline_header)
> > where working with that header, rather than ETH_HLEN. It is an
> > independent header.
>
> But I can't expect that the header is always there. A random ping/ arp
> packet goes via the same flow. At the same time I don't want to make it
> mandatory for all AF_PACKET users by checking the skb's socket.
I thought skb->protocol is the unambiguous signal whether this custom
header is present?
> The skb starts always with the ethernet header. To avoid collisions with
> a regular packet that looks similar I use the ether-type of the ethernet
> frame and it has to match PTP. It makes no sense to send a PTP packet via
> HSR. Since ether-type is at the end, I can't make it smaller than 14b.
> So eth-type is safeguard #1 and the second is SRC-MAC with a multicast
> sender bit set which is usually not the case.
> > > > All use of this information happens in the context of this ndo_start_xmit?
> > >
> > > I receive it from af_packet in HSR's ndo_start_xmit, yes. Then
> > > hsr_xmit() is forwarding it to the slave device via dev_queue_xmit().
> > > Here the skb->cb information gets overwritten.
> > >
> > > I need this hint in the slave eth driver in case there is hsr-offloading
> > > available.
> >
> > This assumes that the slave device is somehow HSR aware. But standard
> > net_devices are not?
>
> Yes, standard devices are not hsr-aware. It is just your average
> ethernet device that sends everything as-is.
> But you can have devices with HSR-offload capabilities such as
> NETIF_F_HW_HSR_FWD, NETIF_F_HW_HSR_DUP, NETIF_F_HW_HSR_TAG_INS,
> NETIF_F_HW_HSR_TAG_RM.
>
> So if a device provides NETIF_F_HW_HSR_TAG_INS and it is enabled
> (via ethtool -K) then the HSR stack will pass regular skb and the device
> will prepend the HSR-header (and maintain the HSR-sequence number and so
> on) before putting it on the wire.
> Also, the HSR stack will send a skb on both slave interfaces which are
> regular ethernet devices. But with NETIF_F_HW_HSR_DUP enabled it will
> pass it only to the first slave and expect the underlying device to
> forward it also via the other slave interface.
>
> So I need to pass skb which is can be sent by a dumb device but at the
> same time a device which does offload needs to be able to know when it
> should not do it.
Interesting. I was not aware of those offloads.
>
> > Isn't it HSR's ndo_start_xmit that selects which slave to forward to,
> > based on the information in this header?
>
> Yes, this is correct. I needed to verify that the slave device with
> offload capabilities does not send the skb on both ports and add a
> HSR header while doing so. The non-offloading devices are not an issue,
> it sends packets as-is.
> I managed to rework it and it works without the skb-ext. I just track
> the HSR mode (HSR vs PRP) and then parse the packet for its type and
> decide what needs to be done.
> This works now. Once we settle on the header I can repost it.
Excellent.
^ permalink raw reply
* Re: [PATCH net 2/5] net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
From: Chester A. Unal @ 2026-05-05 16:12 UTC (permalink / raw)
To: Daniel Golle
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, DENG Qingfang, Florian Fainelli,
Arınç ÜNAL, Sean Wang, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <afoUt46gGwAC33ZU@makrotopia.org>
On 05/05/2026 17:03, Daniel Golle wrote:
> On Tue, May 05, 2026 at 03:37:29PM +0000, Chester A. Unal wrote:
>> Hey Daniel.
>>
>> On 05/05/2026 15:16, Daniel Golle wrote:
>>> The BPC, RGAC1 and RGAC2 registers control the handling of link-local
>>> frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are
>>> correctly trapped to the CPU port, but the egress VLAN tag attribute was
>>> set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any
>>> VLAN tags from trapped frames before they reach the CPU.
>>>
>>> This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer
>>> Delay Requests) to arrive at the CPU without their VLAN tag, so they
>>> are delivered to the base network interface instead of the VLAN
>>> sub-interface. The DSA local_termination selftest confirms this: all
>>> link-local protocol tests on VLAN upper interfaces fail.
>>>
>>> Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default)
>>> so that the switch does not modify VLAN tags in trapped frames. This
>>> way VLAN-tagged frames retain their original tag and are delivered to
>>> the correct VLAN sub-interface, matching the behavior of non-trapped
>>> frames which pass through without VLAN tag modification.
>>>
>>> Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames")
>>> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>>
>> Thank you for this patch. Could you please confirm that it conforms to the
>> findings documented on this patch log?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e8bf353577f382c7066c661fed41b2adc0fc7c40
>
> Yes. Combining VLAN CTAG and DSA tag into single "mess" tag is what the
> MT7530 hardware does, and also what tag_mtk.c expects, and mtk_eth_soc
> "special tag" feature handles well.
>
> I've found, addressed and verified all the issues in the series using
> the DSA selftests in tools/testing/selftest/drivers/net/dsa, ie. running
> bridge_vlan_aware.sh, bridge_vlan_unaware.sh and local_termination.sh
> in a loop, and random order, on BPi-R3 (MT7531) and BPi-R4 (MT7988).
>
> With the series applied many of the previously failing tests are now
> passing.
Great to hear!
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
Chester A.
^ permalink raw reply
* Re: [PATCH net v7 1/2] ipv6: flowlabel: take ip6_fl_lock across mem_check and fl_intern
From: Willem de Bruijn @ 2026-05-05 16:11 UTC (permalink / raw)
To: Maoyi Xie, David S . Miller
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, David Ahern,
Alexey Kuznetsov, Willem de Bruijn, Willem de Bruijn, netdev,
linux-kernel, stable
In-Reply-To: <20260505072015.1672730-2-maoyi.xie@ntu.edu.sg>
Maoyi Xie wrote:
> mem_check() in net/ipv6/ip6_flowlabel.c reads fl_size without
> holding ip6_fl_lock. fl_intern() takes the lock immediately
> afterwards. The two checks therefore race against concurrent
> fl_intern, ip6_fl_gc and ip6_fl_purge writers, which makes the
> mem_check budget check approximate.
>
> Move spin_lock_bh(&ip6_fl_lock) and the matching unlock from
> fl_intern() into its only caller ipv6_flowlabel_get(). The
> mem_check() call now runs under the same critical section as the
> fl_intern() insert, so the budget check is exact.
>
> With all writers and the read of fl_size under ip6_fl_lock,
> convert fl_size from atomic_t to plain int. The four sites that
> update or read fl_size are fl_intern (insert path), ip6_fl_gc
> (garbage collector, the !sched check and the per-entry decrement),
> ip6_fl_purge (per-netns purge), and mem_check (budget check), and
> all four now run under ip6_fl_lock.
>
> This is a prerequisite for adding a per-netns budget alongside
> fl_size. The follow-up patch adds netns_ipv6::flowlabel_count and
> folds it into mem_check().
>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Suggested-by: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Please update either your git config name or Signed-off-by to make
sure that the two are the same. Not sure whether that requires a
respin.
With those asides
Reviewed-by: Willem de Bruijn <willemb@google.com>
Thanks for fixing this along with your main fix.
> ---
> net/ipv6/ip6_flowlabel.c | 33 ++++++++++++++++++++-------------
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
> index c92f98c6f..43b5e9ce9 100644
> --- a/net/ipv6/ip6_flowlabel.c
> +++ b/net/ipv6/ip6_flowlabel.c
> @@ -40,7 +40,7 @@
> #define FL_HASH_MASK 255
> #define FL_HASH(l) (ntohl(l)&FL_HASH_MASK)
>
> -static atomic_t fl_size = ATOMIC_INIT(0);
> +static int fl_size;
> static struct ip6_flowlabel __rcu *fl_ht[FL_HASH_MASK+1];
>
> static void ip6_fl_gc(struct timer_list *unused);
> @@ -163,7 +163,7 @@ static void ip6_fl_gc(struct timer_list *unused)
> if (time_after_eq(now, ttd)) {
> *flp = fl->next;
> fl_free(fl);
> - atomic_dec(&fl_size);
> + fl_size--;
> continue;
> }
> if (!sched || time_before(ttd, sched))
> @@ -172,7 +172,7 @@ static void ip6_fl_gc(struct timer_list *unused)
> flp = &fl->next;
> }
> }
> - if (!sched && atomic_read(&fl_size))
> + if (!sched && fl_size)
> sched = now + FL_MAX_LINGER;
> if (sched) {
> mod_timer(&ip6_fl_gc_timer, sched);
> @@ -196,7 +196,7 @@ static void __net_exit ip6_fl_purge(struct net *net)
> atomic_read(&fl->users) == 0) {
> *flp = fl->next;
> fl_free(fl);
> - atomic_dec(&fl_size);
> + fl_size--;
> continue;
> }
> flp = &fl->next;
> @@ -205,6 +205,7 @@ static void __net_exit ip6_fl_purge(struct net *net)
> spin_unlock_bh(&ip6_fl_lock);
> }
>
> +/* Caller must hold ip6_fl_lock. */
nit: lockdep_assert_held as used below is preferable over comments
> @@ -464,10 +459,14 @@ fl_create(struct net *net, struct sock *sk, struct in6_flowlabel_req *freq,
>
> static int mem_check(struct sock *sk)
> {
> - int room = FL_MAX_SIZE - atomic_read(&fl_size);
> + int room;
> struct ipv6_fl_socklist *sfl;
> int count = 0;
>
> + lockdep_assert_held(&ip6_fl_lock);
> +
> + room = FL_MAX_SIZE - fl_size;
> +
> if (room > FL_MAX_SIZE - FL_MAX_PER_SOCK)
> return 0;
>
^ permalink raw reply
* Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue
From: Stefano Garzarella @ 2026-05-05 16:11 UTC (permalink / raw)
To: Eric Dumazet, Arseniy Krasnov, Bobby Eshleman, Stefan Hajnoczi,
Michael S. Tsirkin
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, eric.dumazet, Arseniy Krasnov, Stefan Hajnoczi,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
kvm, virtualization
In-Reply-To: <CANn89iLs8DOWJwDpf_ARoMrV+6b2tbhEJ=VVzeC8gCm5dRGaig@mail.gmail.com>
On Tue, May 05, 2026 at 07:14:36AM -0700, Eric Dumazet wrote:
>On Tue, May 5, 2026 at 6:52 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> On Thu, Apr 30, 2026 at 12:26:52PM +0000, Eric Dumazet wrote:
>> >virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
>> >
>> >virtio_transport_recv_enqueue() skips coalescing for packets
>> >with VIRTIO_VSOCK_SEQ_EOM.
>> >
>> >If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
>> >a very large number of packets can be queued
>> >because vvs->rx_bytes stays at 0.
>> >
>> >Fix this by estimating the skb metadata size:
>> >
>> > (Number of skbs in the queue) * SKB_TRUESIZE(0)
>> >
>> >Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
>> >Signed-off-by: Eric Dumazet <edumazet@google.com>
>> >Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>> >Cc: Stefan Hajnoczi <stefanha@redhat.com>
>> >Cc: Stefano Garzarella <sgarzare@redhat.com>
>> >Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> >Cc: Jason Wang <jasowang@redhat.com>
>> >Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>> >Cc: "Eugenio Pérez" <eperezma@redhat.com>
>> >Cc: kvm@vger.kernel.org
>> >Cc: virtualization@lists.linux.dev
>> >---
>> > net/vmw_vsock/virtio_transport_common.c | 4 +++-
>> > 1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>> >index 416d533f493d7b07e9c77c43f741d28cfcd0953e..9b8014516f4fb1130ae184635fbba4dfee58bd64 100644
>> >--- a/net/vmw_vsock/virtio_transport_common.c
>> >+++ b/net/vmw_vsock/virtio_transport_common.c
>> >@@ -447,7 +447,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
>> > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
>> > u32 len)
>> > {
>> >- if (vvs->buf_used + len > vvs->buf_alloc)
>> >+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
>> >+
>> >+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
>> > return false;
>>
>> I'm not sure about this fix, I mean that maybe this is incomplete.
>> In virtio-vsock, there is a credit mechanism between the two peers:
>> https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-4850003
>>
>> This takes only the payload into account, so it’s true that this problem
>> exists; however, perhaps we should also inform the other peer of a lower
>> credit balance, otherwise the other peer will believe it has much more
>> credit than it actually does, send a large payload, and then the packet
>> will be discarded and the data lost (there are no retransmissions,
>> etc.).
>
>I dunno, perhaps revert 077706165717 ("virtio/vsock: don't use skbuff
>state to account credit")
>and find a better fix then?
IIRC the same issue was there before the commit fixed by that one
(commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with
sk_buff")), so not sure about reverting it TBH.
CCing Arseniy and Bobby.
>
>There is always a discrepancy between skb->len and skb->truesize.
>You will not be able to announce a 1MB window, and accept one milliion
>skb of 1-byte each.
>
>This kind of contract is broken.
>
Yep, I agree, but before we start discarding data (and losing it), IMHO
we should at least inform the other peer that we're out of space.
@Stefan, @Michael, do you think we can do something in the spec to avoid
this issue and in some way take into account also the metadata in the
credit. I mean to avoid the 1-byte packets flooding.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH net v4 3/4] bonding: 3ad: fix mux port state on oper down
From: Louis Scalbert @ 2026-05-05 16:10 UTC (permalink / raw)
To: Jay Vosburgh
Cc: netdev, stephen, andrew+netdev, edumazet, kuba, pabeni, fbl, andy,
shemminger, maheshb
In-Reply-To: <1142168.1776974419@famine>
Hello Jay,
Sorry for the late reply. I’ve been busy with another project these
past few days.
Le jeu. 23 avr. 2026 à 22:00, Jay Vosburgh <jv@jvosburgh.net> a écrit :
>
> Louis Scalbert <louis.scalbert@6wind.com> wrote:
>
> >When the bonding interface has carrier down due to the absence of
> >usable slaves and a slave transitions from down to up, the bonding
> >interface briefly goes carrier up, then down again, and finally up
> >once LACP negotiates collecting and distributing on the port.
> >
> >When lacp_strict mode is on, the interface should not transition to
> >carrier up until LACP negotiation is complete.
> >
> >This happens because the actor and partner port states remain in
> >Collecting_Distributing when the port goes down. When the port
> >comes back up, it temporarily remains in this state until LACP
> >renegotiation occurs.
> >
> >Previously this was mostly cosmetic, but since the bonding carrier
> >state may depend on the LACP negotiation state, it causes the
> >interface to flap.
> >
> >Move an operationally down port to the Mux WAITING state and clear the
> >Synchronization, Collecting, and Distributing states, in accordance with
> >the 802.1AX Mux state machine diagram.
> >
> >Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad")
> >Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
> >---
> > drivers/net/bonding/bond_3ad.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> >diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> >index 9cf064243d58..bc2964ea11f5 100644
> >--- a/drivers/net/bonding/bond_3ad.c
> >+++ b/drivers/net/bonding/bond_3ad.c
> >@@ -1053,6 +1053,8 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> >
> > if (port->sm_vars & AD_PORT_BEGIN) {
> > port->sm_mux_state = AD_MUX_DETACHED;
> >+ } else if (!port->is_enabled && port->sm_mux_state != AD_MUX_DETACHED) {
> >+ port->sm_mux_state = AD_MUX_WAITING;
>
> Technically, this is not exactly following the state machines.
>
> The mux machine should transition to WAITING from DETACHED when
> Selected == SELECTED or STANDBY, not for !is_enabled ("port_enabled" in
> the standard).
The MUX machine still transitions from DETACHED to WAITING; this
happens a few lines later and is unchanged.
The relevant code is:
} else if (!port->is_enabled && port->sm_mux_state != AD_MUX_DETACHED) {
port->sm_mux_state = AD_MUX_WAITING;
} else {
switch (port->sm_mux_state) {
case AD_MUX_DETACHED:
if ((port->sm_vars & AD_PORT_SELECTED)
|| (port->sm_vars & AD_PORT_STANDBY))
/* if SELECTED or STANDBY */
port->sm_mux_state = AD_MUX_WAITING;
break;
My change is for NOT is_enabled AND NOT AD_MUX_DETACHED.
> The check for !is_enabled happens in the receive
> machine, and it would transition to PORT_DISABLED state (which clears
> Synchronization).
I agree with that statement. However, clearing Synchronization is not
sufficient: the purpose of the fix is to clear Collecting and
Distributing.
I noticed that is_enabled is defined in the 802.3ad-2000 standard, while
Port_Operational is defined in 802.1AX-2020. I am not sure about
802.1AX-2014, as I do not have access to that version.
The 802.1AX-2020 standard uses a different MUX state diagram. Compared to
802.3ad, the ATTACHED state has been split into ATTACH and ATTACHED.
There is no longer a WAITING state; it has been replaced by
ATTACHED_WTR.
The new standard says that the MUX machine should transition to
ATTACHED_WTR when Port_Operational is FALSE and the current state is
not DETACHED.
So, in my opinion, the change is correct, at least with respect to
802.1AX-2020.
>
> I'm not sure if this is actually an issue or not; I need to read
> the relevant bits again to make sure I understand how it's supposed to
> work.
Please confirm what you want me to do: should I keep the fix as it is ?
best regards,
Louis Scalbert
>
> -J
>
> > } else {
> > switch (port->sm_mux_state) {
> > case AD_MUX_DETACHED:
> >@@ -1200,6 +1202,11 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> > break;
> > case AD_MUX_WAITING:
> > port->sm_mux_timer_counter = __ad_timer_to_ticks(AD_WAIT_WHILE_TIMER, 0);
> >+ port->actor_oper_port_state &= ~LACP_STATE_SYNCHRONIZATION;
> >+ ad_disable_collecting_distributing(port,
> >+ update_slave_arr);
> >+ port->actor_oper_port_state &= ~LACP_STATE_COLLECTING;
> >+ port->actor_oper_port_state &= ~LACP_STATE_DISTRIBUTING;
> > break;
> > case AD_MUX_ATTACHED:
> > if (port->aggregator->is_active)
> >--
> >2.39.2
> >
>
> ---
> -Jay Vosburgh, jv@jvosburgh.net
^ permalink raw reply
* Re: [PATCH v1] gve: Use generic power management
From: Alexander Lobakin @ 2026-05-05 16:08 UTC (permalink / raw)
To: Vaibhav Gupta
Cc: Joshua Washington, Harshitha Ramamurthy, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Willem de Bruijn, Ankit Garg, Tim Hostetler, Alok Tiwari,
John Fraker, Matt Olson, Praveen Kaligineedi, netdev,
linux-kernel
In-Reply-To: <20260504182139.604925-1-vaibhavgupta40@gmail.com>
From: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Date: Mon, 4 May 2026 18:21:32 +0000
> Switch to the generic power management and remove the usage of legacy
> (pci_driver) hooks.
>
> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/ethernet/google/gve/gve_main.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH 07/11] vfio: selftests: Allow drivers to specify required region size
From: David Matlack @ 2026-05-05 16:05 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches
In-Reply-To: <afoSQWreOWDIfVxZ@nvidia.com>
On Tue, May 5, 2026 at 8:52 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, May 04, 2026 at 08:55:58PM +0000, David Matlack wrote:
> > On 2026-04-30 09:08 PM, Jason Gunthorpe wrote:
> > > Add a region_size field to struct vfio_pci_driver_ops so drivers can
> > > declare how much DMA-mapped region they need. The mlx5 driver will
> > > need ~18MB for firmware pages. Existing drivers leave region_size as
> > > 0 and get the current default of SZ_2M.
> >
> > I would like to get rid of the magic SZ_2M to make it easier for other
> > tests to use the driver framework. Can you make this commit update all
> > the drivers to set region_size? They can all use the same approach:
> >
> > struct vfio_pci_driver_ops foo_driver = {
> > ...
> > .region_size = roundup_pow_of_two(sizeof(struct foo)),
> > ...
> > };
>
> Sure, lets put the roundup in the core code?
Sounds good.
^ permalink raw reply
* Re: [PATCH 09/11] vfio: selftests: Add mlx5 driver - HW init and command interface
From: David Matlack @ 2026-05-05 16:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches
In-Reply-To: <afoQtL6gEN2wUba7@nvidia.com>
On Tue, May 5, 2026 at 8:46 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, May 04, 2026 at 10:35:43PM +0000, David Matlack wrote:
> > On 2026-04-30 09:08 PM, Jason Gunthorpe wrote:
> >
> > > +/*
> > > + * Driver state — overlaid on device->driver.region.vaddr.
> > > + *
> > > + * Contains both software-only state and HW-visible DMA buffers. HW buffers need
> > > + * strict IOVA alignment.
> > > + */
> > > +struct mlx5st_device {
> >
> > Can we do s/mlx5st/mlx5/ on the series?
>
> No, I don't want to do this. Since it is in tree I want to reserve the
> mlx5_ prefix only for the main driver. The driver is huge, I do not
> want to harm or confuse grep - that team will get mad.
git-grep can be scoped to directories, but ok let's keep mlx5st to
avoid disrupting anyone's workflow.
^ permalink raw reply
* Re: [PATCH net 2/5] net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
From: Daniel Golle @ 2026-05-05 16:03 UTC (permalink / raw)
To: Chester A. Unal
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, DENG Qingfang, Florian Fainelli,
Arınç ÜNAL, Sean Wang, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <46071c08-d85f-4157-9d61-6a0feef56747@arinc9.com>
On Tue, May 05, 2026 at 03:37:29PM +0000, Chester A. Unal wrote:
> Hey Daniel.
>
> On 05/05/2026 15:16, Daniel Golle wrote:
> > The BPC, RGAC1 and RGAC2 registers control the handling of link-local
> > frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are
> > correctly trapped to the CPU port, but the egress VLAN tag attribute was
> > set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any
> > VLAN tags from trapped frames before they reach the CPU.
> >
> > This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer
> > Delay Requests) to arrive at the CPU without their VLAN tag, so they
> > are delivered to the base network interface instead of the VLAN
> > sub-interface. The DSA local_termination selftest confirms this: all
> > link-local protocol tests on VLAN upper interfaces fail.
> >
> > Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default)
> > so that the switch does not modify VLAN tags in trapped frames. This
> > way VLAN-tagged frames retain their original tag and are delivered to
> > the correct VLAN sub-interface, matching the behavior of non-trapped
> > frames which pass through without VLAN tag modification.
> >
> > Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames")
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>
> Thank you for this patch. Could you please confirm that it conforms to the
> findings documented on this patch log?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e8bf353577f382c7066c661fed41b2adc0fc7c40
Yes. Combining VLAN CTAG and DSA tag into single "mess" tag is what the
MT7530 hardware does, and also what tag_mtk.c expects, and mtk_eth_soc
"special tag" feature handles well.
I've found, addressed and verified all the issues in the series using
the DSA selftests in tools/testing/selftest/drivers/net/dsa, ie. running
bridge_vlan_aware.sh, bridge_vlan_unaware.sh and local_termination.sh
in a loop, and random order, on BPi-R3 (MT7531) and BPi-R4 (MT7988).
With the series applied many of the previously failing tests are now
passing.
^ permalink raw reply
* Re: [PATCH net-next 02/12] net: pcs: pcs-xpcs: select operating mode for 10G-baseR capable PCS
From: Daniel Thompson @ 2026-05-05 15:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alex Elder, andrew+netdev, davem, edumazet, kuba, pabeni,
maxime.chevallier, rmk+kernel, andersson, konradybcio, robh,
krzk+dt, conor+dt, linusw, brgl, arnd, gregkh, mohd.anwar,
a0987203069, alexandre.torgue, ast, boon.khai.ng, chenchuangyu,
chenhuacai, daniel, hawk, hkallweit1, inochiama, john.fastabend,
julianbraha, livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <f9a581a2-02ea-4948-8c97-835cb7638b1d@lunn.ch>
On Fri, May 01, 2026 at 06:50:45PM +0200, Andrew Lunn wrote:
> > +static int xpcs_config_operating_mode(struct dw_xpcs *xpcs, int an_mode)
> > +{
> > + int mdio_stat2, ret;
> > +
> > + switch (an_mode) {
> > + case DW_AN_C37_SGMII:
> > + case DW_AN_C37_1000BASEX:
> > + case DW_2500BASEX:
> > + mdio_stat2 = xpcs_read(xpcs, MDIO_MMD_PCS, MDIO_STAT2);
> > + if (mdio_stat2 < 0)
> > + return mdio_stat2;
> > +
> > + /*
> > + * If this XPCS supports 10Gbase-R then it will be the default
> > + * which prevents 1000base-X and slower from working correctly.
>
> It would be interesting to know if Toshiba messed up the integration
> of the PCS, or there is an errata for the licensed IP.
I'm afraid I don't know, but it looks like the issue is not unique to
Toshiba!
This is a discovery which, rather to my chagrin, I only made after we
posted the patches (thanks to a hint from Sashiko): there is similar
code in txgbe_xpcs_switch_mode(). I cleary overlooked that when I
originally reviewed the existing XPCS code. I suspect I stopped
scanning that code path due to the PMA related conditional branch...
Regardless of how I missed it, txgbe_xpcs_switch_mode() implements
similar logic to this patch. I think it is using MDIO_PCS_CTRL2_10GBX as
the Reserved value but otherwise looks similar. There are comments that
imply 10Gbase-X isn't implemented by their XPCS which would make
MDIO_PCS_CTRL2_10GBX reserved (but are too vague to be 100% sure).
Right now it looks like xpcs_switch_interface_mode() and my
xpcs_config_operating_mode() are more closely related than I realized
so I plan to move my code into xpcs_switch_interface_mode().
I don't think I can unify the Wangxun and Toshiba code (the waits and
resets in the Wangxun code make that too high risk) but I'm not yet
ready to give up and just make the Toshiba changes into another vendor
quirk!
Daniel.
^ permalink raw reply
* Re: [PATCH net v7 2/2] ipv6: flowlabel: enforce per-netns limit for unprivileged callers
From: Willem de Bruijn @ 2026-05-05 15:58 UTC (permalink / raw)
To: Maoyi Xie, David S . Miller
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, David Ahern,
Alexey Kuznetsov, Willem de Bruijn, Willem de Bruijn, netdev,
linux-kernel, stable
In-Reply-To: <20260505072015.1672730-3-maoyi.xie@ntu.edu.sg>
Maoyi Xie wrote:
> fl_size, fl_ht and ip6_fl_lock in net/ipv6/ip6_flowlabel.c are
> file scope and shared across netns. mem_check() reads fl_size to
> decide whether to deny non-CAP_NET_ADMIN callers. capable() runs
> against init_user_ns, so an unprivileged user in any non-init
> userns can push fl_size past FL_MAX_SIZE - FL_MAX_SIZE / 4 and
> starve every other unprivileged userns on the host.
>
> Add struct netns_ipv6::flowlabel_count, bumped and decremented
> next to fl_size in fl_intern, ip6_fl_gc and ip6_fl_purge. The new
> field fills the existing 4-byte hole after ipmr_seq, so struct
> netns_ipv6 stays the same size on 64-bit builds.
>
> Bump FL_MAX_SIZE from 4096 to 8192. It has been 4096 since the
> file was added. Machines and connection counts have grown.
>
> mem_check() folds an extra per-netns ceiling into the existing
> non-CAP_NET_ADMIN conditional. The ceiling is half of the total
> budget that unprivileged callers have ever been able to use, i.e.
> (FL_MAX_SIZE - FL_MAX_SIZE / 4) / 2 = 3072 entries. With
> FL_MAX_SIZE doubled, this preserves the original per-user reach
> of 3K (what an unprivileged caller could already obtain before
> this change), while forcing an attacker to spread allocations
> across at least two netns to exhaust the global non-CAP_NET_ADMIN
> budget.
>
> CAP_NET_ADMIN against init_user_ns still bypasses both caps.
>
> The previous patch took ip6_fl_lock across mem_check and
> fl_intern, so the new flowlabel_count read in mem_check and the
> new flowlabel_count++ in fl_intern run under the same critical
> section. flowlabel_count is therefore plain int, like fl_size.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Suggested-by: Willem de Bruijn <willemb@google.com>
> Cc: stable@vger.kernel.org # v5.15+
> Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH 00/11] mlx5 support for VFIO self test
From: David Matlack @ 2026-05-05 15:57 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches, Josh Hilke
In-Reply-To: <afoR1izCEe9y0MZA@nvidia.com>
On Tue, May 5, 2026 at 8:50 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, May 04, 2026 at 10:54:08PM +0000, David Matlack wrote:
> > > The PF support flow requires a bunch more complicated stuff.
> >
> > Do you think it's worth supporting PFs? If anyone with a CX NIC can
> > enable SR-IOV and run selftests on a VF then we can keep the driver
> > somewhat simpler.
>
> It turns out my test system cannot enable SR-IOV due to iommu_group
> problems so I rather prefer to have this :) I had to hack a kernel up
> to do the initial testing and it was very annoying.
Ok sounds good.
^ permalink raw reply
* Re: [PATCH v2] net: dsa: realtek: rtl8365mb: add support for RTL8367SB
From: Alexander Lobakin @ 2026-05-05 15:55 UTC (permalink / raw)
To: Mieczyslaw Nalewaj
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev
In-Reply-To: <05921e1f-693b-4322-a762-c8f03c386a78@yahoo.com>
From: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Date: Tue, 5 May 2026 16:17:19 +0200
> Add chip info entry for the Realtek RTL8367SB switch. This device has
> chip ID 0x6367 and version 0x0010. It exposes two external interfaces:
> port 6 supports SGMII and HSGMII, while port 7 supports MII, TMII,
> RMII and RGMII. Use the existing 8365MB-VC jam table for initialization.
>
> Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/dsa/realtek/rtl8365mb.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Thanks,
Olek
^ permalink raw reply
* [PATCH net-next v4 2/3] r8152: Add support for the RTL8159 chip
From: Birger Koblitz @ 2026-05-05 15:56 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz,
Aleksander Jan Bajkowski
In-Reply-To: <20260505-rtl8159_net_next-v4-0-1a648a9c4d8d@birger-koblitz.de>
The RTL8159 re-uses the packet descriptor format introduced with the
RTL8157 and other hardware features of the RTL8157 (RTL_VER_16) such
as the SRAM access. The support therefore consists in expanding the
existing RTL8157 code for initialization and USB power management
to also be used for the RTL8159 (RTL_VER_17).
Most of the additional code is added in r8157_hw_phy_cfg() to configure
the RTL8159 PHY.
Add support for the USB device ID of Realtek RTL8159-based adapters,
for which the product ID is 0x815a. Detect the RTL8159 as RTL_VER_17
and set it up.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
drivers/net/usb/r8152.c | 277 +++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 261 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 05abfab1df94a571347196bfce7c232865e1058e..1e7f20348ac6def85106f1e8bab93a377980c77d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1247,6 +1247,7 @@ enum rtl_version {
RTL_VER_14,
RTL_VER_15,
RTL_VER_16,
+ RTL_VER_17,
RTL_VER_MAX
};
@@ -3432,6 +3433,7 @@ static void rtl8152_nic_reset(struct r8152 *tp)
break;
case RTL_VER_16:
+ case RTL_VER_17:
ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE | CR_TE);
break;
@@ -3471,6 +3473,9 @@ static void rtl_eee_plus_en(struct r8152 *tp, bool enable)
static void rtl_set_eee_plus(struct r8152 *tp)
{
+ if (tp->version == RTL_VER_17)
+ return rtl_eee_plus_en(tp, false);
+
if (rtl8152_get_speed(tp) & _10bps)
rtl_eee_plus_en(tp, true);
else
@@ -3656,6 +3661,7 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
case RTL_VER_13:
case RTL_VER_15:
case RTL_VER_16:
+ case RTL_VER_17:
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_TIMEOUT,
640 / 8);
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EXTRA_AGGR_TMR,
@@ -3700,6 +3706,7 @@ static void r8153_set_rx_early_size(struct r8152 *tp)
ocp_data / 8);
break;
case RTL_VER_16:
+ case RTL_VER_17:
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE,
ocp_data / 16);
break;
@@ -4548,6 +4555,7 @@ static void rtl_clear_bp(struct r8152 *tp, u16 type)
break;
case RTL_VER_14:
case RTL_VER_16:
+ case RTL_VER_17:
default:
ocp_write_word(tp, type, USB_BP2_EN, 0);
bp_num = 16;
@@ -5818,6 +5826,7 @@ static void rtl_eee_enable(struct r8152 *tp, bool enable)
case RTL_VER_13:
case RTL_VER_15:
case RTL_VER_16:
+ case RTL_VER_17:
if (enable) {
r8156_eee_en(tp, true);
ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
@@ -6408,7 +6417,7 @@ static int rtl8156_enable(struct r8152 *tp)
set_tx_qlen(tp);
rtl_set_eee_plus(tp);
- if (tp->version >= RTL_VER_12 && tp->version <= RTL_VER_16)
+ if (tp->version >= RTL_VER_12 && tp->version <= RTL_VER_17)
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_RX_AGGR_NUM, RX_AGGR_NUM_MASK);
r8153_set_rx_early_timeout(tp);
@@ -6817,7 +6826,7 @@ static void rtl8156_up(struct r8152 *tp)
return;
r8153b_u1u2en(tp, false);
- if (tp->version != RTL_VER_16)
+ if (tp->version < RTL_VER_16)
r8153_u2p3en(tp, false);
r8153_aldps_en(tp, false);
@@ -6831,7 +6840,7 @@ static void rtl8156_up(struct r8152 *tp)
ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, NOW_IS_OOB);
- if (tp->version == RTL_VER_16)
+ if (tp->version >= RTL_VER_16)
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_RCR1, BIT(3));
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_SFF_STS_7, MCU_BORW_EN);
@@ -6856,7 +6865,7 @@ static void rtl8156_up(struct r8152 *tp)
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
- if (tp->version != RTL_VER_16)
+ if (tp->version < RTL_VER_16)
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
RG_PWRDN_EN | ALL_SPEED_OFF);
@@ -6868,10 +6877,10 @@ static void rtl8156_up(struct r8152 *tp)
}
r8153_aldps_en(tp, true);
- if (tp->version != RTL_VER_16)
+ if (tp->version < RTL_VER_16)
r8153_u2p3en(tp, true);
- if (tp->version != RTL_VER_16 && tp->udev->speed >= USB_SPEED_SUPER)
+ if (tp->version < RTL_VER_16 && tp->udev->speed >= USB_SPEED_SUPER)
r8153b_u1u2en(tp, true);
}
@@ -6886,7 +6895,7 @@ static void rtl8156_down(struct r8152 *tp)
PLA_MCU_SPDWN_EN);
r8153b_u1u2en(tp, false);
- if (tp->version != RTL_VER_16) {
+ if (tp->version < RTL_VER_16) {
r8153_u2p3en(tp, false);
r8153b_power_cut_en(tp, false);
}
@@ -7996,7 +8005,7 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
/* Advanced Power Saving parameter */
ocp_reg_set_bits(tp, 0xa430, BIT(0) | BIT(1));
- /* aldpsce force mode */
+ /* Disable ALDPS force mode */
ocp_reg_clr_bits(tp, 0xa44a, BIT(2));
switch (tp->version) {
@@ -8120,6 +8129,190 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
sram2_write_w0w1(tp, 0x807c, 0xff00, 0x5000);
sram2_write_w0w1(tp, 0x809d, 0xff00, 0x5000);
break;
+
+ case RTL_VER_17:
+ /* Disable bypass turn off clk in ALDPS */
+ ocp_byte_clr_bits(tp, MCU_TYPE_PLA, 0xd3c8, BIT(0));
+
+ /* Power level tuning
+ * test mode power level
+ */
+ sram_write_w0w1(tp, 0x8415, 0xff00, 0x9300);
+ /* normal link power level 10G, 5G, 2.5G */
+ sram_write_w0w1(tp, 0x81a3, 0xff00, 0x0f00);
+ sram_write_w0w1(tp, 0x81ae, 0xff00, 0x0f00);
+ sram_write_w0w1(tp, 0x81b9, 0xff00, 0xb900);
+ /* normal link TX filter */
+ sram2_write_w0w1(tp, 0x83b0, 0x0e00, 0);
+ sram2_write_w0w1(tp, 0x83c5, 0x0e00, 0);
+ sram2_write_w0w1(tp, 0x83da, 0x0e00, 0);
+ sram2_write_w0w1(tp, 0x83ef, 0x0e00, 0);
+
+ /* AFE power saving for 2.5G & 5G */
+ sram_write(tp, 0x8173, 0x8620);
+ sram_write(tp, 0x8175, 0x8671);
+
+ sram_write_w0w1(tp, 0x817c, 0, BIT(13));
+ sram_write_w0w1(tp, 0x8187, 0, BIT(13));
+ sram_write_w0w1(tp, 0x8192, 0, BIT(13));
+ sram_write_w0w1(tp, 0x819d, 0, BIT(13));
+ sram_write_w0w1(tp, 0x81a8, BIT(13), 0);
+ sram_write_w0w1(tp, 0x81b3, BIT(13), 0);
+ sram_write_w0w1(tp, 0x81be, 0, BIT(13));
+
+ sram_write_w0w1(tp, 0x817d, 0xff00, 0xa600);
+ sram_write_w0w1(tp, 0x8188, 0xff00, 0xa600);
+ sram_write_w0w1(tp, 0x8193, 0xff00, 0xa600);
+ sram_write_w0w1(tp, 0x819e, 0xff00, 0xa600);
+ sram_write_w0w1(tp, 0x81a9, 0xff00, 0x1400);
+ sram_write_w0w1(tp, 0x81b4, 0xff00, 0x1400);
+ sram_write_w0w1(tp, 0x81bf, 0xff00, 0xa600);
+
+ /* RFI parameter
+ * disable preset FBE
+ */
+ ocp_reg_clr_bits(tp, 0xaeaa, BIT(5) | BIT(3));
+ /* modify PGA for 5G&10G */
+ sram2_write(tp, 0x84f0, 0x201c);
+ sram2_write(tp, 0x84f2, 0x3117);
+ /* RFI parameter */
+ ocp_reg_write(tp, 0xaec6, 0x0000);
+ ocp_reg_write(tp, 0xae20, 0xffff);
+ ocp_reg_write(tp, 0xaece, 0xffff);
+ ocp_reg_write(tp, 0xaed2, 0xffff);
+ ocp_reg_write(tp, 0xaec8, 0x0000);
+ ocp_reg_clr_bits(tp, 0xaed0, BIT(0));
+ ocp_reg_write(tp, 0xadb8, 0x0150);
+ sram2_write_w0w1(tp, 0x8197, 0xff00, 0x5000);
+ sram2_write_w0w1(tp, 0x8231, 0xff00, 0x5000);
+ sram2_write_w0w1(tp, 0x82cb, 0xff00, 0x5000);
+ sram2_write_w0w1(tp, 0x82cd, 0xff00, 0x5700);
+ sram2_write_w0w1(tp, 0x8233, 0xff00, 0x5700);
+ sram2_write_w0w1(tp, 0x8199, 0xff00, 0x5700);
+
+ sram2_write(tp, 0x815a, 0x0150);
+ sram2_write(tp, 0x81f4, 0x0150);
+ sram2_write(tp, 0x828e, 0x0150);
+ sram2_write(tp, 0x81b1, 0x0000);
+ sram2_write(tp, 0x824b, 0x0000);
+ sram2_write(tp, 0x82e5, 0x0000);
+
+ sram2_write_w0w1(tp, 0x84f7, 0xff00, 0x2800);
+ ocp_reg_set_bits(tp, 0xaec2, BIT(12));
+ sram2_write_w0w1(tp, 0x81b3, 0xff00, 0xad00);
+ sram2_write_w0w1(tp, 0x824d, 0xff00, 0xad00);
+ sram2_write_w0w1(tp, 0x82e7, 0xff00, 0xad00);
+ ocp_reg_w0w1(tp, 0xae4e, 0x000f, 0x0001);
+ sram2_write_w0w1(tp, 0x82ce, 0xf000, 0x4000);
+
+ /* 5G shift sel, default = '04'
+ * 10G shift sel, default = '03'
+ */
+ sram2_write_w0w1(tp, 0x83a5, 0xff00, 0x0400);
+ sram2_write_w0w1(tp, 0x83a6, 0xff00, 0x0400);
+ sram2_write_w0w1(tp, 0x83a7, 0xff00, 0x0400);
+ sram2_write_w0w1(tp, 0x83a8, 0xff00, 0x0400);
+
+ /* XG INRX parameters
+ * RC coefficients
+ */
+ sram2_write(tp, 0x84ac, 0x0000);
+ sram2_write(tp, 0x84ae, 0x0000);
+ sram2_write(tp, 0x84b0, 0xf818);
+ sram2_write_w0w1(tp, 0x84b2, 0xff00, 0x6000);
+ /* Training AAGC PAR (with uc2 patch) */
+ sram2_write(tp, 0x8ffc, 0x6008);
+ sram2_write(tp, 0x8ffe, 0xf450);
+ /* DAC BGK */
+ sram2_write_w0w1(tp, 0x8015, 0, BIT(9));
+ sram2_write_w0w1(tp, 0x8016, 0, BIT(11));
+ sram2_write_w0w1(tp, 0x8fe6, 0xff00, 0x0800);
+ sram2_write(tp, 0x8fe4, 0x2114);
+ /* 10G PBO table */
+ sram2_write(tp, 0x8647, 0xa7b1);
+ sram2_write(tp, 0x8649, 0xbbca);
+ sram2_write_w0w1(tp, 0x864b, 0xff00, 0xdc00);
+ /* 2.5G ado power window size */
+ sram2_write_w0w1(tp, 0x8154, 0xc000, 0x4000);
+ sram2_write_w0w1(tp, 0x8158, 0xc000, 0);
+ /* 10G lock far */
+ sram2_write(tp, 0x826c, 0xffff);
+ sram2_write(tp, 0x826e, 0xffff);
+ /* XG INRX parameter */
+ sram2_write_w0w1(tp, 0x8872, 0xff00, 0x0e00);
+ sram_write_w0w1(tp, 0x8012, 0, BIT(11));
+ sram_write_w0w1(tp, 0x8012, 0, BIT(14));
+ ocp_reg_set_bits(tp, 0xb576, BIT(0));
+ sram_write_w0w1(tp, 0x834a, 0xff00, 0x0700);
+ sram2_write_w0w1(tp, 0x8217, 0x3f00, 0x2a00);
+ sram_write_w0w1(tp, 0x81b1, 0xff00, 0x0b00);
+ sram2_write_w0w1(tp, 0x8fed, 0xff00, 0x4e00);
+ /* Slave about EC mu of datamode AAGC and DAC BG */
+ sram2_write_w0w1(tp, 0x88ac, 0xff00, 0x2300);
+ /* improve UBE */
+ ocp_reg_set_bits(tp, 0xbf0c, 0x7 << 11);
+ /* close Sparse NEC, improve connect 5EUU cable performance */
+ sram2_write_w0w1(tp, 0x88de, 0xff00, 0);
+ /* 5G slave compatibility issue */
+ sram2_write(tp, 0x80b4, 0x5195);
+
+ /* XG Test Mode
+ * xgtstm_map_tbl for mdi_cap_sel
+ */
+ sram_write(tp, 0x8370, 0x8671);
+ sram_write(tp, 0x8372, 0x86c8);
+ /* xgtstm_amp_map_tbl for REG_IBX_UP_SHIFT_L */
+ sram_write(tp, 0x8401, 0x86c8);
+ sram_write(tp, 0x8403, 0x86da);
+ sram_write_w0w1(tp, 0x8406, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x8408, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x840a, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x840c, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x840e, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x8410, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x8412, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x8414, 0x1800, 0x1000);
+ sram_write_w0w1(tp, 0x8416, 0x1800, 0x1000);
+
+ /* Cable Test Patch */
+ sram_write(tp, 0x82bd, 0x1f40);
+
+ /* Thermal sensor parameters */
+ ocp_reg_w0w1(tp, 0xbfb4, 0x07ff, 0x0328);
+ ocp_reg_write(tp, 0xbfb6, 0x3e14);
+
+ /* spdchg_gtx_shape_100M */
+ ocp_reg_write(tp, OCP_SRAM_ADDR, 0x81c4);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x003b);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0086);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00b7);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00db);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00c3);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0078);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0047);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0023);
+
+ /* lsbmsk_parameters
+ * RL6961_lsbmsk_parameter_250207
+ */
+ sram2_write(tp, 0x88d7, 0x01a0);
+ sram2_write(tp, 0x88d9, 0x01a0);
+ sram2_write(tp, 0x8ffa, 0x002a);
+
+ sram2_write(tp, 0x8fee, 0xffdf);
+ sram2_write(tp, 0x8ff0, 0xffff);
+ sram2_write(tp, 0x8ff2, 0x0a4a);
+ sram2_write(tp, 0x8ff4, 0xaa5a);
+ sram2_write(tp, 0x8ff6, 0x0a4a);
+ sram2_write(tp, 0x8ff8, 0xaa5a);
+
+ sram2_write_w0w1(tp, 0x88d5, 0xff00, 0x0200);
+ break;
+
default:
break;
}
@@ -8155,6 +8348,18 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
set_bit(PHY_RESET, &tp->flags);
}
+static int r8159_wait_backup_restore(struct r8152 *tp)
+{
+ u32 ocp_data;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
+ if (!(ocp_data & PCUT_STATUS))
+ return 0;
+
+ return poll_timeout_us(ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_GPHY_CTRL),
+ ocp_data & BACKUP_RESTRORE, 200, 20000, false);
+}
+
static void r8156_init(struct r8152 *tp)
{
u32 ocp_data;
@@ -8164,14 +8369,14 @@ static void r8156_init(struct r8152 *tp)
if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
return;
- if (tp->version == RTL_VER_16) {
+ if (tp->version == RTL_VER_16 || tp->version == RTL_VER_17) {
ocp_byte_set_bits(tp, MCU_TYPE_USB, 0xcffe, BIT(3));
ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xd3ca, BIT(0));
}
ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_ECM_OP, EN_ALL_SPEED);
- if (tp->version != RTL_VER_16)
+ if (tp->version < RTL_VER_16)
ocp_write_word(tp, MCU_TYPE_USB, USB_SPEED_OPTION, 0);
ocp_word_set_bits(tp, MCU_TYPE_USB, USB_ECM_OPTION, BYPASS_MAC_RESET);
@@ -8185,6 +8390,7 @@ static void r8156_init(struct r8152 *tp)
case RTL_VER_13:
case RTL_VER_15:
case RTL_VER_16:
+ case RTL_VER_17:
r8156b_wait_loading_flash(tp);
break;
default:
@@ -8201,6 +8407,12 @@ static void r8156_init(struct r8152 *tp)
return;
}
+ if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp)) {
+ rtl_set_inaccessible(tp);
+ dev_err(&tp->intf->dev, "init failed, backup-restore timed out\n");
+ return;
+ }
+
data = r8153_phy_status(tp, 0);
if (data == PHY_STAT_EXT_INIT) {
ocp_reg_clr_bits(tp, 0xa468, BIT(3) | BIT(1));
@@ -8216,7 +8428,7 @@ static void r8156_init(struct r8152 *tp)
data = r8153_phy_status(tp, PHY_STAT_LAN_ON);
- if (tp->version == RTL_VER_16)
+ if (tp->version >= RTL_VER_16)
r8157_u2p3en(tp, false);
else
r8153_u2p3en(tp, false);
@@ -8227,7 +8439,7 @@ static void r8156_init(struct r8152 *tp)
/* U1/U2/L1 idle timer. 500 us */
ocp_write_word(tp, MCU_TYPE_USB, USB_U1U2_TIMER, 500);
- if (tp->version == RTL_VER_16)
+ if (tp->version >= RTL_VER_16)
r8157_power_cut_en(tp, false);
else
r8153b_power_cut_en(tp, false);
@@ -8260,7 +8472,7 @@ static void r8156_init(struct r8152 *tp)
r8156_mac_clk_spd(tp, true);
- if (tp->version != RTL_VER_16)
+ if (tp->version < RTL_VER_16)
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EXTRA_STATUS);
@@ -8273,8 +8485,13 @@ static void r8156_init(struct r8152 *tp)
set_bit(GREEN_ETHERNET, &tp->flags);
- /* rx aggregation / 16 bytes Rx descriptor */
- if (tp->version == RTL_VER_16)
+ /* RX aggregation / 16 bytes RX descriptor
+ * BIT(11) is specific to RTL8159, with unknown meaning
+ */
+ if (tp->version == RTL_VER_17)
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
+ RX_AGG_DISABLE | RX_DESC_16B | BIT(11));
+ else if (tp->version == RTL_VER_16)
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_DESC_16B);
else
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_ZERO_EN);
@@ -8282,7 +8499,7 @@ static void r8156_init(struct r8152 *tp)
if (tp->version < RTL_VER_12)
ocp_byte_set_bits(tp, MCU_TYPE_USB, USB_BMU_CONFIG, ACT_ODMA);
- if (tp->version == RTL_VER_16) {
+ if (tp->version >= RTL_VER_16) {
/* Disable Rx Zero Len */
rtl_bmu_clr_bits(tp, 0x2300, BIT(3));
/* TX descriptor Signature */
@@ -9670,6 +9887,29 @@ static int rtl_ops_init(struct r8152 *tp)
r8157_desc_init(tp);
break;
+ case RTL_VER_17:
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_100TX | MDIO_EEE_1000T | MDIO_EEE_10GT;
+ tp->eee_adv2 = MDIO_EEE_2_5GT | MDIO_EEE_5GT;
+ ops->init = r8156_init;
+ ops->enable = rtl8156_enable;
+ ops->disable = rtl8153_disable;
+ ops->up = rtl8156_up;
+ ops->down = rtl8156_down;
+ ops->unload = rtl8153_unload;
+ ops->eee_get = r8153_get_eee;
+ ops->eee_set = r8152_set_eee;
+ ops->in_nway = rtl8153_in_nway;
+ ops->hw_phy_cfg = r8157_hw_phy_cfg;
+ ops->autosuspend_en = rtl8157_runtime_enable;
+ ops->change_mtu = rtl8156_change_mtu;
+ tp->rx_buf_sz = 48 * 1024;
+ tp->support_2500full = 1;
+ tp->support_5000full = 1;
+ tp->support_10000full = 1;
+ r8157_desc_init(tp);
+ break;
+
default:
ret = -ENODEV;
dev_err(&tp->intf->dev, "Unknown Device\n");
@@ -9823,6 +10063,9 @@ static u8 __rtl_get_hw_ver(struct usb_device *udev)
case 0x1030:
version = RTL_VER_16;
break;
+ case 0x2020:
+ version = RTL_VER_17;
+ break;
default:
version = RTL_VER_UNKNOWN;
dev_info(&udev->dev, "Unknown version 0x%04x\n", ocp_data);
@@ -9975,6 +10218,7 @@ static int rtl8152_probe_once(struct usb_interface *intf,
case RTL_VER_13:
case RTL_VER_15:
case RTL_VER_16:
+ case RTL_VER_17:
netdev->max_mtu = size_to_mtu(16 * 1024);
break;
case RTL_VER_01:
@@ -10140,6 +10384,7 @@ static const struct usb_device_id rtl8152_table[] = {
{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8155) },
{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8156) },
{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8157) },
+ { USB_DEVICE(VENDOR_ID_REALTEK, 0x815a) },
/* Microsoft */
{ USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab) },
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v4 3/3] r8152: Add firmware upload capability for RTL8157/RTL8159
From: Birger Koblitz @ 2026-05-05 15:56 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz,
Aleksander Jan Bajkowski
In-Reply-To: <20260505-rtl8159_net_next-v4-0-1a648a9c4d8d@birger-koblitz.de>
The RTL8159 (RTL_VER_17) requires firmware for its PHY in order to work
at connection speeds > 5GBit. Add support for uploading firmware for
the PHY using the existing rtl8152_apply_firmware() function
in r8157_hw_phy_cfg() and set up the correct names for the firmware
files.
This also adds support for uploading firmware for the RTL8157
(RTL_VER_16) PHY, for which firmware is however not strictly necessary
to work. Still, this allows to upload newer versions of the firmware used
by this chip, e.g. to improve interoperability.
If no firmware is found, both the RTL8157 and the RTL8159 will continue
to work.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
drivers/net/usb/r8152.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1e7f20348ac6def85106f1e8bab93a377980c77d..d281ad5ed78eded01876c6064aed95e1f78cfc05 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4663,10 +4663,11 @@ static bool rtl8152_is_fw_phy_speed_up_ok(struct r8152 *tp, struct fw_phy_speed_
case RTL_VER_11:
case RTL_VER_12:
case RTL_VER_14:
- case RTL_VER_16:
goto out;
case RTL_VER_13:
case RTL_VER_15:
+ case RTL_VER_16:
+ case RTL_VER_17:
default:
break;
}
@@ -7982,12 +7983,14 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
data = r8153_phy_status(tp, 0);
switch (data) {
case PHY_STAT_EXT_INIT:
+ rtl8152_apply_firmware(tp, true);
ocp_reg_clr_bits(tp, 0xa466, BIT(0));
ocp_reg_clr_bits(tp, 0xa468, BIT(3) | BIT(1));
break;
case PHY_STAT_LAN_ON:
case PHY_STAT_PWRDN:
default:
+ rtl8152_apply_firmware(tp, false);
break;
}
@@ -9926,6 +9929,8 @@ static int rtl_ops_init(struct r8152 *tp)
#define FIRMWARE_8153C_1 "rtl_nic/rtl8153c-1.fw"
#define FIRMWARE_8156A_2 "rtl_nic/rtl8156a-2.fw"
#define FIRMWARE_8156B_2 "rtl_nic/rtl8156b-2.fw"
+#define FIRMWARE_8157_1 "rtl_nic/rtl8157-1.fw"
+#define FIRMWARE_8159_1 "rtl_nic/rtl8159-1.fw"
MODULE_FIRMWARE(FIRMWARE_8153A_2);
MODULE_FIRMWARE(FIRMWARE_8153A_3);
@@ -9934,6 +9939,8 @@ MODULE_FIRMWARE(FIRMWARE_8153B_2);
MODULE_FIRMWARE(FIRMWARE_8153C_1);
MODULE_FIRMWARE(FIRMWARE_8156A_2);
MODULE_FIRMWARE(FIRMWARE_8156B_2);
+MODULE_FIRMWARE(FIRMWARE_8157_1);
+MODULE_FIRMWARE(FIRMWARE_8159_1);
static int rtl_fw_init(struct r8152 *tp)
{
@@ -9972,6 +9979,12 @@ static int rtl_fw_init(struct r8152 *tp)
rtl_fw->pre_fw = r8153b_pre_firmware_1;
rtl_fw->post_fw = r8153c_post_firmware_1;
break;
+ case RTL_VER_16:
+ rtl_fw->fw_name = FIRMWARE_8157_1;
+ break;
+ case RTL_VER_17:
+ rtl_fw->fw_name = FIRMWARE_8159_1;
+ break;
default:
break;
}
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v4 1/3] r8152: Add support for 10Gbit Link Speeds and EEE
From: Birger Koblitz @ 2026-05-05 15:56 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz,
Andrew Lunn, Aleksander Jan Bajkowski
In-Reply-To: <20260505-rtl8159_net_next-v4-0-1a648a9c4d8d@birger-koblitz.de>
The RTL8159 supports 10GBit Link speeds. Add support for this speed
in the setup and setting/getting through ethtool. Also add 10GBit EEE.
Add functionality for setup and ethtool get/set methods.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
drivers/net/usb/r8152.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ae834876aa1acc7a9af08a4c01b7a984c4ab8433..05abfab1df94a571347196bfce7c232865e1058e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -621,6 +621,7 @@ enum spd_duplex {
FORCE_1000M_FULL,
NWAY_2500M_FULL,
NWAY_5000M_FULL,
+ NWAY_10000M_FULL,
};
/* OCP_ALDPS_CONFIG */
@@ -742,6 +743,7 @@ enum spd_duplex {
#define BP4_SUPER_ONLY 0x1578 /* RTL_VER_04 only */
enum rtl_register_content {
+ _10000bps = BIT(14),
_5000bps = BIT(12),
_2500bps = BIT(10),
_1250bps = BIT(9),
@@ -757,6 +759,8 @@ enum rtl_register_content {
#define is_speed_2500(_speed) (((_speed) & (_2500bps | LINK_STATUS)) == (_2500bps | LINK_STATUS))
#define is_speed_5000(_speed) (((_speed) & (_5000bps | LINK_STATUS)) == (_5000bps | LINK_STATUS))
+#define is_speed_10000(_speed) (((_speed) & (_10000bps | LINK_STATUS)) \
+ == (_10000bps | LINK_STATUS))
#define is_flow_control(_speed) (((_speed) & (_tx_flow | _rx_flow)) == (_tx_flow | _rx_flow))
#define RTL8152_MAX_TX 4
@@ -1008,6 +1012,7 @@ struct r8152 {
u32 support_2500full:1;
u32 support_5000full:1;
+ u32 support_10000full:1;
u32 lenovo_macpassthru:1;
u32 dell_tb_rx_agg_bug:1;
u16 ocp_base;
@@ -1260,6 +1265,7 @@ enum tx_csum_stat {
#define RTL_ADVERTISED_1000_FULL BIT(5)
#define RTL_ADVERTISED_2500_FULL BIT(6)
#define RTL_ADVERTISED_5000_FULL BIT(7)
+#define RTL_ADVERTISED_10000_FULL BIT(8)
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
* The RTL chips use a 64 element hash table based on the Ethernet CRC.
@@ -6513,6 +6519,9 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
if (tp->support_5000full)
support |= RTL_ADVERTISED_5000_FULL;
+
+ if (tp->support_10000full)
+ support |= RTL_ADVERTISED_10000_FULL;
}
advertising &= support;
@@ -6559,9 +6568,10 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
r8152_mdio_write(tp, MII_CTRL1000, new1);
}
- if (tp->support_2500full || tp->support_5000full) {
+ if (tp->support_2500full || tp->support_5000full || tp->support_10000full) {
orig = ocp_reg_read(tp, OCP_10GBT_CTRL);
- new1 = orig & ~(MDIO_AN_10GBT_CTRL_ADV2_5G | MDIO_AN_10GBT_CTRL_ADV5G);
+ new1 = orig & ~(MDIO_AN_10GBT_CTRL_ADV2_5G | MDIO_AN_10GBT_CTRL_ADV5G
+ | MDIO_AN_10GBT_CTRL_ADV10G);
if (advertising & RTL_ADVERTISED_2500_FULL) {
new1 |= MDIO_AN_10GBT_CTRL_ADV2_5G;
@@ -6573,6 +6583,11 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
tp->ups_info.speed_duplex = NWAY_5000M_FULL;
}
+ if (advertising & RTL_ADVERTISED_10000_FULL) {
+ new1 |= MDIO_AN_10GBT_CTRL_ADV10G;
+ tp->ups_info.speed_duplex = NWAY_10000M_FULL;
+ }
+
if (orig != new1)
ocp_reg_write(tp, OCP_10GBT_CTRL, new1);
}
@@ -8708,7 +8723,10 @@ int rtl8152_get_link_ksettings(struct net_device *netdev,
linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
cmd->link_modes.supported, tp->support_5000full);
- if (tp->support_2500full || tp->support_5000full) {
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+ cmd->link_modes.supported, tp->support_10000full);
+
+ if (tp->support_2500full || tp->support_5000full || tp->support_10000full) {
u16 ocp_10gbt_ctrl = ocp_reg_read(tp, OCP_10GBT_CTRL);
u16 ocp_10gbt_stat = ocp_reg_read(tp, OCP_10GBT_STAT);
@@ -8737,6 +8755,19 @@ int rtl8152_get_link_ksettings(struct net_device *netdev,
if (is_speed_5000(rtl8152_get_speed(tp)))
cmd->base.speed = SPEED_5000;
}
+
+ if (tp->support_10000full) {
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+ cmd->link_modes.advertising,
+ ocp_10gbt_ctrl & MDIO_AN_10GBT_CTRL_ADV10G);
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+ cmd->link_modes.lp_advertising,
+ ocp_10gbt_stat & MDIO_AN_10GBT_STAT_LP10G);
+
+ if (is_speed_10000(rtl8152_get_speed(tp)))
+ cmd->base.speed = SPEED_10000;
+ }
}
mutex_unlock(&tp->control);
@@ -8790,6 +8821,10 @@ static int rtl8152_set_link_ksettings(struct net_device *dev,
cmd->link_modes.advertising))
advertising |= RTL_ADVERTISED_5000_FULL;
+ if (test_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+ cmd->link_modes.advertising))
+ advertising |= RTL_ADVERTISED_10000_FULL;
+
mutex_lock(&tp->control);
ret = rtl8152_set_speed(tp, cmd->base.autoneg, cmd->base.speed,
@@ -8953,6 +8988,13 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_keee *eee)
linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, common);
}
+ if (tp->support_10000full) {
+ linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, eee->supported);
+
+ if (speed & _10000bps)
+ linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, common);
+ }
+
eee->eee_enabled = tp->eee_en;
if (speed & _1000bps)
@@ -9967,6 +10009,11 @@ static int rtl8152_probe_once(struct usb_interface *intf,
tp->speed = SPEED_5000;
tp->advertising |= RTL_ADVERTISED_5000_FULL;
}
+ if (tp->support_10000full &&
+ tp->udev->speed >= USB_SPEED_SUPER) {
+ tp->speed = SPEED_10000;
+ tp->advertising |= RTL_ADVERTISED_10000_FULL;
+ }
tp->advertising |= RTL_ADVERTISED_1000_FULL;
}
tp->duplex = DUPLEX_FULL;
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v4 0/3] r8152: Add support for the RTL8159 10Gbit USB Ethernet chip
From: Birger Koblitz @ 2026-05-05 15:56 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz,
Andrew Lunn, Aleksander Jan Bajkowski
Add support for the RTL8159, which is a 10GBit USB-Ethernet adapter
chip in the RTL815x family of chips.
The RTL8159 re-uses the frame descriptor format and SRAM2 access introduced
with the RTL8157 as well as most of the setup and PM logic of the RTL8157.
The module was tested with a Lekuo DR59R11 USB-C 10GbE Ethernet Adapter:
[ 2502.906947] usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd
[ 2502.927859] usb 2-1: New USB device found, idVendor=0bda, idProduct=815a, bcdDevice=30.00
[ 2502.927867] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[ 2502.927871] usb 2-1: Product: USB 10/100/1G/2.5G/5G/10G LAN
[ 2502.927873] usb 2-1: Manufacturer: Realtek
[ 2502.927875] usb 2-1: SerialNumber: 000388C9B3B5XXXX
[ 2503.063745] r8152-cfgselector 2-1: reset SuperSpeed USB device number 3 using xhci_hcd
[ 2503.123876] r8152 2-1:1.0: Requesting firmware: rtl_nic/rtl8159-1.fw
[ 2503.126267] r8152 2-1:1.0: PHY firmware installed 0 to be loaded: 20
[ 2503.156265] r8152 2-1:1.0: load rtl8159-1 v1 2026/01/01 successfully
[ 2503.270729] r8152 2-1:1.0 eth0: v1.12.13
[ 2503.289349] r8152 2-1:1.0 enx88c9b3b5xxxx: renamed from eth0
[ 2507.777055] r8152 2-1:1.0 enx88c9b3b5xxxx: carrier on
The RTL8159 adapter was tested against an AQC107 PCIe-card supporting
10GBit/s and an RTL8157 5Gbit USB-Ethernet adapter supporting 5GBit/s for
performance, link speed and EEE negotiation. Using USB3.2 Gen 2 (20GBit) with
the RTL8159 USB adapter and running iperf3 against the AQC107 PCIe
card resulted in 8.96 Gbits/sec transfer speed.
The code is based on the out-of-tree r8152 driver published by Realtek under
the GPL.
The RTL8159 requires firmware for the PHY in order to achieve a 10GBit link
speed. Without firmware, only 5GBit were achieved. The firmware can be
extracted from the out-of-tree r8152 driver-code where it is stored in the
ram17 u8-array. Code is added to use the existing firmware upload mechanism
of the driver for the RTL8157/9 PHY firmware code. The firmware will be
submitted separately to linux-firmware.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
Changes in v4:
- Fix formatting and spelling in r8157_hw_phy_cfg()
- Set RTL8152_INACCESSIBLE when r8159_wait_backup_restore() times out
- More documentation on RX aggregation/descriptor settings
- Link to v3: https://lore.kernel.org/r/20260502-rtl8159_net_next-v3-0-12c895d46cd6@birger-koblitz.de
Changes in v3:
- Various references to RTL8157 in the commit description changed
to RTL8159
- Fix incorrect use of OCP_EEE_ADV2 register for 10GBit
- Fix various instances where a gate on RTL_VER_16 was not extended
to RTL_VER_17, although RTL8159 needs the same code-path as RTL8157
- Explain use of 0x815a device-ID for RTL8159 in commit message
- Extend poll-timeout for backup-restore to 20ms
- Drop patch for IRQ mitigation
- Link to v2: https://lore.kernel.org/r/20260429-rtl8159_net_next-v2-0-bab3cd4e4c66@birger-koblitz.de
Changes in v2:
- Correct formatting of comments
- Order case statement values correctly
- Add error message when backup-restore fails
- Correct commit message of support for firmware upload
- Link to v1: https://lore.kernel.org/r/20260428-rtl8159_net_next-v1-0-52d03927b46f@birger-koblitz.de
---
Birger Koblitz (3):
r8152: Add support for 10Gbit Link Speeds and EEE
r8152: Add support for the RTL8159 chip
r8152: Add firmware upload capability for RTL8157/RTL8159
drivers/net/usb/r8152.c | 345 +++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 325 insertions(+), 20 deletions(-)
---
base-commit: 0f19519fdd22bc0f5429377da3a52327c5eee166
change-id: 20260427-rtl8159_net_next-4f778a614fa7
Best regards,
--
Birger Koblitz <mail@birger-koblitz.de>
^ permalink raw reply
* Re: [PATCH net-next 1/5] ionic: Small improvements in devcmd retry logic
From: Eric Joyner @ 2026-05-05 15:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Brett Creeley, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni
In-Reply-To: <20260501163740.0f775e67@kernel.org>
On 5/1/2026 4:37 PM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Thu, 30 Apr 2026 20:15:51 -0700 Eric Joyner wrote:
>> If the timeout time is hit when the last attempt returned EAGAIN, the
>> driver returns -ETIMEDOUT. This causes the -EAGAIN result to be lost.
>> Fix this by returning -EAGAIN if the timeout time is hit and the
>> previous result matches.
>>
>> Also, reduce the sleep between the write to done and doorbell
>> registers. The msleep(1000) was initially added in an arbitrary
>> manner. However, this long of a sleep is problematic because
>> it reduces the number of retries when -EAGAIN is returned, which
>> may result in the devmcd giving up early due to the timeout. Fix
>> this by reducing the sleep to msleep(50).
>
> It would be useful to explain the significance of the return value
> to the callers. Are you trying to return EAGAIN to user space?
> Or some kernel-internal function catches this?
It looks like the -EAGAIN return value used here would have been used by
"[PATCH net 1/7] ionic: Allow the first devcmd to trigger deferred probe" [1];
this change got put in this series because we decided it was more of a net-next
change rather than a net change, but didn't realize these two were more
connected than what we saw at first glance.
1: https://lore.kernel.org/netdev/20260429210007.40015-2-eric.joyner@amd.com/
- Eric
^ permalink raw reply
* Re: [PATCH net-next v3 2/3] r8152: Add support for the RTL8159 chip
From: Birger Koblitz @ 2026-05-05 15:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, linux-usb, netdev,
linux-kernel, hsu.chih.kai, olek2
In-Reply-To: <20260505023022.877676-1-kuba@kernel.org>
On 05/05/2026 4:30 am, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> r8152: Add support for the RTL8159 chip
>
> This patch adds support for the RTL8159 chip as RTL_VER_17, reusing the
> RTL8157 initialization and USB power management paths. The bulk of the
> new code lives in r8157_hw_phy_cfg() to configure the RTL8159 PHY, and
> the USB product ID 0x815a is added to the device table.
> Is the leading space before ocp_byte_clr_bits here intentional? The rest
> of the switch statement uses a single tab for indentation. checkpatch.pl
> should catch this.
No, will fix in v4. Interesting, that checkpatch does not find this. I
am very sure I ran b4 prep --check before, it is near impossible to omit
that step before sending.
>
> Small typo, "nomal" -> "normal".
Will fix.
>> + /* close Sparse NEC, improve connect 5EUU calble performace */
> ^^^^^ ^^^^^^^^^
>
> Two typos here, "calble" -> "cable" and "performace" -> "performance".
Will fix.
> Is this "will include in v10" comment a reference to an internal Realtek
> source-tree revision? It does not appear to have meaning in the upstream
> tree and could be dropped or rephrased.
I will drop this.
>> @@ -8201,6 +8407,11 @@ static void r8156_init(struct r8152 *tp)
>> return;
>> }
>>
>> + if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp)) {
>> + dev_err(&tp->intf->dev, "init failed, backup-restore timed out\n");
>> + return;
>> + }
>> +
>
> Should this path also set RTL8152_INACCESSIBLE on tp->flags, or should the
> init callback be changed to return an error that probe can honor, so that
> a half-initialized device is not exposed to userspace?
I'll set RTL8152_INACCESSIBLE in line with what is done already in the
rest of r8156_init()
>> @@ -8274,7 +8485,10 @@ static void r8156_init(struct r8152 *tp)
>> set_bit(GREEN_ETHERNET, &tp->flags);
>>
>> /* rx aggregation / 16 bytes Rx descriptor */
>> - if (tp->version == RTL_VER_16)
>> + if (tp->version == RTL_VER_17)
>> + ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
>> + RX_AGG_DISABLE | RX_DESC_16B | BIT(11));
> ^^^^^^
>
> What does BIT(11) in USB_USB_CTRL correspond to here, and is it
> RTL8159-specific?
>
> The commit message says the RTL8159 "reuses hardware features of the
> RTL8157 (RTL_VER_16)", but this path clears an extra bit that the
> RTL_VER_16 path does not. Since there is no symbolic name or comment,
> it is hard to tell whether RTL_VER_16 is missing this clear, whether
> RTL_VER_17 should not be clearing it, or whether it really is an
> RTL8159-only quirk.
>
> Could a named define and/or a short comment be added to describe what
> this bit does?
This was brought up before, and unfortunately, there is no documentation
whatsoever for this bit. Any guess at a name may turn out to be misleading.
But I will change the comment to read:
/* RX aggregation / 16 bytes RX descriptor
* BIT(11) is specific to RTL8159, with unknown meaning
*/
if (tp->version == RTL_VER_17)
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
RX_AGG_DISABLE | RX_DESC_16B | BIT(11));
else if (tp->version == RTL_VER_16)
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE |
RX_DESC_16B);
else ...
Birger
^ permalink raw reply
* Re: [PATCH 08/11] vfio: selftests: Add dev_dbg
From: Jason Gunthorpe @ 2026-05-05 15:53 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches
In-Reply-To: <afkMenQ_gfmLUJIy@google.com>
On Mon, May 04, 2026 at 09:15:38PM +0000, David Matlack wrote:
> On 2026-04-30 09:08 PM, Jason Gunthorpe wrote:
> > Enable it with a #define DEBUG at the top of the file. Allows leaving
> > behind debugging prints that are useful in case future changes are
> > required.
> >
> > Assisted-by: Claude:claude-opus-4.6
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> > .../selftests/vfio/lib/include/libvfio/vfio_pci_device.h | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h b/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h
> > index bb4525abd01a22..2d587b988c09fa 100644
> > --- a/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h
> > +++ b/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h
> > @@ -38,6 +38,12 @@ struct vfio_pci_device {
> > #define dev_info(_dev, _fmt, ...) printf("%s: " _fmt, (_dev)->bdf, ##__VA_ARGS__)
> > #define dev_err(_dev, _fmt, ...) fprintf(stderr, "%s: " _fmt, (_dev)->bdf, ##__VA_ARGS__)
> >
> > +#ifdef DEBUG
> > +#define dev_dbg dev_info
> > +#else
> > +#define dev_dbg(_dev, _fmt, ...) do { } while (0)
>
> Can you add something to make sure the format strings are still
> validated by the compiler even if DEBUG is not defined? (since it
> will almost never be defined). e.g.
Yeah, I did this with the usual "if (false) printk()" technique
Jason
^ permalink raw reply
* Re: [PATCH 07/11] vfio: selftests: Allow drivers to specify required region size
From: Jason Gunthorpe @ 2026-05-05 15:52 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches
In-Reply-To: <afkH3pMJKkIbElhI@google.com>
On Mon, May 04, 2026 at 08:55:58PM +0000, David Matlack wrote:
> On 2026-04-30 09:08 PM, Jason Gunthorpe wrote:
> > Add a region_size field to struct vfio_pci_driver_ops so drivers can
> > declare how much DMA-mapped region they need. The mlx5 driver will
> > need ~18MB for firmware pages. Existing drivers leave region_size as
> > 0 and get the current default of SZ_2M.
>
> I would like to get rid of the magic SZ_2M to make it easier for other
> tests to use the driver framework. Can you make this commit update all
> the drivers to set region_size? They can all use the same approach:
>
> struct vfio_pci_driver_ops foo_driver = {
> ...
> .region_size = roundup_pow_of_two(sizeof(struct foo)),
> ...
> };
Sure, lets put the roundup in the core code?
Jason
^ permalink raw reply
* Re: [PATCH 00/11] mlx5 support for VFIO self test
From: Jason Gunthorpe @ 2026-05-05 15:50 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches, Josh Hilke
In-Reply-To: <afkjkBq8B-4KjhS_@google.com>
On Mon, May 04, 2026 at 10:54:08PM +0000, David Matlack wrote:
> > The PF support flow requires a bunch more complicated stuff.
>
> Do you think it's worth supporting PFs? If anyone with a CX NIC can
> enable SR-IOV and run selftests on a VF then we can keep the driver
> somewhat simpler.
It turns out my test system cannot enable SR-IOV due to iommu_group
problems so I rather prefer to have this :) I had to hack a kernel up
to do the initial testing and it was very annoying.
Jason
^ permalink raw reply
* Re: [PATCH 10/11] vfio: selftests: Add mlx5 driver - data path and memcpy ops
From: Jason Gunthorpe @ 2026-05-05 15:49 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches
In-Reply-To: <afkghFm9Vo-SfF5c@google.com>
On Mon, May 04, 2026 at 10:41:08PM +0000, David Matlack wrote:
> On 2026-04-30 09:08 PM, Jason Gunthorpe wrote:
>
> > @@ -1368,6 +1716,11 @@ static void mlx5st_init(struct vfio_pci_device *device)
> > mlx5st_alloc_pd(dev);
> > mlx5st_create_mkey(dev);
> >
> > + mlx5st_setup_datapath(dev);
> > +
> > + device->driver.max_memcpy_size = 1 << 20;
> > + device->driver.max_memcpy_count = SQ_WQE_CNT - 1;
>
> What are these limits a function of? e.g. Is the 1MB size a hardware
> limit? Can we change SQ_WQE_CNT in the future to increase max count?
I have to check, I don't think there is a small limit on RDMA WRITE,
and SQ_WQE_CNT is just a number it could be somewhat bigger.
This may be a hold over from an ealier version where it was trying to
make a PAS array, and the PAS array was capped. I removed that but
would have missed this.
Jason
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox