* Re: [PATCH v10 rdma-next] RDMA: Change capability fields in ib_device_attr from int to u32
From: Leon Romanovsky @ 2026-07-12 8:50 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: Jason Gunthorpe, mkalderon, zyjzyj2000, sagi, mgurtovoy,
haris.iqbal, jinpu.wang, bvanassche, kbusch, Jens Axboe,
Christoph Hellwig, kch, smfrench, linkinjeon, metze, tom, cel,
jlayton, neil, okorniev, Dai.Ngo, trondmy, anna, achender, davem,
edumazet, kuba, pabeni, horms, kees, michaelgur, edwards, phaddad,
eadavis, yishaih, kalesh-anakkur.purayil, andriy.shevchenko, clm,
ebadger, linux-rdma, linux-kernel, target-devel, linux-nvme,
linux-cifs, samba-technical, linux-nfs, netdev, rds-devel,
Jason Gunthorpe
In-Reply-To: <20260709055211.2498307-1-ernis@linux.microsoft.com>
On Wed, Jul 08, 2026 at 10:51:29PM -0700, Erni Sri Satya Vennela wrote:
> The capability counter fields in struct ib_device_attr are declared
> as signed int, but these values are inherently non-negative. Drivers
> maintain their cached caps as u32 and assign them directly into these
> int fields; if a cap exceeds INT_MAX the implicit narrowing yields a
> negative value visible to the IB core.
>
> Change the signed int capability fields to u32 to match the
> underlying nature of the data. Also update consumers across the IB
> core, ULPs, NVMe-oF target, RDS, and NFS/RDMA so the new u32 values
> are not forced back through signed int or u8 via min()/min_t() or
> narrowing local variables.
>
> The nvmet-rdma consumer of max_srq clamps it against
> ib_device.num_comp_vectors, which stays a signed int, so that site
> uses min_t() instead of min() to handle the signed/unsigned mismatch.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
> Acked-by: Stefan Metzmacher <metze@samba.org> # smbdirect
> ---
> Changes in v10:
> * Convert max_srq to u32. Use min_t() against the still-signed ib_device.num_comp_vectors.
> * Update commit message.
> * Change rdma_restrack_count() to return u32 and make fill_res_info()'s curr and max u64.
> Changes in v9:
> * Switch the srq_size module parameter accessors to param_get_uint and
> kstrtouint()/param_set_uint() so they match the now-unsigned
> nvmet_rdma_srq_size variable.
> Changes in v8:
> * Convert the remaining non-negative counter fields max_ee_rd_atom,
> max_ee_init_rd_atom, max_ee, max_rdd, max_raw_ipv6_qp and max_srq_wr
> to u32; keep max_srq as int (its consumer compares it against
> ib_device.num_comp_vectors, still int).
> * Drop all remaining min_t() where plain min() now works.
> * Make the srq_size module parameters unsigned int so the srq_size min()
> stays a plain min().
> * Replace the ternary-inside-min() with the simpler "if (x) x--;".
> * Reorder the send_queue_depth min() to min(value, CONST) to match the
> sibling site.
> * Restore reverse xmas-tree declaration order.
> * Collapse the min()/min3() assignments that now fit onto a single line
> within 100 columns.
> * Print the now-u32 fields with %u instead of %d.
> Changes in v7:
> * Drop min_t() in all sites where a plain min() (or min3()) works
> cleanly
> * Guard nvme/host/rdma.c num_inline_segments computation against a
> device reporting max_send_sge == 0, so the u32 subtract
> cannot wrap to UINT_MAX.
> * Use %u when printing the newly-u32 capability fields
> in diagnostic messages.
> Changes in v6:
> * Fix subject prefix: net-next -> rdma-next.
> Changes in v5:
> * Add U8_MAX clamps in iser_verbs, nvme/host, nvme/target, isert,
> * rds/ib_cm, smbdirect/connect and smbdirect/accept where u32 capability
> fields were directly narrowed into u8 rdma_conn_param fields without
> clamping.
> * Guard the inline_sge_count calculation in nvmet_rdma_find_get_device()
> to prevent u32 underflow when both max_sge_rd and max_recv_sge are
> zero.
> * Expand type migration to 9 additional fields (max_mw, max_raw_ethy_qp,
> max_mcast_grp, max_mcast_qp_attach, max_total_mcast_qp_attach, max_ah,
> max_srq, max_srq_wr, max_srq_sge)
> * Fix min_t(int,...) in svc_rdma_transport; min_t(u32,...) in ipoib,
> srpt, nvme/target, rds/ib, rtrs-clt, rtrs-srv, xprtrdma/verbsdd.
> * Fix frwr_ops.c u32 underflow guard (reorder check before subtraction)
> * Change sc_max_send_sges to unsigned int, inline_sge_count to u32
> * Fix %d -> %u in rxe_qp, rxe_srq, ipoib_cm, ib_isert,
> * svc_rdma_transport
> * Update commit message.
> Changes in v4:
> * Drop clamping the values in mana_ib_query_device, instead update
> the props values from int to u32.
> Changes in v3:
> * Drop clamping from mana_ib_gd_query_adapter_caps(). The internal u32
> caps cache does not need to be clamped.
> * Move all clamping exclusively to mana_ib_query_device(), which is the
> only place the cached u32 values are narrowed into the signed int
> fields of struct ib_device_attr.
> * Reframe commit message: this is a u32-to-int type boundary fix, not a
> CVM/untrusted-hardware hardening patch.
> Changes in v2:
> * Update patch title.
> ---
> drivers/infiniband/core/cq.c | 3 +-
> drivers/infiniband/core/nldev.c | 3 +-
> drivers/infiniband/core/restrack.c | 2 +-
> drivers/infiniband/hw/qedr/verbs.c | 2 +-
> drivers/infiniband/sw/rxe/rxe_qp.c | 22 ++++-----
> drivers/infiniband/sw/rxe/rxe_srq.c | 16 +++----
> drivers/infiniband/ulp/ipoib/ipoib_cm.c | 10 ++---
> drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 3 +-
> drivers/infiniband/ulp/iser/iser_verbs.c | 5 +--
> drivers/infiniband/ulp/isert/ib_isert.c | 7 ++-
> drivers/infiniband/ulp/rtrs/rtrs-clt.c | 11 ++---
> drivers/infiniband/ulp/rtrs/rtrs-srv.c | 11 ++---
> drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
> drivers/infiniband/ulp/srpt/ib_srpt.c | 21 +++++----
> drivers/nvme/host/rdma.c | 8 ++--
> drivers/nvme/target/rdma.c | 26 ++++++-----
> fs/smb/smbdirect/accept.c | 5 ++-
> fs/smb/smbdirect/connect.c | 5 ++-
> fs/smb/smbdirect/connection.c | 8 ++--
> include/linux/sunrpc/svc_rdma.h | 4 +-
> include/rdma/ib_verbs.h | 52 +++++++++++-----------
> include/rdma/restrack.h | 2 +-
> net/rds/ib.c | 10 ++---
> net/rds/ib_cm.c | 10 ++---
> net/sunrpc/xprtrdma/frwr_ops.c | 7 +--
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 5 +--
> net/sunrpc/xprtrdma/verbs.c | 2 +-
> 27 files changed, 129 insertions(+), 133 deletions(-)
This patch touches too many areas to delay it further. Let's merge it
now and improve it later, if needed.
Thanks
^ permalink raw reply
* Re: Failed to reinit phy of spacemit-dwmac when reset-gpio is present
From: Maxime Chevallier @ 2026-07-12 8:55 UTC (permalink / raw)
To: Inochi Amaoto, Andrew Lunn, Eric Dumazet, David S. Miller,
Jakub Kicinski, Paolo Abeni, Yixun Lan, Maxime Coquelin,
Alexandre Torgue
Cc: netdev, linux-riscv, spacemit, linux-stm32, linux-arm-kernel,
linux-kernel, E Shattow, Han Gao
In-Reply-To: <20260712045233.800748-1-inochiama@gmail.com>
Hi Inochi,
On 7/12/26 06:52, Inochi Amaoto wrote:
> TL;DR:
>
> The DWMAC on Spacemit K3 is failled to register phy after the reload
> the driver module (rmmod then insmod). Because the reset-gpio is
> asserted while unloading the driver and is not desserted before reading
> the c22 id, which leads to a fault.
You're not the first one facing this type of issues, this is a long standing
source of issues. The problem is partially hidden by the fact that often times
the bootloader deals with the PHY reset (like the case you're facing)
Take a look at these discussions :
https://lore.kernel.org/netdev/cover.1761732347.git.buday.csaba@prolan.hu/
and maybe more intersting, Russell suggested an approach on how we could potentially
address this here :
https://lore.kernel.org/all/aTBeVTlsElGXUCSN@shell.armlinux.org.uk/
> ---
> --- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> @@ -196,7 +196,8 @@ ð0 {
>
> mdio {
> phy0: phy@1 {
> - compatible = "ethernet-phy-ieee802.3-c22";
> + compatible = "ethernet-phy-id001c.c916",
> + "ethernet-phy-ieee802.3-c22";
Indeed that's merely a workaround :(
Maxime
^ permalink raw reply
* Re: [PATCH net v2] net: stmmac: enable the MAC on link up for all supported speeds
From: Maxime Chevallier @ 2026-07-12 9:02 UTC (permalink / raw)
To: vadik likholetov, netdev
Cc: andrew, andrew+netdev, davem, edumazet, kuba, pabeni,
thierry.reding, jonathanh, vbhadram, linux-tegra, linux-kernel
In-Reply-To: <20260712065522.30241-1-vadikas@gmail.com>
Hi,
When sending a new iteration, it should be a standalone thread, and not
a reply to the previous version. Patchwork seems to have picked it up, so
I _think_ it's ok for this one though :)
On 7/12/26 08:55, vadik likholetov wrote:
> stmmac_mac_link_down() clears the MAC's transmit and receive enable bits.
> stmmac_mac_link_up() is expected to set them again through
> stmmac_mac_set(..., true), but it first switches on the negotiated speed
> and returns early for a speed the switch does not list. The MAC is then
> left gated off.
>
> The speed selection is split into three switches, keyed on the interface.
> The generic branch -- taken for everything that is neither USXGMII nor
> XLGMII, so including PHY_INTERFACE_MODE_10GBASER -- lists only SPEED_2500,
> SPEED_1000, SPEED_100 and SPEED_10.
>
> MGBE on Tegra234 runs 10GBASE-R into an Aquantia AQR113C. That PHY does
> rate matching, so phylink_link_up() replaces the media speed with the
> MAC-side interface speed before calling into the MAC:
>
> case RATE_MATCH_PAUSE:
> speed = phylink_interface_max_speed(link_state.interface);
> duplex = DUPLEX_FULL;
>
> The driver is therefore called as
>
> stmmac_mac_link_up(interface=10GBASER, speed=10000, duplex=1)
>
> which falls through to "default: return;". The interface stops passing
> traffic after the first link flap.
>
> The failure is easy to misread. The link still comes up, because the PHY
> is polled over MDIO and needs no MAC, so the interface reports carrier 1
> at the media speed. The DMA is untouched, so its start bits stay set and
> descriptors are still consumed. Only the MAC itself is gated off: the
> receiver counts nothing (mmc_rx_framecount_gb stops advancing, RE is 0)
> and nothing reaches the wire (TE is 0). The interface survives boot only
> because stmmac_hw_setup(), called from ndo_open, enables the MAC
> unconditionally -- so the problem appears only once the cable has been
> unplugged and plugged back in, and "ip link set dev <ethX> down && ip
> link set dev <ethX> up" appears to fix it.
>
> The interface is not what the speed bits depend on: with the single
> exception of 2.5G, which is selected through the XGMII block on USXGMII
> and through the regular speed bits otherwise, each speed maps to one
> field of struct mac_link. The per-interface switches are speed
> validation, and phylink already validates the speed against
> priv->hw->link.caps. So collapse the three switches into one keyed on the
> speed alone, keeping the interface test only for the 2.5G case. This
> covers 10G on 10GBASE-R, and equally 5G, and 1G/100/10 on USXGMII, all of
> which hit "default: return;" today.
>
> A core that does not support a speed leaves the corresponding mac_link
> field at 0, and phylink will not offer it that speed in the first place.
> For dwxgmac2 at 10G, link.xgmii.speed10000 is XGMAC_CONFIG_SS_10000,
> which is 0 and is the correct speed selection for a 10GBASE-R MAC: ctrl
> then equals old_ctrl, the register write is skipped, and execution
> reaches stmmac_mac_set(..., true).
>
> Log an error in the default case, since a speed with no entry here leaves
> the MAC disabled and the symptom does not point at the cause.
>
> Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support")
> Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Signed-off-by: vadik likholetov <vadikas@gmail.com>
> ---
> v2:
> - Collapse the three per-interface switches into a single switch on the
> speed, rather than adding SPEED_10000 to the generic branch, which
> left SPEED_5000 and the USXGMII sub-1G speeds broken (Maxime).
> - netdev_err() in the default case (Andrew).
>
> Fixes tag: the missing speeds predate the commit cited above. I picked
> d8ca113724e7 because MGBE is the first in-tree user to reach it -- it
> needs a 10GBASE-R interface driven by a rate-matching PHY, so that
> phylink hands the MAC a 10G speed. Happy to re-target it.
>
> Verified on an AGX Orin devkit (Tegra234 MGBE0 + AQR113C), before and
> after, on the same board and cable. MAC registers read with `ethtool -d`,
> after a physical unplug and replug:
>
> stock MAC_TX_CONFIG 0x00010000 (TE=0)
> MAC_RX_CONFIG 0x3ff022c0 (RE=0)
> rx_packets frozen, DHCP lease lost
>
> patched MAC_TX_CONFIG 0x00010001 (TE=1)
> MAC_RX_CONFIG 0x3ff022c1 (RE=1)
> rx_packets keeps climbing, DHCP lease retained
>
> Only the 10GBASE-R path is covered by hardware here; the other speeds are
> by inspection. Testing was done with MGBE0 handed to a VM via
> vfio-platform, so the driver ran in a guest; the MAC register evidence
> above is read from the device itself and the code path is not
> virtualisation-specific.
>
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 92 ++++++++-----------
> 1 file changed, 37 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 2a0d7eff8..fa9f88e51 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1083,63 +1083,45 @@ static void stmmac_mac_link_up(struct phylink_config *config,
> old_ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
> ctrl = old_ctrl & ~priv->hw->link.speed_mask;
>
> - if (interface == PHY_INTERFACE_MODE_USXGMII) {
> - switch (speed) {
> - case SPEED_10000:
> - ctrl |= priv->hw->link.xgmii.speed10000;
> - break;
> - case SPEED_5000:
> - ctrl |= priv->hw->link.xgmii.speed5000;
> - break;
> - case SPEED_2500:
> + switch (speed) {
> + case SPEED_100000:
> + ctrl |= priv->hw->link.xlgmii.speed100000;
> + break;
> + case SPEED_50000:
> + ctrl |= priv->hw->link.xlgmii.speed50000;
> + break;
> + case SPEED_40000:
> + ctrl |= priv->hw->link.xlgmii.speed40000;
> + break;
> + case SPEED_25000:
> + ctrl |= priv->hw->link.xlgmii.speed25000;
> + break;
> + case SPEED_10000:
> + ctrl |= priv->hw->link.xgmii.speed10000;
> + break;
> + case SPEED_5000:
> + ctrl |= priv->hw->link.xgmii.speed5000;
> + break;
> + case SPEED_2500:
> + if (interface == PHY_INTERFACE_MODE_USXGMII)
> ctrl |= priv->hw->link.xgmii.speed2500;
> - break;
> - default:
> - return;
> - }
> - } else if (interface == PHY_INTERFACE_MODE_XLGMII) {
> - switch (speed) {
> - case SPEED_100000:
> - ctrl |= priv->hw->link.xlgmii.speed100000;
> - break;
> - case SPEED_50000:
> - ctrl |= priv->hw->link.xlgmii.speed50000;
> - break;
> - case SPEED_40000:
> - ctrl |= priv->hw->link.xlgmii.speed40000;
> - break;
> - case SPEED_25000:
> - ctrl |= priv->hw->link.xlgmii.speed25000;
> - break;
> - case SPEED_10000:
> - ctrl |= priv->hw->link.xgmii.speed10000;
> - break;
> - case SPEED_2500:
> - ctrl |= priv->hw->link.speed2500;
> - break;
> - case SPEED_1000:
> - ctrl |= priv->hw->link.speed1000;
> - break;
> - default:
> - return;
> - }
> - } else {
> - switch (speed) {
> - case SPEED_2500:
> + else
> ctrl |= priv->hw->link.speed2500;
> - break;
> - case SPEED_1000:
> - ctrl |= priv->hw->link.speed1000;
> - break;
> - case SPEED_100:
> - ctrl |= priv->hw->link.speed100;
> - break;
> - case SPEED_10:
> - ctrl |= priv->hw->link.speed10;
> - break;
> - default:
> - return;
> - }
> + break;
> + case SPEED_1000:
> + ctrl |= priv->hw->link.speed1000;
> + break;
> + case SPEED_100:
> + ctrl |= priv->hw->link.speed100;
> + break;
> + case SPEED_10:
> + ctrl |= priv->hw->link.speed10;
> + break;
> + default:
> + netdev_err(priv->dev,
> + "unsupported speed %d on %s, leaving the MAC disabled\n",
> + speed, phy_modes(interface));
You should probably be using phy_speed_to_str() to print the speed.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH iproute2-next v5 1/2] rdma: update uapi headers
From: Leon Romanovsky @ 2026-07-12 9:03 UTC (permalink / raw)
To: Tao Cui; +Cc: dsahern, linux-rdma, netdev, cuitao
In-Reply-To: <20260710011759.378893-2-cui.tao@linux.dev>
On Fri, Jul 10, 2026 at 09:17:58AM +0800, Tao Cui wrote:
> From: Tao Cui <cuitao@kylinos.cn>
>
> Update rdma_netlink.h file upto kernel commit 5911f6d6e7ce
> ("RDMA/nldev: Add resource summary max values for usage display")
This SHA-1 is incorrect.
5911f6d6e7cc ("RDMA/nldev: Add resource summary max values for usage display")
Thanks
^ permalink raw reply
* Re: [PATCH 01/13 RFC net-next] net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack
From: Arnd Bergmann @ 2026-07-12 11:01 UTC (permalink / raw)
To: Fernando Fernandez Mancera, Netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern, Simon Horman, Ido Schimmel, Jason Gunthorpe,
Leon Romanovsky, Andrew Lunn, Anthony L Nguyen, Przemek Kitszel,
Elad Nachman, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Petr Machata, Edward Cree, Maxime Coquelin, Alexandre Torgue,
Arend van Spriel, Miri Korenblit, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Saurav Kashyap, Javed Hasan, GR-QLogic-Storage-Upstream,
James E . J . Bottomley, Martin K. Petersen, Nilesh Javali,
Manish Rangankar, Varun Prakash, Alexander Viro,
Christian Brauner, Jan Kara, David Howells, Marc Dionne,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sven Eckelmann,
Nikolay Aleksandrov, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Johannes Berg, Matthieu Baerts, Mat Martineau,
Geliang Tang, Julian Anastasov, Aaron Conole, Eelco Chaudron,
Ilya Maximets, Allison Henderson, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, D. Wythe, Dust Li,
Sidraya Jayagond, Wenjia Zhang, Mahanta Jambigi, Tony Lu, Wen Gu,
Jon Maloy, Steffen Klassert, Herbert Xu, Vikas Gupta,
Rajashekar Hudumula, Justin Chen, Bhargava Marreddy,
Nicolai Buchwitz, Florian Fainelli, Heiner Kallweit,
Krzysztof Kozlowski, Russell King, Yao Zi, Yanteng Si,
Maxime Chevallier, Julian Braha, Joey Lu, Shangjuan Wei,
Chen-Yu Tsai, Inochi Amaoto, Lad, Prabhakar, Qingfang Deng,
Greg Kroah-Hartman, Eric Biggers, Ethan Nelson-Moore,
Ard Biesheuvel, Dmitry Safonov, Kuniyuki Iwashima, Alyssa Ross,
linux-rdma, linux-kernel, intel-wired-lan@lists.osuosl.org,
open list:NETRONOME ETHERNET DRIVERS, linux-net-drivers,
linux-stm32, linux-arm-kernel, linux-wireless, brcm80211,
brcm80211-dev-list.pdl, linux-nvme, linux-scsi, target-devel,
linux-fsdevel, linux-afs, linux-nfs, b.a.t.m.a.n,
open list:ETHERNET BRIDGE, netfilter-devel, coreteam, mptcp,
lvs-devel, dev, rds-devel, linux-sctp, linux-s390,
open list:TIPC NETWORK LAYER
In-Reply-To: <20260712013941.4570-2-fmancera@suse.de>
On Sun, Jul 12, 2026, at 03:38, Fernando Fernandez Mancera wrote:
> Historically, the IPv4 protocol has been linked to the core INET
> subsystem. Because shared infrastructure like the TCP/UDP engine,
> routing or INET hashtables live inside net/ipv4/, it has been impossible
> to compile a kernel with only IPv6 support.
>
> This patch introduces the CONFIG_IPV4 Kconfig symbol, which is set to
> 'def_bool y' for now. This does not allow to completely disable the
> IPv4 stack yet but it lays the necessary build-system work for that
> goal.
I expect this will cause additional (trivial) build regression in the
next step when randconfig builds run into obscure corner cases, either
with INET=y IPV4=n IPV6=y or with INET=y IPV4=n IPV6=n.
I can probably give your patch (with IPV4 visible or disabled) an
early go on the randconfig tree to find these more quickly.
If I run into regressions, should I just add more 'depends on IPV4',
or do you have other plans?
Should we have some logic to ensure that at least one of IPV4 or
IPV6 is enabled? I think this would work
config IPV4
bool "The IPv4 protocol" if IPV6
default INET
which only allows turning IPV4 off if IPV6 has enabled.
Arnd
^ permalink raw reply
* Re: [PATCH v10 rdma-next] RDMA: Change capability fields in ib_device_attr from int to u32
From: Leon Romanovsky @ 2026-07-12 11:26 UTC (permalink / raw)
To: Jason Gunthorpe, mkalderon, zyjzyj2000, sagi, mgurtovoy,
haris.iqbal, jinpu.wang, bvanassche, kbusch, Jens Axboe,
Christoph Hellwig, kch, smfrench, linkinjeon, metze, tom, cel,
jlayton, neil, okorniev, Dai.Ngo, trondmy, anna, achender, davem,
edumazet, kuba, pabeni, horms, kees, michaelgur, edwards, phaddad,
eadavis, yishaih, kalesh-anakkur.purayil, andriy.shevchenko, clm,
ebadger, linux-rdma, linux-kernel, target-devel, linux-nvme,
linux-cifs, samba-technical, linux-nfs, netdev, rds-devel,
Erni Sri Satya Vennela
Cc: Jason Gunthorpe
In-Reply-To: <20260709055211.2498307-1-ernis@linux.microsoft.com>
On Wed, 08 Jul 2026 22:51:29 -0700, Erni Sri Satya Vennela wrote:
> The capability counter fields in struct ib_device_attr are declared
> as signed int, but these values are inherently non-negative. Drivers
> maintain their cached caps as u32 and assign them directly into these
> int fields; if a cap exceeds INT_MAX the implicit narrowing yields a
> negative value visible to the IB core.
>
> Change the signed int capability fields to u32 to match the
> underlying nature of the data. Also update consumers across the IB
> core, ULPs, NVMe-oF target, RDS, and NFS/RDMA so the new u32 values
> are not forced back through signed int or u8 via min()/min_t() or
> narrowing local variables.
>
> [...]
Applied, thanks!
[1/1] RDMA: Change capability fields in ib_device_attr from int to u32
https://git.kernel.org/rdma/rdma/c/eebd08d91ddbd6
Best regards,
--
Leon Romanovsky <leon@kernel.org>
^ permalink raw reply
* [PATCH v4] dt-bindings: net: microchip,lan78xx: convert to DT schema
From: Mikhail Lukianchikov @ 2026-07-12 11:38 UTC (permalink / raw)
To: Thangaraj.S, Rengarajan.S
Cc: avermoal, andrew+netdev, conor+dt, davem, devicetree, edumazet,
krzk+dt, kuba, linux-kernel, netdev, pabeni, robh
Convert the Microchip LAN78xx family (LAN7800, LAN7801, LAN7850) binding
documentation from plain text to DT schema.
Restoring a mistakenly deleted email in MAINTAINERS file and fixing
microchip,lan7800.yaml.
Signed-off-by: Mikhail Lukianchikov <avermoal@gmail.com>
---
Changes in v3:
- Restoring an erroneously deleted email in a MAINTAINERS file.
- The local-mac-address was deleted.
- The missing email was added to the maintainers section.
Link to v3: https://lore.kernel.org/netdev/20260711105537.11065-2-avermoal@gmail.com
.../bindings/net/microchip,lan7800.yaml | 89 +++++++++++++++++++
.../bindings/net/microchip,lan78xx.txt | 53 -----------
MAINTAINERS | 2 +-
3 files changed, 90 insertions(+), 54 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan7800.yaml
delete mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
diff --git a/Documentation/devicetree/bindings/net/microchip,lan7800.yaml b/Documentation/devicetree/bindings/net/microchip,lan7800.yaml
new file mode 100644
index 000000000000..cb3927215dfc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan7800.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,lan7800.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip LAN7800/LAN7801/LAN7850 Gigabit Ethernet controller
+
+maintainers:
+ - Thangaraj Samynathan <Thangaraj.S@microchip.com>
+ - Rengarajan Sundararajan <Rengarajan.S@microchip.com>
+
+description:
+ The LAN7800/LAN7801/LAN7850 devices are usually configured by
+ programming their OTP or with an external EEPROM, but some
+ platforms (e.g. Raspberry Pi 3 B+) have neither. The Device Tree
+ properties, if present, override the OTP and EEPROM.
+
+allOf:
+ - $ref: /schemas/usb/usb-device.yaml#
+ - $ref: /schemas/net/ethernet-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - usb424,7800
+ - usb424,7801
+ - usb424,7850
+
+ reg:
+ maxItems: 1
+ description: USB port number
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+
+ patternProperties:
+ "^ethernet-phy(@[0-9a-f]+)?$":
+ $ref: /schemas/net/ethernet-phy.yaml#
+ unevaluatedProperties: false
+ type: object
+
+ properties:
+ microchip,led-modes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ description:
+ Array of LED mode values for each of up to 4 LEDs.
+ Omitted LEDs are turned off. Allowed values are defined
+ in include/dt-bindings/net/microchip-lan78xx.h.
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/net/microchip-lan78xx.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usb424,7800";
+ reg = <1>;
+ local-mac-address = [00 11 22 33 44 55];
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethernet-phy@1 {
+ reg = <1>;
+ microchip,led-modes = <
+ LAN78XX_LINK_1000_ACTIVITY
+ LAN78XX_LINK_10_100_ACTIVITY
+ >;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
deleted file mode 100644
index 11a679530ae6..000000000000
--- a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Microchip LAN78xx Gigabit Ethernet controller
-
-The LAN78XX devices are usually configured by programming their OTP or with
-an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
-The Device Tree properties, if present, override the OTP and EEPROM.
-
-Required properties:
-- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
-
-The MAC address will be determined using the optional properties
-defined in ethernet.txt.
-
-Optional properties of the embedded PHY:
-- microchip,led-modes: a 0..4 element vector, with each element configuring
- the operating mode of an LED. Omitted LEDs are turned off. Allowed values
- are defined in "include/dt-bindings/net/microchip-lan78xx.h".
-
-Example:
-
-/* Based on the configuration for a Raspberry Pi 3 B+ */
-&usb {
- usb-port@1 {
- compatible = "usb424,2514";
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb-port@1 {
- compatible = "usb424,2514";
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethernet: ethernet@1 {
- compatible = "usb424,7800";
- reg = <1>;
- local-mac-address = [ 00 11 22 33 44 55 ];
-
- mdio {
- #address-cells = <0x1>;
- #size-cells = <0x0>;
- eth_phy: ethernet-phy@1 {
- reg = <1>;
- microchip,led-modes = <
- LAN78XX_LINK_1000_ACTIVITY
- LAN78XX_LINK_10_100_ACTIVITY
- >;
- };
- };
- };
- };
- };
-};
diff --git a/MAINTAINERS b/MAINTAINERS
index f37a81950e25..5de154167b33 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27931,7 +27931,7 @@ M: Rengarajan Sundararajan <Rengarajan.S@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
-F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
+F: Documentation/devicetree/bindings/net/microchip,lan7800.yaml
F: drivers/net/usb/lan78xx.*
F: include/dt-bindings/net/microchip-lan78xx.h
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net] nfc: llcp: reject PDUs shorter than the LLCP header
From: Vadim Fedorenko @ 2026-07-12 12:00 UTC (permalink / raw)
To: Doruk Tan Ozturk, David Heidelberg
Cc: Simon Horman, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <20260711072702.70231-1-doruk@0sec.ai>
On 11/07/2026 08:27, Doruk Tan Ozturk wrote:
> nfc_llcp_rx_skb() reads the two-byte LLCP header (DSAP/SSAP/PTYPE) and
> dispatches by PDU type; several handlers then derive a TLV-array length as
> skb->len - LLCP_HEADER_SIZE. Neither nfc_llcp_rx_skb() nor its callers
> guarantee the frame is at least LLCP_HEADER_SIZE bytes, and a sub-header
that's not correct. there are 2 ways to get to nfc_llcp_rx_skb() - via
nfc_llcp_recv_agf() or through commands/locally generated skbs. The
first one checks against LLCP_HEADER_SIZE, while latter one creates skb
payload with correct LLCP header size. Do you have a reproducer to
trigger the issue?
> PDU does reach it: digital_in_recv_dep_res() and digital_tg_recv_dep_req()
> strip the DEP header with skb_pull() after only checking the DEP header
> size, so a DEP I-PDU carrying a 0- or 1-byte LLCP payload is handed up as
> a sub-2-byte skb.
>
> For a CONNECT or CC PDU, nfc_llcp_recv_connect() and nfc_llcp_recv_cc()
> then pass skb->len - LLCP_HEADER_SIZE to nfc_llcp_parse_connection_tlv().
> For skb->len < 2 that subtraction underflows: truncated into the u16
> tlv_array_len parameter it becomes ~0xFFFE, and for a CONNECT to the SDP
> SAP, nfc_llcp_connect_sn() uses a size_t and underflows to SIZE_MAX. The
> TLV parsers bound their walk relative to that length, so they read far
> past the end of the skb.
>
> The aggregated-frame path (nfc_llcp_recv_agf()) already drops sub-PDUs
> shorter than the header. Apply the same guard once, in the dispatcher, so
that not exactly correct, it drops skbs which are shorter or equal to
the header, the check added in this patch is not correct then.
> every PDU type is covered.
>
> Found by 0sec (https://0sec.ai) using automated source analysis; the
> missing guard is evident from source. Compile-tested.
>
> Fixes: d646960f7986 ("NFC: Initial LLCP support")
> Cc: stable@vger.kernel.org
> Assisted-by: 0sec:claude-opus-4-8
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> ---
> net/nfc/llcp_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
> index aed5fe1afef0..e3b3077e0e83 100644
> --- a/net/nfc/llcp_core.c
> +++ b/net/nfc/llcp_core.c
> @@ -1481,6 +1481,9 @@ static void nfc_llcp_rx_skb(struct nfc_llcp_local *local, struct sk_buff *skb)
> {
> u8 dsap, ssap, ptype;
>
> + if (skb->len < LLCP_HEADER_SIZE)
> + return;
> +
> ptype = nfc_llcp_ptype(skb);
> dsap = nfc_llcp_dsap(skb);
> ssap = nfc_llcp_ssap(skb);
^ permalink raw reply
* Re: [PATCH net 0/2] ptp: fix scaled_ppm_to_ppb() overflow bypassing the max_adj check
From: Vadim Fedorenko @ 2026-07-12 12:16 UTC (permalink / raw)
To: Deep Shah, netdev, Richard Cochran, David S . Miller,
Jakub Kicinski, Paolo Abeni, Eric Dumazet, Andrew Lunn
Cc: linux-kernel, Shuah Khan, linux-kselftest
In-Reply-To: <20260712040922.6403-1-deepshah146@gmail.com>
On 12/07/2026 05:09, Deep Shah wrote:
> ptp_clock_adjtime() validates an ADJ_FREQUENCY request by converting
> tx->freq to ppb and comparing it against ops->max_adj. On 64-bit systems
> that conversion can overflow s64 and wrap the result back into range, so
> a crafted tx->freq bypasses the check and reaches ->adjfine() unclamped.
>
> Patch 1 rejects the overflow in ptp_clock_adjtime().
> Patch 2 adds a regression test that crafts struct timex.freq directly
> (testptp's int-ppb path cannot express the value) and confirms it is
> rejected with -ERANGE.
>
> Deep Shah (2):
> ptp: reject frequency adjustments that overflow scaled_ppm_to_ppb()
> selftests: ptp: add a regression test for the frequency adjustment
> overflow
>
> drivers/ptp/ptp_clock.c | 14 +++-
> tools/testing/selftests/ptp/Makefile | 2 +-
> .../testing/selftests/ptp/ptp_freq_overflow.c | 74 +++++++++++++++++++
> 3 files changed, 88 insertions(+), 2 deletions(-)
> create mode 100644 tools/testing/selftests/ptp/ptp_freq_overflow.c
>
>
> base-commit: 3f1f755366687d051174739fb99f7d560202f60b
For the series:
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
^ permalink raw reply
* [PATCH net v1] llc: fix SAP refcount leak when creating incoming sockets
From: Xuanqiang Luo @ 2026-07-12 13:03 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, linux-kernel, opurdila,
tim.bird, Xuanqiang Luo, stable
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
llc_sap_add_socket() takes a SAP reference for each socket added to a SAP,
and llc_sap_remove_socket() releases it. llc_create_incoming_sock() takes
an additional SAP reference after adding the child socket.
This extra reference was balanced by an explicit llc_sap_put() in
llc_ui_release() until commit 3100aa9d74db ("llc: fix SAP reference
counting w.r.t. socket handling") removed that put. The corresponding hold
in the accept path was left behind.
When such a child socket is removed, only the reference taken by
llc_sap_add_socket() is released. The extra reference keeps the SAP alive
after its last socket is removed. Remove the obsolete hold.
Fixes: 3100aa9d74db ("llc: fix SAP reference counting w.r.t. socket handling")
Cc: stable@vger.kernel.org
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
---
net/llc/llc_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
index e8f427375c68..260460d50f54 100644
--- a/net/llc/llc_conn.c
+++ b/net/llc/llc_conn.c
@@ -767,7 +767,6 @@ static struct sock *llc_create_incoming_sock(struct sock *sk,
newllc->dev = dev;
dev_hold(dev);
llc_sap_add_socket(llc->sap, newsk);
- llc_sap_hold(llc->sap);
out:
return newsk;
}
--
2.51.0
^ permalink raw reply related
* [PATCH net] igc: remove napi_synchronize() in igc_down()
From: David Carlier @ 2026-07-12 13:22 UTC (permalink / raw)
To: intel-wired-lan, netdev
Cc: anthony.l.nguyen, przemyslaw.kitszel, maciej.fijalkowski,
aleksandr.loktionov, advoretsky, stable, David Carlier
When an AF_XDP zero-copy application is killed abruptly, the XSK pool is
torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the
full budget on every poll, so napi_complete_done() never clears
NAPI_STATE_SCHED.
igc_down() calls napi_synchronize() before napi_disable(), so it spins
forever waiting for that bit and the interface never goes down. Drop the
napi_synchronize() and let napi_disable() do the job -- it sets
NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it
ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after
polling has stopped, matching the recent igb fix b1e067240379.
Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy")
Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
drivers/net/ethernet/intel/igc/igc_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 2c9e2dfd8499..b3883a5a7d7a 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -5352,9 +5352,8 @@ void igc_down(struct igc_adapter *adapter)
for (i = 0; i < adapter->num_q_vectors; i++) {
if (adapter->q_vector[i]) {
- napi_synchronize(&adapter->q_vector[i]->napi);
- igc_set_queue_napi(adapter, i, NULL);
napi_disable(&adapter->q_vector[i]->napi);
+ igc_set_queue_napi(adapter, i, NULL);
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH net] tcp: reject TIME_WAIT reopens when SYN queue is full
From: Yizhou Zhao @ 2026-07-12 13:25 UTC (permalink / raw)
To: netdev
Cc: Yizhou Zhao, Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima,
David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
linux-kernel, Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li, Ke Xu,
stable
A valid SYN that matches a TIME_WAIT socket is redirected to the
listener with a non-zero tcp_tw_isn. tcp_conn_request() deliberately
exempts those requests from normal SYN queue throttling. A peer can
therefore create victim-side TIME_WAIT entries with short connections,
replay valid reopen SYNs, and withhold the final ACK to allocate
request_sock objects outside the listener's normal SYN-flood controls.
Do not send syncookies for this path: tcp_timewait_state_process()
derives tcp_tw_isn from tw_snd_nxt so that a direct reopen uses an ISN
after the prior connection's sequence space. A syncookie ISN is a
hash-derived value and has no such ordering guarantee.
Check the selected listener's SYN queue before descheduling the
TIME_WAIT socket. If it is full, account a request-queue drop, retain
the TIME_WAIT socket, and discard the SYN. Once the queue has room,
the existing direct-reopen path and its TIME_WAIT ISN are unchanged.
Normal SYNs continue to use syncookies when the listener is full.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2-special
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
net/ipv4/tcp_ipv4.c | 8 ++++++++
net/ipv6/tcp_ipv6.c | 9 +++++++++
2 files changed, 17 insertions(+)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 209ef7522508fcc3974ae71d35dd66cba96b73d0..ddb5daede802d355b51b802b29b2e1ead3597bd2 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2310,6 +2310,14 @@ int tcp_v4_rcv(struct sk_buff *skb)
inet_iif(skb),
sdif);
if (sk2) {
+ if (inet_csk_reqsk_queue_is_full(sk2)) {
+ drop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;
+ __NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);
+ tcp_listendrop(sk2);
+ inet_twsk_put(inet_twsk(sk));
+ goto discard_it;
+ }
+
inet_twsk_deschedule_put(inet_twsk(sk));
sk = sk2;
tcp_v4_restore_cb(skb);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index ebe161d72fbd07a13d92812b45b5a3ce2464a015..8d3ff7184d03f5dd81f9a9c20e3ebbf174efc43a 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1969,6 +1969,15 @@ INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb)
sdif);
if (sk2) {
struct inet_timewait_sock *tw = inet_twsk(sk);
+
+ if (inet_csk_reqsk_queue_is_full(sk2)) {
+ drop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;
+ __NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);
+ tcp_listendrop(sk2);
+ inet_twsk_put(tw);
+ goto discard_it;
+ }
+
inet_twsk_deschedule_put(tw);
sk = sk2;
tcp_v6_restore_cb(skb);
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next] tls: sw: coalesce records in tls_sw_splice_read()
From: Northernside via B4 Relay @ 2026-07-12 13:39 UTC (permalink / raw)
To: John Fastabend, Jakub Kicinski, Sabrina Dubroca, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman
Cc: netdev, linux-kernel, Northernside
From: Northernside <git@northernsi.de>
tls_sw_splice_read() currently returns a single TLS record per call.
It dequeues (or decrypts) one record, splices it into the pipe and
returns. Draining a stream therefore costs one splice() syscall per
~16KB record, unlike tls_sw_recvmsg() which already coalesces multiple
records into the caller's buffer in a single call.
With this splice_read coalesces the same way by looping over ready
records, splicing each into the pipe, until the requested length is
reached, the pipe cannot take another record or a non DATA record is
hit.
Blocking behaviour is deliberately preserved.
Only the first record may block:
- data records after the first are fetched with a nonblocking wait
so a short splice is returned rather than sleeping for more input
- a further record is only started if it already fits in the pipe, so
the loop never turns a short read into a blocking
skb_splice_bits() where the original single record path would not
have blocked
A non DATA record met mid batch is left on rx_list and returned on the
next call. The copied ?: err return masks the -EINVAL exactly as
tls_sw_recvmsg() does for mid batch errors. When it is the first
record the -EINVAL behaviour is unchanged.
Since the loop can decrypt many records under a single reader lock,
the socket backlog is flushed periodically between records via
tls_read_flush_backlog(), like tls_sw_recvmsg() and tls_sw_read_sock()
already do and the released state is fed back into the next
tls_rx_rec_wait() call. Waits after the first record pass has_copied
so a pending sk_err is preserved rather than consumed by a short
splice.
Measured on a single stream (TLS 1.3, AES-128-GCM, loopback, 16KB
records), draining an upload dropped from 64 splice syscalls per MiB
(one per record) to ~12/MiB and throughput rose from ~2.2 to
~2.8 GiB/s, reaching parity with what tls_sw_recvmsg() achieves on
the same workload.
read()/recvmsg() users should see no change. This only brings the
zerocopy splice path (e.g. a proxy splicing a TLS socket to a backend
fd) to parity.
Signed-off-by: Northernside <git@northernsi.de>
---
net/tls/tls_sw.c | 101 +++++++++++++++++++++++++++++++++++++------------------
1 file changed, 69 insertions(+), 32 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index d4afc90fd796..8bc0361e3bf4 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1986,8 +1986,11 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
{
struct tls_context *tls_ctx = tls_get_ctx(sock->sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+ struct tls_prot_info *prot = &tls_ctx->prot_info;
struct strp_msg *rxm = NULL;
struct sock *sk = sock->sk;
+ size_t flushed_at = 0;
+ bool released = true;
struct tls_msg *tlm;
struct sk_buff *skb;
ssize_t copied = 0;
@@ -1998,47 +2001,81 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
if (err < 0)
return err;
- if (!skb_queue_empty(&ctx->rx_list)) {
- skb = __skb_dequeue(&ctx->rx_list);
- } else {
- struct tls_decrypt_arg darg;
+ /* Coalesce successive DATA records into the pipe, the way
+ * tls_sw_recvmsg() coalesces into the msg buffer, instead of
+ * returning one record per call. Only the first record may block.
+ */
+ while (copied < len) {
+ bool first = !copied;
- err = tls_rx_rec_wait(sk, flags & SPLICE_F_NONBLOCK,
- true, false);
- if (err <= 0)
- goto splice_read_end;
+ if (!skb_queue_empty(&ctx->rx_list)) {
+ skb = __skb_dequeue(&ctx->rx_list);
+ } else {
+ struct tls_decrypt_arg darg;
- memset(&darg.inargs, 0, sizeof(darg.inargs));
+ err = tls_rx_rec_wait(sk,
+ first ? (flags & SPLICE_F_NONBLOCK) : true,
+ released, !first);
+ if (err <= 0)
+ goto splice_read_end;
- err = tls_rx_one_record(sk, NULL, &darg);
- if (err < 0)
- goto splice_read_end;
+ memset(&darg.inargs, 0, sizeof(darg.inargs));
- tls_rx_rec_done(ctx);
- skb = darg.skb;
- }
+ err = tls_rx_one_record(sk, NULL, &darg);
+ if (err < 0)
+ goto splice_read_end;
- rxm = strp_msg(skb);
- tlm = tls_msg(skb);
+ released = tls_read_flush_backlog(sk, prot,
+ len - copied, 0,
+ copied, &flushed_at);
+ tls_rx_rec_done(ctx);
+ skb = darg.skb;
+ }
- /* splice does not support reading control messages */
- if (tlm->control != TLS_RECORD_TYPE_DATA) {
- err = -EINVAL;
- goto splice_requeue;
- }
+ rxm = strp_msg(skb);
+ tlm = tls_msg(skb);
- chunk = min_t(unsigned int, rxm->full_len, len);
- copied = skb_splice_bits(skb, sk, rxm->offset, pipe, chunk, flags);
- if (copied < 0)
- goto splice_requeue;
+ /* splice does not support reading control messages
+ * mid batch the record is left on rx_list for the next call
+ */
+ if (tlm->control != TLS_RECORD_TYPE_DATA) {
+ err = -EINVAL;
+ goto splice_requeue;
+ }
- if (copied < rxm->full_len) {
- rxm->offset += copied;
- rxm->full_len -= copied;
- goto splice_requeue;
- }
+ /* Records after the first must not block on pipe space,
+ * stop if this one does not already fit
+ */
+ if (!first) {
+ unsigned int need = DIV_ROUND_UP(rxm->full_len,
+ PAGE_SIZE);
+
+ if (pipe_occupancy(pipe->head, pipe->tail) + need >
+ pipe->max_usage) {
+ __skb_queue_head(&ctx->rx_list, skb);
+ goto splice_read_end;
+ }
+ }
+
+ chunk = min_t(unsigned int, rxm->full_len, len - copied);
+ chunk = skb_splice_bits(skb, sk, rxm->offset, pipe, chunk,
+ flags);
+ if (chunk < 0) {
+ err = chunk;
+ goto splice_requeue;
+ }
- consume_skb(skb);
+ copied += chunk;
+
+ /* pipe full, requeue the remainder */
+ if (chunk < rxm->full_len) {
+ rxm->offset += chunk;
+ rxm->full_len -= chunk;
+ goto splice_requeue;
+ }
+
+ consume_skb(skb);
+ }
splice_read_end:
tls_rx_reader_unlock(sk, ctx);
---
base-commit: f6f3b36c15ed44de1fbb44e645e4fae8c4a4453e
change-id: 20260712-tls-splice-coalesce-dd1bd5fa623c
Best regards,
--
Northernside <git@northernsi.de>
^ permalink raw reply related
* Re: Failed to reinit phy of spacemit-dwmac when reset-gpio is present
From: Andrew Lunn @ 2026-07-12 13:49 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Inochi Amaoto, Andrew Lunn, Eric Dumazet, David S. Miller,
Jakub Kicinski, Paolo Abeni, Yixun Lan, Maxime Coquelin,
Alexandre Torgue, netdev, linux-riscv, spacemit, linux-stm32,
linux-arm-kernel, linux-kernel, E Shattow, Han Gao
In-Reply-To: <bc78469c-3f45-4234-88b0-49f050d651db@bootlin.com>
> > --- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> > +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
> > @@ -196,7 +196,8 @@ ð0 {
> >
> > mdio {
> > phy0: phy@1 {
> > - compatible = "ethernet-phy-ieee802.3-c22";
> > + compatible = "ethernet-phy-id001c.c916",
> > + "ethernet-phy-ieee802.3-c22";
>
> Indeed that's merely a workaround :(
Despite is being a workaround, there has not been much progress on a
generic framework for dealing with clocks, resets, regulators etc,
before probing PHYs. So this is probably what you want to do.
Andrew
^ permalink raw reply
* Re: [PATCH net] tcp: reject TIME_WAIT reopens when SYN queue is full
From: Eric Dumazet @ 2026-07-12 13:51 UTC (permalink / raw)
To: Yizhou Zhao
Cc: netdev, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-kernel,
Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li, Ke Xu, stable
In-Reply-To: <20260712132531.33028-1-zhaoyz24@mails.tsinghua.edu.cn>
On Sun, Jul 12, 2026 at 3:26 PM Yizhou Zhao
<zhaoyz24@mails.tsinghua.edu.cn> wrote:
>
> A valid SYN that matches a TIME_WAIT socket is redirected to the
> listener with a non-zero tcp_tw_isn. tcp_conn_request() deliberately
> exempts those requests from normal SYN queue throttling. A peer can
> therefore create victim-side TIME_WAIT entries with short connections,
> replay valid reopen SYNs, and withhold the final ACK to allocate
> request_sock objects outside the listener's normal SYN-flood controls.
>
> Do not send syncookies for this path: tcp_timewait_state_process()
> derives tcp_tw_isn from tw_snd_nxt so that a direct reopen uses an ISN
> after the prior connection's sequence space. A syncookie ISN is a
> hash-derived value and has no such ordering guarantee.
>
> Check the selected listener's SYN queue before descheduling the
> TIME_WAIT socket. If it is full, account a request-queue drop, retain
> the TIME_WAIT socket, and discard the SYN. Once the queue has room,
> the existing direct-reopen path and its TIME_WAIT ISN are unchanged.
> Normal SYNs continue to use syncookies when the listener is full.
I do not see it as a threat, sorry.
Say no to AI hallucinations.
^ permalink raw reply
* Re: [PATCH 1/2] PCI: Replace pci_dev->is_busmaster with accessors
From: Lukas Wunner @ 2026-07-12 14:28 UTC (permalink / raw)
To: Maurice Hieronymus
Cc: Edward Cree, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Bjorn Helgaas, Justin Tee, Paul Ely,
James E.J. Bottomley, Martin K. Petersen, Juergen Gross,
Stefano Stabellini, Oleksandr Tyshchenko, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Daniel Almeida,
Tamir Duberstein, Alexandre Courbot, Onur Özkan,
Borislav Petkov, Tony Luck, Danilo Krummrich, rust-for-linux,
netdev, linux-net-drivers, linux-kernel, linux-pci, linux-scsi,
xen-devel, linux-edac
In-Reply-To: <20260711-pci-dev-flags-v1-1-2fcf2811138c@mailbox.org>
On Sat, Jul 11, 2026 at 05:21:06PM +0200, Maurice Hieronymus wrote:
> `is_busmaster` is one bit of a ~60-bit C bitfield in `struct pci_dev`.
> Bits sharing a bitfield word must not be modified concurrently, but its
> writers take no common lock: `pci_set_master()` can run without the
> device lock (e.g. from runtime PM resume paths), `pci_disable_device()`
> clears the bit, and other bits in the same word are written from
> entirely different contexts, e.g. `broken_parity_status` from sysfs.
> Concurrent read-modify-write cycles of the shared word can then lose
> updates.
>
> Move `is_busmaster` into a new `flags` bitmap modified with atomic
> bitops and accessed through generated accessor functions, following the
> example of commit a7cc262a1135 ("driver core: Replace dev->offline +
> ->offline_disabled with accessors"). More bitfield flags can follow the
> same pattern later.
We already have the priv_flags member in struct pci_dev,
please use that instead of adding another one for the same purpose.
Thanks,
Lukas
^ permalink raw reply
* [PATCH net] net: hip04: fix RX buffer leak on build_skb failure
From: Fan Wu @ 2026-07-12 14:27 UTC (permalink / raw)
To: netdev
Cc: przemyslaw.kitszel, horms, shenjian15, salil.mehta, dingtianhong,
andrew+netdev, davem, edumazet, kuba, pabeni, linux-kernel,
stable, Fan Wu
When build_skb() fails in hip04_rx_poll(), the driver jumps to the
refill path without releasing the current RX buffer and its DMA mapping.
Installing a replacement buffer then overwrites the slot references and
leaks both resources.
Keep the current slot intact and return budget so NAPI retries the same
buffer. Also free a newly allocated RX fragment when dma_map_single()
fails.
This issue was found by an in-house static analysis tool.
Fixes: 701a0fd52318 ("hip04_eth: fix missing error handle for build_skb failed")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.5
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 18376bcc7..1d03039b4 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -594,7 +594,10 @@ static int hip04_rx_poll(struct napi_struct *napi, int budget)
skb = build_skb(buf, priv->rx_buf_size);
if (unlikely(!skb)) {
net_dbg_ratelimited("build_skb failed\n");
- goto refill;
+ /* Retain the slot; return budget so NAPI retries this buffer.
+ * Refill would overwrite rx_buf[]/rx_phys[] and leak them.
+ */
+ return budget;
}
dma_unmap_single(priv->dev, priv->rx_phys[priv->rx_head],
@@ -622,14 +625,15 @@ static int hip04_rx_poll(struct napi_struct *napi, int budget)
rx++;
}
-refill:
buf = netdev_alloc_frag(priv->rx_buf_size);
if (!buf)
goto done;
phys = dma_map_single(priv->dev, buf,
RX_BUF_SIZE, DMA_FROM_DEVICE);
- if (dma_mapping_error(priv->dev, phys))
+ if (dma_mapping_error(priv->dev, phys)) {
+ skb_free_frag(buf);
goto done;
+ }
priv->rx_buf[priv->rx_head] = buf;
priv->rx_phys[priv->rx_head] = phys;
hip04_set_recv_desc(priv, phys);
^ permalink raw reply related
* Re: [PATCH v2 7/8] clk: sunxi-ng: a733: Add bus clock gates
From: Junhui Liu @ 2026-07-12 14:29 UTC (permalink / raw)
To: Junhui Liu, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Philipp Zabel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran
Cc: linux-clk, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv, netdev, Jerome Brunet
In-Reply-To: <20260711-a733-clk-v2-7-974d188cbe0c@pigmoral.tech>
On Sat Jul 11, 2026 at 4:10 PM CST, Junhui Liu wrote:
[...]
> +
> +static SUNXI_CCU_GATE_HWS(mbus_iommu1_sys_clk, "mbus-iommu1-sys", mbus_hws, 0x5b4, BIT(0), 0);
> +static SUNXI_CCU_GATE_HWS(apb_iommu1_sys_clk, "apb_iommu1-sys", apb0_hws, 0x5b4, BIT(1), 0);
> +static SUNXI_CCU_GATE_HWS(ahb_iommu1_sys_clk, "ahb_iommu1-sys", ahb_hws, 0x5b4, BIT(2), 0);
The clock names here should be "apb-iommu1-sys" and "ahb-iommu1-sys". I
will update them in next version.
--
Best regards,
Junhui Liu
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: clk: sun60i-a733-ccu: Add allwinner A733 support
From: Krzysztof Kozlowski @ 2026-07-12 14:35 UTC (permalink / raw)
To: Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Richard Cochran, linux-clk,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-riscv, netdev, Jerome Brunet
In-Reply-To: <20260711-a733-clk-v2-1-974d188cbe0c@pigmoral.tech>
On Sat, Jul 11, 2026 at 04:10:27PM +0800, Junhui Liu wrote:
> +properties:
> + "#clock-cells":
> + const: 1
> +
> + "#reset-cells":
> + const: 1
> +
Please order according to DTS coding style. compatible is ALWAYS the
first, then reg. Then name ordering, so reset-cells go to the end.
> + compatible:
> + enum:
> + - allwinner,sun60i-a733-ccu
> + - allwinner,sun60i-a733-r-ccu
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + minItems: 4
> + maxItems: 7
> +
> + clock-names:
> + minItems: 4
> + maxItems: 7
> +
> +required:
> + - "#clock-cells"
> + - "#reset-cells"
As well.
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + enum:
> + - allwinner,sun60i-a733-ccu
> +
> + then:
> + properties:
> + clocks:
> + items:
> + - description: High Frequency Oscillator (19.2MHz, 24MHz, or 26MHz)
> + - description: Low Frequency Oscillator (usually at 32kHz)
> + - description: Internal Oscillator
> + - description: Low Frequency Oscillator fanout
> +
> + clock-names:
> + items:
> + - const: hosc
> + - const: losc
> + - const: iosc
> + - const: losc-fanout
> +
> + - if:
> + properties:
> + compatible:
> + enum:
> + - allwinner,sun60i-a733-r-ccu
> +
> + then:
> + properties:
> + clocks:
> + items:
> + - description: High Frequency Oscillator (19.2MHz, 24MHz, or 26MHz)
> + - description: Low Frequency Oscillator (usually at 32kHz)
> + - description: Internal Oscillator
> + - description: System 24MHz Clock
> + - description: Peripherals PLL 0 (200 MHz output)
> + - description: Peripherals PLL 0 (300 MHz output)
> + - description: Peripherals PLL 1 (300 MHz output)
> +
> + clock-names:
> + items:
> + - const: hosc
> + - const: losc
> + - const: iosc
> + - const: sys-24m
> + - const: pll-periph0-200m
> + - const: pll-periph0-300m
> + - const: pll-periph1-300m
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + clock-controller@2002000 {
> + compatible = "allwinner,sun60i-a733-ccu";
> + reg = <0x02002000 0x2000>;
> + clocks = <&osc>, <&rtc 0>, <&rtc 2>, <&rtc 1>;
> + clock-names = "hosc", "losc", "iosc", "losc-fanout";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> +...
> diff --git a/include/dt-bindings/clock/sun60i-a733-ccu.h b/include/dt-bindings/clock/sun60i-a733-ccu.h
> new file mode 100644
> index 000000000000..6742070e3086
> --- /dev/null
> +++ b/include/dt-bindings/clock/sun60i-a733-ccu.h
Filename must match compatible.
> @@ -0,0 +1,290 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
Why different license than the binding?
> +/*
> + * Copyright (C) 2026 Junhui Liu <junhui.liu@pigmoral.tech>
...
> +#define CLK_BUS_DSC 257
> +#define CLK_CSI_MASTER0 258
> +#define CLK_CSI_MASTER1 259
> +#define CLK_CSI_MASTER2 260
> +#define CLK_CSI 261
> +#define CLK_BUS_CSI 262
> +#define CLK_ISP 263
> +#define CLK_RES_DCAP_24M 264
> +#define CLK_APB2JTAG 265
> +#define CLK_FANOUT_24M 266
> +#define CLK_FANOUT_12M 267
> +#define CLK_FANOUT_16M 268
> +#define CLK_FANOUT_25M 269
> +#define CLK_FANOUT_27M 270
> +#define CLK_FANOUT_PCLK 271
> +#define CLK_FANOUT0 272
> +#define CLK_FANOUT1 273
> +#define CLK_FANOUT2 274
> +#define CLK_FANOUT3 275
> +
> +#endif /* _DT_BINDINGS_CLK_SUN60I_A733_CCU_H_ */
> diff --git a/include/dt-bindings/clock/sun60i-a733-r-ccu.h b/include/dt-bindings/clock/sun60i-a733-r-ccu.h
> new file mode 100644
> index 000000000000..1d3845b483bf
> --- /dev/null
> +++ b/include/dt-bindings/clock/sun60i-a733-r-ccu.h
Here as well and so on (other places as well).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] dt-bindings: net: dsa: mediatek,mt7530: add econet,en7528-switch
From: Krzysztof Kozlowski @ 2026-07-12 14:36 UTC (permalink / raw)
To: Ahmed Naseef
Cc: netdev, Arınç ÜNAL, Chester A. Unal,
David S. Miller, Andrew Lunn, AngeloGioacchino Del Regno,
Conor Dooley, DENG Qingfang, Daniel Golle, Eric Dumazet,
Jakub Kicinski, Krzysztof Kozlowski, Landen Chao,
Matthias Brugger, Paolo Abeni, Rob Herring, Russell King,
Sean Wang, Vladimir Oltean, devicetree, linux-arm-kernel,
linux-kernel, linux-mediatek
In-Reply-To: <2133035bb22eacc8a0e21f86c0c800a45023ee01.1783770059.git.naseefkm@gmail.com>
On Sat, Jul 11, 2026 at 03:41:00PM +0400, Ahmed Naseef wrote:
> The EcoNet EN7528 MIPS SoC integrates an MT7530 Gigabit switch,
> memory-mapped in the SoC register space like the built-in switches of
> the MediaTek MT7988 and Airoha EN7581/AN7583 SoCs. Its four user ports
> are connected to integrated Gigabit PHYs and its CPU port is connected
> internally to the SoC Ethernet MAC.
>
> Those three switches are MT7531-based, whereas the EN7528 has a genuine
> MT7530 switch core (its chip revision register reads 0x7530). The two
> generations differ in their register programming - for example the CPU
> port is selected through the MT7530-style MFC register rather than the
> MT7531 CFC register - so the EN7528 is not compatible with the existing
> switch compatibles and cannot fall back to one of them.
>
> Add the econet,en7528-switch compatible, with the same constraints as
> the other built-in switches.
>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/8] clk: sunxi-ng: a733: Add mod clocks support
From: Junhui Liu @ 2026-07-12 14:25 UTC (permalink / raw)
To: Junhui Liu, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Philipp Zabel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran
Cc: linux-clk, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv, netdev, Jerome Brunet
In-Reply-To: <20260711-a733-clk-v2-6-974d188cbe0c@pigmoral.tech>
On Sat Jul 11, 2026 at 4:10 PM CST, Junhui Liu wrote:
[...]
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer0_clk, "timer0", timer_parents, 0x800,
I will update these to SUNXI_CCU_P_DATA_WITH_MUX_GATE in next version.
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer1_clk, "timer1", timer_parents, 0x804,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer2_clk, "timer2", timer_parents, 0x808,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer3_clk, "timer3", timer_parents, 0x80c,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer4_clk, "timer4", timer_parents, 0x810,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer5_clk, "timer5", timer_parents, 0x814,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer6_clk, "timer6", timer_parents, 0x818,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer7_clk, "timer7", timer_parents, 0x81c,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer8_clk, "timer8", timer_parents, 0x820,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE(timer9_clk, "timer9", timer_parents, 0x824,
> + 0, 0, /* no M */
> + 0, 3, /* P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
[...]
--
Best regards,
Junhui Liu
^ permalink raw reply
* Re: Failed to reinit phy of spacemit-dwmac when reset-gpio is present
From: E Shattow @ 2026-07-12 14:49 UTC (permalink / raw)
To: Andrew Lunn, Maxime Chevallier
Cc: Inochi Amaoto, Andrew Lunn, Eric Dumazet, David S. Miller,
Jakub Kicinski, Paolo Abeni, Yixun Lan, Maxime Coquelin,
Alexandre Torgue, netdev, linux-riscv, spacemit, linux-stm32,
linux-arm-kernel, linux-kernel, Han Gao
In-Reply-To: <8689bf7d-e00d-4097-bd3c-4d7d7844d1d2@lunn.ch>
On 7/12/26 06:49, Andrew Lunn wrote:
>>> --- a/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
>>> +++ b/arch/riscv/boot/dts/spacemit/k3-pico-itx.dts
>>> @@ -196,7 +196,8 @@ ð0 {
>>>
>>> mdio {
>>> phy0: phy@1 {
>>> - compatible = "ethernet-phy-ieee802.3-c22";
>>> + compatible = "ethernet-phy-id001c.c916",
>>> + "ethernet-phy-ieee802.3-c22";
>>
>> Indeed that's merely a workaround :(
>
> Despite is being a workaround, there has not been much progress on a
> generic framework for dealing with clocks, resets, regulators etc,
> before probing PHYs. So this is probably what you want to do.
>
> Andrew
Aside for my participation in reporting and testing here, I confirm that
the above addition to 'compatible' node does not itself resolve what I
observed to be a problem for debian-installer, however it does itself
resolve the rmmod/modprobe cycling issue of the eventual installed
Debian system as I described and what I am quoted as having reported
from dmesg output.
So the other report of increasing de-assert from 10ms to 50ms is needed
for success of the debian-installer hwprobe detection, and this here
issue of adding to the 'compatible' is needed for success of
rmmod/modprobe cycling. In concert together both fixes resolve all of
the trouble I observed and reported, tested and verified on Sipeed K3
Pico ITX.
Thanks for tracking this down it is very much appreciated :)
With that,
Tested-by: E Shattow <e@freeshell.de>
^ permalink raw reply
* Re: [PATCH 2/2] PCI: Replace pci_dev->broken_parity_status with accessors
From: Lukas Wunner @ 2026-07-12 14:55 UTC (permalink / raw)
To: Maurice Hieronymus
Cc: Edward Cree, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Bjorn Helgaas, Justin Tee, Paul Ely,
James E.J. Bottomley, Martin K. Petersen, Juergen Gross,
Stefano Stabellini, Oleksandr Tyshchenko, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Daniel Almeida,
Tamir Duberstein, Alexandre Courbot, Onur Özkan,
Borislav Petkov, Tony Luck, Danilo Krummrich, rust-for-linux,
netdev, linux-net-drivers, linux-kernel, linux-pci, linux-scsi,
xen-devel, linux-edac
In-Reply-To: <20260711-pci-dev-flags-v1-2-2fcf2811138c@mailbox.org>
On Sat, Jul 11, 2026 at 05:21:07PM +0200, Maurice Hieronymus wrote:
> `broken_parity_status` shares a C bitfield word in `struct pci_dev`
> with many other bits. `broken_parity_status_store()` writes it from
> sysfs at any time without taking any lock, so userspace can make it
> race with every other writer of the same word, e.g. `pci_set_master()`
> from a runtime PM resume path, and updates of neighboring bits can be
> lost.
For static bits in struct pci_dev, i.e. ones that are mostly read
and almost never written, and in particular ones that are only
written on device enumeration, it's perfectly fine and more convenient
to keep them as bitfields. broken_parity_status seems to fit that bill.
For other bits which are modified more frequently, move them to the existing
priv_flags member if you believe they can be updated concurrently.
I'm not sure is_busmaster fits that bill, it isn't updated that often.
Quite honestly I'm wondering if there is anything to fix here.
Yes I get it, userspace may interfere with adjacent bits.
But broken_parity_status is only used for certain broken devices
on EDAC-capable platforms. That's a fringe use case.
Is it really worth refactoring this?
Perhaps a better approach is to enclose dev_attr_broken_parity_status.attr
in "#ifdef CONFIG_EDAC" so that the attribute isn't shown unless it's used.
We shouldn't have used a sysfs attribute for this in the first place
but rather a quirk. Unfortunately 6b09ff9d7879 does not betray for which
device this was needed, so it's difficult to convert it to a quirk now.
Bjorn introduced a pci_disable_parity() API in 2021 which is used in a
quirk for certain Mellanox products:
https://lore.kernel.org/all/20210330174318.1289680-1-helgaas@kernel.org/
Perhaps we can deprecate the sysfs attribute in favor of using quirks
for broken devices?
Thanks,
Lukas
^ permalink raw reply
* Re: [PATCH] net: alacritech: add missing MODULE_DEVICE_TABLE()
From: Lino Sanfilippo @ 2026-07-12 15:43 UTC (permalink / raw)
To: Pengpeng Hou, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel
In-Reply-To: <20260704152053.49780-1-pengpeng@iscas.ac.cn>
Hi,
On 04.07.26 17:20, Pengpeng Hou wrote:
> The driver has a match table for the pci bus wired into its driver
> structure, but the table is not exported with MODULE_DEVICE_TABLE().
>
> Add the missing MODULE_DEVICE_TABLE() entry so module alias information
> is generated for automatic module loading.
>
> This is a source-level fix. It does not claim dynamic hardware
> reproduction; the evidence is the driver-owned match table, its use by
> the driver registration structure, and the missing module alias
> publication.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/net/ethernet/alacritech/slicoss.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/alacritech/slicoss.c b/drivers/net/ethernet/alacritech/slicoss.c
> index c1949ca060ca..14b74c09233e 100644
> --- a/drivers/net/ethernet/alacritech/slicoss.c
> +++ b/drivers/net/ethernet/alacritech/slicoss.c
> @@ -34,6 +34,7 @@ static const struct pci_device_id slic_id_tbl[] = {
> PCI_DEVICE_ID_ALACRITECH_OASIS) },
> { 0 }
> };
> +MODULE_DEVICE_TABLE(pci, slic_id_tbl);
>
> static const char slic_stats_strings[][ETH_GSTRING_LEN] = {
> "rx_packets",
Reviewed-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
^ permalink raw reply
* Re: [PATCH net] nfc: llcp: reject PDUs shorter than the LLCP header
From: Doruk (0sec) @ 2026-07-12 16:02 UTC (permalink / raw)
To: vadim.fedorenko; +Cc: david, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <be1731eb-e6ec-4015-92e4-c09fd88019e6@linux.dev>
Hi Vadim
this was reproduced from userspace on unmodified
linux-next (bee763d5f341) without RF hardware.
It's the peer-RX path, not a local command skb:
virtual_ncidev_write (peer NCI DATA) -> nci_rx_data_packet
-> nfc_tm_data_received -> nfc_llcp_data_received
-> rx_work -> nfc_llcp_rx_skb -> nfc_llcp_recv_connect
Bring the LLCP link up via a normal NFC-DEP activation, then send
one NCI DATA packet with a 1-byte CONNECT PDU. skb->len - 2 wraps
to 0xffffffff and the TLV walk runs off the end:
BUG: KFENCE: out-of-bounds read in nfc_llcp_recv_connect+0x9f6/0xf80
nfc_llcp_recv_connect+0x9f6 -> nfc_llcp_rx_work -> process_one_work
read 4219B past a 704B skbuff_small_head from virtual_ncidev_write
R14: 00000000ffffffff (wrapped tlv_array_len)
With the guard: rx_skb runs for all 600 short PDUs, recv_connect
reached 0 times, 0 reports.
The bound stays "<", not "<=" -- a header-only SYMM/DISC/DM is
exactly 2 bytes and must still dispatch; AGF uses "<=" only
because an AGF frame must also carry a sub-PDU. I'll drop the
"same guard as AGF" line from the commit message.
Instantiating /dev/virtual_nci needs privilege, but that's just
the syzbot transport; the 1-byte CONNECT is what a remote NFC-DEP
peer emits, and the DEP layer imposes no minimum LLCP length.
Impact is a proximity OOB read (DoS).
I can send the full reproducer if you'd like.
best
Doruk
On Sun, Jul 12, 2026 02:01 PM, Vadim Fedorenko
<vadim.fedorenko@linux.dev> wrote:
>
> On 11/07/2026 08:27, Doruk Tan Ozturk wrote:
> > nfc_llcp_rx_skb() reads the two-byte LLCP header (DSAP/SSAP/PTYPE) and
> > dispatches by PDU type; several handlers then derive a TLV-array length as
> > skb->len - LLCP_HEADER_SIZE. Neither nfc_llcp_rx_skb() nor its callers
> > guarantee the frame is at least LLCP_HEADER_SIZE bytes, and a sub-header
>
> that's not correct. there are 2 ways to get to nfc_llcp_rx_skb() - via
> nfc_llcp_recv_agf() or through commands/locally generated skbs. The
> first one checks against LLCP_HEADER_SIZE, while latter one creates skb
> payload with correct LLCP header size. Do you have a reproducer to
> trigger the issue?
>
>
> > PDU does reach it: digital_in_recv_dep_res() and digital_tg_recv_dep_req()
> > strip the DEP header with skb_pull() after only checking the DEP header
> > size, so a DEP I-PDU carrying a 0- or 1-byte LLCP payload is handed up as
> > a sub-2-byte skb.
> >
> > For a CONNECT or CC PDU, nfc_llcp_recv_connect() and nfc_llcp_recv_cc()
> > then pass skb->len - LLCP_HEADER_SIZE to nfc_llcp_parse_connection_tlv().
> > For skb->len < 2 that subtraction underflows: truncated into the u16
> > tlv_array_len parameter it becomes ~0xFFFE, and for a CONNECT to the SDP
> > SAP, nfc_llcp_connect_sn() uses a size_t and underflows to SIZE_MAX. The
> > TLV parsers bound their walk relative to that length, so they read far
> > past the end of the skb.
> >
> > The aggregated-frame path (nfc_llcp_recv_agf()) already drops sub-PDUs
> > shorter than the header. Apply the same guard once, in the dispatcher, so
>
> that not exactly correct, it drops skbs which are shorter or equal to
> the header, the check added in this patch is not correct then.
>
> > every PDU type is covered.
> >
> > Found by 0sec (https://0sec.ai) using automated source analysis; the
> > missing guard is evident from source. Compile-tested.
> >
> > Fixes: d646960f7986 ("NFC: Initial LLCP support")
> > Cc: stable@vger.kernel.org
> > Assisted-by: 0sec:claude-opus-4-8
> > Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> > ---
> > net/nfc/llcp_core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
> > index aed5fe1afef0..e3b3077e0e83 100644
> > --- a/net/nfc/llcp_core.c
> > +++ b/net/nfc/llcp_core.c
> > @@ -1481,6 +1481,9 @@ static void nfc_llcp_rx_skb(struct nfc_llcp_local *local, struct sk_buff *skb)
> > {
> > u8 dsap, ssap, ptype;
> >
> > + if (skb->len < LLCP_HEADER_SIZE)
> > + return;
> > +
> > ptype = nfc_llcp_ptype(skb);
> > dsap = nfc_llcp_dsap(skb);
> > ssap = nfc_llcp_ssap(skb);
>
^ 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