* [PATCH iwl-net] ice: fix NULL pointer dereference in ice_reset_all_vfs()
From: Petr Oros @ 2026-04-01 11:09 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Brett Creeley, intel-wired-lan, linux-kernel
ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi().
When the VSI rebuild fails (e.g. during NVM firmware update via
nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path,
leaving txq_map and rxq_map as NULL. The subsequent unconditional call
to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in
ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0].
The single-VF reset path in ice_reset_vf() already handles this
correctly by checking the return value of ice_vf_reconfig_vsi() and
skipping ice_vf_post_vsi_rebuild() on failure.
Apply the same pattern to ice_reset_all_vfs(): check the return value
of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and
ice_eswitch_attach_vf() on failure. The VF is left safely disabled
(ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can
be recovered via a VFLR triggered by a PCI reset of the VF
(sysfs reset or driver rebind).
Note that this patch does not prevent the VF VSI rebuild from failing
during NVM update — the underlying cause is firmware being in a
transitional state while the EMP reset is processed, which can cause
Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This
patch only prevents the subsequent NULL pointer dereference that
crashes the kernel when the rebuild does fail.
crash> bt
PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5"
#0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee
#1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba
#2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540
#3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda
#4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997
#5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595
#6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2
[exception RIP: ice_ena_vf_q_mappings+0x79]
RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206
RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000
RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040
R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000
R13: 0000000000000010 R14: R15:
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice]
#8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice]
#9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice]
#10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4
#11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de
#12 [ff72159bcfe5bf18] kthread at ffffffffaa946663
#13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9
The panic occurs attempting to dereference the NULL pointer in RDX at
ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi).
The faulting VSI is an allocated slab object but not fully initialized
after a failed ice_vsi_rebuild():
crash> struct ice_vsi 0xff34c9efc27d4828
netdev = 0x0,
rx_rings = 0x0,
tx_rings = 0x0,
q_vectors = 0x0,
txq_map = 0x0,
rxq_map = 0x0,
alloc_txq = 0x10,
num_txq = 0x10,
alloc_rxq = 0x10,
num_rxq = 0x10,
The nvmupdate64e process was performing NVM firmware update:
crash> bt 0xff34c9edd1a30000
PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e"
#0 [ff72159bcd617618] __schedule at ffffffffab5333f8
#4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice]
#5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice]
#6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice]
#7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice]
#8 [ff72159bcd6178b8] ice_read_flat_nvm at ffffffffc0a4034c [ice]
#9 [ff72159bcd617918] ice_devlink_nvm_snapshot at ffffffffc0a6ffa5 [ice]
dmesg:
ice 0000:13:00.0: firmware recommends not updating fw.mgmt, as it
may result in a downgrade. continuing anyways
ice 0000:13:00.1: ice_init_nvm failed -5
ice 0000:13:00.1: Rebuild failed, unload and reload driver
Fixes: 12bb018c538c ("ice: Refactor VF reset")
Signed-off-by: Petr Oros <poros@redhat.com>
---
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index c8bc952f05cdb5..51259a4fdda4b9 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -804,7 +804,12 @@ void ice_reset_all_vfs(struct ice_pf *pf)
ice_vf_ctrl_invalidate_vsi(vf);
ice_vf_pre_vsi_rebuild(vf);
- ice_vf_rebuild_vsi(vf);
+ if (ice_vf_rebuild_vsi(vf)) {
+ dev_err(dev, "VF %u VSI rebuild failed, leaving VF disabled\n",
+ vf->vf_id);
+ mutex_unlock(&vf->cfg_lock);
+ continue;
+ }
ice_vf_post_vsi_rebuild(vf);
ice_eswitch_attach_vf(pf, vf);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 1/1] net: phy: realtek: Add support for PHY LEDs on RTL8221B
From: Nicolai Buchwitz @ 2026-04-01 11:13 UTC (permalink / raw)
To: Chukun Pan
Cc: David S . Miller, Andrew Lunn, Paolo Abeni, Jakub Kicinski,
Eric Dumazet, Russell King, Daniel Golle, Heiner Kallweit,
linux-kernel, netdev
In-Reply-To: <20260401100010.3079700-1-amadeus@jmu.edu.cn>
On 1.4.2026 12:00, Chukun Pan wrote:
> Realtek RTL8221B Ethernet PHY supports three LED pins which are used to
> indicate link status and activity. Add netdev trigger support for them.
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> drivers/net/phy/realtek/realtek_main.c | 146 +++++++++++++++++++++++++
> 1 file changed, 146 insertions(+)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c
> b/drivers/net/phy/realtek/realtek_main.c
> index 023e47ad605b..8a22e18e5c56 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -150,6 +150,15 @@
>
[...]
>
> +static int rtl822xb_led_brightness_set(struct phy_device *phydev, u8
> index,
> + enum led_brightness value)
> +{
> + int ret;
> +
> + if (index >= RTL8211x_LED_COUNT)
> + return -EINVAL;
> +
> + /* clear HW LED setup */
> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2,
> + RTL822X_VND2_LED(index), 0);
> + if (ret < 0)
> + return ret;
> +
> + /* clear HW LED blink */
> + return phy_clear_bits_mmd(phydev, MDIO_MMD_VEND2,
> + RTL822X_VND2_LCR6,
> + RTL822X_VND2_LED_ACT(index));
> +}
This clears HW triggers but never actually turns the LED on when
value != LED_OFF. Both paths do the same thing: clear link and
activity config (value isn't used at all).
For LED_OFF that works (no triggers = LED off), but for LED_ON the
LED stays off too since there's no force-on written anywhere.
Compare with bcm_phy_led_brightness_set() which explicitly switches
between BCM_LED_SRC_ON and BCM_LED_SRC_OFF based on value.
If the RTL8221B has a software force-on register, it needs to be
programmed here. If it doesn't, brightness_set should not be
implemented at all. The framework handles its absence.
[...]
Thanks
Nicolai
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac support
From: Dmitry Baryshkov @ 2026-04-01 11:36 UTC (permalink / raw)
To: Umang Chheda
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel, netdev
In-Reply-To: <20260401-monaco-evk-ac-sku-v2-1-27b5f702cfba@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 12:14:42AM +0530, Umang Chheda wrote:
> Introduce bindings for the monaco-evk-ac IoT board, which is
> based on the monaco-ac (QCS8300-AC) SoC variant.
If it is a different SoC SKU, should it be reflected in the SoC compat
strings?
>
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index ca880c105f3b..c76365a89687 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -918,6 +918,7 @@ properties:
> - enum:
> - arduino,monza
> - qcom,monaco-evk
> + - qcom,monaco-evk-ac
> - qcom,qcs8300-ride
> - const: qcom,qcs8300
>
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ 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-01 11:46 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195629.2789129-1-kuba@kernel.org>
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.
> [ ... ]
> > +void lan9645x_npi_port_init(struct lan9645x *lan9645x,
> > + struct dsa_port *cpu_port)
> > +{
> > + int port = cpu_port->index;
> > + struct lan9645x_port *p;
> > +
> > + p = lan9645x_to_port(lan9645x, port);
> > + lan9645x->npi = port;
>
> In a cascaded multi-switch DSA topology, cpu_port->index may belong to a
> different switch and be greater than 8. If lan9645x_to_port returns NULL,
> will this cause a panic when dereferencing p->chip_port below?
>
> [ ... ]
> > + /* 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.
> 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.
> [ ... ]
> > + /* 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.
> [ ... ]
> > + /* 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.
> diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c
> --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c
> +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_phylink.c
> [ ... ]
> > +static int lan9645x_phylink_mac_prepare(struct phylink_config *config,
> > + unsigned int mode,
> > + phy_interface_t iface)
> > +{
> > + struct lan9645x_port *p = lan9645x_phylink_config_to_port(config);
> > + struct lan9645x *lan9645x = p->lan9645x;
> > + int port = p->chip_port;
> > + u32 mask;
> > +
> > + if (port == 5 || port == 6 || port > 8)
> > + return -EINVAL;
> > +
> > + mask = HSIO_HW_CFG_GMII_ENA_SET(BIT(port));
> > + lan_rmw(mask, mask, lan9645x, HSIO_HW_CFG);
> > +
> > + if (port == 4 && phy_interface_mode_is_rgmii(iface))
> > + lan_rmw(HSIO_HW_CFG_RGMII_0_CFG_SET(1),
> > + HSIO_HW_CFG_RGMII_0_CFG,
> > + lan9645x, HSIO_HW_CFG);
>
> The lan9645x_phylink_get_caps function advertises RGMII support for ports
> 4, 7, and 8. Does restricting the hardware multiplexer configuration here to
> port 4 break connectivity for ports 7 and 8 when used in RGMII mode?
>
Yes. The multiplexing controls which port module RGMII0 should use. It is either port 4 or
port 7. So you can not use RGMII on both port 4 and 7 at the same time.
In theory you could use port 8, but the intended use for this is when QSGMII is enabled. This
will always use port modules 5-8. The multiplexing makes it possible to still use
1 RGMII port in this case.
> diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c
> --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c
> +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_port.c
> [ ... ]
> > +int lan9645x_port_set_maxlen(struct lan9645x *lan9645x, int port, size_t sdu)
> > +{
> > + struct lan9645x_port *p = lan9645x_to_port(lan9645x, port);
> > + int maxlen = sdu + ETH_HLEN + ETH_FCS_LEN;
>
> Does this maximum frame length calculation drop standard 1500-byte MTU
> frames that are 802.1Q VLAN tagged (1522 bytes total), since it does not
> account for VLAN_HLEN?
>
I was about to say that the VLAN overhead is managed seperately via the DEV_MAC_TAGS_CFG
register.
However, after testing I see there is a bug here. We only configure DEV_MAC_TAGS_CFG
for vlan aware ports. This is a problem in the vlan unaware case.
Furthermore, the NPI port does not get this configuration. I will move the
DEV_MAC_TAGS_CFG configuration to port_setup, so we always allow 2x VLAN tags overhead
in both vlan aware and unaware mode, and towards the CPU.
> [ ... ]
> > +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.
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: macb: Consolidate MACB_CAPS_ISR_CLEAR_ON_WRITE checks in IRQ handler
From: Nicolai Buchwitz @ 2026-04-01 11:49 UTC (permalink / raw)
To: Kevin Hao
Cc: Jakub Kicinski, Nicolas Ferre, Claudiu Beznea, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, netdev
In-Reply-To: <aczly5AD_PkYv6mJ@pek-khao-d3>
On 1.4.2026 11:30, Kevin Hao wrote:
>> On Sat, 28 Mar 2026 18:17:46 +0800 Kevin Hao wrote:
> On Tue, Mar 31, 2026 at 07:54:00PM -0700, Jakub Kicinski wrote:
>> > Currently, the MACB_CAPS_ISR_CLEAR_ON_WRITE flag is checked in every
>> > branch of the IRQ handler. This repeated evaluation is unnecessary.
>> > By consolidating the flag check, we eliminate redundant loads of
>> > bp->caps when TX and RX events occur simultaneously, a common scenario
>> > under high network throughput. Additionally, this optimization reduces
>> > the function size from 0x2e8 to 0x2c4.
>>
>> feels a bit subjective TBH. An alternative improvement would be to
>> factor out the conditional to a helper:
>>
>> static void macb_queue_isr_clear(bp, queue, mask)
>> {
>> if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>> queue_writel(queue, ISR, mask);
>> }
>
> In addition to the similar pattern in the macb_interrupt() function,
> there are
> seven other instances of this pattern in the macb driver.
> $ git grep "if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)"
> drivers/net/ethernet/cadence/ | wc -l
> 7
>
> I agree that using a helper function, as you proposed, would reduce the
> number
> of source code lines and improve the readability of the driver.
> However, such
> changes would not affect the final generated code.
>
> The goal of my changes is to reduce both the footprint of
> macb_interrupt() and
> the number of assembly instructions executed within its event loop.
>
> Before the patch, the condition `if (bp->caps &
> MACB_CAPS_ISR_CLEAR_ON_WRITE)`
> produced the following assembly:
> ffff800080d58b1c: 387b6a68 ldrb w8, [x19, x27]
> ffff800080d58b20: 360000c8 tbz w8, #0,
> ffff800080d58b38 <macb_interrupt+0xd0>
>
> After the patch, the condition `if (isr_clear)` results in:
> ffff800080d58a4c: 360000d8 tbz w24, #0,
> ffff800080d58a64 <macb_interrupt+0xac>
>
> Thus, we eliminate two `ldrb` overheads per iteration of the event loop
> in
> macb_interrupt() when both TX and RX events occur simultaneously. This
> also
> reduces the function's footprint by 36 bytes, as the `ldrb`
> instructions are
> omitted in each event branch.
>
> Therefore, your proposed changes and mine serve different purposes.
> I acknowledge that my change represents only a very slight optimization
> for
> the interrupt handler. I am also open to your preference for improving
> source
> code readability. Please let me know your decision.
I'm always a fan of optimizations, but I guess in this case the
saved ldrb is negligible next to the MMIO in the same path. We're
talking a single L1 cache hit (~1ns) vs an uncacheable register
write (~100ns+). Patch 3 also re-reads bp->caps in
macb_interrupt_misc() anyway, undoing the local bool for the misc
path.
I'd ack Jakub's helper approach. A macb_queue_isr_clear() would
be consistent across all callsites, including the 7 other
instances you counted outside macb_interrupt().
> Thanks,
> Kevin
Nicolai
^ permalink raw reply
* [PATCH net-next] net: phy: bcm84881: add LED framework support for BCM84891/BCM84892
From: Daniel Wagner @ 2026-04-01 11:49 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, bcm-kernel-feedback-list, Andrew Lunn,
Heiner Kallweit, Russell King, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Daniel Wagner
Expose LED1 and LED2 pins via the PHY LED framework. Each pin has a
source mask (MASK_LOW + MASK_EXT registers) selecting which hardware
events light it, plus a CTL field in the shared 0xA83B register
(RMW; LED4 is firmware-controlled per the datasheet).
Hardware can offload per-speed link triggers (1000/2500/5000/10000),
RX/TX activity, and force-on. LINK_100 is accepted only alongside
LINK_1000: source bit 4 lights at both speeds and 100-alone isn't
representable, so the unrepresentable case falls to software.
The chip has five LED pins; only LED1/LED2 are exposed here as those
are the only ones characterized on tested hardware. LED4 is firmware-
controlled regardless of strap configuration.
Tested on TRENDnet TEG-S750 (LED1/LED2 wired to an antiparallel
bicolor LED): brightness_set via sysfs; netdev trigger offloaded=1
with amber lit at 100M/1G/2.5G and green lit at 10G via respective
link_* modes; LED off immediately on cable unplug with no software
involvement.
Signed-off-by: Daniel Wagner <wagner.daniel.t@gmail.com>
---
drivers/net/phy/bcm84881.c | 156 +++++++++++++++++++++++++++++++++++++
1 file changed, 156 insertions(+)
diff --git a/drivers/net/phy/bcm84881.c b/drivers/net/phy/bcm84881.c
index f114212dd3..2ae70dcf82 100644
--- a/drivers/net/phy/bcm84881.c
+++ b/drivers/net/phy/bcm84881.c
@@ -20,6 +20,33 @@ enum {
MDIO_AN_C22 = 0xffe0,
};
+/* BCM8489x LED controller (BCM84891L datasheet 2.4.1.58). Each pin has
+ * CTL bits in 0xA83B (stride 3: 2-bit CTL + 1-bit OE_N) plus MASK_LOW/
+ * MASK_EXT source selects. LED4 is firmware-controlled; always RMW.
+ */
+#define BCM8489X_LED_CTL 0xa83b
+#define BCM8489X_LED_CTL_ON(i) (0x2 << ((i) * 3))
+#define BCM8489X_LED_CTL_MASK(i) (0x3 << ((i) * 3))
+
+#define BCM8489X_LED_SRC_RX BIT(1)
+#define BCM8489X_LED_SRC_TX BIT(2)
+#define BCM8489X_LED_SRC_1000 BIT(3) /* high only at 1000 */
+#define BCM8489X_LED_SRC_100_1000 BIT(4) /* high at 100 and 1000 */
+#define BCM8489X_LED_SRC_FORCE BIT(5) /* always-1 source */
+#define BCM8489X_LED_SRC_10G BIT(7)
+#define BCM8489X_LED_SRCX_2500 BIT(2)
+#define BCM8489X_LED_SRCX_5000 BIT(3)
+
+#define BCM8489X_MAX_LEDS 2
+
+static const struct {
+ u16 mask_low;
+ u16 mask_ext;
+} bcm8489x_led_regs[BCM8489X_MAX_LEDS] = {
+ { 0xa82c, 0xa8ef }, /* LED1 */
+ { 0xa82f, 0xa8f0 }, /* LED2 */
+};
+
static int bcm84881_wait_init(struct phy_device *phydev)
{
int val;
@@ -69,6 +96,127 @@ static int bcm8489x_config_init(struct phy_device *phydev)
MDIO_CTRL1_LPOWER);
}
+static int bcm8489x_led_write(struct phy_device *phydev, u8 index,
+ u16 low, u16 ext)
+{
+ int ret;
+
+ ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD,
+ bcm8489x_led_regs[index].mask_low, low);
+ if (ret)
+ return ret;
+ ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD,
+ bcm8489x_led_regs[index].mask_ext, ext);
+ if (ret)
+ return ret;
+ return phy_modify_mmd(phydev, MDIO_MMD_PMAPMD, BCM8489X_LED_CTL,
+ BCM8489X_LED_CTL_MASK(index),
+ (low | ext) ? BCM8489X_LED_CTL_ON(index) : 0);
+}
+
+static int bcm8489x_led_brightness_set(struct phy_device *phydev,
+ u8 index, enum led_brightness value)
+{
+ if (index >= BCM8489X_MAX_LEDS)
+ return -EINVAL;
+
+ return bcm8489x_led_write(phydev, index,
+ value ? BCM8489X_LED_SRC_FORCE : 0, 0);
+}
+
+static const unsigned long bcm8489x_supported_triggers =
+ BIT(TRIGGER_NETDEV_LINK) |
+ BIT(TRIGGER_NETDEV_LINK_100) |
+ BIT(TRIGGER_NETDEV_LINK_1000) |
+ BIT(TRIGGER_NETDEV_LINK_2500) |
+ BIT(TRIGGER_NETDEV_LINK_5000) |
+ BIT(TRIGGER_NETDEV_LINK_10000) |
+ BIT(TRIGGER_NETDEV_RX) |
+ BIT(TRIGGER_NETDEV_TX);
+
+static int bcm8489x_led_hw_is_supported(struct phy_device *phydev, u8 index,
+ unsigned long rules)
+{
+ if (index >= BCM8489X_MAX_LEDS)
+ return -EINVAL;
+
+ if (rules & ~bcm8489x_supported_triggers)
+ return -EOPNOTSUPP;
+
+ /* Source bit 4 lights at both 100 and 1000; "100 only" isn't
+ * representable in hardware. Accept LINK_100 only alongside
+ * LINK_1000 or LINK so the offload is precise.
+ */
+ if ((rules & BIT(TRIGGER_NETDEV_LINK_100)) &&
+ !(rules & (BIT(TRIGGER_NETDEV_LINK_1000) |
+ BIT(TRIGGER_NETDEV_LINK))))
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
+static int bcm8489x_led_hw_control_set(struct phy_device *phydev, u8 index,
+ unsigned long rules)
+{
+ u16 low = 0, ext = 0;
+
+ if (index >= BCM8489X_MAX_LEDS)
+ return -EINVAL;
+
+ if (rules & (BIT(TRIGGER_NETDEV_LINK_100) | BIT(TRIGGER_NETDEV_LINK)))
+ low |= BCM8489X_LED_SRC_100_1000;
+ if (rules & (BIT(TRIGGER_NETDEV_LINK_1000) | BIT(TRIGGER_NETDEV_LINK)))
+ low |= BCM8489X_LED_SRC_1000;
+ if (rules & (BIT(TRIGGER_NETDEV_LINK_2500) | BIT(TRIGGER_NETDEV_LINK)))
+ ext |= BCM8489X_LED_SRCX_2500;
+ if (rules & (BIT(TRIGGER_NETDEV_LINK_5000) | BIT(TRIGGER_NETDEV_LINK)))
+ ext |= BCM8489X_LED_SRCX_5000;
+ if (rules & (BIT(TRIGGER_NETDEV_LINK_10000) | BIT(TRIGGER_NETDEV_LINK)))
+ low |= BCM8489X_LED_SRC_10G;
+ if (rules & BIT(TRIGGER_NETDEV_RX))
+ low |= BCM8489X_LED_SRC_RX;
+ if (rules & BIT(TRIGGER_NETDEV_TX))
+ low |= BCM8489X_LED_SRC_TX;
+
+ return bcm8489x_led_write(phydev, index, low, ext);
+}
+
+static int bcm8489x_led_hw_control_get(struct phy_device *phydev, u8 index,
+ unsigned long *rules)
+{
+ int low, ext;
+
+ if (index >= BCM8489X_MAX_LEDS)
+ return -EINVAL;
+
+ low = phy_read_mmd(phydev, MDIO_MMD_PMAPMD,
+ bcm8489x_led_regs[index].mask_low);
+ if (low < 0)
+ return low;
+ ext = phy_read_mmd(phydev, MDIO_MMD_PMAPMD,
+ bcm8489x_led_regs[index].mask_ext);
+ if (ext < 0)
+ return ext;
+
+ *rules = 0;
+ if (low & BCM8489X_LED_SRC_100_1000)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_100);
+ if (low & BCM8489X_LED_SRC_1000)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_1000);
+ if (ext & BCM8489X_LED_SRCX_2500)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_2500);
+ if (ext & BCM8489X_LED_SRCX_5000)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_5000);
+ if (low & BCM8489X_LED_SRC_10G)
+ *rules |= BIT(TRIGGER_NETDEV_LINK_10000);
+ if (low & BCM8489X_LED_SRC_RX)
+ *rules |= BIT(TRIGGER_NETDEV_RX);
+ if (low & BCM8489X_LED_SRC_TX)
+ *rules |= BIT(TRIGGER_NETDEV_TX);
+
+ return 0;
+}
+
static int bcm84881_probe(struct phy_device *phydev)
{
/* This driver requires PMAPMD and AN blocks */
@@ -290,6 +438,10 @@ static struct phy_driver bcm84881_drivers[] = {
.config_aneg = bcm84881_config_aneg,
.aneg_done = bcm84881_aneg_done,
.read_status = bcm84881_read_status,
+ .led_brightness_set = bcm8489x_led_brightness_set,
+ .led_hw_is_supported = bcm8489x_led_hw_is_supported,
+ .led_hw_control_set = bcm8489x_led_hw_control_set,
+ .led_hw_control_get = bcm8489x_led_hw_control_get,
}, {
PHY_ID_MATCH_MODEL(0x359050a0),
.name = "Broadcom BCM84892",
@@ -300,6 +452,10 @@ static struct phy_driver bcm84881_drivers[] = {
.config_aneg = bcm84881_config_aneg,
.aneg_done = bcm84881_aneg_done,
.read_status = bcm84881_read_status,
+ .led_brightness_set = bcm8489x_led_brightness_set,
+ .led_hw_is_supported = bcm8489x_led_hw_is_supported,
+ .led_hw_control_set = bcm8489x_led_hw_control_set,
+ .led_hw_control_get = bcm8489x_led_hw_control_get,
},
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] net-shapers: free rollback entries using kfree_rcu
From: Paul Moses @ 2026-04-01 11:59 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Kangzheng Gu, gregkh, davem, edumazet, pabeni, horms, kees,
netdev, stable, linux-kernel
In-Reply-To: <20260331183358.3d6f9799@kernel.org>
> I noticed this patch
> https://patchwork.kernel.org/project/netdevbpf/patch/20260309173450.538026-1-p@1g4.org/,
> but it seems that there is no further progress on it.
> Please experiment and return once you are sure.
> netdevsim (netdev simulator) driver supports net_shapers, so you can
> easily exercise this code in a VM.
>
Unfortunately in the case of shaper.c, netdevsim only implemented stubs
that return 0, so it's a not a 1:1 representation of the physical drivers.
The rollback path specifically is not reliably reachable with netdevsim,
whereas it looks like a proper trigger with real hardware.
^ permalink raw reply
* [PATCH net-next] r8152: Add helper functions for SRAM2
From: Chih Kai Hsu @ 2026-04-01 11:55 UTC (permalink / raw)
To: kuba, davem
Cc: netdev, nic_swsd, linux-kernel, linux-usb, edumazet, bjorn,
pabeni, Chih Kai Hsu
Add the following helper functions for SRAM2 access to simplify the code
and improve readability:
- sram2_write() - write data to SRAM2 address
- sram2_read() - read data from SRAM2 address
- sram2_write_w0w1() - read-modify-write operation
Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com>
---
drivers/net/usb/r8152.c | 178 +++++++++++++++++-----------------------
1 file changed, 75 insertions(+), 103 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8747c55e0a48..1765da5bd6cf 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -213,6 +213,8 @@
#define OCP_PHY_PATCH_STAT 0xb800
#define OCP_PHY_PATCH_CMD 0xb820
#define OCP_PHY_LOCK 0xb82e
+#define OCP_SRAM2_ADDR 0xb87c
+#define OCP_SRAM2_DATA 0xb87e
#define OCP_ADC_IOFFSET 0xbcfc
#define OCP_ADC_CFG 0xbc06
#define OCP_SYSCLK_CFG 0xc416
@@ -1764,6 +1766,27 @@ static void sram_set_bits(struct r8152 *tp, u16 addr, u16 set)
sram_write_w0w1(tp, addr, 0, set);
}
+static void sram2_write(struct r8152 *tp, u16 addr, u16 data)
+{
+ ocp_reg_write(tp, OCP_SRAM2_ADDR, addr);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, data);
+}
+
+static u16 sram2_read(struct r8152 *tp, u16 addr)
+{
+ ocp_reg_write(tp, OCP_SRAM2_ADDR, addr);
+ return ocp_reg_read(tp, OCP_SRAM2_DATA);
+}
+
+static void sram2_write_w0w1(struct r8152 *tp, u16 addr, u16 clear, u16 set)
+{
+ u16 data;
+
+ data = sram2_read(tp, addr);
+ data = (data & ~clear) | set;
+ ocp_reg_write(tp, OCP_SRAM2_DATA, data);
+}
+
static void r8152_mdio_clr_bit(struct r8152 *tp, u16 addr, u16 clear)
{
int data;
@@ -7195,16 +7218,12 @@ static void r8156_hw_phy_cfg(struct r8152 *tp)
ocp_reg_write(tp, 0xad4c, 0x00a8);
ocp_reg_write(tp, 0xac5c, 0x01ff);
ocp_reg_w0w1(tp, 0xac8a, 0xf0, BIT(4) | BIT(5));
- ocp_reg_write(tp, 0xb87c, 0x8157);
- ocp_reg_w0w1(tp, 0xb87e, 0xff00, 0x0500);
- ocp_reg_write(tp, 0xb87c, 0x8159);
- ocp_reg_w0w1(tp, 0xb87e, 0xff00, 0x0700);
+ sram2_write_w0w1(tp, 0x8157, 0xff00, 0x0500);
+ sram2_write_w0w1(tp, 0x8159, 0xff00, 0x0700);
/* AAGC */
- ocp_reg_write(tp, 0xb87c, 0x80a2);
- ocp_reg_write(tp, 0xb87e, 0x0153);
- ocp_reg_write(tp, 0xb87c, 0x809c);
- ocp_reg_write(tp, 0xb87e, 0x0153);
+ sram2_write(tp, 0x80a2, 0x0153);
+ sram2_write(tp, 0x809c, 0x0153);
/* EEE parameter */
ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_TXTWSYS_2P5G, 0x0056);
@@ -7402,82 +7421,48 @@ static void r8156b_hw_phy_cfg(struct r8152 *tp)
ocp_reg_write(tp, 0xacc8, 0xa0d3);
ocp_reg_write(tp, 0xad08, 0x0007);
- ocp_reg_write(tp, 0xb87c, 0x8560);
- ocp_reg_write(tp, 0xb87e, 0x19cc);
- ocp_reg_write(tp, 0xb87c, 0x8562);
- ocp_reg_write(tp, 0xb87e, 0x19cc);
- ocp_reg_write(tp, 0xb87c, 0x8564);
- ocp_reg_write(tp, 0xb87e, 0x19cc);
- ocp_reg_write(tp, 0xb87c, 0x8566);
- ocp_reg_write(tp, 0xb87e, 0x147d);
- ocp_reg_write(tp, 0xb87c, 0x8568);
- ocp_reg_write(tp, 0xb87e, 0x147d);
- ocp_reg_write(tp, 0xb87c, 0x856a);
- ocp_reg_write(tp, 0xb87e, 0x147d);
- ocp_reg_write(tp, 0xb87c, 0x8ffe);
- ocp_reg_write(tp, 0xb87e, 0x0907);
- ocp_reg_write(tp, 0xb87c, 0x80d6);
- ocp_reg_write(tp, 0xb87e, 0x2801);
- ocp_reg_write(tp, 0xb87c, 0x80f2);
- ocp_reg_write(tp, 0xb87e, 0x2801);
- ocp_reg_write(tp, 0xb87c, 0x80f4);
- ocp_reg_write(tp, 0xb87e, 0x6077);
+ sram2_write(tp, 0x8560, 0x19cc);
+ sram2_write(tp, 0x8562, 0x19cc);
+ sram2_write(tp, 0x8564, 0x19cc);
+ sram2_write(tp, 0x8566, 0x147d);
+ sram2_write(tp, 0x8568, 0x147d);
+ sram2_write(tp, 0x856a, 0x147d);
+ sram2_write(tp, 0x8ffe, 0x0907);
+ sram2_write(tp, 0x80d6, 0x2801);
+ sram2_write(tp, 0x80f2, 0x2801);
+ sram2_write(tp, 0x80f4, 0x6077);
ocp_reg_write(tp, 0xb506, 0x01e7);
- ocp_reg_write(tp, 0xb87c, 0x8013);
- ocp_reg_write(tp, 0xb87e, 0x0700);
- ocp_reg_write(tp, 0xb87c, 0x8fb9);
- ocp_reg_write(tp, 0xb87e, 0x2801);
- ocp_reg_write(tp, 0xb87c, 0x8fba);
- ocp_reg_write(tp, 0xb87e, 0x0100);
- ocp_reg_write(tp, 0xb87c, 0x8fbc);
- ocp_reg_write(tp, 0xb87e, 0x1900);
- ocp_reg_write(tp, 0xb87c, 0x8fbe);
- ocp_reg_write(tp, 0xb87e, 0xe100);
- ocp_reg_write(tp, 0xb87c, 0x8fc0);
- ocp_reg_write(tp, 0xb87e, 0x0800);
- ocp_reg_write(tp, 0xb87c, 0x8fc2);
- ocp_reg_write(tp, 0xb87e, 0xe500);
- ocp_reg_write(tp, 0xb87c, 0x8fc4);
- ocp_reg_write(tp, 0xb87e, 0x0f00);
- ocp_reg_write(tp, 0xb87c, 0x8fc6);
- ocp_reg_write(tp, 0xb87e, 0xf100);
- ocp_reg_write(tp, 0xb87c, 0x8fc8);
- ocp_reg_write(tp, 0xb87e, 0x0400);
- ocp_reg_write(tp, 0xb87c, 0x8fca);
- ocp_reg_write(tp, 0xb87e, 0xf300);
- ocp_reg_write(tp, 0xb87c, 0x8fcc);
- ocp_reg_write(tp, 0xb87e, 0xfd00);
- ocp_reg_write(tp, 0xb87c, 0x8fce);
- ocp_reg_write(tp, 0xb87e, 0xff00);
- ocp_reg_write(tp, 0xb87c, 0x8fd0);
- ocp_reg_write(tp, 0xb87e, 0xfb00);
- ocp_reg_write(tp, 0xb87c, 0x8fd2);
- ocp_reg_write(tp, 0xb87e, 0x0100);
- ocp_reg_write(tp, 0xb87c, 0x8fd4);
- ocp_reg_write(tp, 0xb87e, 0xf400);
- ocp_reg_write(tp, 0xb87c, 0x8fd6);
- ocp_reg_write(tp, 0xb87e, 0xff00);
- ocp_reg_write(tp, 0xb87c, 0x8fd8);
- ocp_reg_write(tp, 0xb87e, 0xf600);
+ sram2_write(tp, 0x8013, 0x0700);
+ sram2_write(tp, 0x8fb9, 0x2801);
+ sram2_write(tp, 0x8fba, 0x0100);
+ sram2_write(tp, 0x8fbc, 0x1900);
+ sram2_write(tp, 0x8fbe, 0xe100);
+ sram2_write(tp, 0x8fc0, 0x0800);
+ sram2_write(tp, 0x8fc2, 0xe500);
+ sram2_write(tp, 0x8fc4, 0x0f00);
+ sram2_write(tp, 0x8fc6, 0xf100);
+ sram2_write(tp, 0x8fc8, 0x0400);
+ sram2_write(tp, 0x8fca, 0xf300);
+ sram2_write(tp, 0x8fcc, 0xfd00);
+ sram2_write(tp, 0x8fce, 0xff00);
+ sram2_write(tp, 0x8fd0, 0xfb00);
+ sram2_write(tp, 0x8fd2, 0x0100);
+ sram2_write(tp, 0x8fd4, 0xf400);
+ sram2_write(tp, 0x8fd6, 0xff00);
+ sram2_write(tp, 0x8fd8, 0xf600);
ocp_byte_set_bits(tp, MCU_TYPE_PLA, PLA_USB_CFG,
EN_XG_LIP | EN_G_LIP);
- ocp_reg_write(tp, 0xb87c, 0x813d);
- ocp_reg_write(tp, 0xb87e, 0x390e);
- ocp_reg_write(tp, 0xb87c, 0x814f);
- ocp_reg_write(tp, 0xb87e, 0x790e);
- ocp_reg_write(tp, 0xb87c, 0x80b0);
- ocp_reg_write(tp, 0xb87e, 0x0f31);
+ sram2_write(tp, 0x813d, 0x390e);
+ sram2_write(tp, 0x814f, 0x790e);
+ sram2_write(tp, 0x80b0, 0x0f31);
ocp_reg_set_bits(tp, 0xbf4c, BIT(1));
ocp_reg_set_bits(tp, 0xbcca, BIT(9) | BIT(8));
- ocp_reg_write(tp, 0xb87c, 0x8141);
- ocp_reg_write(tp, 0xb87e, 0x320e);
- ocp_reg_write(tp, 0xb87c, 0x8153);
- ocp_reg_write(tp, 0xb87e, 0x720e);
- ocp_reg_write(tp, 0xb87c, 0x8529);
- ocp_reg_write(tp, 0xb87e, 0x050e);
+ sram2_write(tp, 0x8141, 0x320e);
+ sram2_write(tp, 0x8153, 0x720e);
+ sram2_write(tp, 0x8529, 0x050e);
ocp_reg_clr_bits(tp, OCP_EEE_CFG, CTAP_SHORT_EN);
sram_write(tp, 0x816c, 0xc4a0);
@@ -7489,27 +7474,17 @@ static void r8156b_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, 0x8ff1, 0x0404);
ocp_reg_write(tp, 0xbf4a, 0x001b);
- ocp_reg_write(tp, 0xb87c, 0x8033);
- ocp_reg_write(tp, 0xb87e, 0x7c13);
- ocp_reg_write(tp, 0xb87c, 0x8037);
- ocp_reg_write(tp, 0xb87e, 0x7c13);
- ocp_reg_write(tp, 0xb87c, 0x803b);
- ocp_reg_write(tp, 0xb87e, 0xfc32);
- ocp_reg_write(tp, 0xb87c, 0x803f);
- ocp_reg_write(tp, 0xb87e, 0x7c13);
- ocp_reg_write(tp, 0xb87c, 0x8043);
- ocp_reg_write(tp, 0xb87e, 0x7c13);
- ocp_reg_write(tp, 0xb87c, 0x8047);
- ocp_reg_write(tp, 0xb87e, 0x7c13);
-
- ocp_reg_write(tp, 0xb87c, 0x8145);
- ocp_reg_write(tp, 0xb87e, 0x370e);
- ocp_reg_write(tp, 0xb87c, 0x8157);
- ocp_reg_write(tp, 0xb87e, 0x770e);
- ocp_reg_write(tp, 0xb87c, 0x8169);
- ocp_reg_write(tp, 0xb87e, 0x0d0a);
- ocp_reg_write(tp, 0xb87c, 0x817b);
- ocp_reg_write(tp, 0xb87e, 0x1d0a);
+ sram2_write(tp, 0x8033, 0x7c13);
+ sram2_write(tp, 0x8037, 0x7c13);
+ sram2_write(tp, 0x803b, 0xfc32);
+ sram2_write(tp, 0x803f, 0x7c13);
+ sram2_write(tp, 0x8043, 0x7c13);
+ sram2_write(tp, 0x8047, 0x7c13);
+
+ sram2_write(tp, 0x8145, 0x370e);
+ sram2_write(tp, 0x8157, 0x770e);
+ sram2_write(tp, 0x8169, 0x0d0a);
+ sram2_write(tp, 0x817b, 0x1d0a);
sram_write_w0w1(tp, 0x8217, 0xff00, 0x5000);
sram_write_w0w1(tp, 0x821a, 0xff00, 0x5000);
@@ -7574,12 +7549,9 @@ static void r8156b_hw_phy_cfg(struct r8152 *tp)
fallthrough;
case RTL_VER_15:
/* EEE parameter */
- ocp_reg_write(tp, 0xb87c, 0x80f5);
- ocp_reg_write(tp, 0xb87e, 0x760e);
- ocp_reg_write(tp, 0xb87c, 0x8107);
- ocp_reg_write(tp, 0xb87e, 0x360e);
- ocp_reg_write(tp, 0xb87c, 0x8551);
- ocp_reg_w0w1(tp, 0xb87e, 0xff00, 0x0800);
+ sram2_write(tp, 0x80f5, 0x760e);
+ sram2_write(tp, 0x8107, 0x360e);
+ sram2_write_w0w1(tp, 0x8551, 0xff00, 0x0800);
/* ADC_PGA parameter */
ocp_reg_w0w1(tp, 0xbf00, 0xe000, 0xa000);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v4 1/2] net: hsr: require valid EOT supervision TLV
From: Fernando Fernandez Mancera @ 2026-04-01 12:05 UTC (permalink / raw)
To: Luka Gejak, davem, edumazet, kuba, pabeni; +Cc: netdev, fmaurer, horms
In-Reply-To: <85A635E3-DF1B-42CA-B552-729943E5C0D5@linux.dev>
On 4/1/26 1:06 PM, Luka Gejak wrote:
> On April 1, 2026 11:52:02 AM GMT+02:00, Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>> On 4/1/26 11:23 AM, luka.gejak@linux.dev wrote:
>>> From: Luka Gejak <luka.gejak@linux.dev>
>>>
>>> Supervision frames are only valid if terminated with a zero-length EOT
>>> TLV. The current check fails to reject non-EOT entries as the terminal
>>> TLV, potentially allowing malformed supervision traffic.
>>>
>>> Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
>>> with a length of zero.
>>>
>>> Reviewed-by: Felix Maurer <fmaurer@redhat.com>
>>> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
>>> ---
>>
>> Hi,
>>
>> This has not been reviewed by Felix. Felix provided his Reviewed-by tag for the v1 which was completely different than this.
>>
>> Revisions of this patch:
>>
>> v3: https://lore.kernel.org/all/20260329112313.17164-4-luka.gejak@linux.dev/
>>
>> v2: https://lore.kernel.org/all/20260326154715.38405-4-luka.gejak@linux.dev/
>>
>> v1: https://lore.kernel.org/all/20260324143503.187642-4-luka.gejak@linux.dev/
>>
>> Are these contributions LLM/AI generated? I believe so based on the email history.
>>
>> AI generated review on rtl8723bs: https://lore.kernel.org/all/B2394A3C-25FD-4CEA-8557-3E68F1F60357@linux.dev/
>>
>> Another AI generated review on rtl8723bs: https://lore.kernel.org/all/3831D599-655E-40B2-9E5D-9DF956013088@linux.dev/
>>
>> Likely an AI generated review on a 1 year old HSR patch: https://lore.kernel.org/all/DHFG26KI6L23.1YCOVQ5SSYMO5@linux.dev/
>>
>> If these are indeed, AI generated contributions or reviews they should be disclosed beforehand. Also there is the Assisted-by: tag. Also note that developer must take full responsibility for the contribution which means understanding it completely.
>>
>> https://docs.kernel.org/process/coding-assistants.html#signed-off-by-and-developer-certificate-of-origin
>>
>> Thanks,
>> Fernando.
>
> Hi Fernando,
> About the Reviewed-by tag, that was my mistake. I forgot to remove it
> when rebasing. And about AI. I’ve been using it to help format my
> emails and translate them into English since it isn't my native
> language. However, the technical logic and the code itself are my own
> work, written without AI.
So I don't think this change in code is related to rebasing at all. The
code in this function is identical when comparing net and net-next tree
so why a rebase would cause such change in the code? Am I missing
something here?
In addition to that, the new logic does not make any sense. What
motivated the diff from v3 to v4? All that information is missing.
Thanks,
Fernando.
Should I send v5, and if so, what should I
> do besides stripping the Reviewed-by tag? I've read the documentation
> on coding assistants you linked and will make sure to follow it on the
> next revision.
> Best regards,
> Luka Gejak
>
^ permalink raw reply
* [PATCH net-next v3 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Nora Schiffer @ 2026-04-01 12:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: keep ti,am642-cpsw-nuss as a fallback
v3: resubmission for net-next, no changes
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index a959c1d7e643a..70d25f5ff1cfe 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -53,13 +53,19 @@ properties:
"#size-cells": true
compatible:
- enum:
- - ti,am642-cpsw-nuss
- - ti,am654-cpsw-nuss
- - ti,j7200-cpswxg-nuss
- - ti,j721e-cpsw-nuss
- - ti,j721e-cpswxg-nuss
- - ti,j784s4-cpswxg-nuss
+ oneOf:
+ - items:
+ - enum:
+ - ti,am642-cpsw-nuss
+ - ti,am654-cpsw-nuss
+ - ti,j7200-cpswxg-nuss
+ - ti,j721e-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
+ - items:
+ - enum:
+ - ti,j722s-cpsw-nuss
+ - const: ti,am642-cpsw-nuss
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH net-next v3 2/2] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <e7ec1b928357d1240a962a88dc6ac67fd2c92357.1774958552.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: drop AM64_CPSW_QUIRK_CUT_THRU flag, which is a downstream ti-linux feature
v3: resubmission for net-next, no changes
SGMII operation also requires changes to the phy-j721e-wiz and gmii-sel drivers.
The full series was previously posted here:
https://lore.kernel.org/lkml/cover.1774354734.git.nora.schiffer@ew.tq-group.com/
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d9400599e80a4..7ac75fc8cdcf4 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -3468,6 +3468,13 @@ static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
.fdqring_mode = K3_RINGACC_RING_MODE_RING,
};
+static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
+ .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ,
+ .ale_dev_id = "am64-cpswxg",
+ .fdqring_mode = K3_RINGACC_RING_MODE_RING,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const struct am65_cpsw_pdata j7200_cpswxg_pdata = {
.quirks = 0,
.ale_dev_id = "am64-cpswxg",
@@ -3495,6 +3502,7 @@ static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
{ .compatible = "ti,am654-cpsw-nuss", .data = &am65x_sr1_0},
{ .compatible = "ti,j721e-cpsw-nuss", .data = &j721e_pdata},
{ .compatible = "ti,am642-cpsw-nuss", .data = &am64x_cpswxg_pdata},
+ { .compatible = "ti,j722s-cpsw-nuss", .data = &j722s_cpswxg_pdata},
{ .compatible = "ti,j7200-cpswxg-nuss", .data = &j7200_cpswxg_pdata},
{ .compatible = "ti,j721e-cpswxg-nuss", .data = &j721e_cpswxg_pdata},
{ .compatible = "ti,j784s4-cpswxg-nuss", .data = &j784s4_cpswxg_pdata},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH net-next v3 0/2] e1000/e1000e: limit endianness conversion to boundary words
From: Agalakov Daniil @ 2026-04-01 12:08 UTC (permalink / raw)
To: Tony Nguyen
Cc: Agalakov Daniil, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel, lvc-project, Daniil Iskhakov, Roman Razov
In-Reply-To: <20260325151615.1407182-1-ade@amicon.ru>
This series refactors the EEPROM write logic in e1000 and e1000e drivers
to avoid processing uninitialized memory. Instead of looping over the
entire buffer, we now only perform endianness conversion on the boundary
words that were actually read from the hardware.
Patch 1: e1000: limit endianness conversion to boundary words
Patch 2: e1000e: limit endianness conversion to boundary words
---
v3:
- Reverted to v1's "check-then-convert" logic in patch for e1000e: the
return value of e1000_read_nvm() is now checked before performing
le16_to_cpus().
- Removed the redundant full-buffer loops in patch for e1000e that
caused double endianness conversion in v2.
v2:
- Moved these improvements to the 'net-next' tree.
- Improved commit description for clarity.
.../net/ethernet/intel/e1000/e1000_ethtool.c | 11 +++++++----
drivers/net/ethernet/intel/e1000e/ethtool.c | 19 ++++++++++++-------
2 files changed, 19 insertions(+), 11 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH net-next v3 1/2] e1000: limit endianness conversion to boundary words
From: Agalakov Daniil @ 2026-04-01 12:08 UTC (permalink / raw)
To: Tony Nguyen
Cc: Agalakov Daniil, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel, lvc-project, Daniil Iskhakov, Roman Razov
In-Reply-To: <20260401120919.282668-1-ade@amicon.ru>
[Why]
In e1000_set_eeprom(), the eeprom_buff is allocated to hold a range of
words. However, only the boundary words (the first and the last) are
populated from the EEPROM if the write request is not word-aligned.
The words in the middle of the buffer remain uninitialized because they
are intended to be completely overwritten by the new data via memcpy().
The previous implementation had a loop that performed le16_to_cpus()
on the entire buffer. This resulted in endianness conversion being
performed on uninitialized memory for all interior words.
Fix this by converting the endianness only for the boundary words
immediately after they are successfully read from the EEPROM.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Co-developed-by: Iskhakov Daniil <dish@amicon.ru>
Signed-off-by: Iskhakov Daniil <dish@amicon.ru>
Signed-off-by: Agalakov Daniil <ade@amicon.ru>
---
v2:
- Split from the original bugfix series and targeted at 'net-next'.
- Removed the Fixes: tag; limiting the conversion scope is an
improvement to avoid unnecessary processing of uninitialized memory.
- Improved commit description for clarity.
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index ab232b3fbbd0..38b1f91823ef 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -496,6 +496,10 @@ static int e1000_set_eeprom(struct net_device *netdev,
*/
ret_val = e1000_read_eeprom(hw, first_word, 1,
&eeprom_buff[0]);
+
+ /* Device's eeprom is always little-endian, word addressable */
+ le16_to_cpus(&eeprom_buff[0]);
+
ptr++;
}
if (((eeprom->offset + eeprom->len) & 1) && (ret_val == 0)) {
@@ -504,11 +508,10 @@ static int e1000_set_eeprom(struct net_device *netdev,
*/
ret_val = e1000_read_eeprom(hw, last_word, 1,
&eeprom_buff[last_word - first_word]);
- }
- /* Device's eeprom is always little-endian, word addressable */
- for (i = 0; i < last_word - first_word + 1; i++)
- le16_to_cpus(&eeprom_buff[i]);
+ /* Device's eeprom is always little-endian, word addressable */
+ le16_to_cpus(&eeprom_buff[last_word - first_word]);
+ }
memcpy(ptr, bytes, eeprom->len);
--
2.51.0
^ permalink raw reply related
* [PATCH net-next v3 2/2] e1000e: limit endianness conversion to boundary words
From: Agalakov Daniil @ 2026-04-01 12:08 UTC (permalink / raw)
To: Tony Nguyen
Cc: Agalakov Daniil, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel, lvc-project, Daniil Iskhakov, Roman Razov
In-Reply-To: <20260401120919.282668-1-ade@amicon.ru>
[Why]
In e1000_set_eeprom(), the eeprom_buff is allocated to hold a range of
words. However, only the boundary words (the first and the last) are
populated from the EEPROM if the write request is not word-aligned.
The words in the middle of the buffer remain uninitialized because they
are intended to be completely overwritten by the new data via memcpy().
The previous implementation had a loop that performed le16_to_cpus()
on the entire buffer. This resulted in endianness conversion being
performed on uninitialized memory for all interior words.
Fix this by converting the endianness only for the boundary words
immediately after they are successfully read from the EEPROM.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Co-developed-by: Iskhakov Daniil <dish@amicon.ru>
Signed-off-by: Iskhakov Daniil <dish@amicon.ru>
Signed-off-by: Agalakov Daniil <ade@amicon.ru>
---
v3:
- Reverted to v1's "check-then-convert" logic: the return value of
e1000_read_nvm() is now checked before performing le16_to_cpus().
- Removed the redundant full-buffer loops that caused double endianness
conversion in v2.
v2:
- Split from the original bugfix series and targeted at 'net-next'.
- Removed the Fixes: tag; limiting the conversion scope is an
improvement to avoid unnecessary processing of uninitialized memory.
- Improved commit description for clarity.
- Note on e1000e: this driver already contains the necessary return
value checks for EEPROM reads, so only the endianness conversion
cleanup is included for e1000e.
drivers/net/ethernet/intel/e1000e/ethtool.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
index dbed30943ef4..a8b35ae41141 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -583,20 +583,25 @@ static int e1000_set_eeprom(struct net_device *netdev,
/* need read/modify/write of first changed EEPROM word */
/* only the second byte of the word is being modified */
ret_val = e1000_read_nvm(hw, first_word, 1, &eeprom_buff[0]);
+ if (ret_val)
+ goto out;
+
+ /* Device's eeprom is always little-endian, word addressable */
+ le16_to_cpus(&eeprom_buff[0]);
+
ptr++;
}
- if (((eeprom->offset + eeprom->len) & 1) && (!ret_val))
+ if ((eeprom->offset + eeprom->len) & 1) {
/* need read/modify/write of last changed EEPROM word */
/* only the first byte of the word is being modified */
ret_val = e1000_read_nvm(hw, last_word, 1,
&eeprom_buff[last_word - first_word]);
+ if (ret_val)
+ goto out;
- if (ret_val)
- goto out;
-
- /* Device's eeprom is always little-endian, word addressable */
- for (i = 0; i < last_word - first_word + 1; i++)
- le16_to_cpus(&eeprom_buff[i]);
+ /* Device's eeprom is always little-endian, word addressable */
+ le16_to_cpus(&eeprom_buff[last_word - first_word]);
+ }
memcpy(ptr, bytes, eeprom->len);
--
2.51.0
^ permalink raw reply related
* Re: RFC: phylink: disable PHY autonomous EEE when MAC manages LPI
From: Nicolai Buchwitz @ 2026-04-01 12:12 UTC (permalink / raw)
To: Russell King (Oracle); +Cc: Andrew Lunn, netdev
In-Reply-To: <aczMqBNesQH-tHx0@shell.armlinux.org.uk>
On 1.4.2026 09:43, Russell King (Oracle) wrote:
> On Wed, Apr 01, 2026 at 12:56:08AM +0200, Andrew Lunn wrote:
>> On Tue, Mar 31, 2026 at 11:27:20PM +0200, Nicolai Buchwitz wrote:
>> > Hi
>> >
>> > Some PHYs (e.g. Broadcom BCM54xx "AutogrEEEn") manage EEE LPI
>> > autonomously without forwarding LPI signaling to the MAC. This works
>> > fine when the MAC doesn't support EEE, but conflicts with MACs that
>> > implement their own LPI control via phylink's mac_enable_tx_lpi /
>> > mac_disable_tx_lpi.
>> >
>> > When the MAC has lpi_capabilities set, the PHY should use Native EEE
>> > mode so the MAC can control LPI entry/exit and observe RX LPI
>> > transitions.
>> >
>> > I'm thinking of a flag on phy_device (similar to mac_managed_pm) that
>> > phylink sets when the MAC has lpi_capabilities, and that PHY drivers
>> > check in config_init to disable their autonomous EEE mode:
>> >
>> > /* set by phylink when MAC manages LPI */
>> > phydev->mac_managed_lpi = true;
>> >
>> > /* in bcm54xx_config_init: */
>> > if (phydev->mac_managed_lpi)
>> > bcm_phy_modify_exp(phydev, MII_BUF_CNTL0,
>> > AUTOGREEEN_EN, 0);
>> >
>> > This came up while adding EEE support to the Cadence macb driver (used
>> > on Raspberry Pi 5 with a BCM54210PE PHY). The PHY's AutogrEEEn mode
>> > prevented the MAC from tracking LPI state. As a workaround, the
>> > Raspberry Pi tree currently carries a downstream patch that
>> > unconditionally disables AutogrEEEn for all BCM54xx PHYs, since both
>> > genet and macb now support EEE properly. That's obviously not suitable
>> > for upstream where other MACs paired with BCM54xx may not have LPI
>> > support.
>> >
>> > Does this seem like a reasonable approach, or is there a better way to
>> > handle PHY autonomous EEE within phylink?
>>
>> You should also think about it from the other direction. What happens
>> with the MAC does not indicate it supports EEE, but the PHY has
>> autonomous EEE. At some point in the future we are going to want the
>> PHY drivers to export API calls so that phylink/phylib can implement
>> ethtool set_eee and get_eee using this autonomous EEE.
>
> Indeed - this needs to first be solved in phylib so that non-phylink
> drivers can work before adding support to phylink.
>
>> Maybe it makes more sense for Broadcom BCM54xx etc, to implement a
>> .set_eee() call which only accepts eee_enable == False, and when
>> called so, disables autonomous EEE. .get_eee() can similarly return
>> that EEE is disabled. When phylink sees the MAC implements EEE it can
>> calll into the PHY driver to turn off autonomous EEE. And we have a
>> path to later add support for turning on and fully configuring
>> autonomous EEE.
>
> I think the current phylink_ethtool_[sg]et_eee() may eventually need
> tweaking - for the case where the MAC eee ops are populated but the
> MAC support is disabled for some reason - e.g. the instance doesn't
> support EEE but the driver does for other instances.
>
> However, I don't think we can re-use phy_ethtool_set_eee() for this -
> even with MAC based EEE, we still call through to phylib's
> phy_ethtool_set_eee() which would change the on-PHY EEE support in
> ways we wouldn't want. This call remains necessary because of the
> requirement to configure the EEE advertisement which happens at phylib
> level.
>
> I think we need a separate phylib interface which disables PHY-based
> EEE.
Thanks Russell and Andrew. You're both heading in the same direction,
so to make sure I understand correctly:
1. Add a new phylib interface (separate from phy_ethtool_set_eee) to
control PHY-autonomous EEE, e.g. phy_set_autonomous_eee(phydev,
enable) and phy_get_autonomous_eee(phydev) to query the current
state.
2. PHY drivers implement it where applicable. BCM54xx AutogrEEEn as
the first user, Realtek RTL8211F as a second - it already
unconditionally disables PHY-mode EEE in config_init with the same
intent.
3. phylib calls it when the MAC registers EEE support, phylink can
build on top of that. Since EEE advertisement happens during
autoneg and LPI management is independent, the autonomous EEE
mode can be switched at any point after probe.
4. phy_ethtool_set_eee() handles EEE advertisement at the autoneg
level and stays untouched. The new phy_set_autonomous_eee() only
controls who manages LPI after EEE is negotiated: the PHY
autonomously or the MAC.
I think solving this properly in phylib is the right approach. Having
to guess whether autonomous EEE is interfering with MAC-managed LPI is
a recurring pain point, so it's worth getting a clean interface for it.
I'd put together patches once we've agreed on the overall architecture.
Nicolai
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups
From: Andrew Lunn @ 2026-04-01 12:19 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <aczHVF04LIGq_lYO@shell.armlinux.org.uk>
> I'm moving the setup of the GSO features, cleaning those up, and
> adding a warning if platform glue requests this to be enabled but the
> hardware has no support. Hopefully this will never trigger if everyone
> got the STMMAC_FLAG_TSO_EN flag correct.
Is this:
snps,tso:
$ref: /schemas/types.yaml#/definitions/flag
description:
Enables the TSO feature otherwise it will be managed by MAC HW capability
register.
I would not be too surprised if there is cargo cult copy/paste going
on and some do get it wrong.
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi: snps,tso;
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi: snps,tso;
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi: snps,tso;
arch/arm64/boot/dts/toshiba/tmpv7708.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3576.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3576.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3568.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3528.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk3528.dtsi: snps,tso;
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/qcs404.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/lemans.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/lemans.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/sm8150.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/sc8280xp.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/sc8280xp.dtsi: snps,tso;
arch/arm64/boot/dts/qcom/monaco.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp253.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp233.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp231.dtsi: snps,tso;
arch/arm64/boot/dts/st/stm32mp251.dtsi: snps,tso;
arch/riscv/boot/dts/sophgo/sg2042.dtsi: snps,tso;
arch/riscv/boot/dts/sophgo/sg2044.dtsi: snps,tso;
arch/riscv/boot/dts/starfive/jh7110.dtsi: snps,tso;
arch/riscv/boot/dts/starfive/jh7110.dtsi: snps,tso;
arch/arm/boot/dts/axis/artpec6.dtsi: snps,tso;
arch/arm/boot/dts/rockchip/rv1126.dtsi: snps,tso;
arch/arm/boot/dts/st/stm32mp131.dtsi: snps,tso;
arch/arm/boot/dts/st/stm32mp133.dtsi: snps,tso;
arch/arm/boot/dts/st/stm32mp151.dtsi: snps,tso;
Andrew
^ permalink raw reply
* Re: [PATCH net-next v10 00/14] netkit: Support for io_uring zero-copy and AF_XDP
From: Daniel Borkmann @ 2026-04-01 12:05 UTC (permalink / raw)
To: netdev
Cc: bpf, kuba, davem, razor, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260327121049.334562-1-daniel@iogearbox.net>
On 3/27/26 1:10 PM, Daniel Borkmann wrote:
> Containers use virtual netdevs to route traffic from a physical netdev
> in the host namespace. They do not have access to the physical netdev
> in the host and thus can't use memory providers or AF_XDP that require
> reconfiguring/restarting queues in the physical netdev.
>
> This patchset adds the concept of queue leasing to virtual netdevs that
> allow containers to use memory providers and AF_XDP at native speed.
> Leased queues are bound to a real queue in a physical netdev and act
> as a proxy.
>
> Memory providers and AF_XDP operations take an ifindex and queue id,
> so containers would pass in an ifindex for a virtual netdev and a queue
> id of a leased queue, which then gets proxied to the underlying real
> queue.
>
> We have implemented support for this concept in netkit and tested the
> latter against Nvidia ConnectX-6 (mlx5) as well as Broadcom BCM957504
> (bnxt_en) 100G NICs. For more details see the individual patches.
>
> v9->v10:
fyi, I'm planning to push a v11. I've investigated the latest sashiko
run on this series [0] and 2 out of the 11 findings were correct and
I've fixed them locally already.
Thanks,
Daniel
[0] https://sashiko.dev/#/patchset/20260327121049.334562-1-daniel%40iogearbox.net
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] e1000/e1000e: limit endianness conversion to boundary words
From: Fedor Pchelkin @ 2026-04-01 12:25 UTC (permalink / raw)
To: Agalakov Daniil
Cc: Tony Nguyen, lvc-project, Roman Razov, Przemek Kitszel,
linux-kernel, Andrew Lunn, Eric Dumazet, intel-wired-lan, netdev,
Jakub Kicinski, Paolo Abeni, Daniil Iskhakov, David S. Miller
In-Reply-To: <20260401120919.282668-1-ade@amicon.ru>
On Wed, 01. Apr 15:08, Agalakov Daniil wrote:
> This series refactors the EEPROM write logic in e1000 and e1000e drivers
> to avoid processing uninitialized memory. Instead of looping over the
> entire buffer, we now only perform endianness conversion on the boundary
> words that were actually read from the hardware.
>
> Patch 1: e1000: limit endianness conversion to boundary words
> Patch 2: e1000e: limit endianness conversion to boundary words
> ---
Daniil, for future submissions, please post new versions of the patches
in a separate email-thread, not In-Reply-To.
https://docs.kernel.org/process/maintainer-netdev.html#resending-after-review
https://docs.kernel.org/process/maintainer-netdev.html#changes-requested
^ permalink raw reply
* [PATCH v3 4/5] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..c2865a6b1d7fb 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,15 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .features = BIT(PHY_GMII_SEL_RGMII_ID_MODE) |
+ BIT(PHY_GMII_SEL_FIXED_TX_DELAY),
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +316,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v3 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..6e12a75100eb8 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,21 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - items:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v3 5/5] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v3 3/5] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6e9ecb88dc8b7..99a80740cdc6b 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v3 0/5] J722S SGMII support
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
For SGMII to actually work on the J722S, the am65-cpsw needs to be extended
as well, which has been submitted for net-next:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1075806
Fallback compatible strings allow for the patches to be applied in any
order and to go through different trees without breaking existing
functionality.
v3:
- Drop am65-cpsw changes from this series, they need to go through net-next
- Fix missing PHY_GMII_SEL_RGMII_ID_MODE and PHY_GMII_SEL_FIXED_TX_DELAY in
gmii-sel driver for RGMII delay mode configuration
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages
- Drop reference to AM64_CPSW_QUIRK_CUT_THRU flag, which only exists in the
TI vendor kernel
Nora Schiffer (5):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/phy/ti/phy-gmii-sel.c | 13 ++++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
5 files changed, 75 insertions(+), 18 deletions(-)
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* [PATCH v3 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..283e3eedc0f31 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,19 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - items:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* linux-next: manual merge of the bpf-next tree with the bpf tree
From: Mark Brown @ 2026-04-01 12:29 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: Eduard Zingerman, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
kernel/bpf/verifier.c
between commit:
a8502a79e832b ("bpf: Fix regsafe() for pointers to packet")
from the bpf tree and commit:
022ac07508836 ("bpf: use reg->var_off instead of reg->off for pointers")
from the bpf-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 kernel/bpf/verifier.c
index a3388cb8fcbdf,8c1cf2eb6cbbd..0000000000000
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@@ -19915,18 -20075,8 +20075,13 @@@ static bool regsafe(struct bpf_verifier
* since someone could have accessed through (ptr - k), or
* even done ptr -= k in a register, to get a safe access.
*/
- if (rold->range > rcur->range)
+ if (rold->range < 0 || rcur->range < 0) {
+ /* special case for [BEYOND|AT]_PKT_END */
+ if (rold->range != rcur->range)
+ return false;
+ } else if (rold->range > rcur->range) {
return false;
+ }
- /* If the offsets don't match, we can't trust our alignment;
- * nor can we be sure that we won't fall out of range.
- */
- if (rold->off != rcur->off)
- return false;
/* id relations must be preserved */
if (!check_ids(rold->id, rcur->id, idmap))
return false;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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