* [PATCH iwl-next] e1000e: use ktime_get_real_ns() in e1000e_systim_reset()
From: Aleksandr Loktionov @ 2026-04-08 8:36 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov
Cc: netdev, Jacob Keller, Simon Horman
Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
ktime_get_real_ns() in e1000e_systim_reset(). Using the combined helper
avoids the unnecessary intermediate ktime_t variable and makes the
intent clearer.
Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
Suggested-by: Simon Horman <horms@kernel.org>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9befdac..6278ce9 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3943,7 +3943,7 @@ static void e1000e_systim_reset(struct e1000_adapter *adapter)
/* reset the systim ns time counter */
spin_lock_irqsave(&adapter->systim_lock, flags);
timecounter_init(&adapter->tc, &adapter->cc,
- ktime_to_ns(ktime_get_real()));
+ ktime_get_real_ns());
spin_unlock_irqrestore(&adapter->systim_lock, flags);
/* restore the previous hwtstamp configuration settings */
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net] nfc: llcp: add missing return after LLCP_CLOSED checks
From: Eric Dumazet @ 2026-04-08 8:40 UTC (permalink / raw)
To: Junxi Qian; +Cc: netdev, davem, kuba, pabeni, horms
In-Reply-To: <20260408081006.3723-1-qjx1298677004@gmail.com>
On Wed, Apr 8, 2026 at 1:10 AM Junxi Qian <qjx1298677004@gmail.com> wrote:
>
> In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket
> state is LLCP_CLOSED, the code correctly calls release_sock() and
> nfc_llcp_sock_put() but fails to return. Execution falls through to
> the remainder of the function, which calls release_sock() and
> nfc_llcp_sock_put() again. This results in a double release_sock()
> and a refcount underflow via double nfc_llcp_sock_put(), leading to
> a use-after-free.
>
> Add the missing return statements after the LLCP_CLOSED branches
> in both functions to prevent the fall-through.
>
> Fixes: d646960f7986 ("NFC: Initial LLCP support")
> Signed-off-by: Junxi Qian <qjx1298677004@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks!
^ permalink raw reply
* [net-next v1 v1 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Remove JH8100 dt-bindings because do not support it now.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 28 ++++---------------
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 313a15331661..0d1962980f57 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -30,10 +30,6 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
- - items:
- - const: starfive,jh8100-dwmac
- - const: starfive,jh7110-dwmac
- - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -120,25 +116,11 @@ allOf:
minItems: 3
maxItems: 3
- if:
- properties:
- compatible:
- contains:
- const: starfive,jh8100-dwmac
- then:
- properties:
- resets:
- maxItems: 1
-
- reset-names:
- const: stmmaceth
- else:
- properties:
- resets:
- minItems: 2
-
- reset-names:
- minItems: 2
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
unevaluatedProperties: false
--
2.17.1
^ permalink raw reply related
* [net-next v1 v1 2/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add StarFive JHB100 dwmac support and compatible.
The JHB100 dwmac shares the same driver code as the JH7110 dwmac,
which contains 2 SGMII interfaces, 1 RGMII/RMII interface and
1 RMII interface.
JHB100 dwmacc has only one reset signal and one main interrupt
line.
Please refer to below:
JHB100: reset-names = "stmmaceth";
Example usage of JHB100 in the device tree:
gmac0: ethernet@11b80000 {
compatible = "starfive,jhb100-dwmac",
"snps,dwmac-5.20";
interrupts = <225>;
interrupt-names = "macirq";
...
};
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 23 +++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 38bc34dc4f09..85cd3252e8b1 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -115,6 +115,7 @@ properties:
- sophgo,sg2044-dwmac
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
- tesla,fsd-ethqos
- thead,th1520-gmac
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 0d1962980f57..edc246a71ce3 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -18,6 +18,7 @@ select:
enum:
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
required:
- compatible
@@ -30,6 +31,9 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
+ - items:
+ - const: starfive,jhb100-dwmac
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -122,6 +126,25 @@ allOf:
reset-names:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jhb100-dwmac
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+
unevaluatedProperties: false
examples:
--
2.17.1
^ permalink raw reply related
* [net-next v1 v1 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
JHB100 SGMII interface tx/rx mac clock is split and require to
set clock rate in 10M/100M/1000M speed. So dts need to add a
new rx clock in code, dts and dt binding doc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 42 ++++++++++++++++---
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index edc246a71ce3..847d67a2c1d5 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -39,20 +39,26 @@ properties:
maxItems: 1
clocks:
+ minItems: 5
items:
- description: GMAC main clock
- description: GMAC AHB clock
- description: PTP clock
- description: TX clock
- description: GTX clock
+ - description: SGMII RX clock
clock-names:
- items:
- - const: stmmaceth
- - const: pclk
- - const: ptp_ref
- - const: tx
- - const: gtx
+ minItems: 5
+ maxItems: 6
+ contains:
+ enum:
+ - stmmaceth
+ - pclk
+ - ptp_ref
+ - tx
+ - gtx
+ - rx
starfive,tx-use-rgmii-clk:
description:
@@ -99,6 +105,14 @@ allOf:
minItems: 2
maxItems: 2
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
maxItems: 1
@@ -120,6 +134,14 @@ allOf:
minItems: 3
maxItems: 3
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
minItems: 2
@@ -139,6 +161,14 @@ allOf:
interrupt-names:
const: macirq
+ clocks:
+ minItems: 5
+ maxItems: 6
+
+ clock-names:
+ minItems: 5
+ maxItems: 6
+
resets:
maxItems: 1
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net v2] ppp: require CAP_NET_ADMIN in target netns for unattached ioctls
From: Qingfang Deng @ 2026-04-08 8:45 UTC (permalink / raw)
To: Taegu Ha; +Cc: linux-ppp, gnault, jaco, richardbgobert, ericwouds, netdev
In-Reply-To: <20260408065109.2171-1-hataegu0826@gmail.com>
Hi, Taegu
Please wait at least 24 hours before posting a new patch to netdev. See
https://docs.kernel.org/process/maintainer-netdev.html for more information.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem
From: Petr Oros @ 2026-04-08 8:54 UTC (permalink / raw)
To: Rinitha, SX, netdev@vger.kernel.org
Cc: Vecera, Ivan, Kitszel, Przemyslaw, Eric Dumazet,
Kubalewski, Arkadiusz, Andrew Lunn, Nguyen, Anthony L,
Simon Horman, intel-wired-lan@lists.osuosl.org, Jakub Kicinski,
Paolo Abeni, David S. Miller, linux-kernel@vger.kernel.org
In-Reply-To: <IA1PR11MB6241B58FF425A8684CFAE7A28B50A@IA1PR11MB6241.namprd11.prod.outlook.com>
On 4/1/26 18:29, Rinitha, SX wrote:
>> -----Original Message-----
>> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
>> Sent: 13 February 2026 19:47
>> To: netdev@vger.kernel.org
>> Cc: Vecera, Ivan <ivecera@redhat.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet <edumazet@google.com>; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-wired-lan@lists.osuosl.org; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; linux-kernel@vger.kernel.org
>> Subject: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem
>>
>> The DPLL SMA/U.FL pin redesign introduced ice_dpll_sw_pin_frequency_get() which gates frequency reporting on the pin's active flag. This flag is determined by ice_dpll_sw_pins_update() from the PCA9575 GPIO expander state. Before the redesign, SMA pins were exposed as direct HW input/output pins and ice_dpll_frequency_get() returned the CGU frequency unconditionally — the PCA9575 state was never consulted.
>>
>> The PCA9575 powers on with all outputs high, setting ICE_SMA1_DIR_EN, ICE_SMA1_TX_EN, ICE_SMA2_DIR_EN and ICE_SMA2_TX_EN. Nothing in the driver writes the register during initialization, so
>> ice_dpll_sw_pins_update() sees all pins as inactive and
>> ice_dpll_sw_pin_frequency_get() permanently returns 0 Hz for every SW pin.
>>
>> Fix this by writing a default SMA configuration in
>> ice_dpll_init_info_sw_pins(): clear all SMA bits, then set SMA1 and
>> SMA2 as active inputs (DIR_EN=0) with U.FL1 output and U.FL2 input disabled. Each SMA/U.FL pair shares a physical signal path so only one pin per pair can be active at a time. U.FL pins still report frequency 0 after this fix: U.FL1 (output-only) is disabled by ICE_SMA1_TX_EN which keeps the TX output buffer off, and U.FL2
>> (input-only) is disabled by ICE_SMA2_UFL2_RX_DIS. They can be activated by changing the corresponding SMA pin direction via dpll netlink.
>>
>> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
>> Signed-off-by: Petr Oros <poros@redhat.com>
>> ---
>> drivers/net/ethernet/intel/ice/ice_dpll.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
> When SMA1 is changed from output to input , U.FL1 (input) is expected to get connected but is still disconnected
> Similary, when SMA2 is changed from input to output , U.FL2 (output) is still disconnected
Hi Rinitha,
Thanks for testing this.
The initialization patch itself is correct. After boot, the PCA9575
register is written to a known-good default state and SMA1/SMA2
properly report as active inputs with the expected frequency.
The behavior you describe (U.FL1/U.FL2 staying disconnected after
SMA direction change) is a pre-existing issue in
ice_dpll_sma_direction_set(), not in the initialization path.
I am addressing this in v2 of "[PATCH iwl-net] ice: fix U.FL pin
state set affecting paired SMA pin" with an expanded scope that
covers both directions of the SMA/U.FL pairing.
Is it OK like this?
Regards,
Petr
^ permalink raw reply
* Re: [PATCH net] net_sched: fix skb memory leak in deferred qdisc drops
From: Eric Dumazet @ 2026-04-08 8:54 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, kuba, davem, Damilola Bello
In-Reply-To: <80b74501-5c15-4b69-a825-b747ac509855@suse.de>
On Tue, Apr 7, 2026 at 10:14 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
>
>
> On 4/7/26 7:02 PM, Fernando Fernandez Mancera wrote:
> > When the network stack cleans up the deferred list via qdisc_run_end(),
> > it operates on the root qdisc. If the root qdisc do not implement the
> > TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and
> > gets stranded on the child's local to_free list.
> >
> > Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It
> > fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If
> > the flag is present, the packet is appended directly to the root's
> > to_free list. Otherwise, drop it directly as it was done before the
> > optimization was implemented.
> >
> > Fixes: a6efc273ab82 ("net_sched: use qdisc_dequeue_drop() in cake, codel, fq_codel")
> > Reported-by: Damilola Bello <damilola@aterlo.com>
> > Closes: https://lore.kernel.org/netdev/CAPgFtOLaedBMU0f_BxV2bXftTJSmJr018Q5uozOo5vVo6b9tjw@mail.gmail.com/
> > Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> > ---
> > include/net/sch_generic.h | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> > index c3d657359a3d..61ba54e909f2 100644
> > --- a/include/net/sch_generic.h
> > +++ b/include/net/sch_generic.h
> > @@ -1170,12 +1170,18 @@ static inline void tcf_kfree_skb_list(struct sk_buff *skb)
> > static inline void qdisc_dequeue_drop(struct Qdisc *q, struct sk_buff *skb,
> > enum skb_drop_reason reason)
> > {
> > + struct Qdisc *root = qdisc_root_sleeping(q);
> > +
> > DEBUG_NET_WARN_ON_ONCE(!(q->flags & TCQ_F_DEQUEUE_DROPS));
> > DEBUG_NET_WARN_ON_ONCE(q->flags & TCQ_F_NOLOCK);
> >
> > - tcf_set_drop_reason(skb, reason);
> > - skb->next = q->to_free;
> > - q->to_free = skb;
> > + if (root->flags & TCQ_F_DEQUEUE_DROPS) {
> > + tcf_set_drop_reason(skb, reason);
> > + skb->next = q->to_free;
> > + q->to_free = skb;
> > + } else {
> > + kfree_skb_reason(skb, reason);
> > + }
> > }
> >
>
> *sigh* this is missing the following diff - tested it but forgot to
> amend it. Anyway, Eric let me know what do you think, if you like this
> solution I can send the v2 appending the skb to the root's to_free list
> properly.
>
> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> index 61ba54e909f2..0e4166319c02 100644
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -1177,8 +1177,8 @@ static inline void qdisc_dequeue_drop(struct Qdisc
> *q, struct sk_buff *skb,
>
> if (root->flags & TCQ_F_DEQUEUE_DROPS) {
> tcf_set_drop_reason(skb, reason);
> - skb->next = q->to_free;
> - q->to_free = skb;
> + skb->next = root->to_free;
> + root->to_free = skb;
> } else {
> kfree_skb_reason(skb, reason);
> }
>
Sure, please also use rcu_read_lock() before calling qdisc_root_sleeping()
^ permalink raw reply
* RE: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Wei Fang @ 2026-04-08 8:59 UTC (permalink / raw)
To: Jakub Kicinski, Vladimir Oltean
Cc: Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011738.1795644-1-kuba@kernel.org>
> > +static int netc_init_switch_id(struct netc_switch *priv)
> > +{
> > + struct netc_switch_regs *regs = &priv->regs;
> > + struct dsa_switch *ds = priv->ds;
> > +
> > + /* The value of 0 is reserved for the VEPA switch and cannot
> > + * be used.
> > + */
> > + if (ds->index > SWCR_SWID || !ds->index) {
> > + dev_err(priv->dev, "Switch index %d out of range\n",
> > + ds->index);
> > + return -ERANGE;
> > + }
>
> Does this check cause the probe to fail unconditionally for standard
> single-switch topologies?
>
> The DSA core typically assigns ds->index = 0 by default for the first switch.
> Because !ds->index evaluates to true for index 0, this setup function will
> always fail unless the dsa,member property is explicitly overridden in the
> device tree.
As I mentioned in another mail, we added the 'dsa,member' property to the
netc switch DT-binding doc, specifying that the 'member' (switch index) value
cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> Could the driver translate the hardware ID internally, for example by writing
> ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> restriction onto the software DSA index?
The current approach is based on Vladimir's suggestion. I need to confirm with
Vladimir which approach is better.
Hi Vladimir,
What are your thoughts on this suggestion? Is this approach better?
>
> [ ... ]
> > + for_each_available_child_of_node_scoped(ports, child) {
> > + /* If the node does not have phy-handle property, then
> > + * the port does not connect to a PHY, so the port is
> > + * not the EMDIO consumer.
> > + */
> > + phy_node = of_parse_phandle(child, "phy-handle", 0);
> > + if (!phy_node)
> > + continue;
> > +
> > + if (!netc_port_is_emdio_consumer(child)) {
> > + of_node_put(phy_node);
> > + continue;
> > + }
> > +
> > + phydev = of_phy_find_device(phy_node);
> > + of_node_put(phy_node);
> > + if (!phydev) {
> > + err = -EPROBE_DEFER;
> > + goto out;
> > + }
>
> Could this logic cause an infinite probe deferral loop for ports sharing an
> internal MDIO bus?
>
> The netc_port_is_emdio_consumer() function assumes any port node without
> an
> mdio child is an EMDIO consumer waiting for an external controller. However,
> if multiple sibling ports on the same switch share a single internal MDIO bus
> defined under one port, the other ports will lack an mdio child node.
>
> This would cause those ports to be mistakenly treated as external EMDIO
> consumers, calling of_phy_find_device(). Because the internal MDIO bus is not
> registered until later in netc_setup(), the PHY device cannot be found, and
> the driver returns -EPROBE_DEFER.
>
> Since netc_setup() is never reached, the MDIO bus is never registered,
> causing an infinite deferral loop. Could the driver more accurately identify
> whether the PHY belongs to its own switch before deferring?
This case will not be true, from the hardware perspective, the switch ports
do not support share a single internal MDIO bus defined under one port.
The internal MDIO bus of a port can only access its own external PHY. So
a switch port must either use EMDIO to access its PHY or its internal MDIO
bus to access its PHY.
>
> > +
> > + put_device(&phydev->mdio.dev);
> > + }
> > +
> > +out:
> > + of_node_put(ports);
> > +
> > + return err;
> > +}
> > +
> > +static int netc_switch_pci_init(struct pci_dev *pdev)
> > +{
> [ ... ]
> > + regs->base = pci_ioremap_bar(pdev, NETC_REGS_BAR);
> > + if (!regs->base) {
> > + err = -ENXIO;
> > + dev_err(dev, "pci_ioremap_bar() failed\n");
> > + goto release_mem_regions;
> > + }
> [ ... ]
> > +static void netc_switch_pci_destroy(struct pci_dev *pdev)
> > +{
> > + struct netc_switch *priv = pci_get_drvdata(pdev);
> > +
> > + iounmap(priv->regs.base);
> > + pci_release_mem_regions(pdev);
> > + pci_disable_device(pdev);
> > +}
>
> Does unmapping the memory here introduce a use-after-unmap issue when the
> MDIO bus is unregistered?
>
> The driver registers the MDIO bus using devm_of_mdiobus_register(), meaning
> devres cleans it up asynchronously after the remove function returns or when
> probe fails.
>
> However, in netc_switch_pci_destroy(), the driver explicitly unmaps the PCI
> I/O memory via iounmap(). Since netc_switch_pci_destroy() is called
> synchronously inside the remove function and probe error paths, the memory is
> unmapped before the MDIO bus is unregistered by devres.
>
> When devres eventually unregisters the MDIO bus, it detaches PHY devices,
> which often perform MDIO transactions during removal. Because the
> underlying
> memory priv->regs.base is already unmapped, these MDIO read/write callbacks
> could trigger a synchronous external abort or kernel panic.
>
> Would it be better to use pcim_iomap() to tie the memory mapping lifecycle to
> devres, ensuring it outlives the MDIO bus?
Great, I will pcim_iomap().
^ permalink raw reply
* [net-next v1 v1 0/5] Add StarFive JHB100 soc SGMII GMAC support
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
Managent Controller). Similar with Aspeed 27x0.
The JHB100 minimal system upstream is in progress:
https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
JHB100 GMAC still using designware GMAC core like JH7100 and JH7110,
and contains 2 SGMII interfaces, 1 RGMII/RMII interface, 1 RMII
interface. In JH7100/JH7110 dwmac-starfive.c have supported RGMII/RMII
interface. So require to add SGMII support to dwmac-starfive.c for JHB100.
SGMII serdes PHY has been intergrated in JHB100 and do not have driver
setting.
In JHB100 EVB board, SGMII connect with motorcomm YT8531s external PHY
and support RJ45 ethernet port.
The patch base in 7.0-rc5
Minda Chen (5):
dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
net: stmmac: starfive: Add JHB100 SGMII interface
net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 89 +++++++++++++------
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 38 +++++++-
3 files changed, 98 insertions(+), 30 deletions(-)
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.17.1
^ permalink raw reply
* [net-next v1 v1 5/5] net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add default disable split header flag in all the starfive
soc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index df7b2fc9989d..f6e5a2c4dc27 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -143,7 +143,7 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
}
dwmac->dev = &pdev->dev;
- plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
+ plat_dat->flags |= (STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | STMMAC_FLAG_SPH_DISABLE);
plat_dat->bsp_priv = dwmac;
plat_dat->dma_cfg->dche = true;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v5 00/10] Decouple receive and transmit enablement in team driver
From: Jiri Pirko @ 2026-04-08 9:00 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <CANkEMgn80UM7+mymVm21Q8yszgVeh029tvO+kHqmLGmf-2MU5g@mail.gmail.com>
Wed, Apr 08, 2026 at 02:12:35AM +0200, marcharvey@google.com wrote:
>On Tue, Apr 7, 2026 at 4:55 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Mon, Apr 06, 2026 at 05:03:36AM +0200, marcharvey@google.com wrote:
>> >Allow independent control over receive and transmit enablement states
>> >for aggregated ports in the team driver.
>> >
>> >The motivation is that IEE 802.3ad LACP "independent control" can't
>> >be implemented for the team driver currently. This was added to the
>> >bonding driver in commit 240fd405528b ("bonding: Add independent
>> >control state machine").
>> >
>> >This series also has a few patches that add tests to show that the old
>> >coupled enablement still works and that the new decoupled enablement
>> >works as intended (4, 5, and 10).
>> >
>> >There are three patches with small fixes as well, with the goal of
>> >making the final decoupling patch clearer (1, 2, and 3).
>>
>> Looks fine to me now. Do you have libteam/teamd counterpart?
>
>I don't see a need for this to be used in any of the teamd runners.
Why do you need this then?
^ permalink raw reply
* Re: [PATCH net-next v6 03/10] net: team: Rename port_disabled team mode op to port_tx_disabled
From: Jiri Pirko @ 2026-04-08 9:02 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260408-teaming-driver-internal-v6-3-e5bcdcf72504@google.com>
Wed, Apr 08, 2026 at 04:52:22AM +0200, marcharvey@google.com wrote:
>This team mode op is only used by the load balance mode, and it only
>uses it in the tx path.
>
>Signed-off-by: Marc Harvey <marcharvey@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* Re: [PATCH 3/3] io_uring/zcrx: fix resource leak and double-free hazard in io_import_umem
From: Pavel Begunkov @ 2026-04-08 9:06 UTC (permalink / raw)
To: KobaK, Jens Axboe; +Cc: Keith Busch, Ming Lei, io-uring, netdev, linux-kernel
In-Reply-To: <20260408065408.2017967-4-kobak@nvidia.com>
On 4/8/26 07:54, KobaK wrote:
> From: Koba Ko <kobak@nvidia.com>
>
> io_import_umem() has two problems:
>
> 1. When io_account_mem() fails, the function returns an error but leaves
> live pinned pages and sg_table in the mem struct without cleaning them
> up. The caller happens to handle this today via io_zcrx_free_area() ->
> io_release_area_mem(), but the contract is fragile.
That was the intention for the caller to clean it up, but in either
case the function has already been rewritten. In general, it seems
you based your patches on top of an outdated tree.
> 2. io_release_area_mem() doesn't NULL out mem->pages after kvfree(),
> making it unsafe to call twice. Since io_zcrx_free_area() always
> calls it during teardown, any earlier cleanup call would cause a
> double-free.
>
> Fix both: populate mem fields before io_account_mem() so
> io_release_area_mem() can do a proper cleanup on failure, and add
> mem->pages = NULL in io_release_area_mem() to make it idempotent.
>
> Fixes: 262ab205180d2 ("io_uring/zcrx: account area memory")
> Signed-off-by: Koba Ko <kobak@nvidia.com>
> ---
...
>
> static void io_release_area_mem(struct io_zcrx_mem *mem)
> @@ -236,6 +242,7 @@ static void io_release_area_mem(struct io_zcrx_mem *mem)
> sg_free_table(mem->sgt);
> mem->sgt = NULL;
> kvfree(mem->pages);
> + mem->pages = NULL;
The entire struct io_zcrx_mem / area is freed right after,
calling io_zcrx_free_area() multiple times for the same area
is not allowed.
--
Pavel Begunkov
^ permalink raw reply
* Re: [PATCH net-next v11 03/14] net: Add lease info to queue-get response
From: Daniel Borkmann @ 2026-04-08 9:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, bpf, davem, razor, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260407204017.3fc79d1b@kernel.org>
On 4/8/26 5:40 AM, Jakub Kicinski wrote:
> On Fri, 3 Apr 2026 01:10:20 +0200 Daniel Borkmann wrote:
>> +struct netdev_rx_queue *
>> +__netif_get_rx_queue_lease(struct net_device **dev, unsigned int *rxq_idx,
>> + enum netif_lease_dir dir)
>> +{
>> + struct net_device *orig_dev = *dev;
>> + struct netdev_rx_queue *rxq = __netif_get_rx_queue(orig_dev, *rxq_idx);
>> +
>> + if (rxq->lease) {
>> + if (!netif_lease_dir_ok(orig_dev, dir))
>> + return NULL;
>> + rxq = rxq->lease;
>> + *rxq_idx = get_netdev_rx_queue_index(rxq);
>> + *dev = rxq->dev;
>> + }
>> + return rxq;
>> +}
>> +
>> +struct netdev_rx_queue *
>> +netif_get_rx_queue_lease_locked(struct net_device **dev, unsigned int *rxq_idx)
>> +{
>> + struct net_device *orig_dev = *dev;
>> + struct netdev_rx_queue *rxq;
>> +
>> + /* Locking order is always from the virtual to the physical device
>> + * see netdev_nl_queue_create_doit().
>> + */
>> + netdev_ops_assert_locked(orig_dev);
>> + rxq = __netif_get_rx_queue_lease(dev, rxq_idx, NETIF_VIRT_TO_PHYS);
>> + if (rxq && orig_dev != *dev)
>> + netdev_lock(*dev);
>> + return rxq;
>> +}
>> +
>> +void netif_put_rx_queue_lease_locked(struct net_device *orig_dev,
>> + struct net_device *dev)
>> +{
>> + if (orig_dev != dev)
>> + netdev_unlock(dev);
>> +}
>
> Pretty sure I already complained about these ugly helpers.
> I'll try to find the time tomorrow to come up with something better.
Ok, sounds good. Happy to adapt if you find something better and then I'll
work this into the series, and also integrate the things mentioned in my
cover letter reply (netkit nl dump + additional tests).
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 4/5] bus: mhi: host: Update the Time sync logic to read 64 bit register value
From: Krishna Chaitanya Chundru @ 2026-04-08 9:22 UTC (permalink / raw)
To: Konrad Dybcio, Manivannan Sadhasivam, Richard Cochran
Cc: mhi, linux-arm-msm, linux-kernel, netdev, taniya.das, imran.shaik,
quic_vbadigan, quic_mrana
In-Reply-To: <16698a59-1a2f-4816-98fe-56b125be669b@oss.qualcomm.com>
On 9/2/2025 2:44 PM, Konrad Dybcio wrote:
> On 8/18/25 8:55 AM, Krishna Chaitanya Chundru wrote:
>> Instead of reading low and high of the mhi registers twice use 64 bit
>> register value to avoid any time penality.
>>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> drivers/bus/mhi/host/main.c | 19 +++++++++++++++----
>> 1 file changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
>> index b7ceeb7261b708d46572d1f68dc277b6e1186b6e..f628198218ef9dc760bbfc3ec496603d1a45dfc1 100644
>> --- a/drivers/bus/mhi/host/main.c
>> +++ b/drivers/bus/mhi/host/main.c
>> @@ -1719,6 +1719,7 @@ static int mhi_get_remote_time(struct mhi_controller *mhi_cntrl, struct mhi_time
>> struct mhi_timesync_info *time)
>> {
>> struct device *dev = &mhi_cntrl->mhi_dev->dev;
>> + u64 val = U64_MAX;
>> int ret, i;
>>
>> if (!mhi_tsync && !mhi_tsync->time_reg) {
>> @@ -1756,15 +1757,25 @@ static int mhi_get_remote_time(struct mhi_controller *mhi_cntrl, struct mhi_time
>> * transition to L0.
>> */
>> for (i = 0; i < MHI_NUM_BACK_TO_BACK_READS; i++) {
>> - ret = mhi_read_reg(mhi_cntrl, mhi_tsync->time_reg,
>> - TSC_TIMESYNC_TIME_LOW_OFFSET, &time->t_dev_lo);
>> + if (mhi_cntrl->read_reg64) {
>> + ret = mhi_read_reg64(mhi_cntrl, mhi_tsync->time_reg,
>> + TSC_TIMESYNC_TIME_LOW_OFFSET, &val);
> Since you're passing mhi_cntrl to the read_reg64 function anyway,
> perhaps this could remove some verbosity:
Hi Konrad,
Sorry for late reply, in pci_generic patch we are defining read_reg64 only if
readq is defined
in the system. As per your suggesting if we go define mhi_read_reg64 always,
we need to
have #ifdef inside the mhi_read_reg64() or create a new function both of them
doesn't look
good better to have this way only.
- Krishna Chaitanya.
> int mhi_read_reg64(...) {
> u32 val_hi, val_lo;
> u64 val;
>
> if (mhi_cntrl->read_reg64) {
> ...
> } else {
> ...
> val = FIELD_PREP(GENMASK(63, 32), val_hi)) |
> FIELD_PREP(GENMASK(31, 0), val_lo));
> }
>
> return val
> }
>
>
> Konrad
^ permalink raw reply
* [PATCH RFC net-next 00/10] net: stmmac: clean up / fix synopsys IP version checks
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-stm32,
linux-sunxi, netdev, Paolo Abeni, Samuel Holland,
Jitendra Vegiraju
Oh lookie, another relatively large stmmac patch series as a result of
reviewing Jitendra Vegiraju's patch series! Yay! :(
This series cleans up and in some cases fixes the Synopsys IP version
checks, which is a per-core numberspace.
For example, for dwmac1000 and dwmac4, we have versions such as v3.4 to
up v5.2, which are represented by two BCD digits. For XGMAC, we have
versions v2.1 and v2.2 represented by 0x21 and 0x22 respectively. For
XLGMAC, we have v2.0, which is 0x20.
Note that hwif.c supports GMAC4 core type with the IP version in the
range 0..0x40, which overlaps with the GMAC core type.
Thus, testing the Synopsys IP version for <= v4.0 will match dwmac1000,
potentially some dwmac4, and all xgmac and xlgmac cores. In some cases,
the latter two are provably incorrect.
The Synopsys IP version is named "synopsys_id" in the driver - as
stated, it is the Synopsys IP version, and the register field is called
snpsver. Use this name throughout the driver to avoid confusion. Also,
dev_id seems to actually be userver.
The first decision making change is for dche, which is only looked at
by the dwmac4 DMA code which requires core_type == DWMAC_CORE_GMAC4.
Thus, it makes no sense to merely look at the IP version. Since setting
this to true makes no sense for non-GMAC4 cores, force it to false for
non-DWMAC_CORE_GMAC4 cores.
The MAC .debug() method is only populated by the dwmac1000 and dwmac4
cores, yet the test checks only for the IP version >= v3.5. While this
works today, it may not work in the future given the different version
numberspaces. Make this conditional on DWMAC_CORE_GMAC or GMAC4 core
types to limit the version check. Ideally, it would be better to
move the version check inside the .dwbug() method implementation, but
that would require the method signature to change.
As getting to that point involved quite a bit of research, add comments
into stmmac_get_ethtool_stats() so others don't have to re-analyse the
code.
Clean up the resulting code in stmmac_get_ethtool_stats() given the
complexity, adding documentation for each test.
Address the rx_coe handling, which checks for IP version >= v4.0 or
the XGMAC core type. However, the members being printed are only
present in the GMAC4 and XGMAC core type in one path, and GMAC in
the other. There is an odd-ball which is sun8i, but we preserve its
current behaviour. Also, given the research, add documentation in
appropriate places. Note that priv->plat->rx_coe (and also
priv->hw->rx_csum) has different value spaces depending on the core
type - which is not nice.
Lastly, make the printing of the COE type, which as identified above,
depend on the GMAC core type.
This leaves four locations unaddressed:
1) PTP filter code:
case HWTSTAMP_FILTER_PTP_V2_EVENT:
/* PTP v2/802.AS1 any layer, any kind of event packet */
config->rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
if (priv->snpsver < DWMAC_CORE_4_10)
ts_event_en = PTP_TCR_TSEVNTENA;
I don't yet have an answer for this one, but it does mean that
PTP_TCR_TSEVNTENA will be set for XGMAC cores for
HWTSTAMP_FILTER_PTP_V2_EVENT... if they have PTP support.
2) riwt watchdog:
/* Rx Watchdog is available in the COREs newer than the 3.40.
* In some case, for example on bugged HW this feature
* has to be disable and this can be done by passing the
* riwt_off field from the platform.
*/
if ((priv->snpsver >= DWMAC_CORE_3_50 ||
priv->plat->core_type == DWMAC_CORE_XGMAC) &&
!priv->plat->riwt_off) {
priv->use_riwt = 1;
This to me looks like the version check is only really applicable for
the DWMAC_CORE_GMAC core type. So, I'm thinking that:
if (priv->plat->core_type >= DWMAC_CORE_GMAC4 ||
(priv->plat->core_type == DWMAC_CORE_GMAC &&
priv->snpsver >= DWMAC_CORE_3_50)) {
if (!priv->plat->rwit_off) {
...
would be clearer (note the splitting of the if() conditions which seems
to me would be more readable than trying to munge it all into one
expression.)
3) max_mtu setup:
/* Set the maximum MTU.
* For XGMAC cores, 16KiB.
* For cores using enhanced descriptors or GMAC cores >= v4.00, 9kB.
* For everything else, PAGE_SIZE - NET_SKB_PAD - NET_IP_ALIGN -
* aligned skb_shared_info.
*/
if (priv->plat->core_type == DWMAC_CORE_XGMAC)
ndev->max_mtu = XGMAC_JUMBO_LEN;
else if (priv->plat->enh_desc || priv->snpsver >= DWMAC_CORE_4_00)
ndev->max_mtu = JUMBO_LEN;
else
ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
which I've previously identified is very buggy, and I'm not sure what
the real tests here should be. I'm quite certain that the max_mtu
values are basically completely wrong, especially in the last case.
This needs a lot of analysis and comparing with documentation to get
to the bottom of what the tests and resulting max_mtu values should
actually be.
.../net/ethernet/stmicro/stmmac/dwmac-loongson.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/hwif.c | 54 +++++++++++-----------
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 51 +++++++++++---------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 24 ++++++----
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 ++--
include/linux/stmmac.h | 7 +++
9 files changed, 85 insertions(+), 67 deletions(-)
--
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
* [PATCH RFC net-next 01/10] net: stmmac: rename min_id to min_snpsver
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
min_id is the minimum Synopsys IP version that the hwif entry will
match. Name it min_snpsver so that it's clear which part of the
version ID it is related to.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 511b0fd5e834..3774af66db48 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -110,7 +110,7 @@ int stmmac_reset(struct stmmac_priv *priv)
static const struct stmmac_hwif_entry {
enum dwmac_core_type core_type;
- u32 min_id;
+ u32 min_snpsver;
u32 dev_id;
const struct stmmac_regs_off regs;
const void *desc;
@@ -129,7 +129,7 @@ static const struct stmmac_hwif_entry {
/* NOTE: New HW versions shall go to the end of this table */
{
.core_type = DWMAC_CORE_MAC100,
- .min_id = 0,
+ .min_snpsver = 0,
.regs = {
.ptp_off = PTP_GMAC3_X_OFFSET,
.mmc_off = MMC_GMAC3_X_OFFSET,
@@ -146,7 +146,7 @@ static const struct stmmac_hwif_entry {
.quirks = stmmac_dwmac1_quirks,
}, {
.core_type = DWMAC_CORE_GMAC,
- .min_id = 0,
+ .min_snpsver = 0,
.regs = {
.ptp_off = PTP_GMAC3_X_OFFSET,
.mmc_off = MMC_GMAC3_X_OFFSET,
@@ -163,7 +163,7 @@ static const struct stmmac_hwif_entry {
.quirks = stmmac_dwmac1_quirks,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = 0,
+ .min_snpsver = 0,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -183,7 +183,7 @@ static const struct stmmac_hwif_entry {
.quirks = stmmac_dwmac4_quirks,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = DWMAC_CORE_4_00,
+ .min_snpsver = DWMAC_CORE_4_00,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -204,7 +204,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = DWMAC_CORE_4_10,
+ .min_snpsver = DWMAC_CORE_4_10,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -225,7 +225,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_GMAC4,
- .min_id = DWMAC_CORE_5_10,
+ .min_snpsver = DWMAC_CORE_5_10,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
.mmc_off = MMC_GMAC4_OFFSET,
@@ -246,7 +246,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_XGMAC,
- .min_id = DWXGMAC_CORE_2_10,
+ .min_snpsver = DWXGMAC_CORE_2_10,
.dev_id = DWXGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
@@ -268,7 +268,7 @@ static const struct stmmac_hwif_entry {
.quirks = NULL,
}, {
.core_type = DWMAC_CORE_XGMAC,
- .min_id = DWXLGMAC_CORE_2_00,
+ .min_snpsver = DWXLGMAC_CORE_2_00,
.dev_id = DWXLGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
@@ -302,7 +302,7 @@ stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
if (core_type != entry->core_type)
continue;
/* Use synopsys_id var because some setups can override this */
- if (snpsver < entry->min_id)
+ if (snpsver < entry->min_snpsver)
continue;
if (core_type == DWMAC_CORE_XGMAC &&
dev_id != entry->dev_id)
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 02/10] net: stmmac: rename dev_id to userver
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
The Synopsys Databook and several implementation TRMs identify bits
15:8 of the version register in dwmac v3.xx and v4.xx as "userver".
We even print its value with "User ID". Rather than using "dev_id",
use "userver" instead.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 3774af66db48..830ff816ab4f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -15,7 +15,7 @@
struct stmmac_version {
u8 snpsver;
- u8 dev_id;
+ u8 userver;
};
static void stmmac_get_version(struct stmmac_priv *priv,
@@ -26,7 +26,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
u32 version;
ver->snpsver = 0;
- ver->dev_id = 0;
+ ver->userver = 0;
if (core_type == DWMAC_CORE_MAC100)
return;
@@ -48,7 +48,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
ver->snpsver = FIELD_GET(DWMAC_SNPSVER, version);
if (core_type == DWMAC_CORE_XGMAC)
- ver->dev_id = FIELD_GET(DWMAC_USERVER, version);
+ ver->userver = FIELD_GET(DWMAC_USERVER, version);
}
static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
@@ -111,7 +111,7 @@ int stmmac_reset(struct stmmac_priv *priv)
static const struct stmmac_hwif_entry {
enum dwmac_core_type core_type;
u32 min_snpsver;
- u32 dev_id;
+ u32 userver;
const struct stmmac_regs_off regs;
const void *desc;
const void *dma;
@@ -247,7 +247,7 @@ static const struct stmmac_hwif_entry {
}, {
.core_type = DWMAC_CORE_XGMAC,
.min_snpsver = DWXGMAC_CORE_2_10,
- .dev_id = DWXGMAC_ID,
+ .userver = DWXGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
.mmc_off = MMC_XGMAC_OFFSET,
@@ -269,7 +269,7 @@ static const struct stmmac_hwif_entry {
}, {
.core_type = DWMAC_CORE_XGMAC,
.min_snpsver = DWXLGMAC_CORE_2_00,
- .dev_id = DWXLGMAC_ID,
+ .userver = DWXLGMAC_ID,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
.mmc_off = MMC_XGMAC_OFFSET,
@@ -291,7 +291,7 @@ static const struct stmmac_hwif_entry {
};
static const struct stmmac_hwif_entry *
-stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
+stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 userver)
{
const struct stmmac_hwif_entry *entry;
int i;
@@ -305,7 +305,7 @@ stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
if (snpsver < entry->min_snpsver)
continue;
if (core_type == DWMAC_CORE_XGMAC &&
- dev_id != entry->dev_id)
+ userver != entry->userver)
continue;
return entry;
@@ -358,7 +358,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
/* Fallback to generic HW */
/* Use synopsys_id var because some setups can override this */
- entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.dev_id);
+ entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.userver);
if (!entry) {
dev_err(priv->device,
"Failed to find HW IF (id=0x%x, gmac=%d/%d)\n",
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 03/10] net: stmmac: always fill in ver->userver
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
Always fill in ver->userver irrespective of the core type. This has no
functional impact but tidies up the code by removing an unnecessary
conditional.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 830ff816ab4f..aacf78d4a2ee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -47,8 +47,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
FIELD_GET(DWMAC_SNPSVER, version));
ver->snpsver = FIELD_GET(DWMAC_SNPSVER, version);
- if (core_type == DWMAC_CORE_XGMAC)
- ver->userver = FIELD_GET(DWMAC_USERVER, version);
+ ver->userver = FIELD_GET(DWMAC_USERVER, version);
}
static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 04/10] net: stmmac: use ver->userver and ver->snpsver to print version
From: Russell King (Oracle) @ 2026-04-08 9:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
Rather than using FIELD_GET() twice, reorder the code to extract the
version fields into struct stmmac_version, and then print them.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index aacf78d4a2ee..7f95a2a5be4c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -42,12 +42,11 @@ static void stmmac_get_version(struct stmmac_priv *priv,
return;
}
- dev_info(priv->device, "User ID: 0x%x, Synopsys ID: 0x%x\n",
- FIELD_GET(DWMAC_USERVER, version),
- FIELD_GET(DWMAC_SNPSVER, version));
-
ver->snpsver = FIELD_GET(DWMAC_SNPSVER, version);
ver->userver = FIELD_GET(DWMAC_USERVER, version);
+
+ dev_info(priv->device, "User ID: 0x%x, Synopsys ID: 0x%x\n",
+ ver->userver, ver->snpsver);
}
static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 05/10] net: stmmac: rename confusing synopsys_id
From: Russell King (Oracle) @ 2026-04-08 9:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
priv->synopsys_id is the Synopsys IP version, defined by snpsver in
the databook. This is made up of the major version in bits 7:4 and
the first digit of the minor version in bits 3:0. Change the type
for synopsys_id to be a u8 and rename to snpsver.
For reference, the values for snpsver:
GMAC100 cores do not have a readable snpsver number.
GMAC cores generally have a snpsver number less than 0x40.
GMAC4 cores may have a version number that overlaps GMAC cores
(see first entry for DWMAC_CORE_GMAC4).
XGMAC and XLGMAC cores each have an entirely separate IP version
number space from GMAC and GMAC4, which are distinguished by their
respective userver.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/hwif.c | 10 +++++-----
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 ++++++------
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 8 ++++----
8 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index eb14c197d6ae..789b384a2838 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -326,7 +326,7 @@ static int loongson_dwmac_setup(void *apriv, struct mac_device_info *mac)
* original value so the correct HW-interface would be selected.
*/
if (ld->multichan) {
- priv->synopsys_id = DWMAC_CORE_3_70;
+ priv->snpsver = DWMAC_CORE_3_70;
*dma = dwmac1000_dma_ops;
dma->init_chan = loongson_dwmac_dma_init_channel;
dma->dma_interrupt = loongson_dwmac_dma_interrupt;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 48c52eb96233..4bff7592c652 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1069,7 +1069,7 @@ static int sun8i_dwmac_setup(void *ppriv, struct mac_device_info *mac)
mac->unicast_filter_entries = 8;
/* Synopsys Id is not available */
- priv->synopsys_id = 0;
+ priv->snpsver = 0;
return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 03437f1cf3df..635d711a554e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -380,7 +380,7 @@ static int dwxgmac2_get_hw_feature(void __iomem *ioaddr,
dma_cap->vlhash = (hw_cap & XGMAC_HWFEAT_VLHASH) >> 4;
dma_cap->half_duplex = (hw_cap & XGMAC_HWFEAT_HDSEL) >> 3;
dma_cap->mbps_1000 = (hw_cap & XGMAC_HWFEAT_GMIISEL) >> 1;
- if (dma_cap->mbps_1000 && priv->synopsys_id >= DWXGMAC_CORE_2_20)
+ if (dma_cap->mbps_1000 && priv->snpsver >= DWXGMAC_CORE_2_20)
dma_cap->mbps_10_100 = 1;
/* MAC HW feature 1 */
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 7f95a2a5be4c..e5629afc391f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -72,7 +72,7 @@ static int stmmac_dwmac1_quirks(struct stmmac_priv *priv)
dev_info(priv->device, "Enhanced/Alternate descriptors\n");
/* GMAC older than 3.50 has no extended descriptors */
- if (priv->synopsys_id >= DWMAC_CORE_3_50) {
+ if (priv->snpsver >= DWMAC_CORE_3_50) {
dev_info(priv->device, "Enabled extended descriptors\n");
priv->extend_desc = true;
} else {
@@ -299,7 +299,7 @@ stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 userver)
if (core_type != entry->core_type)
continue;
- /* Use synopsys_id var because some setups can override this */
+ /* Use snpsver var because some setups can override this */
if (snpsver < entry->min_snpsver)
continue;
if (core_type == DWMAC_CORE_XGMAC &&
@@ -324,7 +324,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
stmmac_get_version(priv, &version);
/* Save ID for later use */
- priv->synopsys_id = version.snpsver;
+ priv->snpsver = version.snpsver;
/* Lets assume some safe values first */
if (core_type == DWMAC_CORE_GMAC4) {
@@ -355,8 +355,8 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
/* Fallback to generic HW */
- /* Use synopsys_id var because some setups can override this */
- entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.userver);
+ /* Use snpsver var because some setups can override this */
+ entry = stmmac_hwif_find(core_type, priv->snpsver, version.userver);
if (!entry) {
dev_err(priv->device,
"Failed to find HW IF (id=0x%x, gmac=%d/%d)\n",
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 8ba8f03e1ce0..9a5d9c404e4f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -304,7 +304,7 @@ struct stmmac_priv {
struct dma_features dma_cap;
struct stmmac_counters mmc;
int hw_cap_support;
- int synopsys_id;
+ u8 snpsver;
u32 msg_enable;
/* Our MAC Wake-on-Lan options */
int wolopts;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 92585d27ab88..343cf903c0bf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -553,7 +553,7 @@ static void stmmac_get_ethtool_stats(struct net_device *dev,
priv->xstats.phy_eee_wakeup_error_n = val;
}
- if (priv->synopsys_id >= DWMAC_CORE_3_50)
+ if (priv->snpsver >= DWMAC_CORE_3_50)
stmmac_mac_debug(priv, priv->ioaddr,
(void *)&priv->xstats,
rx_queues_count, tx_queues_count);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 01a983001ab4..295d31d7b28b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -755,7 +755,7 @@ static int stmmac_hwtstamp_set(struct net_device *dev,
config->rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
- if (priv->synopsys_id < DWMAC_CORE_4_10)
+ if (priv->snpsver < DWMAC_CORE_4_10)
ts_event_en = PTP_TCR_TSEVNTENA;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -6624,7 +6624,7 @@ static int stmmac_dma_cap_show(struct seq_file *seq, void *v)
seq_printf(seq, "\tAV features: %s\n", (priv->dma_cap.av) ? "Y" : "N");
seq_printf(seq, "\tChecksum Offload in TX: %s\n",
(priv->dma_cap.tx_coe) ? "Y" : "N");
- if (priv->synopsys_id >= DWMAC_CORE_4_00 ||
+ if (priv->snpsver >= DWMAC_CORE_4_00 ||
priv->plat->core_type == DWMAC_CORE_XGMAC) {
seq_printf(seq, "\tIP Checksum Offload in RX: %s\n",
(priv->dma_cap.rx_coe) ? "Y" : "N");
@@ -7454,7 +7454,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
if (priv->plat->rx_coe) {
priv->hw->rx_csum = priv->plat->rx_coe;
dev_info(priv->device, "RX Checksum Offload Engine supported\n");
- if (priv->synopsys_id < DWMAC_CORE_4_00)
+ if (priv->snpsver < DWMAC_CORE_4_00)
dev_info(priv->device, "COE Type %d\n", priv->hw->rx_csum);
}
if (priv->plat->tx_coe)
@@ -7520,7 +7520,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
* has to be disable and this can be done by passing the
* riwt_off field from the platform.
*/
- if ((priv->synopsys_id >= DWMAC_CORE_3_50 ||
+ if ((priv->snpsver >= DWMAC_CORE_3_50 ||
priv->plat->core_type == DWMAC_CORE_XGMAC) &&
!priv->plat->riwt_off) {
priv->use_riwt = 1;
@@ -7897,7 +7897,7 @@ static int __stmmac_dvr_probe(struct device *device,
/* Only DWMAC core version 5.20 onwards supports HW descriptor prefetch.
*/
- if (priv->synopsys_id < DWMAC_CORE_5_20)
+ if (priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
stmmac_check_ether_addr(priv);
@@ -7997,7 +7997,7 @@ static int __stmmac_dvr_probe(struct device *device,
if (priv->plat->core_type == DWMAC_CORE_XGMAC)
ndev->max_mtu = XGMAC_JUMBO_LEN;
- else if (priv->plat->enh_desc || priv->synopsys_id >= DWMAC_CORE_4_00)
+ else if (priv->plat->enh_desc || priv->snpsver >= DWMAC_CORE_4_00)
ndev->max_mtu = JUMBO_LEN;
else
ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index afe98ff5bdcb..0107119f68d2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -74,7 +74,7 @@ static void stmmac_xgmac2_c22_format(struct stmmac_priv *priv, int phyaddr,
{
u32 tmp = 0;
- if (priv->synopsys_id < DWXGMAC_CORE_2_20) {
+ if (priv->snpsver < DWXGMAC_CORE_2_20) {
/* Until ver 2.20 XGMAC does not support C22 addr >= 4. Those
* bits above bit 3 of XGMAC_MDIO_C22P register are reserved.
*/
@@ -136,7 +136,7 @@ static int stmmac_xgmac2_mdio_read_c22(struct mii_bus *bus, int phyaddr,
u32 addr;
/* Until ver 2.20 XGMAC does not support C22 addr >= 4 */
- if (priv->synopsys_id < DWXGMAC_CORE_2_20 &&
+ if (priv->snpsver < DWXGMAC_CORE_2_20 &&
phyaddr > MII_XGMAC_MAX_C22ADDR)
return -ENODEV;
@@ -199,7 +199,7 @@ static int stmmac_xgmac2_mdio_write_c22(struct mii_bus *bus, int phyaddr,
u32 addr;
/* Until ver 2.20 XGMAC does not support C22 addr >= 4 */
- if (priv->synopsys_id < DWXGMAC_CORE_2_20 &&
+ if (priv->snpsver < DWXGMAC_CORE_2_20 &&
phyaddr > MII_XGMAC_MAX_C22ADDR)
return -ENODEV;
@@ -625,7 +625,7 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->read_c45 = &stmmac_xgmac2_mdio_read_c45;
new_bus->write_c45 = &stmmac_xgmac2_mdio_write_c45;
- if (priv->synopsys_id < DWXGMAC_CORE_2_20) {
+ if (priv->snpsver < DWXGMAC_CORE_2_20) {
/* Right now only C22 phys are supported */
max_addr = MII_XGMAC_MAX_C22ADDR;
--
2.47.3
^ permalink raw reply related
* [PATCH RFC net-next 06/10] net: stmmac: dche is only for GMAC4 cores
From: Russell King (Oracle) @ 2026-04-08 9:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai, David S. Miller,
Eric Dumazet, Jakub Kicinski, Jitendra Vegiraju, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <adYfPBHsXxQUsMyr@shell.armlinux.org.uk>
dma_cfg->dche is only read by dwmac4_dma_init(), which is only called
for the DWMAC_CORE_GMAC4 core type. Rather than having a bare IP
version check that can match any core type, make this conditional on
DWMAC_CORE_GMAC4 to make it clear that it's a GMAC4 feature.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 295d31d7b28b..e47321119c83 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7895,9 +7895,10 @@ static int __stmmac_dvr_probe(struct device *device,
if (ret)
goto error_hw_init;
- /* Only DWMAC core version 5.20 onwards supports HW descriptor prefetch.
+ /* Only DWMAC4 core version 5.20 onwards support HW descriptor prefetch.
*/
- if (priv->snpsver < DWMAC_CORE_5_20)
+ if (priv->plat->core_type != DWMAC_CORE_GMAC4 ||
+ priv->snpsver < DWMAC_CORE_5_20)
priv->plat->dma_cfg->dche = false;
stmmac_check_ether_addr(priv);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH ipsec] xfrm: fix refcount leak in xfrm_migrate_policy_find
From: Steffen Klassert @ 2026-04-08 9:29 UTC (permalink / raw)
To: Kotlyarov Mihail
Cc: netdev, lvc-project, herbert, davem, edumazet, kuba, pabeni,
horms, fw, linux-kernel
In-Reply-To: <20260404090525.105083-1-mihailkotlyarow@gmail.com>
On Sat, Apr 04, 2026 at 12:05:20PM +0300, Kotlyarov Mihail wrote:
> syzkaller reported a memory leak in xfrm_policy_alloc:
>
> BUG: memory leak
> unreferenced object 0xffff888114d79000 (size 1024):
> comm "syz.1.17", pid 931
> ...
> xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432
>
> The root cause is a double call to xfrm_pol_hold_rcu() in
> xfrm_migrate_policy_find(). The lookup function already returns
> a policy with held reference, making the second call redundant.
>
> Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount
> imbalance and prevent the memory leak.
>
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
>
> Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype")
> Signed-off-by: Kotlyarov Mihail <mihailkotlyarow@gmail.com>
Applied, thanks a lot!
^ permalink raw reply
* Re: [PATCH net] xfrm_user: fix info leak in build_mapping()
From: Steffen Klassert @ 2026-04-08 9:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Greg Kroah-Hartman, netdev, linux-kernel, Herbert Xu,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman
In-Reply-To: <20260407181211.5419f2cc@kernel.org>
On Tue, Apr 07, 2026 at 06:12:11PM -0700, Jakub Kicinski wrote:
> On Tue, 7 Apr 2026 07:51:15 +0200 Greg Kroah-Hartman wrote:
> > > > I guess nlmsg_append() would work? It tries to do some zeroing out for
> > > > alignment for some reason...
> > > >
> > > > Want me to do that? I don't have a way to test any of this, I just
> > > > found it using some static code analysis tools that looked at holes in
> > > > structures.
> > >
> > > Do you have any more Netlink leaks in the queue? If you do let's do it,
> > > if you don't we can wait until the next victi^w patch to arrive.
> >
> > I do not have any more, sorry. So is it worth it for just these 2?
> > Your call :)
>
> These are fine. I would have applied but I think Steffen will take them
> via the ipsec tree first (LMK if that's not the plan, Steffen)
Both patches are now applied to the ipsec tree. Thanks a lot!
^ 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