summaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/microchip/lan966x
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2024-01-31 12:30:47 +0000
committerDavid S. Miller <davem@davemloft.net>2024-01-31 12:30:47 +0000
commit737fc16129cf286185c54ba6937d850d530b6787 (patch)
treef8e8d22372e6f19e6c41d381fa32aac0dc736c70 /drivers/net/ethernet/microchip/lan966x
parent2acfd589e50e6a4d63fc007b9ac3e366bbf819fb (diff)
parent2bb0526129592de59c3e2cd3e8ebe426b7b5b07f (diff)
downloadlinux-stable-737fc16129cf286185c54ba6937d850d530b6787.tar.gz
linux-stable-737fc16129cf286185c54ba6937d850d530b6787.tar.bz2
linux-stable-737fc16129cf286185c54ba6937d850d530b6787.zip
Merge branch 'ethtool-EEE'
Heiner Kallweit says: ==================== ethtool: switch EEE netlink interface to use EEE linkmode bitmaps So far only 32bit legacy bitmaps are passed to userspace. This makes it impossible to manage EEE linkmodes beyond bit 32, e.g. manage EEE for 2500BaseT and 5000BaseT. This series adds support for passing full linkmode bitmaps between kernel and userspace. Fortunately the netlink-based part of ethtool is quite smart and no changes are needed in ethtool. However this applies to the netlink interface only, the ioctl interface for now remains restricted to legacy bitmaps. Next step will be adding support for the c45 EEE2 standard registers (3.21, 7.62, 7.63) to the genphy_c45 functions dealing with EEE. I have a follow-up series for this ready to be submitted. v2: - now as RFC - adopt suggestion from Andrew to start with struct ethtool_keee being an identical copy of ethtool_eee, and switch all users v3: - switch from RFC to net-next - add patch 4, and reuse old names in patch 5 - rebase patch 1 v4: - fix missing replacement in patch 4 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/microchip/lan966x')
0 files changed, 0 insertions, 0 deletions