linux-kernel - Re: [PATCH v2] drm/i915: Invoke BXT _DSM to enable MUX on HP Workstation laptops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YILAc6EhoWWhENq8@intel.com>
Date:   Fri, 23 Apr 2021 15:41:23 +0300
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     jani.nikula@...ux.intel.com, joonas.lahtinen@...ux.intel.com,
        rodrigo.vivi@...el.com, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>, Takashi Iwai <tiwai@...e.de>,
        intel-gfx@...ts.freedesktop.org,
        "open list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] drm/i915: Invoke BXT _DSM to enable MUX on HP
 Workstation laptops

On Fri, Apr 23, 2021 at 12:46:54PM +0800, Kai-Heng Feng wrote:
> On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> to discrete GFX after S3. This is not desirable, because userspace will
> treat connected display as a new one, losing display settings.
> 
> The expected behavior is to let discrete GFX drives all external
> displays.
> 
> The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX.
> The method is inside the BXT _DSM, so add the _DSM and call it
> accordingly.
> 
> I also tested some MUX-less and iGPU only laptops with the BXT _DSM, no
> regression was found.
> 
> v2:
>  - Forward declare struct pci_dev.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113
> References: https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.manna@intel.com/
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
> ---
>  drivers/gpu/drm/i915/display/intel_acpi.c | 17 +++++++++++++++++
>  drivers/gpu/drm/i915/display/intel_acpi.h |  3 +++
>  drivers/gpu/drm/i915/i915_drv.c           |  5 +++++
>  3 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 833d0c1be4f1..c7b57c22dce3 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -14,11 +14,16 @@
>  
>  #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
>  #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
> +#define INTEL_DSM_FN_PLATFORM_BXT_MUX_INFO 0 /* No args */
>  
>  static const guid_t intel_dsm_guid =
>  	GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
>  		  0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
>  
> +static const guid_t intel_bxt_dsm_guid =
> +	GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> +		  0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14);
> +

I think this dsm is just supposed to be more or less an
alternative to the opregion SCI stuff. Why there are two
ways to do the same things I have no idea. The opregion
spec does not tell us such mundane details.

It's also not documented to do anything except list the
supported functions:
"Get BIOS Data Functions Supported “Function #0"
 This function can be called to discover which “_DSM” Functions are
 supported. It may only return success if the return value accurately
 lists supported Functions."

But what you're apparently saying is that calling this changes
the behaviour of the system somehow? That is troubling.

-- 
Ville Syrjälä
Intel