From: Simon Horman <horms@kernel.org>
To: dima.ruinskiy@intel.com
Cc: Simon Horman <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
anthony.l.nguyen@intel.com, allen.lan@intel.com,
acelan.kao@canonical.com, kuba@kernel.org
Subject: Re: [PATCH iwl-next v4] igc: Support ACPI-based MAC passthrough
Date: Sun, 13 Sep 2026 15:19:31 +0100 [thread overview]
Message-ID: <20260913141931.205787-1-horms@kernel.org> (raw)
In-Reply-To: <20260910193824.3257378-1-dima.ruinskiy@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/#/patchset/20260910193824.3257378-1-dima.ruinskiy@intel.com?part=1
---
igc: Support ACPI-based MAC passthrough
This commit implements support for seamlessly passing through a system MAC
address provided in the ACPI table to an I225/I226 network controller
attached via a Thunderbolt dock.
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 1fb5f3cbe93c5..abffd385f3e8c 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
[ ... ]
> @@ -7106,6 +7108,58 @@ static enum hrtimer_restart igc_qbv_scheduling_timer(struct hrtimer *timer)
> return HRTIMER_NORESTART;
> }
>
> +static bool igc_get_acpi_mac_passthru(u8 *mac)
> +{
[ ... ]
> + acpi_status status;
> + u8 buf[ETH_ALEN];
[Severity: High]
Does this array lack a 16-bit alignment guarantee?
Because it is declared as a simple byte array on the stack, the compiler is
free to place it at an odd memory address.
> + int i;
> +
> + if (!IS_ENABLED(CONFIG_ACPI))
> + return false;
> +
> + for (i = 0; i < ARRAY_SIZE(sources) && !mac_found; i++) {
[ ... ]
> + if (hex2bin(buf, obj->string.pointer + 9, ETH_ALEN) ||
> + !is_valid_ether_addr(buf))
> + goto free_obj;
> +
> + ether_addr_copy(mac, buf);
[Severity: High]
Can passing this buffer to is_valid_ether_addr() and ether_addr_copy() cause
an alignment trap on architectures that strictly enforce memory alignment?
Both of these helpers cast the pointer to a u16 pointer to perform 16-bit
memory operations when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is not set.
If buf ends up placed at an odd address, this could cause a kernel panic.
Could this be avoided by defining buf as a u16 array or by adding an explicit
__aligned(2) attribute?
> + mac_found = true;
> +free_obj:
> + ACPI_FREE(obj);
> + }
> +
> + return mac_found;
> +}
> +
prev parent reply other threads:[~2026-09-13 14:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 19:38 [PATCH iwl-next v4] igc: Support ACPI-based MAC passthrough Dima Ruinskiy
2026-09-13 14:19 ` Simon Horman [this message]
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=20260913141931.205787-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=acelan.kao@canonical.com \
--cc=allen.lan@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=dima.ruinskiy@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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.