Re: [Intel-wired-lan] [PATCH 1/2] igc: Wait for MAC passthrough after reset

"Chia-Lin Kao (AceLan)" <[email protected]> Tue, 4 Aug 2026 13:59:39 +0800
Newsgroups gmane.linux.network,gmane.linux.kernel
Message-ID <anF_hoO57nh2363f@acelan-Precision-5480>
On Wed, Jul 15, 2026 at 10:57:04AM +0300, Ruinskiy, Dima wrote:
> Hi AceLan,
>
> > > > I wish we can detect if the MAC passthrough is enabled, so that we
> > > > know if we need to poll for the MAC address.
> > > Unfortunately, like you I am not aware of any way for the driver to know
> > > whether MAC passthrough via FW is enabled. Because of this we have been
> > > exploring a simpler way to support this feature via ACPI objects (which are
> > > set by the BIOS when MAC passthrough is enabled and are easy for the driver
> > > to query). I know some vendors have already implemented it, and I am
> > > currently drafting a patch to send.
> > Any good news about this patch?
> The patch is here: https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20260706/055944.html
>
> I tested it on my setup with MAC passthrough enabled in the BIOS, with good
> results; no community feedback yet. I encourage you to try it. Lenovo and
> Dell laptops should have the capability.
Yes, the patch works for me.
Verified with both enable and disable of MAC passthrough, and it works
as expected.

Looking forward to see this patch merged.
Thanks.
>
> > > The mechanism I have in mind does not require BIOS support - the I225/I226
> > > FW already supports the required interrupt, AFAIK - it merely needs to be
> > > enabled in the igc driver. With that said, there still remains the question
> > > of how to notify the network stack above us that the MAC address has changed
> > > post-probe - and whether it is even supported.
> Looking at it again, this may not be as big of a deal as I feared. If we can
> call eth_hw_addr_set at any point in time to change the address, then we
> should be able to do this in a response to a FW interrupt. I can try to
> draft a patch for that, in parallel to collecting feedback on the ACPI
> approach. These are two different means to the same end, and some solutions
> may implement one but not the other.
>
> --Dima