This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
r8152: Add 2500baseT EEE status/configuration support

The r8152 driver supports the RTL8156, which is a 2.5Gbit Ethernet
controller for USB 3.0, for which support is added for configuring and
displaying the EEE advertisement status for 2.5GBit connections. The
patch also corrects the determination of whether EEE is active to include
the 2.5GBit connection status and make the determination dependent not on
the desired speed configuration (tp->speed), but on the actual speed used
by the controller.

[ ... ]

Simon says: please declare local variables in reverse xmas tree order -
            longest line to shortest.

Does this code read uninitialized memory? The 'common' bitmap is declared
via __ETHTOOL_DECLARE_LINK_MODE_MASK(common), which expands to
DECLARE_BITMAP -- an uninitialized stack array:

unsigned long common[BITS_TO_LONGS(__ETHTOOL_LINK_MODE_MASK_NBITS)];

The new code conditionally sets individual bits via linkmode_set_bit(),
which calls __set_bit() to set a single bit position. This leaves all
other bits in the array containing whatever garbage was on the stack.

Then linkmode_and(common, common, eee->advertised) reads all the
uninitialized bits when performing the bitwise AND operation.

The old code was safe because it used linkmode_and(common,
eee->advertised, eee->lp_advertised), which fully wrote 'common' from two
initialized bitmaps before reading it.

With uninitialized stack data, eee_active could be incorrectly reported as
true if garbage bits happen to overlap with the advertised and
lp_advertised bitmasks.

[Simon says: I note that Daniel Golle flagged this issue already]

Is the user's 2500baseT EEE configuration actually applied to hardware?
The code stores the user's preference in tp->eee_adv2, but
rtl_eee_enable() never writes this value to the OCP_EEE_ADV2 register.

For RTL_VER_10-15 (the 2500full-capable chips), rtl_eee_enable() calls
r8156_eee_en() which unconditionally sets MDIO_EEE_2_5GT rather than using
tp->eee_adv2:

drivers/net/usb/r8152.c:r8156_eee_en() {
    ...
    if (enable) {
        ...
        set |= MDIO_EEE_2_5GT;
    } else {
        ...
        clr |= MDIO_EEE_2_5GT;
    }
    ocp_data = (ocp_data & ~clr) | set;
    ocp_reg_write(tp, OCP_EEE_ADV2, ocp_data);
}

Then rtl_eee_enable() writes only tp->eee_adv to OCP_EEE_ADV:

drivers/net/usb/r8152.c:rtl_eee_enable() {
    ...
    case RTL_VER_10: ... case RTL_VER_15:
        r8156_eee_en(tp, enable);
        ...
        ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
        break;
}

The OCP_EEE_ADV2 register is never updated with tp->eee_adv2. This means
user attempts to selectively control 2500baseT EEE advertisement via
ethtool are silently ignored.

The cap1 path correctly writes tp->eee_adv to OCP_EEE_ADV. Shouldn't the
cap2 path similarly write tp->eee_adv2 to OCP_EEE_ADV2?

[ ... ]

The same uninitialized memory issue exists here in r8153_get_eee. The
'common' bitmap declared via __ETHTOOL_DECLARE_LINK_MODE_MASK is never
zeroed before individual speed bits are conditionally set with
linkmode_set_bit(). Then linkmode_and() reads the uninitialized garbage
bits.

This function affects RTL_VER_03 through RTL_VER_15, which is the majority
of supported devices.