summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorVladimir Oltean <vladimir.oltean@nxp.com>2023-04-18 14:14:51 +0300
committerJakub Kicinski <kuba@kernel.org>2023-04-21 06:03:21 +0300
commit59be75db5966f920bf5cccfd2a34b3bf222660d7 (patch)
treee7e815a1e7f8e248c82277c5678252b4d662f4a8 /tools/perf/scripts/python/export-to-postgresql.py
parent787e6144aef74e73f88875cb5d3a5af01701af6f (diff)
downloadlinux-59be75db5966f920bf5cccfd2a34b3bf222660d7.tar.xz
net: enetc: fix MAC Merge layer remaining enabled until a link down event
Current enetc_set_mm() is designed to set the priv->active_offloads bit ENETC_F_QBU for enetc_mm_link_state_update() to act on, but if the link is already up, it modifies the ENETC_MMCSR_ME ("Merge Enable") bit directly. The problem is that it only *sets* ENETC_MMCSR_ME if the link is up, it doesn't *clear* it if needed. So subsequent enetc_get_mm() calls still see tx-enabled as true, up until a link down event, which is when enetc_mm_link_state_update() will get called. This is not a functional issue as far as I can assess. It has only come up because I'd like to uphold a simple API rule in core ethtool code: the pMAC cannot be disabled if TX is going to be enabled. Currently, the fact that TX remains enabled for longer than expected (after the enetc_set_mm() call that disables it) is going to violate that rule, which is how it was caught. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions