From: Simon Horman <horms@kernel.org>
To: mheib@redhat.com
Cc: netdev@vger.kernel.org, mohamed@pensando.io,
brett.creeley@amd.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, sln@onemain.com
Subject: Re: [PATCH net] ionic: fix persistent MAC address override on PF
Date: Thu, 19 Mar 2026 16:25:41 +0000 [thread overview]
Message-ID: <20260319162541.GJ1753385@horms.kernel.org> (raw)
In-Reply-To: <20260317170806.35390-1-mheib@redhat.com>
On Tue, Mar 17, 2026 at 07:08:06PM +0200, mheib@redhat.com wrote:
> From: Mohammad Heib <mheib@redhat.com>
>
> The use of IONIC_CMD_LIF_SETATTR in the MAC address update path causes
> the ionic firmware to update the LIF's identity in its persistent state.
> Since the firmware state is maintained across host warm boots and driver
> reloads, any MAC change on the Physical Function (PF) becomes "sticky.
>
> This is problematic because it causes ethtool -P to report the
> user-configured MAC as the permanent factory address, which breaks
> system management tools that rely on a stable hardware identity.
>
> While Virtual Functions (VFs) need this hardware-level programming to
> properly handle MAC assignments in guest environments, the PF should
> maintain standard transient behavior. This patch gates the
> ionic_program_mac call using is_virtfn so that PF MAC changes remain
> local to the netdev filters and do not overwrite the firmware's
> permanent identity block.
>
> Fixes: 19058be7c48c ("ionic: VF initial random MAC address if no assigned mac")
> Signed-off-by: Mohammad Heib <mheib@redhat.com>
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-03-19 16:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 17:08 [PATCH net] ionic: fix persistent MAC address override on PF mheib
2026-03-19 16:25 ` Simon Horman [this message]
2026-03-19 16:44 ` Creeley, Brett
2026-03-19 18:11 ` Creeley, Brett
2026-03-19 22:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260319162541.GJ1753385@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=brett.creeley@amd.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=mheib@redhat.com \
--cc=mohamed@pensando.io \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sln@onemain.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.