All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Atharva Tiwari" <atharvatiwarilinuxdev@gmail.com>
Cc: "open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	"open list:DRM DRIVERS" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 05/13] platform/apple-gmux: Write switch state to EFI on MMIO devices
Date: Sun, 25 Oct 2026 04:36:50 +0000	[thread overview]
Message-ID: <sashiko-outbox-184071@kernel.org> (raw)
In-Reply-To: <20261025040046.1602-6-atharvatiwarilinuxdev@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] platform/x86: apple-gmux: NULL deref in gmux_write_switch_state_efi()
- [Medium] platform/apple-gmux: redundant NVRAM writes in gmux_switchto() on runtime suspend
--

commit ef107e78a2e02b388268e04355f8632ba5066eb7
Author: Andre Eikmeyer <dev@deq.rocks>

platform/apple-gmux: Write switch state to EFI on MMIO devices

This commit updates the apple-gmux driver to write the display mux switch
state to the gpu-active EFI variable when switching GPUs on MMIO (T2)
devices.

> diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c
> index bef87a57ad43c..637b3b216d4e3 100644
> --- a/drivers/platform/x86/apple-gmux.c
> +++ b/drivers/platform/x86/apple-gmux.c

[ ... ]

> @@ -494,6 +495,31 @@ static void gmux_write_switch_state(struct apple_gmux_data *gmux_data)
>  		gmux_write8(gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
>  }
>  
> +#define APPLE_GPU_VARS_GUID EFI_GUID(0xfa4ce28d, 0xb62f, 0x4c99, \
> +				     0x9c, 0xc3, 0x68, 0x15, 0x68, 0x6e, 0x30, 0xf9)
> +
> +static efi_char16_t gmux_gpu_active_name[] = L"gpu-active";
> +
> +static void gmux_write_switch_state_efi(struct apple_gmux_data *gmux_data)
> +{
> +	efi_guid_t guid = APPLE_GPU_VARS_GUID;
> +	u32 active = gmux_data->switch_state_display == VGA_SWITCHEROO_IGD;
> +	efi_status_t status;
> +
> +	if (!efivar_is_available())
> +		return;
> +
> +	status = efivar_set_variable(gmux_gpu_active_name, &guid,
> +				     EFI_VARIABLE_NON_VOLATILE |
> +				     EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +				     EFI_VARIABLE_RUNTIME_ACCESS,
> +				     sizeof(active), &active);

[Severity: High]
Should gmux_write_switch_state_efi() check efivar_supports_writes() instead
of efivar_is_available() before calling efivar_set_variable()?

In drivers/firmware/efi/efi.c:generic_ops_register(), generic_efivars is
registered even when EFI_RT_SUPPORTED_SET_VARIABLE is not supported, leaving
generic_ops.set_variable as NULL while efivar_is_available() returns true:

	if (efi_rt_services_supported(EFI_RT_SUPPORTED_SET_VARIABLE)) {
		generic_ops.set_variable = efi.set_variable;
		generic_ops.set_variable_nonblocking = efi.set_variable_nonblocking;
	}
	return efivars_register(&generic_efivars, &generic_ops);

When efivar_set_variable() calls efivar_set_variable_locked() in
drivers/firmware/efi/vars.c, setvar is called unconditionally:

	setvar = __efivars->ops->set_variable_nonblocking;
	if (!setvar || !nonblocking)
		 setvar = __efivars->ops->set_variable;

	return setvar(name, vendor, attr, data_size, data);

Can this cause a NULL function pointer dereference via
gmux_switchto() -> gmux_write_switch_state_efi() -> efivar_set_variable() on
systems where efivars is registered without write support?

> +	if (status != EFI_SUCCESS)
> +		pr_warn("writing gpu-active failed: 0x%lx\n", status);
> +	else
> +		pr_debug("gpu-active: %u\n", active);
> +}
> +
>  static int gmux_switchto(enum vga_switcheroo_client_id id)
>  {
>  	apple_gmux_data->switch_state_ddc = id;
> @@ -502,6 +528,8 @@ static int gmux_switchto(enum vga_switcheroo_client_id id)
>  		apple_gmux_data->switch_state_external = id;
>  
>  	gmux_write_switch_state(apple_gmux_data);
> +	if (apple_gmux_data->type == APPLE_GMUX_TYPE_MMIO)
> +		gmux_write_switch_state_efi(apple_gmux_data);

[Severity: Medium]
Will calling gmux_write_switch_state_efi() unconditionally in gmux_switchto()
cause redundant non-volatile NVRAM writes on every discrete GPU runtime
suspend?

In drivers/gpu/vga/vga_switcheroo.c:vga_switcheroo_runtime_suspend(), the
mux handler is called to switch to VGA_SWITCHEROO_IGD regardless of the
current mux state:

	if (vgasr_priv.handler->switchto) {
		mutex_lock(&vgasr_priv.mux_hw_lock);
		vgasr_priv.handler->switchto(VGA_SWITCHEROO_IGD);
		mutex_unlock(&vgasr_priv.mux_hw_lock);
	}

When the display is already on VGA_SWITCHEROO_IGD and the discrete GPU goes
through runtime wake and suspend cycles (such as during PRIME offload or
display hotplug), gmux_switchto(VGA_SWITCHEROO_IGD) will write the
non-volatile gpu-active variable to NVRAM even though switch_state_display
did not change.

Would it make sense to skip calling gmux_write_switch_state_efi() when
apple_gmux_data->switch_state_display is already equal to id (while ensuring
the initial state is still synchronized if needed)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261025040046.1602-1-atharvatiwarilinuxdev@gmail.com?part=5

  reply	other threads:[~2026-10-25  4:36 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-25  3:59 [PATCH 00/13] Fixes for apple-gmux and runtime support Atharva Tiwari
2026-10-25  3:59 ` [PATCH 01/13] platform/apple-gmux: Fix power for MMIO systems Atharva Tiwari
2026-10-25  4:49   ` sashiko-bot
2026-10-25  3:59 ` [PATCH 02/13] PCI: Disable pcie port and access on D3 on specific amd devices Atharva Tiwari
2026-10-25  4:34   ` sashiko-bot
2026-10-27 23:00   ` Bjorn Helgaas
2026-10-28  0:08     ` Atharva Tiwari
2026-10-28  1:19       ` Atharva Tiwari
2026-10-25  3:59 ` [PATCH 03/13] platform/apple-gmux: Fix MMIO interface Atharva Tiwari
2026-10-25  4:27   ` sashiko-bot
2026-10-25 22:10   ` kernel test robot
2026-10-25  3:59 ` [PATCH 04/13] platform/apple-gmux: Fix Interrupts for MMIO systems Atharva Tiwari
2026-10-25  4:39   ` sashiko-bot
2026-10-25  3:59 ` [PATCH 05/13] platform/apple-gmux: Write switch state to EFI on MMIO devices Atharva Tiwari
2026-10-25  4:36   ` sashiko-bot [this message]
2026-10-25  3:59 ` [PATCH 06/13] platform/apple-gmux: Add parameter to configure boot gpu Atharva Tiwari
2026-10-25  4:33   ` sashiko-bot
2026-10-25  3:59 ` [PATCH 07/13] platform/apple-gmux: Add check to detect FSS Atharva Tiwari
2026-10-25  4:30   ` sashiko-bot
2026-10-25  3:59 ` [PATCH 08/13] platform/apple-gmux: Add documentation about iMacs Atharva Tiwari
2026-10-25  4:37   ` sashiko-bot
2026-10-25  3:59 ` [PATCH 09/13] drm/amdgpu: Add Apple GMUX runtime PM support Atharva Tiwari
2026-10-25  5:56   ` sashiko-bot
2026-10-25  3:59 ` [PATCH 10/13] drm/amdgpu: Catch register access while GMUX keeps the GPU off Atharva Tiwari
2026-10-25  4:40   ` sashiko-bot
2026-10-26 18:25   ` Alex Deucher
2026-10-27  8:29     ` Atharva Tiwari
2026-10-27 15:22       ` Alex Deucher
2026-10-25  3:59 ` [PATCH 11/13] drm/amd/display: Refuse DP AUX " Atharva Tiwari
2026-10-25  4:41   ` sashiko-bot
2026-10-26 18:25   ` Alex Deucher
2026-10-25  3:59 ` [PATCH 12/13] drm/amdgpu: Skip AC/DC notification while the GPU is runtime suspended Atharva Tiwari
2026-10-25  4:43   ` sashiko-bot
2026-10-26 18:18   ` Alex Deucher
2026-10-25  3:59 ` [PATCH 13/13] drm/amd/display: Skip panel power savings on eDP links without a panel Atharva Tiwari
2026-10-25  4:30   ` sashiko-bot

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=sashiko-outbox-184071@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atharvatiwarilinuxdev@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.