* Re: linux-next: manual merge of the net-next tree with the netfilter tree
From: Mark Brown @ 2026-04-08 15:08 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Andrea Mayer, Justin Iurman, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <adZhwtOYfo-0ImSa@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
On Wed, Apr 08, 2026 at 03:10:10PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/ipv6/seg6_iptunnel.c
>
> between commit:
>
> c3812651b522f ("seg6: separate dst_cache for input and output paths in seg6 lwtunnel")
>
> from the netfilter tree and commit:
>
> 78723a62b969a ("seg6: add per-route tunnel source address")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc net/ipv6/seg6_iptunnel.c
> index d6a0f7df90807,e76cc0cc481ec..0000000000000
> --- a/net/ipv6/seg6_iptunnel.c
> +++ b/net/ipv6/seg6_iptunnel.c
> @@@ -48,8 -48,8 +48,9 @@@ static size_t seg6_lwt_headroom(struct
> }
>
> struct seg6_lwt {
> - struct dst_cache cache;
> + struct dst_cache cache_input;
> + struct dst_cache cache_output;
> + struct in6_addr tunsrc;
> struct seg6_iptunnel_encap tuninfo[];
> };
>
This also needs a fixup for a new jump to the error handling paths that
was added in seg6_build_state().
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Jens Emil Schulz Ostergaard @ 2026-04-08 14:59 UTC (permalink / raw)
To: Rob Herring
Cc: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Krzysztof Kozlowski, Conor Dooley, Woojung Huh, Russell King,
Steen Hegelund, Daniel Machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260407171854.GA2970003-robh@kernel.org>
On Tue, 2026-04-07 at 12:18 -0500, Rob Herring wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Mar 24, 2026 at 11:46:45AM +0100, Jens Emil Schulz Østergaard wrote:
> > Add bindings for LAN9645X switch. We use a fallback compatible for the
> > smallest SKU microchip,lan96455s-switch.
> >
> > Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
> > Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> > ---
> > Changes in v2:
> > - rename file to microchip,lan96455s-switch.yaml
> > - remove led vendor property
> > - add {rx,tx}-internal-delay-ps for rgmii delay
> > - remove labels from example
> > - remove container node from example
> > ---
> > .../net/dsa/microchip,lan96455s-switch.yaml | 119 +++++++++++++++++++++
> > MAINTAINERS | 1 +
> > 2 files changed, 120 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > new file mode 100644
> > index 000000000000..0282e25c05d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > @@ -0,0 +1,119 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/dsa/microchip,lan96455s-switch.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Microchip LAN9645x Ethernet switch
> > +
> > +maintainers:
> > + - Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> > +
> > +description: |
>
> Don't need '|'
I will remove this.
>
> > + The LAN9645x switch is a multi-port Gigabit AVB/TSN Ethernet switch with
> > + five integrated 10/100/1000Base-T PHYs. In addition to the integrated PHYs,
> > + it supports up to 2 RGMII/RMII, up to 2 BASE-X/SERDES/2.5GBASE-X and one
> > + Quad-SGMII interfaces.
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - enum:
> > + - microchip,lan96455s-switch
> > + - items:
> > + - enum:
> > + - microchip,lan96455f-switch
> > + - microchip,lan96457f-switch
> > + - microchip,lan96459f-switch
> > + - microchip,lan96457s-switch
> > + - microchip,lan96459s-switch
> > + - const: microchip,lan96455s-switch
> > +
> > + reg:
> > + maxItems: 1
> > +
> > +$ref: dsa.yaml#
>
> Since you don't have any custom properties (just constraints), this ref
> should be "dsa.yaml#/$defs/ethernet-ports".
Right, I will update the ref.
>
> > +
> > +patternProperties:
> > + "^(ethernet-)?ports$":
>
> For a new binding, use the preferred name which is ethernet-ports. ports
> and port collide with the graph binding.
>
OK, I will use ethernet-ports and move it from patternProperties to properties.
> > + type: object
> > + additionalProperties: true
> > + patternProperties:
> > + "^(ethernet-)?port@[0-8]$":
>
> And 'ethernet-port'
I will change this and update the example.
>
> > + type: object
> > + description: Ethernet switch ports
> > +
> > + $ref: dsa-port.yaml#
> > +
> > + properties:
> > + rx-internal-delay-ps:
> > + const: 2000
> > +
> > + tx-internal-delay-ps:
> > + const: 2000
> > +
> > + unevaluatedProperties: false
>
> Place this after the $ref.
I will move this.
>
> > +
> > +oneOf:
> > + - required:
> > + - ports
> > + - required:
> > + - ethernet-ports
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + ethernet-switch@4000 {
> > + compatible = "microchip,lan96459f-switch", "microchip,lan96455s-switch";
> > + reg = <0x4000 0x244>;
> > +
> > + ethernet-ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy0>;
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy1>;
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy2>;
> > + };
> > +
> > + port@3 {
> > + reg = <3>;
> > + phy-mode = "gmii";
> > + phy-handle = <&cuphy3>;
> > + };
> > +
> > + port@7 {
> > + reg = <7>;
> > + phy-mode = "rgmii";
> > + ethernet = <&cpu_host_port>;
> > + rx-internal-delay-ps = <2000>;
> > + tx-internal-delay-ps = <2000>;
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + pause;
> > + };
> > + };
> > + };
> > + };
> > +...
> > +
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7ae698067c41..8232da1b3951 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -17278,6 +17278,7 @@ M: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> > M: UNGLinuxDriver@microchip.com
> > L: netdev@vger.kernel.org
> > S: Maintained
> > +F: Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > F: include/linux/dsa/lan9645x.h
> > F: net/dsa/tag_lan9645x.c
> >
> >
> > --
> > 2.52.0
> >
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next 0/2] i40e: implement per-queue stats
From: Paolo Abeni @ 2026-04-08 14:58 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-wired-lan, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, netdev
In-Reply-To: <3c7e8261-7528-431c-adb9-3b90124cef99@molgen.mpg.de>
On 4/8/26 1:50 PM, Paul Menzel wrote:
> Dear Paolo,
>
> Thank you for your patches.
>
> Am 08.04.26 um 13:43 schrieb Paolo Abeni:
>> The i40e driver already collects some per queue statistics, but does
>> not expose them to the user-space using the standard interface.
>>
>> Implement the stat_ops callbacks and extends the already collected info
>
> s/extends/extend/
>
>> with basic GSO counters. Overall this allows passing the kernel NIC
>> drivers TSO test cases.
>
> It’d be great, if you added the commands to show the stats, and to run
> the test cases.
I'll add some "show stats" examples in the v2 cover, hopefully fixing
the typos while at it.
How to run NID driver H/W self-tests is IMHO a bit too wide topic to be
discussed in the cover letter, but there is already a quite
comprehensive readme in the selftests dir:
https://elixir.bootlin.com/linux/v7.0-rc7/source/tools/testing/selftests/drivers/net/README.rst
/P
^ permalink raw reply
* Re: [PATCH net-next v2 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X
From: Jens Emil Schulz Ostergaard @ 2026-04-08 14:57 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, davem, edumazet, pabeni,
horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260407091217.rrwzho3lcmfip3y5@skbuf>
On Tue, 2026-04-07 at 12:12 +0300, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Wed, Apr 01, 2026 at 01:46:19PM +0200, Jens Emil Schulz Ostergaard wrote:
> > On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > This is an AI-generated review of your patch. The human sending this
> > > email has considered the AI review valid, or at least plausible.
> > > ---
> > > Subject: net: dsa: lan9645x: add basic dsa driver for LAN9645X
> > >
> > > This commit adds a basic DSA driver for the Microchip LAN9645X switch. It
> > > includes initialization, port module setup for NPI, CPU, and front ports,
> > > and phylink integration for MAC side configuration.
> > >
> > > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > > [ ... ]
> > > > +static void disable_conduit_ipv6(struct lan9645x *lan9645x,
> > > > + struct net_device *conduit)
> > > > +{
> > > > + struct inet6_dev *dev_v6;
> > > > +
> > > > + if (!conduit)
> > > > + return;
> > > > +
> > > > + /* IPv6 on the conduit will generate frames bypassing our tag driver, so
> > > > + * they lack an IFH. This will be garbage in garbage out and we want to
> > > > + * avoid this.
> > > > + */
> > > > + rtnl_lock();
> > > > + dev_v6 = __in6_dev_get(conduit);
> > > > + if (dev_v6) {
> > > > + WRITE_ONCE(dev_v6->cnf.disable_ipv6, 1);
> > > > + dev_warn(lan9645x->dev, "Disabled IPv6 on conduit device: %s\n",
> > > > + netdev_name(conduit));
> > > > + }
> > > > + rtnl_lock();
> > > > +}
> > >
> > > Does directly modifying dev_v6->cnf.disable_ipv6 bypass the proper sysctl
> > > teardown path (addrconf_disable_ipv6) and leave the IPv6 stack in an
> > > inconsistent state on the conduit device by failing to clean up routes,
> > > addresses, and MLD memberships?
> > >
> > > Is it a layering violation for a switch driver to alter the networking
> > > configuration of an external upper device, especially since this change
> > > isn't reverted during driver unbind?
> >
> > Yes this will bypass the sysctl teardown path. I can change this to instead
> > read disable_ipv6 state and warn the user that their device is misconfigured.
>
> I don't want to have to deal with a DSA driver altering the conduit
> configuration outside of the DSA core. NACK to any attempts of trying
> this.
>
> Define "garbage in, garbage out" for your case. The packets are sent to
> random ports? Normally, switches are configured by their drivers to drop
> those packets that don't contain DSA tags. You can also do that, by
> setting up the switch to require an injection prefix.
>
> > > [ ... ]
> > > > + /* Configure IFH prefix mode for NPI port. */
> > > > + lan_rmw(SYS_PORT_MODE_INCL_XTR_HDR_SET(LAN9645X_TAG_PREFIX_LONG) |
> > > > + SYS_PORT_MODE_INCL_INJ_HDR_SET(LAN9645X_TAG_PREFIX_NONE),
> > > > + SYS_PORT_MODE_INCL_XTR_HDR |
> > > > + SYS_PORT_MODE_INCL_INJ_HDR,
> > > > + lan9645x,
> > > > + SYS_PORT_MODE(p->chip_port));
> > >
> > > Setting LAN9645X_TAG_PREFIX_NONE means the hardware interprets the first
> > > bytes of any frame received from the host as an IFH command structure.
> > >
> > > Does this allow a local user to transmit crafted frames (for example, via
> > > raw sockets or standard protocols) whose MAC address bytes map to malicious
> > > IFH commands, thereby bypassing VLAN isolation or flooding the switch?
> > >
> > > Should the hardware be configured to require a strict prefix, such as
> > > LAN9645X_TAG_PREFIX_LONG, for injected frames to prevent this?
> >
> > A prefix offers no protection against the described scenario. The current
> > configuration is correct. If a prefix is configured frames MUST contain the
> > prefix. With the conduit exposed in userspace this is not something we can
> > guarantee.
>
> The short prefix prevents user space from sending frames by mistake
> which will reach the wire (daemons attaching to all interfaces, like for DHCP).
> It still allows user space to intentionally inject frames into the
> switch (for example from XDP on the conduit).
>
> I recommend you go for the short prefix and drop the conduit alterations.
>
By garbage in, garbage out I mean frames will be interpreted as having
an IFH, and may be sent to random ports depending the bytes in the
frame.
Unfortunately, configuring an injection prefix is not a good solution.
If an injection prefix is configured frames MUST contain this prefix. If
frames are received which do not contain the prefix they will corrupt
the queue system leaving the port unusable.
Since the driver does not have control over frames sent to the NPI port,
an injection prefix configuration is highly undesirable.
I will remove the conduit alterations.
> > > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > > [ ... ]
> > > > +static int lan9645x_setup(struct dsa_switch *ds)
> > > > +{
> > > > + struct lan9645x *lan9645x = ds->priv;
> > > > + struct device *dev = lan9645x->dev;
> > > > + u32 all_phys_ports;
> > > > + int err;
> > > > +
> > > > + lan9645x->num_phys_ports = ds->num_ports;
> > > > + all_phys_ports = GENMASK(lan9645x->num_phys_ports - 1, 0);
> > > > +
> > > > + err = lan9645x_reset_switch(lan9645x);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + lan9645x->ports = devm_kcalloc(lan9645x->dev, lan9645x->num_phys_ports,
> > > > + sizeof(struct lan9645x_port *),
> > > > + GFP_KERNEL);
> > >
> > > Since the DSA .setup callback can be invoked multiple times during the
> > > platform device's lifetime (for example, when the DSA master interface is
> > > unbound and bound again), does using devm_kcalloc here cause a memory leak?
> > > Should these allocations be moved to .probe or managed with kcalloc and
> > > freed in .teardown?
> > >
> >
> > Hmm I do not think this is right? I think dsa_tree_teardown is called from
> > dsa_switch_remove which is called by the switch drivers .remove.
> >
> > So I do not think you can get multiple setup/teardown cycles during the device
> > lifetime?
> >
> > As far as I can tell both felix and ksz use device managed allocations in their
> > setup callback.
>
> It's valid feedback in general. In a multi-switch tree, ds->ops->setup()
> is called when the tree is complete, and ds->ops->teardown() when the
> first switch disappears. If there are 2 switches and you unbind and
> rebind the driver from A, then switch B will see a ds->ops->teardown()
> call followed by ds->ops->setup().
>
> In your case, since the switch doesn't support cascading, it probably
> doesn't matter. But the LLM doesn't have the context to know that.
>
OK, I was not aware of this. I tried following the callstack and it did not seem
like the described scenario was possible. If device managed allocations are fine
when you do not support cascading, I would prefer to keep them.
> > > [ ... ]
> > > > + /* Set all the entries to obey VLAN. */
> > > > + for (int i = 0; i < PGID_ENTRIES; ++i)
> > > > + lan_wr(ANA_PGID_CFG_OBEY_VLAN_SET(1),
> > > > + lan9645x, ANA_PGID_CFG(i));
> > >
> > > PGID_ENTRIES is defined as 89, so this loop initializes indices 0 through
> > > 88. Since the CPU port is index 9, its source PGID is PGID_SRC + CPU_PORT
> > > (80 + 9 = 89).
> > >
> > > Is index 89 left uninitialized, breaking the OBEY_VLAN rule and allowing
> > > CPU-injected frames to leak across VLAN boundaries?
> > >
> >
> > No I this misunderstands OBEY_VLAN. When set the vlan table can control
> > whether cpu copy from the pgid table is enabled. It makes no sense for PGID 89.
>
> Explain that in a comment.
>
I will add a comment about this.
> > > [ ... ]
> > > > + /* Multicast to all front ports */
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MC));
> > > > +
> > > > + /* IP multicast to all front ports */
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV4));
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV6));
> > > > +
> > > > + /* Unicast to all front ports */
> > > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_UC));
> > > > +
> > > > + /* Broadcast to all ports */
> > > > + lan_wr(BIT(CPU_PORT) | all_phys_ports, lan9645x, ANA_PGID(PGID_BC));
> > >
> > > PGID_BC includes BIT(CPU_PORT) and all_phys_ports (which includes the NPI
> > > port). Will this forward broadcast frames to both the CPU extraction queue
> > > and the NPI port's normal egress queue, causing duplicate frames for the host?
> > >
> > > Conversely, the multicast masks and PGID_UC exclude BIT(CPU_PORT). Does
> > > this cause them to bypass the CPU extraction queue entirely, thereby
> > > lacking the LONG extraction prefix and breaking the host's DSA tagger parsing?
> > >
> >
> > No this is not how it works. Generally when you configure the CPU port to use
> > an NPI port, the hardware manages this internally. You do you have to start
> > using the npi port number all of a sudden.
>
> The comment is fair though. Why would you set all_phys_ports to
> GENMASK(lan9645x->num_phys_ports - 1, 0) when you can compute the mask
> of user ports which are enabled? It seems sloppy at best, and also
> contradictory (comments say "all front ports", but code includes the NPI
> port in this mask).
>
I will use dsa_user_ports(ds) as the base mask for the flood masks.
> > > [ ... ]
> > > > +int lan9645x_port_setup(struct dsa_switch *ds, int port)
> > > > +{
> > > > + struct dsa_port *dp = dsa_to_port(ds, port);
> > > > + struct lan9645x *lan9645x = ds->priv;
> > > > + struct lan9645x_port *p;
> > > > +
> > > > + p = lan9645x_to_port(lan9645x, port);
> > > > +
> > > > + if (dp->dn) {
> > > > + p->rx_internal_delay =
> > > > + of_property_present(dp->dn, "rx-internal-delay-ps");
> > > > + p->tx_internal_delay =
> > > > + of_property_present(dp->dn, "tx-internal-delay-ps");
> > > > + }
> > >
> > > These are standard integer properties specifying delays in picoseconds. If
> > > a user explicitly disables the delay via devicetree using a value of 0,
> > > will of_property_present evaluate to true and enable the hardware delay
> > > anyway? Should of_property_read_u32 be used instead to check the value?
> >
> > A value of 0 is not allowed per the bindings. The bindings enforce that if this
> > is present the value must be 2000.
>
> Bindings may change. Please use of_property_read_u32().
>
I will switch to of_property_read_u32.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: fix a return path in get_phy_c45_ids()
From: Charles Perry @ 2026-04-08 14:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Charles Perry, netdev, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Florian Fainelli, linux-kernel
In-Reply-To: <bcc4943d-137f-46d0-b5fd-385577c1259e@lunn.ch>
On Wed, Apr 08, 2026 at 03:48:22PM +0200, Andrew Lunn wrote:
> On Wed, Apr 08, 2026 at 06:31:44AM -0700, Charles Perry wrote:
> > The return value of phy_c45_probe_present() is store in "ret", not
> > "phy_reg", fix this. "phy_reg" always has a positive value if we reach
> > this return path (since it would have returned earlier otherwise), which
> > means that the original goal of the patch of not considering -ENODEV
> > fatal wasn't achieved.
> >
> > Fixes: 17b447539408 ("net: phy: c45 scanning: Don't consider -ENODEV fatal")
> > Signed-off-by: Charles Perry <charles.perry@microchip.com>
>
> Thanks for fixing this.
>
> The Subject line should be [PATCH net] since this is a Fix.
Ok, I'll resend this with the proper patch prefix.
Thanks,
Charles
>
> Otherwise:
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] tcp: rehash onto different ECMP path on retransmit timeout
From: Neal Cardwell @ 2026-04-08 14:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neil Spring, netdev, davem, kuba
In-Reply-To: <CANn89i+6ZaTKZbQrjF_d0mbMkYYK4a5B_Neef9VsgpuVCsU6Ag@mail.gmail.com>
On Wed, Apr 8, 2026 at 3:13 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, Apr 8, 2026 at 12:05 AM Neil Spring <ntspring@meta.com> wrote:
> >
> > Add sk_dst_reset() alongside sk_rethink_txhash() in the RTO, PLB,
> > and spurious-retrans paths so that the next transmit triggers a fresh
> > route lookup. Propagate sk_txhash into fl6->mp_hash in
> > inet6_csk_route_req() and inet6_csk_route_socket() so
> > fib6_select_path() uses the socket's current hash for ECMP selection.
> >
> > The ir_iif update in tcp_check_req() covers both IPv4 and IPv6
> > because it was cleaner than gating on address family; IPv4 is
> > otherwise unaltered, and not having autoflowlabel in IPv4 means
> > I wouldn't expect a new path on timeout.
> >
> > It is possible that PLB does not need this (that there are other
> > methods of reacting to local congestion); I added the sk_dst_reset
> > for consistency.
> >
> > Signed-off-by: Neil Spring <ntspring@meta.com>
For the next rev, I would suggest in the commit titles to rephrase
"ECMP" as "local ECMP" (e.g., rather than "tcp: rehash onto different
ECMP path on retransmit timeout" using "tcp: rehash onto different
local ECMP path on retransmit timeout").
Rationale: the existing Protective ReRoute ( from 3acf3ec3f4b0f "tcp:
Change txhash on every SYN and RTO retransmit" and discussed in
https://dl.acm.org/doi/10.1145/3603269.3604867 ) already changes flow
labels as an attempt to change the ECMP/WCMP path in the middle of the
network. So I found the original titles (like "tcp: rehash onto
different ECMP path on retransmit timeout") a little confusing, since
they read a bit like they are saying they implement something that is
already implemented. :-)
Thanks,
neal
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next 1/2] i40e: implement basic per-queue stats
From: Paolo Abeni @ 2026-04-08 14:44 UTC (permalink / raw)
To: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, netdev@vger.kernel.org
In-Reply-To: <IA3PR11MB89864FAAC7BCD8459A2BCD15E55BA@IA3PR11MB8986.namprd11.prod.outlook.com>
On 4/8/26 2:07 PM, Loktionov, Aleksandr wrote:
>> -----Original Message-----
>> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
>> Of Paolo Abeni
>> Sent: Wednesday, April 8, 2026 1:44 PM
>> To: intel-wired-lan@lists.osuosl.org
>> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
>> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
>> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
>> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
>> Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
>> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>; John
>> Fastabend <john.fastabend@gmail.com>; Stanislav Fomichev
>> <sdf@fomichev.me>; netdev@vger.kernel.org
>> Subject: [Intel-wired-lan] [PATCH iwl-next 1/2] i40e: implement basic
>> per-queue stats
>>
>> Only expose the counters currently available (bytes, packets); add
>> account for base stats to deal with ring clear.
>>
>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>> ---
>> drivers/net/ethernet/intel/i40e/i40e.h | 7 ++
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 133
>> ++++++++++++++++++++
>> 2 files changed, 140 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e.h
>> b/drivers/net/ethernet/intel/i40e/i40e.h
>> index dcb50c2e1aa2..fe642c464e9c 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e.h
>> +++ b/drivers/net/ethernet/intel/i40e/i40e.h
>> @@ -836,16 +836,23 @@ struct i40e_vsi {
>> struct i40e_eth_stats eth_stats;
>> struct i40e_eth_stats eth_stats_offsets;
>> u64 tx_restart;
>
> ...
>
>> +static void i40e_zero_tx_ring_stats(struct netdev_queue_stats_tx *tx)
>> {
>> + tx->bytes = 0;
>> + tx->packets = 0;
>> + tx->stop = 0;
>> + tx->wake = 0;
>> + tx->hw_drops = 0;
>> +}
>> +
>> +static void i40e_add_tx_ring_stats(struct i40e_ring *tx_ring,
>> + struct netdev_queue_stats_tx *tx) {
>> + u64 bytes, packets;
>> + unsigned int start;
>> +
>> + do {
>> + start = u64_stats_fetch_begin(&tx_ring->syncp);
>> + bytes = tx_ring->stats.bytes;
>> + packets = tx_ring->stats.packets;
>> + } while (u64_stats_fetch_retry(&tx_ring->syncp, start));
>> +
>> + tx->bytes += bytes;
>> + tx->packets += packets;
>> +
>> + tx->stop += tx_ring->tx_stats.tx_stopped;
>> + tx->wake += tx_ring->tx_stats.restart_queue;
>> + tx->hw_drops += tx_ring->tx_stats.tx_busy; }
> Why the reads are outside the seqlock region?
> On 32-bit kernels, unprotected u64 reads can tear IMHO
Currently there is no seqlock on the write side; to keep the series
small I preferred avoid fixing the pre-existing issue. In any case I
think moving stop, wake, hw_drops (and others) under seqlock protection
is an orthogonal change.
/P
^ permalink raw reply
* [PATCH net-next v2] ipv6: move IFA_F_PERMANENT percpu allocation in process scope
From: Paolo Abeni @ 2026-04-08 14:36 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Simon Horman
Observed at boot time:
CPU: 43 UID: 0 PID: 3595 Comm: (t-daemon) Not tainted 6.12.0 #1
Call Trace:
<TASK>
dump_stack_lvl+0x4e/0x70
pcpu_alloc_noprof.cold+0x1f/0x4b
fib_nh_common_init+0x4c/0x110
fib6_nh_init+0x387/0x740
ip6_route_info_create+0x46d/0x640
addrconf_f6i_alloc+0x13b/0x180
addrconf_permanent_addr+0xd0/0x220
addrconf_notify+0x93/0x540
notifier_call_chain+0x5a/0xd0
__dev_notify_flags+0x5c/0xf0
dev_change_flags+0x54/0x70
do_setlink+0x36c/0xce0
rtnl_setlink+0x11f/0x1d0
rtnetlink_rcv_msg+0x142/0x3f0
netlink_rcv_skb+0x50/0x100
netlink_unicast+0x242/0x390
netlink_sendmsg+0x21b/0x470
__sys_sendto+0x1dc/0x1f0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x7d/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f5c3852f127
Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 85 ef 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44
RSP: 002b:00007ffe86caf4c8 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000556c5cd93210 RCX: 00007f5c3852f127
RDX: 0000000000000020 RSI: 0000556c5cd938b0 RDI: 0000000000000003
RBP: 00007ffe86caf5a0 R08: 00007ffe86caf4e0 R09: 0000000000000080
R10: 0000000000000000 R11: 0000000000000202 R12: 0000556c5cd932d0
R13: 00000000021d05d1 R14: 00000000021d05d1 R15: 0000000000000001
IFA_F_PERMANENT addresses require the allocation of a bunch of percpu
pointers, currently in atomic scope.
Similar to commit 51454ea42c1a ("ipv6: fix locking issues with loops
over idev->addr_list"), move fixup_permanent_addr() outside the
&idev->lock scope, and do the allocations with GFP_KERNEL. With such
change fixup_permanent_addr() is invoked with the BH enabled, and the
ifp lock acquired there needs the BH variant.
Note that we don't need to acquire a reference to the permanent
addresses before releasing the mentioned write lock, because
addrconf_permanent_addr() runs under RTNL and ifa removal always happens
under RTNL, too.
Also the PERMANENT flag is constant in the relevant scope, as it can be
cleared only by inet6_addr_modify() under the RTNL lock.
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
v1 -> v2:
- rebased on top of "ipv6: prevent possible UaF in
addrconf_permanent_addr()"
v1: https://lore.kernel.org/netdev/d972e1e2-7090-47bd-988a-1ea854cbfb42@kernel.org/
explicitly targeting net-next as this is IMHO an improvement more than a
bug fix
---
net/ipv6/addrconf.c | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index dd0b4d80e0f8..77c77e843c96 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3585,15 +3585,15 @@ static int fixup_permanent_addr(struct net *net,
struct fib6_info *f6i, *prev;
f6i = addrconf_f6i_alloc(net, idev, &ifp->addr, false,
- GFP_ATOMIC, NULL);
+ GFP_KERNEL, NULL);
if (IS_ERR(f6i))
return PTR_ERR(f6i);
/* ifp->rt can be accessed outside of rtnl */
- spin_lock(&ifp->lock);
+ spin_lock_bh(&ifp->lock);
prev = ifp->rt;
ifp->rt = f6i;
- spin_unlock(&ifp->lock);
+ spin_unlock_bh(&ifp->lock);
fib6_info_release(prev);
}
@@ -3601,7 +3601,7 @@ static int fixup_permanent_addr(struct net *net,
if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
addrconf_prefix_route(&ifp->addr, ifp->prefix_len,
ifp->rt_priority, idev->dev, 0, 0,
- GFP_ATOMIC);
+ GFP_KERNEL);
}
if (ifp->state == INET6_IFADDR_STATE_PREDAD)
@@ -3612,29 +3612,36 @@ static int fixup_permanent_addr(struct net *net,
static void addrconf_permanent_addr(struct net *net, struct net_device *dev)
{
- struct inet6_ifaddr *ifp, *tmp;
+ struct inet6_ifaddr *ifp;
+ LIST_HEAD(tmp_addr_list);
struct inet6_dev *idev;
+ /* Mutual exclusion with other if_list_aux users. */
+ ASSERT_RTNL();
+
idev = __in6_dev_get(dev);
if (!idev)
return;
write_lock_bh(&idev->lock);
+ list_for_each_entry(ifp, &idev->addr_list, if_list) {
+ if (ifp->flags & IFA_F_PERMANENT)
+ list_add_tail(&ifp->if_list_aux, &tmp_addr_list);
+ }
+ write_unlock_bh(&idev->lock);
- list_for_each_entry_safe(ifp, tmp, &idev->addr_list, if_list) {
- if ((ifp->flags & IFA_F_PERMANENT) &&
- fixup_permanent_addr(net, idev, ifp) < 0) {
- write_unlock_bh(&idev->lock);
+ while (!list_empty(&tmp_addr_list)) {
+ ifp = list_first_entry(&tmp_addr_list,
+ struct inet6_ifaddr, if_list_aux);
+ list_del(&ifp->if_list_aux);
+ if (fixup_permanent_addr(net, idev, ifp) < 0) {
net_info_ratelimited("%s: Failed to add prefix route for address %pI6c; dropping\n",
idev->dev->name, &ifp->addr);
in6_ifa_hold(ifp);
ipv6_del_addr(ifp);
- write_lock_bh(&idev->lock);
}
}
-
- write_unlock_bh(&idev->lock);
}
static int addrconf_notify(struct notifier_block *this, unsigned long event,
--
2.53.0
^ permalink raw reply related
* [PATCH net] can: raw: fix ro->uniq use-after-free in raw_rcv()
From: Sam P @ 2026-04-08 14:30 UTC (permalink / raw)
To: netdev; +Cc: socketcan, mkl, linux-kernel, linux-can
raw_release() unregisters raw CAN receive filters via can_rx_unregister(),
but receiver deletion is deferred with call_rcu(). This leaves a window
where raw_rcv() may still be running in an RCU read-side critical section
after raw_release() frees ro->uniq, leading to a use-after-free of the
percpu uniq storage.
Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific
socket destructor. can_rx_unregister() takes an extra reference to the
socket and only drops it from the RCU callback, so freeing uniq from
sk_destruct ensures the percpu area is not released until the relevant
callbacks have drained.
Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame for overlapping CAN filters")
Cc: stable@vger.kernel.org # v4.1+
Assisted-by: Bynario AI
Signed-off-by: Samuel Page <sam@bynar.io>
---
net/can/raw.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/can/raw.c b/net/can/raw.c
index eee244ffc31e..f042c4316890 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -361,6 +361,14 @@ static int raw_notifier(struct notifier_block *nb, unsigned long msg,
return NOTIFY_DONE;
}
+static void raw_sock_destruct(struct sock *sk)
+{
+ struct raw_sock *ro = raw_sk(sk);
+
+ free_percpu(ro->uniq);
+ can_sock_destruct(sk);
+}
+
static int raw_init(struct sock *sk)
{
struct raw_sock *ro = raw_sk(sk);
@@ -387,6 +395,8 @@ static int raw_init(struct sock *sk)
if (unlikely(!ro->uniq))
return -ENOMEM;
+ sk->sk_destruct = raw_sock_destruct;
+
/* set notifier */
spin_lock(&raw_notifier_lock);
list_add_tail(&ro->notifier, &raw_notifier_list);
@@ -436,7 +446,6 @@ static int raw_release(struct socket *sock)
ro->bound = 0;
ro->dev = NULL;
ro->count = 0;
- free_percpu(ro->uniq);
sock_orphan(sk);
sock->sk = NULL;
--
2.49.0
^ permalink raw reply related
* Re: [PATCH 3/4] drm/drm_ras: Add DRM RAS netlink error event notification
From: Tauro, Riana @ 2026-04-08 14:29 UTC (permalink / raw)
To: Raag Jadav, aravind.iddamsetty, rodrigo.vivi
Cc: intel-xe, dri-devel, netdev, anshuman.gupta, joonas.lahtinen,
simona.vetter, airlied, pratik.bari, joshua.santosh.ranjan,
ashwin.kumar.kulkarni, shubham.kumar, ravi.kishore.koppuravuri,
anvesh.bakwad, maarten.lankhorst, Zack McKevitt, Lijo Lazar,
Hawking Zhang, David S. Miller, Paolo Abeni, Eric Dumazet,
Jakub Kicinski
In-Reply-To: <acPjxf5XTYuR7sbM@black.igk.intel.com>
On 3/25/2026 7:01 PM, Raag Jadav wrote:
> On Wed, Mar 11, 2026 at 03:59:17PM +0530, Riana Tauro wrote:
>> Add support for asynchronous error notifications in drm_ras.
> It's either drm_ras or DRM RAS, make it consistent in all patches
> (both commit message and subject).
Sure.
>
>> Define a new `error-event` netlink event and a new multicast
>> group `error-notify` in drm_ras spec. Each event contains
>> a node-id and error-id to identify the type and source
>> of error.
>>
>> Add drm_ras_error_notify() to trigger this event from drivers.
>> Userspace can receive this event by subscribing to the
>> multicast group error-notify.
>>
>> Example: Using ynl tool
> Ditto. Either Usage or Example, make it consistent in all patches.
>
> Also, please utilize the full 75 character space where possible.
Will fix.
>
>> $ sudo ynl --family drm_ras --subscribe error-notify
>>
>> Cc: Jakub Kicinski <kuba@kernel.org>
>> Cc: Zack McKevitt <zachary.mckevitt@oss.qualcomm.com>
>> Cc: Lijo Lazar <lijo.lazar@amd.com>
>> Cc: Hawking Zhang <Hawking.Zhang@amd.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Paolo Abeni <pabeni@redhat.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Riana Tauro <riana.tauro@intel.com>
>> ---
>> Documentation/gpu/drm-ras.rst | 9 +++++
>> Documentation/netlink/specs/drm_ras.yaml | 14 +++++++
>> drivers/gpu/drm/drm_ras.c | 48 ++++++++++++++++++++++++
>> drivers/gpu/drm/drm_ras_nl.c | 6 +++
>> drivers/gpu/drm/drm_ras_nl.h | 4 ++
>> include/drm/drm_ras.h | 2 +
>> include/uapi/drm/drm_ras.h | 3 ++
>> 7 files changed, 86 insertions(+)
>>
>> diff --git a/Documentation/gpu/drm-ras.rst b/Documentation/gpu/drm-ras.rst
>> index 4636e68f5678..09b2918f67bd 100644
>> --- a/Documentation/gpu/drm-ras.rst
>> +++ b/Documentation/gpu/drm-ras.rst
>> @@ -54,6 +54,8 @@ User space tools can:
>> ``node-id`` and ``error-id`` as parameters.
>> * Clear specific error counters with the ``clear-error-counter`` command, using both
>> ``node-id`` and ``error-id`` as parameters.
>> +* Listen to ``error-event`` notifications for error events by subscribing to the
>> + ``error-notify`` multicast group.
>>
>> YAML-based Interface
>> --------------------
>> @@ -109,3 +111,10 @@ Example: Clear an error counter for a given node
>>
>> sudo ynl --family drm_ras --do clear-error-counter --json '{"node-id":0, "error-id":1}'
>> None
>> +
>> +Example: Listen to error events
>> +
>> +.. code-block:: bash
>> +
>> + sudo ynl --family drm_ras --subscribe error-notify
>> + {'msg': {'error-id': 1, 'node-id': 1}, 'name': 'error-event'}
> Can we also have error-name and node-name? I'd be pulling my hair off
> if I need to remember all the ids.
Yeah makes sense. We can add the node_name, error_name.
Adding device_name would also be more useful in the event.
@Rodrigo/@aravind thoughts?
>
> On that note, I think it'll be good to have them as part of request
> attributes as an alternative to ids (also for existing commands) but
> that can done as a follow up.
>
We cannot use names as alternative because it won't work for multiple cards.
example in xe: Suppose there are 2 cards and each has 2 nodes. We cannot
query using node_name+error_name.
Also most of the netlink implementations use id's as unique identifiers.
$ sudo ./cli.py --family drm_ras --dump list-nodes
[{'device-name': 'bdf_1', 'node-id': 0, 'node-name':
'correctable-errors', 'node-type': 'error-counter'},
{'device-name': 'bdf_1, 'node-id': 1, 'node-name':
'uncorrectable-errors', 'node-type': 'error-counter'},
{'device-name': 'bdf_2', 'node-id': 2, 'node-name':
'correctable-errors', 'node-type': 'error-counter'},
{'device-name': 'bdf_2', 'node-id': 3, 'node-name':
'uncorrectable-errors', 'node-type': 'error-counter'}]
>
> Also, what if I have multiple devices with multiple nodes. Do they need
> separate subscription?
>
No, we subscribe only to the group not the nodes. In this case the group
is 'error-notify'
$ sudo ./cli.py --family drm_ras --subscribe error-notify
{'msg': {'error-id': 1, 'node-id': 1}, 'name': 'error-event'}
{'msg': {'error-id': 1, 'node-id': 3}, 'name': 'error-event'}
Thanks
Riana
>
> Raag
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: call netif_keep_dst() once when entering switchdev mode
From: Paul Menzel @ 2026-04-08 14:27 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Marcin Szycik
In-Reply-To: <20260408141429.2798589-1-aleksandr.loktionov@intel.com>
Dear Aleksandr, dear Marcin,
Thank you for the patch.
Am 08.04.26 um 16:14 schrieb Aleksandr Loktionov:
> From: Marcin Szycik <marcin.szycik@intel.com>
>
> netif_keep_dst() only needs to be called once for the uplink VSI, not
> once for each port representor. Move it from ice_eswitch_setup_repr()
> to ice_eswitch_enable_switchdev().
It’d be great, if you could share the commands, how to verify your change.
> Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path")
> Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> v1 -> v2:
> - Verified Fixes: tag via bisect - defd52455aee introduced the redundant
> per-repr call to netif_keep_dst(uplink_vsi->netdev) by changing the
> target netdev to the uplink VSI inside the per-representor setup
> function. Before that commit, each call was on a distinct repr->netdev
> so no Fixes: predating it applies.
>
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c b/drivers/net/ethernet/intel/ice/ice_eswitch.c
> index 2e4f096..c30e27b 100644
> --- a/drivers/net/ethernet/intel/ice/ice_eswitch.c
> +++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c
> @@ -117,8 +117,6 @@ static int ice_eswitch_setup_repr(struct ice_pf *pf, struct ice_repr *repr)
> if (!repr->dst)
> return -ENOMEM;
>
> - netif_keep_dst(uplink_vsi->netdev);
> -
> dst = repr->dst;
> dst->u.port_info.port_id = vsi->vsi_num;
> dst->u.port_info.lower_dev = uplink_vsi->netdev;
> @@ -312,6 +310,8 @@ static int ice_eswitch_enable_switchdev(struct ice_pf *pf)
> if (ice_eswitch_br_offloads_init(pf))
> goto err_br_offloads;
>
> + netif_keep_dst(uplink_vsi->netdev);
> +
> pf->eswitch.is_running = true;
>
> return 0;
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply
* [PATCH iwl-next v2] ice: call netif_keep_dst() once when entering switchdev mode
From: Aleksandr Loktionov @ 2026-04-08 14:14 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov
Cc: netdev, Marcin Szycik
From: Marcin Szycik <marcin.szycik@intel.com>
netif_keep_dst() only needs to be called once for the uplink VSI, not
once for each port representor. Move it from ice_eswitch_setup_repr()
to ice_eswitch_enable_switchdev().
Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path")
Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
v1 -> v2:
- Verified Fixes: tag via bisect - defd52455aee introduced the redundant
per-repr call to netif_keep_dst(uplink_vsi->netdev) by changing the
target netdev to the uplink VSI inside the per-representor setup
function. Before that commit, each call was on a distinct repr->netdev
so no Fixes: predating it applies.
drivers/net/ethernet/intel/ice/ice_eswitch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c b/drivers/net/ethernet/intel/ice/ice_eswitch.c
index 2e4f096..c30e27b 100644
--- a/drivers/net/ethernet/intel/ice/ice_eswitch.c
+++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c
@@ -117,8 +117,6 @@ static int ice_eswitch_setup_repr(struct ice_pf *pf, struct ice_repr *repr)
if (!repr->dst)
return -ENOMEM;
- netif_keep_dst(uplink_vsi->netdev);
-
dst = repr->dst;
dst->u.port_info.port_id = vsi->vsi_num;
dst->u.port_info.lower_dev = uplink_vsi->netdev;
@@ -312,6 +310,8 @@ static int ice_eswitch_enable_switchdev(struct ice_pf *pf)
if (ice_eswitch_br_offloads_init(pf))
goto err_br_offloads;
+ netif_keep_dst(uplink_vsi->netdev);
+
pf->eswitch.is_running = true;
return 0;
--
2.52.0
^ permalink raw reply related
* [PATCH net v2] ice: fix ice_init_link() error return preventing probe
From: Aleksandr Loktionov @ 2026-04-08 14:11 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov
Cc: netdev, Paul Greenwalt, Simon Horman
From: Paul Greenwalt <paul.greenwalt@intel.com>
ice_init_link() can return an error status from ice_update_link_info()
or ice_init_phy_user_cfg(), causing probe to fail.
An incorrect NVM update procedure can result in link/PHY errors, and
the recommended resolution is to update the NVM using the correct
procedure. If the driver fails probe due to link errors, the user
cannot update the NVM to recover. The link/PHY errors logged are
non-fatal: they are already annotated as 'not a fatal error if this
fails'.
Since none of the errors inside ice_init_link() should prevent probe
from completing, convert it to void and remove the error check in the
caller. All failures are already logged; callers have no meaningful
recovery path for link init errors.
Fixes: 5b246e533d01 ("ice: split probe into smaller functions")
Cc: stable@vger.kernel.org
Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
v1 -> v2:
- Rename the now-unused goto label err_init_link to err_deinit_pf_sw
to better describe the cleanup it performs (Simon Horman).
drivers/net/ethernet/intel/ice/ice_main.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index cf116bb..a6b0c09 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -4856,16 +4856,14 @@ static void ice_init_wakeup(struct ice_pf *pf)
device_set_wakeup_enable(ice_pf_to_dev(pf), false);
}
-static int ice_init_link(struct ice_pf *pf)
+static void ice_init_link(struct ice_pf *pf)
{
struct device *dev = ice_pf_to_dev(pf);
int err;
err = ice_init_link_events(pf->hw.port_info);
- if (err) {
+ if (err)
dev_err(dev, "ice_init_link_events failed: %d\n", err);
- return err;
- }
/* not a fatal error if this fails */
err = ice_init_nvm_phy_type(pf->hw.port_info);
@@ -4899,8 +4897,6 @@ static int ice_init_link(struct ice_pf *pf)
} else {
set_bit(ICE_FLAG_NO_MEDIA, pf->flags);
}
-
- return err;
}
static int ice_init_pf_sw(struct ice_pf *pf)
@@ -5043,11 +5039,9 @@ static int ice_init(struct ice_pf *pf)
ice_init_wakeup(pf);
- err = ice_init_link(pf);
- if (err)
- goto err_init_link;
+ ice_init_link(pf);
err = ice_send_version(pf);
if (err)
- goto err_init_link;
+ goto err_deinit_pf_sw;
@@ -5069,7 +5063,7 @@ static int ice_init(struct ice_pf *pf)
return 0;
-err_init_link:
+err_deinit_pf_sw:
ice_deinit_pf_sw(pf);
err_init_pf_sw:
ice_dealloc_vsis(pf);
unroll_pf_init:
--
2.52.0
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the netfilter tree
From: Mark Brown @ 2026-04-08 14:10 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Andrea Mayer, Justin Iurman, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv6/seg6_iptunnel.c
between commit:
c3812651b522f ("seg6: separate dst_cache for input and output paths in seg6 lwtunnel")
from the netfilter tree and commit:
78723a62b969a ("seg6: add per-route tunnel source address")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc net/ipv6/seg6_iptunnel.c
index d6a0f7df90807,e76cc0cc481ec..0000000000000
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@@ -48,8 -48,8 +48,9 @@@ static size_t seg6_lwt_headroom(struct
}
struct seg6_lwt {
- struct dst_cache cache;
+ struct dst_cache cache_input;
+ struct dst_cache cache_output;
+ struct in6_addr tunsrc;
struct seg6_iptunnel_encap tuninfo[];
};
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v2 7/8] ixgbe: use GFP_KERNEL in ixgbe_fcoe_ddp_setup()
From: Kohei Enju @ 2026-04-08 14:09 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260408131216.2662245-8-aleksandr.loktionov@intel.com>
On 04/08 15:12, Aleksandr Loktionov wrote:
> ixgbe_fcoe_ddp_setup() is always called from process context (FCoE
> offload setup paths) and never from an atomic context. Using GFP_ATOMIC
As I mentioned in v1, I don't think this path is non-atomic.
fc_exch_seq_send()
fc_exch_alloc() # acquires ep->ex_lock (spinlock) internally
fc_fcp_ddp_setup()
lport->tt.ddp_setup() == fcoe_ddp_setup()
.ndo_fcoe_ddp_setup() == ixgbe_fcoe_ddp_get()
ixgbe_fcoe_ddp_setup()
...
spin_unlock_bh(&ep->ex_lock);
So even if this runs in process context, it still appears to be in
atomic context while ep->ex_lock is held and also bh is disabled.
GFP_KERNEL still looks unsafe here for me.
If I'm misreading something, please let me know.
Thanks.
^ permalink raw reply
* Re: BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Russell King (Oracle) @ 2026-04-08 13:59 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel, iommu, linux-ext4,
Linus Torvalds
Cc: Marek Szyprowski, Robin Murphy, Theodore Ts'o, Andreas Dilger
In-Reply-To: <adZTGOjjJrVJOcT8@shell.armlinux.org.uk>
On Wed, Apr 08, 2026 at 02:07:36PM +0100, Russell King (Oracle) wrote:
> Hi,
>
> Just a heads-up that current net-next (v7.0-rc6 based) fails to boot on
> my nVidia Jetson Xavier platform. v7.0-rc5 and v6.14 based net-next both
> boot fine. This is an arm64 platform.
>
> The problem appears to be completely random in terms of its symptoms,
> and looks like severe memory corruption - every boot seems to produce
> a different problem. The common theme is, although the kernel gets to
> userspace, it never gets anywhere close to a login prompt before
> failing in some way.
>
> The last net-next+ boot (which is currently v7.0-rc6 based) resulted
> in:
>
> tegra-mc 2c00000.memory-controller: xusb_hostw: secure write @0x00000003ffffff00: VPR violation ((null))
> ...
> irq 91: nobody cared (try booting with the "irqpoll" option)
> ...
> depmod: ERROR: could not open directory /lib/modules/7.0.0-rc6-net-next+: No such file or directory
> ...
> Unable to handle kernel paging request at virtual address 0003201fd50320cf
>
>
> A previous boot of the exact same kernel didn't oops, but was unable
> to find the block device to mount for /mnt via block UUID.
>
> A previous boot to that resulted in an oops.
>
>
> The intersting thing is - the depmod error above is incorrect:
>
> root@tegra-ubuntu:~# ls -ld /lib/modules/7.0.0-rc6-net-next+
> drwxrwxr-x 3 root root 4096 Apr 8 10:23 /lib/modules/7.0.0-rc6-net-next+
>
> The directory is definitely there, and is readable - checked after
> booting back into net-next based on 7.0-rc5. In some of these boots,
> stmmac hasn't probed yet, which rules out my changes.
>
> Rootfs is ext4, and it seems there were a lot of ext4 commits merged
> between rc5 and rc6, but nothing for rc7.
>
> My current net-next head is dfecb0c5af3b. Merging rc7 on top also
> fails, I suspect also randomly, with that I just got:
>
> EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error.
> mount: /mnt/: can't find PARTUUID=741c0777-391a-4bce-a222-455e180ece2a.
> Unable to handle kernel paging request at virtual address f9bf0011ac0fb893
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [f9bf0011ac0fb893] address between user and kernel address ranges
> Internal error: Oops: 0000000096000004 [#1] SMP
> Modules linked in:
> CPU: 1 UID: 0 PID: 936 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
> Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : refill_objects+0x298/0x5ec
> lr : refill_objects+0x1f0/0x5ec
>
> ...
>
> Call trace:
> refill_objects+0x298/0x5ec (P)
> __pcs_replace_empty_main+0x13c/0x3a8
> kmem_cache_alloc_noprof+0x324/0x3a0
> alloc_iova+0x3c/0x290
> alloc_iova_fast+0x168/0x2d4
> iommu_dma_alloc_iova+0x84/0x154
> iommu_dma_map_sg+0x2c4/0x538
> __dma_map_sg_attrs+0x124/0x2c0
> dma_map_sg_attrs+0x10/0x20
> sdhci_pre_dma_transfer+0xb8/0x164
> sdhci_pre_req+0x38/0x44
> mmc_blk_mq_issue_rq+0x3dc/0x920
> mmc_mq_queue_rq+0x104/0x2b0
> __blk_mq_issue_directly+0x38/0xb0
> blk_mq_request_issue_directly+0x54/0xb4
> blk_mq_issue_direct+0x84/0x180
> blk_mq_dispatch_queue_requests+0x1a8/0x2e0
> blk_mq_flush_plug_list+0x60/0x140
> __blk_flush_plug+0xe0/0x11c
> blk_finish_plug+0x38/0x4c
> read_pages+0x158/0x260
> page_cache_ra_unbounded+0x158/0x3e0
> force_page_cache_ra+0xb0/0xe4
> page_cache_sync_ra+0x88/0x480
> filemap_get_pages+0xd8/0x850
> filemap_read+0xdc/0x3d8
> blkdev_read_iter+0x84/0x198
> vfs_read+0x208/0x2d8
> ksys_read+0x58/0xf4
> __arm64_sys_read+0x1c/0x28
> invoke_syscall.constprop.0+0x50/0xe0
> do_el0_svc+0x40/0xc0
> el0_svc+0x48/0x2a0
> el0t_64_sync_handler+0xa0/0xe4
> el0t_64_sync+0x19c/0x1a0
> Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: Oops: Fatal exception
>
> Looking at the changes between rc5 and rc6, there's one drivers/block
> change for zram (which is used on this platform), one change in
> drivers/base for regmap, nothing for drivers/mmc, but plenty for
> fs/ext4. There are five DMA API changes.
>
> Now building straight -rc7. If that also fails, my plan is to start
> bisecting rc5..rc6, which will likely take most of the rest of the
> day. So, in the mean time I'm sending this as a heads-up that rc6
> and onwards has a problem.
Plain -rc7 fails (another random oops):
Root device found: PARTUUID=741c0777-391a-4bce-a222-455e180ece2a
depmod: ERROR: could not open directory /lib/modules/7.0.0-rc7-net-next+: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
usb 2-3: new SuperSpeed Plus Gen 2x1 USB device number 2 using tegra-xusb
hub 2-3:1.0: USB hub found
hub 2-3:1.0: 4 ports detected
usb 1-3: new full-speed USB device number 3 using tegra-xusb
Unable to handle kernel paging request at virtual address 0003201fd50320cf
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[0003201fd50320cf] address between user and kernel address ranges
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in:
CPU: 1 UID: 0 PID: 917 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : refill_objects+0x298/0x5ec
lr : refill_objects+0x1f0/0x5ec
sp : ffff80008606b500
x29: ffff80008606b500 x28: 0000000000000001 x27: fffffdffc20e6200
x26: 0000000000000006 x25: 0000000000000000 x24: 000000000000003c
x23: ffff0000809e4840 x22: ffff0000809dba00 x21: ffff80008606b5a0
x20: ffff000081133820 x19: fffffdffc20e6220 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000100 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: ffff800081e5faa8
x11: ffff800082192c70 x10: ffff8000814074dc x9 : 0000000000000050
x8 : ffff80008606b490 x7 : ffff000083988b40 x6 : ffff80008606b4a0
x5 : 000000080015000f x4 : d503201fd503201f x3 : 00000000000000b0
x2 : d503201fd503201f x1 : ffff000081133828 x0 : d503201fd503201f
Call trace:
refill_objects+0x298/0x5ec (P)
__pcs_replace_empty_main+0x13c/0x3a8
kmem_cache_alloc_noprof+0x324/0x3a0
mempool_alloc_slab+0x1c/0x28
mempool_alloc_noprof+0x98/0xe0
bio_alloc_bioset+0x160/0x3e0
do_mpage_readpage+0x3d0/0x618
mpage_readahead+0xb8/0x144
blkdev_readahead+0x18/0x24
read_pages+0x58/0x260
page_cache_ra_unbounded+0x158/0x3e0
force_page_cache_ra+0xb0/0xe4
page_cache_sync_ra+0x88/0x480
filemap_get_pages+0xd8/0x850
filemap_read+0xdc/0x3d8
blkdev_read_iter+0x84/0x198
vfs_read+0x208/0x2d8
ksys_read+0x58/0xf4
__arm64_sys_read+0x1c/0x28
invoke_syscall.constprop.0+0x50/0xe0
do_el0_svc+0x40/0xc0
el0_svc+0x48/0x2a0
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x19c/0x1a0
Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
---[ end trace 0000000000000000 ]---
Now starting the bisect between 7.0-rc5 and 7.0-rc6.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers
From: Stefan Metzmacher @ 2026-04-08 13:56 UTC (permalink / raw)
To: David Laight, Breno Leitao
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, axboe,
Stanislav Fomichev, io-uring, bpf, netdev, Linus Torvalds,
linux-kernel, kernel-team
In-Reply-To: <20260408122653.295953dd@pumpkin>
Am 08.04.26 um 13:26 schrieb David Laight:
> On Wed, 08 Apr 2026 03:30:28 -0700
> Breno Leitao <leitao@debian.org> wrote:
>
>> Currently, the .getsockopt callback requires __user pointers:
>>
>> int (*getsockopt)(struct socket *sock, int level,
>> int optname, char __user *optval, int __user *optlen);
>>
>> This prevents kernel callers (io_uring, BPF) from using getsockopt on
>> levels other than SOL_SOCKET, since they pass kernel pointers.
>>
>> Following Linus' suggestion [0], this series introduces sockopt_t, a
>> type-safe wrapper around iov_iter, and a getsockopt_iter callback that
>> works with both user and kernel buffers. AF_PACKET and CAN raw are
>> converted as initial users, with selftests covering the trickiest
>> conversion patterns.
>
> What are you doing about the cases where 'optlen' is a complete lie?
> IIRC there is one related to some form of async io where it is just
> the length of the header, the actual buffer length depends on
> data in the header.
> This doesn't matter with the existing code for applications, when they
> get it wrong they just crash.
> But kernel users will need to pass the actual buffer length separately
> from optlen.
> It also affects any code that tries to cache the actual data and copy
> it back to userspace in the syscall wrapper - which makes sense for
> most short getsockopt.
>
> (This is different from historic code where the length might be
> assumed to be 4 regardless of what was passed.)
As the insane legacy cases can only happen for keeping
compatibility with existing userspace applications,
we could get the original optval and optlen __user pointers
out of sockopt_t again via something like:
char __user * __must_check sockopt_get_insame_legacy_optval(sockopt_t *sopt);
int __user * __must_check sockopt_get_insame_legacy_optlen(sockopt_t *sopt);
And for kernel callers they return NULL and the code should
turn that into -EINVAL or something similar.
Then legacy stuff can do what they need, but most things are
sane and able to be called via io_uring and in kernel users.
Unrelated to legacy stuff I think it should be an opt-in
(or at least opt-out) for the writeback of optlen.
metze
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers
From: Breno Leitao @ 2026-04-08 13:52 UTC (permalink / raw)
To: David Laight
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, metze, axboe,
Stanislav Fomichev, io-uring, bpf, netdev, Linus Torvalds,
linux-kernel, kernel-team
In-Reply-To: <20260408122653.295953dd@pumpkin>
Hello David,
On Wed, Apr 08, 2026 at 12:26:53PM +0100, David Laight wrote:
> On Wed, 08 Apr 2026 03:30:28 -0700
> Breno Leitao <leitao@debian.org> wrote:
>
> > Currently, the .getsockopt callback requires __user pointers:
> >
> > int (*getsockopt)(struct socket *sock, int level,
> > int optname, char __user *optval, int __user *optlen);
> >
> > This prevents kernel callers (io_uring, BPF) from using getsockopt on
> > levels other than SOL_SOCKET, since they pass kernel pointers.
> >
> > Following Linus' suggestion [0], this series introduces sockopt_t, a
> > type-safe wrapper around iov_iter, and a getsockopt_iter callback that
> > works with both user and kernel buffers. AF_PACKET and CAN raw are
> > converted as initial users, with selftests covering the trickiest
> > conversion patterns.
>
> What are you doing about the cases where 'optlen' is a complete lie?
Is this incorrect optlen originating from userspace, and getting into
the .getsockopt callbacks?
> IIRC there is one related to some form of async io where it is just
> the length of the header, the actual buffer length depends on
> data in the header.
Could you point me to the relevant code so I can examine this case?
> This doesn't matter with the existing code for applications, when they
> get it wrong they just crash.
Is this crash being triggered by the protocol callbacks?
I tried searching for this but couldn't find it. I'd appreciate any
hints you could provide about this case.
Thanks
--breno
^ permalink raw reply
* Re: [PATCH net-next] net: phy: fix a return path in get_phy_c45_ids()
From: Andrew Lunn @ 2026-04-08 13:48 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Florian Fainelli,
linux-kernel
In-Reply-To: <20260408133145.1177417-1-charles.perry@microchip.com>
On Wed, Apr 08, 2026 at 06:31:44AM -0700, Charles Perry wrote:
> The return value of phy_c45_probe_present() is store in "ret", not
> "phy_reg", fix this. "phy_reg" always has a positive value if we reach
> this return path (since it would have returned earlier otherwise), which
> means that the original goal of the patch of not considering -ENODEV
> fatal wasn't achieved.
>
> Fixes: 17b447539408 ("net: phy: c45 scanning: Don't consider -ENODEV fatal")
> Signed-off-by: Charles Perry <charles.perry@microchip.com>
Thanks for fixing this.
The Subject line should be [PATCH net] since this is a Fix.
Otherwise:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v4 net-next 02/14] dt-bindings: net: dsa: add NETC switch
From: Rob Herring @ 2026-04-08 13:43 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, krzk+dt, conor+dt, f.fainelli,
frank.li, chleroy, horms, linux, andrew, netdev, linux-kernel,
devicetree, linuxppc-dev, linux-arm-kernel, imx
In-Reply-To: <20260331113025.1566878-3-wei.fang@nxp.com>
On Tue, Mar 31, 2026 at 07:30:13PM +0800, Wei Fang wrote:
> Add bindings for NETC switch. This switch is a PCIe function of NETC IP,
> it supports advanced QoS with 8 traffic classes and 4 drop resilience
> levels, and a full range of TSN standards capabilities. The switch CPU
> port connects to an internal ENETC port, which is also a PCIe function
> of NETC IP. So these two ports use a light-weight "pseudo MAC" instead
> of a back-to-back MAC, because the "pseudo MAC" provides the delineation
> between switch and ENETC, this translates to lower power (less logic and
> memory) and lower delay (as there is no serialization delay across this
> link).
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../bindings/net/dsa/nxp,netc-switch.yaml | 130 ++++++++++++++++++
> 1 file changed, 130 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> new file mode 100644
> index 000000000000..5577f3ef987f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> @@ -0,0 +1,130 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NETC Switch family
> +
> +description: >
> + The NETC presents itself as a multi-function PCIe Root Complex Integrated
> + Endpoint (RCiEP) and provides full 802.1Q Ethernet switch functionality,
> + advanced QoS with 8 traffic classes and 4 drop resilience levels, and a
> + full range of TSN standards capabilities.
> +
> + The CPU port of the switch connects to an internal ENETC. The switch and
> + the internal ENETC are fully integrated into the NETC IP, a back-to-back
> + MAC is not required. Instead, a light-weight "pseudo MAC" provides the
> + delineation between the switch and ENETC. This translates to lower power
> + (less logic and memory) and lower delay (as there is no serialization
> + delay across this link).
> +
> +maintainers:
> + - Wei Fang <wei.fang@nxp.com>
> +
> +properties:
> + compatible:
> + enum:
> + - pci1131,eef2
> +
> + reg:
> + maxItems: 1
> +
> + dsa,member:
> + description: >
> + The property indicates DSA cluster and switch index. For NETC switch,
> + the valid range of the switch index is 1 ~ 7, the index is reflected
> + in the switch tag as an indication of the switch ID where the frame
> + originated. The value 0 is reserved for ENETC VEPA switch, whose ID
> + is hardwired to zero.
> +
> +$ref: dsa.yaml#
Move this under the 'allOf' so all $ref's are together.
> +
> +patternProperties:
> + "^(ethernet-)?ports$":
'ethernet-ports' for new bindings.
> + type: object
> + additionalProperties: true
> + patternProperties:
> + "^(ethernet-)?port@[0-9a-f]$":
And 'ethernet-port'
> + type: object
> +
> + $ref: dsa-port.yaml#
> +
> + properties:
> + clocks:
> + items:
> + - description: MAC transmit/receive reference clock.
> +
> + clock-names:
> + items:
> + - const: ref
> +
> + mdio:
> + $ref: /schemas/net/mdio.yaml#
> + unevaluatedProperties: false
> + description:
> + Optional child node for switch port, otherwise use NETC EMDIO.
> +
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - dsa,member
> +
> +allOf:
> + - $ref: /schemas/pci/pci-device.yaml
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet-switch@0,2 {
> + compatible = "pci1131,eef2";
> + reg = <0x200 0 0 0 0>;
> + dsa,member = <0 1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_switch>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + phy-handle = <ðphy0>;
> + phy-mode = "mii";
> + };
> +
> + port@1 {
> + reg = <1>;
> + phy-handle = <ðphy1>;
> + phy-mode = "mii";
> + };
> +
> + port@2 {
> + reg = <2>;
> + clocks = <&scmi_clk 103>;
> + clock-names = "ref";
> + phy-handle = <ðphy2>;
> + phy-mode = "rgmii-id";
> + };
> +
> + port@3 {
> + reg = <3>;
> + ethernet = <&enetc3>;
> + phy-mode = "internal";
> +
> + fixed-link {
> + speed = <2500>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> + };
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v4 net-next 01/14] dt-bindings: net: dsa: update the description of 'dsa,member' property
From: Rob Herring (Arm) @ 2026-04-08 13:40 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, kuba, andrew, linux, davem, frank.li, edumazet,
imx, pabeni, devicetree, horms, conor+dt, netdev, linuxppc-dev,
andrew+netdev, f.fainelli, linux-kernel, xiaoning.wang, krzk+dt,
vladimir.oltean, linux-arm-kernel, chleroy
In-Reply-To: <20260331113025.1566878-2-wei.fang@nxp.com>
On Tue, 31 Mar 2026 19:30:12 +0800, Wei Fang wrote:
> The current description indicates that the 'dsa,member' property cannot
> be set for a switch that is not part of any cluster. Vladimir thinks
> that this is a case where the actual technical limitation was poorly
> transposed into words when this restriction was first documented, in
> commit 8c5ad1d6179d ("net: dsa: Document new binding").
>
> The true technical limitation is that many DSA tagging protocols are
> topology-unaware, and always call dsa_conduit_find_user() with a
> switch_id of 0. Specifying a custom "dsa,member" property with a
> non-zero switch_id would break them.
>
> Therefore, for topology-aware switches, it is fine to specify this
> property for them, even if they are not part of any cluster. Our NETC
> switch is a good example which is topology-aware, the switch_id is
> carried in the switch tag, but the switch_id 0 is reserved for VEPA
> switch and cannot be used, so we need to use this property to assign
> a non-zero switch_id for it.
>
> Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> ---
> Documentation/devicetree/bindings/net/dsa/dsa.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH net-next] net: phy: fix a return path in get_phy_c45_ids()
From: Charles Perry @ 2026-04-08 13:31 UTC (permalink / raw)
To: netdev
Cc: Charles Perry, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Florian Fainelli, linux-kernel
The return value of phy_c45_probe_present() is store in "ret", not
"phy_reg", fix this. "phy_reg" always has a positive value if we reach
this return path (since it would have returned earlier otherwise), which
means that the original goal of the patch of not considering -ENODEV
fatal wasn't achieved.
Fixes: 17b447539408 ("net: phy: c45 scanning: Don't consider -ENODEV fatal")
Signed-off-by: Charles Perry <charles.perry@microchip.com>
---
drivers/net/phy/phy_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 81984d4ebb7c..810327fa886a 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -973,8 +973,8 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr,
/* returning -ENODEV doesn't stop bus
* scanning
*/
- return (phy_reg == -EIO ||
- phy_reg == -ENODEV) ? -ENODEV : -EIO;
+ return (ret == -EIO ||
+ ret == -ENODEV) ? -ENODEV : -EIO;
if (!ret)
continue;
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v5 3/3] net: phy: add a PHY write barrier when disabling interrupts
From: Charles Perry @ 2026-04-08 13:18 UTC (permalink / raw)
To: netdev
Cc: MameMaria.Mbaye, Charles Perry, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel
In-Reply-To: <20260408131821.1145334-1-charles.perry@microchip.com>
MDIO bus controllers are not required to wait for write transactions to
complete before returning as synchronization is often achieved by polling
status bits.
This can cause issues when disabling interrupts since an interrupt could
fire before the interrupt handler is unregistered and there's no status
bit to poll.
Add a phy_write_barrier() function and use it in phy_disable_interrupts()
to fix this issue. The write barrier just reads an MII register and
discards the value, which is enough to guarantee that previous writes have
completed.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
---
Notes:
Changes in v5:
- Support the case where the MDIO controller only supports C45
(Russell, Andrew)
- Make the return type of phy_write_barrier() void
Changes in v4:
- Add this patch (Russell, Andrew)
drivers/net/phy/phy.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 13dd1691886d..b21ff204c0dc 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1368,14 +1368,37 @@ void phy_error(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_error);
+/**
+ * phy_write_barrier - ensure the last write completed for this PHY device
+ * @phydev: target phy_device struct
+ *
+ * MDIO bus controllers are not required to wait for write transactions to
+ * complete before returning. Calling this function ensures that the previous
+ * write has completed.
+ */
+static void phy_write_barrier(struct phy_device *phydev)
+{
+ if (mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, MII_PHYSID1) ==
+ -EOPNOTSUPP)
+ mdiobus_c45_read(phydev->mdio.bus, phydev->mdio.addr,
+ MDIO_MMD_PMAPMD, MII_PHYSID1);
+}
+
/**
* phy_disable_interrupts - Disable the PHY interrupts from the PHY side
* @phydev: target phy_device struct
*/
int phy_disable_interrupts(struct phy_device *phydev)
{
+ int err;
+
/* Disable PHY interrupts */
- return phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
+ err = phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
+ if (err)
+ return err;
+
+ phy_write_barrier(phydev);
+ return 0;
}
/**
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v5 2/3] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-04-08 13:18 UTC (permalink / raw)
To: netdev
Cc: MameMaria.Mbaye, Charles Perry, Maxime Chevallier, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260408131821.1145334-1-charles.perry@microchip.com>
This adds an MDIO driver for PIC64-HPSC/HX. The hardware supports C22
and C45 but only C22 is implemented in this commit.
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely
different with pic64hpsc, hence the need for a separate driver.
The documentation recommends an input clock of 156.25MHz and a prescaler
of 39, which yields an MDIO clock of 1.95MHz.
The hardware supports an interrupt pin or a "TRIGGER" bit that can be
polled to signal transaction completion. This commit uses polling.
This was tested on Microchip HB1301 evalkit with a VSC8574 and a
VSC8541.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Notes:
Changes in v5: none
Changes in v4:
- read: return FIELD_GET() directly instead of using "ret" (Russell)
Changes in v3:
- Add a MAINTAINERS entry (Jakub)
Changes in v2:
- Remove #define for unused registers (Maxime)
- Add "c22" to clause 22 read/write ops (Maxime)
- Remove the call to platform_set_drvdata() (Andrew)
- Make the clock mandatory (Andrew)
- Use 2.5MHz if no clock-frequency was specified (Andrew)
- Change the error message for bad clock-frequency (Andrew)
- Fix a use without initialization on bus_freq (Andrew)
MAINTAINERS | 6 +
drivers/net/mdio/Kconfig | 7 ++
drivers/net/mdio/Makefile | 1 +
drivers/net/mdio/mdio-pic64hpsc.c | 190 ++++++++++++++++++++++++++++++
4 files changed, 204 insertions(+)
create mode 100644 drivers/net/mdio/mdio-pic64hpsc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e08767323763..9297c46dba91 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17216,6 +17216,12 @@ L: linux-serial@vger.kernel.org
S: Maintained
F: drivers/tty/serial/8250/8250_pci1xxxx.c
+MICROCHIP PIC64-HPSC/HX DRIVERS
+M: Charles Perry <charles.perry@microchip.com>
+S: Supported
+F: Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
+F: drivers/net/mdio/mdio-pic64hpsc.c
+
MICROCHIP POLARFIRE FPGA DRIVERS
M: Conor Dooley <conor.dooley@microchip.com>
L: linux-fpga@vger.kernel.org
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index 44380378911b..7bdba8c3ddef 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -146,6 +146,13 @@ config MDIO_OCTEON
buses. It is required by the Octeon and ThunderX ethernet device
drivers on some systems.
+config MDIO_PIC64HPSC
+ tristate "PIC64-HPSC/HX MDIO interface support"
+ depends on HAS_IOMEM && OF_MDIO
+ help
+ This driver supports the MDIO interface found on the PIC64-HPSC/HX
+ SoCs.
+
config MDIO_IPQ4019
tristate "Qualcomm IPQ4019 MDIO interface support"
depends on HAS_IOMEM && OF_MDIO
diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile
index fbec636700e7..048586746026 100644
--- a/drivers/net/mdio/Makefile
+++ b/drivers/net/mdio/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
obj-$(CONFIG_MDIO_MSCC_MIIM) += mdio-mscc-miim.o
obj-$(CONFIG_MDIO_MVUSB) += mdio-mvusb.o
obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
+obj-$(CONFIG_MDIO_PIC64HPSC) += mdio-pic64hpsc.o
obj-$(CONFIG_MDIO_REALTEK_RTL9300) += mdio-realtek-rtl9300.o
obj-$(CONFIG_MDIO_REGMAP) += mdio-regmap.o
obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
diff --git a/drivers/net/mdio/mdio-pic64hpsc.c b/drivers/net/mdio/mdio-pic64hpsc.c
new file mode 100644
index 000000000000..28be77ad6cf7
--- /dev/null
+++ b/drivers/net/mdio/mdio-pic64hpsc.c
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Microchip PIC64-HPSC/HX MDIO controller driver
+ *
+ * Copyright (c) 2026 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_mdio.h>
+#include <linux/platform_device.h>
+
+#define MDIO_REG_PRESCALER 0x20
+#define MDIO_CFG_PRESCALE_MASK GENMASK(7, 0)
+
+#define MDIO_REG_FRAME_CFG_1 0x24
+#define MDIO_WDATA_MASK GENMASK(15, 0)
+
+#define MDIO_REG_FRAME_CFG_2 0x28
+#define MDIO_TRIGGER_BIT BIT(31)
+#define MDIO_REG_DEV_ADDR_MASK GENMASK(20, 16)
+#define MDIO_PHY_PRT_ADDR_MASK GENMASK(8, 4)
+#define MDIO_OPERATION_MASK GENMASK(3, 2)
+#define MDIO_START_OF_FRAME_MASK GENMASK(1, 0)
+
+/* Possible value of MDIO_OPERATION_MASK */
+#define MDIO_OPERATION_WRITE BIT(0)
+#define MDIO_OPERATION_READ BIT(1)
+
+#define MDIO_REG_FRAME_STATUS 0x2C
+#define MDIO_READOK_BIT BIT(24)
+#define MDIO_RDATA_MASK GENMASK(15, 0)
+
+struct pic64hpsc_mdio_dev {
+ void __iomem *regs;
+};
+
+static int pic64hpsc_mdio_wait_trigger(struct mii_bus *bus)
+{
+ struct pic64hpsc_mdio_dev *priv = bus->priv;
+ u32 val;
+ int ret;
+
+ /* The MDIO_TRIGGER bit returns 0 when a transaction has completed. */
+ ret = readl_poll_timeout(priv->regs + MDIO_REG_FRAME_CFG_2, val,
+ !(val & MDIO_TRIGGER_BIT), 50, 10000);
+
+ if (ret < 0)
+ dev_dbg(&bus->dev, "TRIGGER bit timeout: %x\n", val);
+
+ return ret;
+}
+
+static int pic64hpsc_mdio_c22_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct pic64hpsc_mdio_dev *priv = bus->priv;
+ u32 val;
+ int ret;
+
+ ret = pic64hpsc_mdio_wait_trigger(bus);
+ if (ret)
+ return ret;
+
+ writel(MDIO_TRIGGER_BIT | FIELD_PREP(MDIO_REG_DEV_ADDR_MASK, regnum) |
+ FIELD_PREP(MDIO_PHY_PRT_ADDR_MASK, mii_id) |
+ FIELD_PREP(MDIO_OPERATION_MASK, MDIO_OPERATION_READ) |
+ FIELD_PREP(MDIO_START_OF_FRAME_MASK, 1),
+ priv->regs + MDIO_REG_FRAME_CFG_2);
+
+ ret = pic64hpsc_mdio_wait_trigger(bus);
+ if (ret)
+ return ret;
+
+ val = readl(priv->regs + MDIO_REG_FRAME_STATUS);
+
+ /* The MDIO_READOK is a 1-bit value reflecting the inverse of the MDIO
+ * bus value captured during the 2nd TA cycle. A PHY/Port should drive
+ * the MDIO bus with a logic 0 on the 2nd TA cycle, however, the
+ * PHY/Port could optionally drive a logic 1, to communicate a read
+ * failure. This feature is optional, not defined by the 802.3 standard
+ * and not supported in standard external PHYs.
+ */
+ if (!(bus->phy_ignore_ta_mask & 1 << mii_id) &&
+ !FIELD_GET(MDIO_READOK_BIT, val)) {
+ dev_dbg(&bus->dev, "READOK bit cleared\n");
+ return -EIO;
+ }
+
+ return FIELD_GET(MDIO_RDATA_MASK, val);
+}
+
+static int pic64hpsc_mdio_c22_write(struct mii_bus *bus, int mii_id, int regnum,
+ u16 value)
+{
+ struct pic64hpsc_mdio_dev *priv = bus->priv;
+ int ret;
+
+ ret = pic64hpsc_mdio_wait_trigger(bus);
+ if (ret < 0)
+ return ret;
+
+ writel(FIELD_PREP(MDIO_WDATA_MASK, value),
+ priv->regs + MDIO_REG_FRAME_CFG_1);
+
+ writel(MDIO_TRIGGER_BIT | FIELD_PREP(MDIO_REG_DEV_ADDR_MASK, regnum) |
+ FIELD_PREP(MDIO_PHY_PRT_ADDR_MASK, mii_id) |
+ FIELD_PREP(MDIO_OPERATION_MASK, MDIO_OPERATION_WRITE) |
+ FIELD_PREP(MDIO_START_OF_FRAME_MASK, 1),
+ priv->regs + MDIO_REG_FRAME_CFG_2);
+
+ return 0;
+}
+
+static int pic64hpsc_mdio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct pic64hpsc_mdio_dev *priv;
+ struct mii_bus *bus;
+ unsigned long rate;
+ struct clk *clk;
+ u32 bus_freq;
+ u32 div;
+ int ret;
+
+ bus = devm_mdiobus_alloc_size(dev, sizeof(*priv));
+ if (!bus)
+ return -ENOMEM;
+
+ priv = bus->priv;
+
+ priv->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->regs))
+ return PTR_ERR(priv->regs);
+
+ bus->name = KBUILD_MODNAME;
+ bus->read = pic64hpsc_mdio_c22_read;
+ bus->write = pic64hpsc_mdio_c22_write;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+ bus->parent = dev;
+
+ clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ if (of_property_read_u32(np, "clock-frequency", &bus_freq))
+ bus_freq = 2500000;
+
+ rate = clk_get_rate(clk);
+
+ div = DIV_ROUND_UP(rate, 2 * bus_freq) - 1;
+ if (div == 0 || div & ~MDIO_CFG_PRESCALE_MASK) {
+ dev_err(dev, "MDIO clock-frequency out of range\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, "rate=%lu bus_freq=%u real_bus_freq=%lu div=%u\n", rate,
+ bus_freq, rate / (2 * (1 + div)), div);
+ writel(div, priv->regs + MDIO_REG_PRESCALER);
+
+ ret = devm_of_mdiobus_register(dev, bus, np);
+ if (ret) {
+ dev_err(dev, "Cannot register MDIO bus (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id pic64hpsc_mdio_match[] = {
+ { .compatible = "microchip,pic64hpsc-mdio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, pic64hpsc_mdio_match);
+
+static struct platform_driver pic64hpsc_mdio_driver = {
+ .probe = pic64hpsc_mdio_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = pic64hpsc_mdio_match,
+ },
+};
+module_platform_driver(pic64hpsc_mdio_driver);
+
+MODULE_AUTHOR("Charles Perry <charles.perry@microchip.com>");
+MODULE_DESCRIPTION("Microchip PIC64-HPSC/HX MDIO driver");
+MODULE_LICENSE("GPL");
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v5 0/3] Add support for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-04-08 13:18 UTC (permalink / raw)
To: netdev
Cc: MameMaria.Mbaye, Charles Perry, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit, Russell King,
devicetree
Hello,
This series adds a driver for the two MDIO controllers of PIC64-HPSC/HX.
The hardware supports C22 and C45 but only C22 is implemented for now.
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for a separate driver.
The documentation recommends an input clock of 156.25MHz and a prescaler of
39, which yields an MDIO clock of 1.95MHz.
This was tested on Microchip HB1301 evalkit which has a VSC8574 and a
VSC8541. I've tested with bus frequencies of 0.6, 1.95 and 2.5 MHz.
This series also adds a PHY write barrier when disabling PHY interrupts as
discussed in [1].
Thanks,
Charles
[1]: https://lore.kernel.org/all/acvUqDgepCIScs8M@shell.armlinux.org.uk/
Changes in v5:
- 1/3: Collect Conor's Acked-by
- 1/3: Remove the "|" in "description: |" (Rob)
- 1/3: Don't mention how many instances of the MDIO controller there are
(Rob)
- 1/3: Hex addresses are now in lowercase (Rob)
- 1/3: Drop the phy DT label in the example (Rob)
- 3/3: Support MDIO controllers that only support C45 (Russell, Andrew)
Changes in v4:
- 2/3: return FIELD_GET() directly instead of using "ret" (Russell)
- 3/3: Add the PHY barrier patch (Russell, Andrew)
Changes in v3:
- 2/2: Add a MAINTAINERS entry (Jakub)
Changes in v2:
- 1/2: Make "clocks" and "interrupts" required (Andrew)
- 1/2: Add a default value to "clock-frequency" (Andrew)
- 2/2: Remove #define for unused registers (Maxime)
- 2/2: Add "c22" to clause 22 read/write ops (Maxime)
- 2/2: Remove the call to platform_set_drvdata() (Andrew)
- 2/2: Make the clock mandatory (Andrew)
- 2/2: Use 2.5MHz if no clock-frequency was specified (Andrew)
- 2/2: Change the error message for bad clock-frequency (Andrew)
- 2/2: Fix a use without initialization on bus_freq (Andrew)
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
CC: Conor Dooley <conor+dt@kernel.org>
CC: Heiner Kallweit <hkallweit1@gmail.com>
CC: Russell King <linux@armlinux.org.uk>
CC: netdev@vger.kernel.org
CC: devicetree@vger.kernel.org
Charles Perry (3):
dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
net: phy: add a PHY write barrier when disabling interrupts
.../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++
MAINTAINERS | 6 +
drivers/net/mdio/Kconfig | 7 +
drivers/net/mdio/Makefile | 1 +
drivers/net/mdio/mdio-pic64hpsc.c | 190 ++++++++++++++++++
drivers/net/phy/phy.c | 25 ++-
6 files changed, 296 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
create mode 100644 drivers/net/mdio/mdio-pic64hpsc.c
--
2.47.3
^ 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