Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp388701rdb; Tue, 23 Jan 2024 02:58:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IEucqQvsS3Uoh4JyDJBs8CcoFU+qryuz0MMbIeQsfkimxVcGDrK+YlYehgkJ2b8WNdysfU5 X-Received: by 2002:a05:6e02:5c7:b0:362:8d4b:51fb with SMTP id l7-20020a056e0205c700b003628d4b51fbmr387475ils.1.1706007531814; Tue, 23 Jan 2024 02:58:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706007531; cv=pass; d=google.com; s=arc-20160816; b=k9Llpoa6mpKrssHd7aODLG22shUZEQJQpBXi8srW4Lx9b+u2jo6qcagtKdsk6DeNDC kuoHVdskl3nkBOJhz3YoRYoIci1j4I9lIhmAMsgNp7XB7PQjDO/V26ZC0gw/k7GtHNlt rG2XzQb+SkgOJWsolfP+H8+HD3lPpQzGQGHphXCICmNQWIxdJXz6gRVSfjTnMb33c1d9 2F4lNSp3oVweR32ddbX6E0TytKk0y9G9B8+mDzDo5zUja2jMSI1rgZsB99XY3PHeJPrG UeP1Ags+t3x2qaEMBXVdV5T3HCPCigbg639P2WszJTio3I5L5t+pZsuUDgrFKb41iKmK XQkw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:organization:references :in-reply-to:message-id:subject:cc:to:from:date; bh=aqyiS6N9G8dwPepuqaBx3wW6LunGnACrGwKfBuOyS7g=; fh=ZRbmVK2ga2vTYuvZN0HcXaq7O5Usrg1yWOT2046EXjw=; b=tgtXXHXLNus13W2cKzBnf6Kd1u/GAlOYrZrhHgMlQ0K0seuuKRBjGf3ZbcGy7RUC3b vgf6bdpkkD03UbK1hUIQ9Zb8+x2sJe1EXbakAxlLRcyvOMj77qpAU8m8ZQtvaZ4xmxsp e63KlfmzU2GXKmjFFySBqKKNTCtctPqe0DNSbrOHr3kkW74BLw2Sjx7OETDmPmoEdmbc 4e3dkC0e4Ii1Ba4FvPEQWGxYMi9iffUj5OaHXZBaEDh3QpKb0w4kzmKlfeJhVg9N68Zg CVMybIP0rry2JzC4UMnKJVN7hQ9AEq0jWXLIam4kSRLPaCtXYW/t4NOnmybHPJb6vd6g Za1g== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-35130-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-35130-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id m24-20020a63ed58000000b00565db2812a0si9880025pgk.60.2024.01.23.02.58.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 02:58:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-35130-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-35130-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-35130-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 77C52B2578A for ; Tue, 23 Jan 2024 10:52:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BA7435C91A; Tue, 23 Jan 2024 10:51:44 +0000 (UTC) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE1E55C8F0; Tue, 23 Jan 2024 10:51:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706007103; cv=none; b=fRBwJC423iNojLLv7zLlGLbsA0BUpOFE7vf+y0v+OTXyoRnie0ilB8SjFkGTBVii9kb1c8wCr9PPttQu+iJTMr6K4jzZgqyDysVynDH1+4mHuykHrJDSsevm9dqbXA4ZomvhYTvRlkP2ias8lS2EfOtIuFWcMrSrI21pW3ToyDY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706007103; c=relaxed/simple; bh=YDWGY21cqzqJqv3snTRrbIpRBoA5JkwvIqTELbIZ6YM=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jm7lfc6yjWdYSPyMRACesxNE0GffpmqK6MyNBEh3hPwKtue83SQSndsxTep6XetQx6EeJms6x7MNCXxN13kCSGXYsoyHOL7dh7xb0kfTO9ILAwbcroI+uh7wjP2PXnZVCfv1FKFafR3htWu86feIWPta9Xtc6HihvRv39jE5KqE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TK3jv1h6bz6K62v; Tue, 23 Jan 2024 18:49:07 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id E85871404F9; Tue, 23 Jan 2024 18:51:37 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 23 Jan 2024 10:51:37 +0000 Date: Tue, 23 Jan 2024 10:51:36 +0000 From: Jonathan Cameron To: Jose Marinho CC: "Russell King (Oracle)" , "linux-pm@vger.kernel.org" , "loongarch@lists.linux.dev" , "linux-acpi@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-riscv@lists.infradead.org" , "kvmarm@lists.linux.dev" , "x86@kernel.org" , "acpica-devel@lists.linuxfoundation.org" , "linux-csky@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-ia64@vger.kernel.org" , "linux-parisc@vger.kernel.org" , Salil Mehta , Jean-Philippe Brucker , Jianyong Wu , Justin He , James Morse , Samer El-Haj-Mahmoud , nd , Kangkang Shen Subject: Re: [PATCH RFC v3 20/21] ACPI: Add _OSC bits to advertise OS support for toggling CPU present/enabled Message-ID: <20240123105136.000043e5@Huawei.com> In-Reply-To: References: <20231215171227.00006550@Huawei.com> <20240102151652.00001b3c@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml500002.china.huawei.com (7.191.160.78) To lhrpeml500005.china.huawei.com (7.191.163.240) On Tue, 2 Jan 2024 15:35:45 +0000 Jose Marinho wrote: > > -----Original Message----- > > From: Jonathan Cameron > > Sent: Tuesday, January 2, 2024 3:17 PM > > To: Jose Marinho > > Cc: Russell King (Oracle) ; linux- > > pm@vger.kernel.org; loongarch@lists.linux.dev; linux-acpi@vger.kernel.org; > > linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > > kernel@lists.infradead.org; linux-riscv@lists.infradead.org; > > kvmarm@lists.linux.dev; x86@kernel.org; acpica- > > devel@lists.linuxfoundation.org; linux-csky@vger.kernel.org; linux- > > doc@vger.kernel.org; linux-ia64@vger.kernel.org; linux-parisc@vger.kernel.org; > > Salil Mehta ; Jean-Philippe Brucker > philippe@linaro.org>; Jianyong Wu ; Justin He > > ; James Morse ; Samer El-Haj- > > Mahmoud ; nd ; Kangkang > > Shen > > Subject: Re: [PATCH RFC v3 20/21] ACPI: Add _OSC bits to advertise OS support > > for toggling CPU present/enabled > > > > On Tue, 2 Jan 2024 13:07:25 +0000 > > Jose Marinho wrote: > > > > > Hi Jonathan, > > > > > > > -----Original Message----- > > > > From: Jonathan Cameron > > > > Sent: Friday, December 15, 2023 5:12 PM > > > > To: Russell King (Oracle) > > > > Cc: linux-pm@vger.kernel.org; loongarch@lists.linux.dev; linux- > > > > acpi@vger.kernel.org; linux-arch@vger.kernel.org; linux- > > > > kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux- > > > > riscv@lists.infradead.org; kvmarm@lists.linux.dev; x86@kernel.org; > > > > acpica- devel@lists.linuxfoundation.org; linux-csky@vger.kernel.org; > > > > linux- doc@vger.kernel.org; linux-ia64@vger.kernel.org; linux- > > > > parisc@vger.kernel.org; Salil Mehta ; > > > > Jean-Philippe Brucker ; Jianyong Wu > > > > ; Justin He ; James Morse > > > > ; Jose Marinho ; Samer > > > > El-Haj-Mahmoud > > > > Subject: Re: [PATCH RFC v3 20/21] ACPI: Add _OSC bits to advertise > > > > OS support for toggling CPU present/enabled > > > > > > > > On Wed, 13 Dec 2023 12:50:54 +0000 > > > > Russell King (Oracle) wrote: > > > > > > > > > From: James Morse > > > > > > > > > > Platform firmware can disabled a CPU, or make it not-present by > > > > > making an eject-request notification, then waiting for the os to > > > > > make it offline > > > > OS > > > > > > > > > and call _EJx. After the firmware updates _STA with the new status. > > > > > > > > > > Not all operating systems support this. For arm64 making CPUs > > > > > not-present has never been supported. For all ACPI architectures, > > > > > making CPUs disabled has recently been added. Firmware can't know > > > > > what > > > > the OS has support for. > > > > > > > > > > Add two new _OSC bits to advertise whether the OS supports the > > > > > _STA enabled or present bits being toggled for CPUs. This will be > > > > > important for arm64 if systems that support physical CPU hotplug > > > > > ever appear as > > > > > arm64 linux doesn't currently support this, so firmware shouldn't try. > > > > > > > > > > Advertising this support to firmware is useful for cloud > > > > > orchestrators to know whether they can scale a particular VM by adding > > CPUs. > > > > > > > > > > Signed-off-by: James Morse > > > > > Tested-by: Miguel Luis > > > > > Tested-by: Vishnu Pajjuri > > > > > Tested-by: Jianyong Wu > > > > > > > > I'm very much in favor of this _OSC but it hasn't been accepted yet I think... > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=4481 > > > > > > > > Jose? Github suggests you are the proposer on this. > > > > > > The addition of these _OSC bits was proposed by us on the forum in question. > > > The forum opted to pause the definition until additional practical information > > could be provided on the use-cases. > > > > > > If anyone is interested in progressing the _OSC bit definition, you are invited to > > express that interest in the Bugzilla ticket. > > > > I've poked around a bit and can't find any reference to how to actually get a > > bugzilla account bugzilla.tianocore.org. Any pointers? I'm sure I had one at one > > stage, but trying every plausible email address and the forgotten password link > > got me nowhere. > > > > The procedure to get a new account is described here: https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues > The immediate next steps are: > - Join https://edk2.groups.io/g/devel, and subscribe edk2 | devel group. > - Send the email with the detail reason to Bugzilla Admin (gaoliming@byosoft.com.cn) , this email address will be created as Bugzilla account. > > > > Information that you should provide to increase the chances of the ticket being > > reopened: > > > - use-case for the new _OSC bits, > > > > Really annoying without it as a hypervisor can't query if a guest can do anything > > useful if the host does virtual CPU hotplug via this newly added route. > > Given this is new functionality and there is non trivial effort required by the host > > to instantiate such a CPU it would be nice to be able to find out if the feature is > > supported by the Guest OS without having to basically suck it an see with > > hypervisors having to do a trial hotplug just to see if it 'might' work. > > > > > - what breaks (if anything) without the proposed _OSC bits. > > > > Nothing breaks - you can merrily poke in hotplugged CPUs with the attendant > > creation of resources in the host and have them disappear into a black hole. > > That's ugly but not broken as such. Hopefully a hypervisor will not keep trying > > until the first attempt either succeeds or fails. > > > > > > > > We did receive additional comments: > > > - the proposed _OSC bits are not generic: the bits simply convey whether the > > guest OS understands CPU hot-plug, but it says nothing about the number of CPUs > > that the OS supports. > > > > If a guest says it supports this feature, you would hope it supports it for the > > number of CPUs that have the present bit set but the enabled not. > > I'd clarify that in the text rather than provide a means of querying the number of > > CPUs supported. > > Number wouldn't be sufficient anyway as it wouldn't indicate 'which' CPUs are > > supported. > > Nothing says they have to be contiguous or lowest IDs etc. > > > > > - There could be alternate schemes that do not rely on spec changes. E.g. there > > could be a hypervisor IMPDEF mechanism to describe if an OS image supports > > CPU hot-plug. > > > > Sigh. Yes, that could be done at the cost of every guest having to be made aware > > of every hypervisor impdef mechanism. Trying to avoid that mess is why I think > > an _OSC makes sense as then everyone can use the same control. > > > > No particular reason we should use ACPI at all for VMs :) > > > > > > > > > > > > > btw v4 looks ok but v5 in the tianocore github seems to have lost > > > > the actual OSC part. > > > > > > Agree that, if we do progress with this spec change, v4 is the correct formulation > > we should adopt. > > > > > Thanks for the update. > > > > Overall this is a question we need to resolve soon. If this code otherwise goes in > > linux without the OSC we will always need to support the 'suck it and see' > > approach as we'll never know if the guest fell down the hole. Thus if not added > > soon we might as well not add it at all and we'll all be looking at the code and > > thinking "that's ugly and shouldn't have been necessary" for years to come. > > > > +CC Kangkang as he might be able to help get this started again. > > We're keen to support the progress of this ECR. So work is underway on kicking this off again, but I think we need a backup plan (even if it is a bit ugly) as I really don't want the kernel code to get caught behind an ASWG discussion that might not end up with the answer we want anyway. So even if we eventually land this _OSC in the spec, I think we will have systems where it's unknowable if they support this feature or not. That is the 'suck it and see' approach will be necessary. If an orchestrator really wants to know if this is supported by the guest it will have to try telling the guest the CPU is enabled, and if the guest turns it on we know it supports this feature. So it'll have to have a tedious probe loop. That can then be shortcut but an _OSC if we have one later. I really want to see this feature go into the kernel this cycle and this ugly corner isn't to my mind a blocker. So I suggest we drop this patch for now and we'll revisit later. > > Regards, > Jose > > > > > Jonathan > > > > > Regards, > > > Jose > > > > > > > > > > > Jonathan > > > > > > > > > --- > > > > > I'm assuming Loongarch machines do not support physical CPU hotplug. > > > > > > > > > > Changes since RFC v3: > > > > > * Drop ia64 changes > > > > > * Update James' comment below "---" to remove reference to ia64 > > > > > > > > > > Outstanding comment: > > > > > https://lore.kernel.org/r/20230914175021.000018fd@Huawei.com > > > > > > > > > > > > > > > > > --- > > > > > arch/x86/Kconfig | 1 + > > > > > drivers/acpi/Kconfig | 9 +++++++++ > > > > > drivers/acpi/acpi_processor.c | 14 +++++++++++++- > > > > > drivers/acpi/bus.c | 16 ++++++++++++++++ > > > > > include/linux/acpi.h | 4 ++++ > > > > > 5 files changed, 43 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index > > > > > 64fc7c475ab0..33fc4dcd950c 100644 > > > > > --- a/arch/x86/Kconfig > > > > > +++ b/arch/x86/Kconfig > > > > > @@ -60,6 +60,7 @@ config X86 > > > > > select ACPI_LEGACY_TABLES_LOOKUP if ACPI > > > > > select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI > > > > > select ACPI_HOTPLUG_PRESENT_CPU if ACPI_PROCESSOR > > > > && HOTPLUG_CPU > > > > > + select ACPI_HOTPLUG_IGNORE_OSC if ACPI && > > > > HOTPLUG_CPU > > > > > select ARCH_32BIT_OFF_T if X86_32 > > > > > select ARCH_CLOCKSOURCE_INIT > > > > > select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE > > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index > > > > > 9c5a43d0aff4..020e7c0ab985 100644 > > > > > --- a/drivers/acpi/Kconfig > > > > > +++ b/drivers/acpi/Kconfig > > > > > @@ -311,6 +311,15 @@ config ACPI_HOTPLUG_PRESENT_CPU > > > > > depends on ACPI_PROCESSOR && HOTPLUG_CPU > > > > > select ACPI_CONTAINER > > > > > > > > > > +config ACPI_HOTPLUG_IGNORE_OSC > > > > > + bool > > > > > + depends on ACPI_HOTPLUG_PRESENT_CPU > > > > > + help > > > > > + Ignore whether firmware acknowledged support for toggling the CPU > > > > > + present bit in _STA. Some architectures predate the _OSC bits, so > > > > > + firmware doesn't know to do this. > > > > > + > > > > > + > > > > > config ACPI_PROCESSOR_AGGREGATOR > > > > > tristate "Processor Aggregator" > > > > > depends on ACPI_PROCESSOR > > > > > diff --git a/drivers/acpi/acpi_processor.c > > > > > b/drivers/acpi/acpi_processor.c index ea12e70dfd39..5bb207a7a1dd > > > > > 100644 > > > > > --- a/drivers/acpi/acpi_processor.c > > > > > +++ b/drivers/acpi/acpi_processor.c > > > > > @@ -182,6 +182,18 @@ static void __init > > > > > acpi_pcc_cpufreq_init(void) static void __init > > > > > acpi_pcc_cpufreq_init(void) {} #endif /* > > > > > CONFIG_X86 */ > > > > > > > > > > +static bool acpi_processor_hotplug_present_supported(void) > > > > > +{ > > > > > + if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU)) > > > > > + return false; > > > > > + > > > > > + /* x86 systems pre-date the _OSC bit */ > > > > > + if (IS_ENABLED(CONFIG_ACPI_HOTPLUG_IGNORE_OSC)) > > > > > + return true; > > > > > + > > > > > + return osc_sb_hotplug_present_support_acked; > > > > > +} > > > > > + > > > > > /* Initialization */ > > > > > static int acpi_processor_make_present(struct acpi_processor *pr) > > > > > { @@ -189,7 +201,7 @@ static int > > > > > acpi_processor_make_present(struct > > > > acpi_processor *pr) > > > > > acpi_status status; > > > > > int ret; > > > > > > > > > > - if (!IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU)) { > > > > > + if (!acpi_processor_hotplug_present_supported()) { > > > > > pr_err_once("Changing CPU present bit is not supported\n"); > > > > > return -ENODEV; > > > > > } > > > > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index > > > > > 72e64c0718c9..7122450739d6 100644 > > > > > --- a/drivers/acpi/bus.c > > > > > +++ b/drivers/acpi/bus.c > > > > > @@ -298,6 +298,13 @@ > > > > > EXPORT_SYMBOL_GPL(osc_sb_native_usb4_support_confirmed); > > > > > > > > > > bool osc_sb_cppc2_support_acked; > > > > > > > > > > +/* > > > > > + * ACPI 6.? Proposed Operating System Capabilities for modifying > > > > > +CPU > > > > > + * present/enable. > > > > > + */ > > > > > +bool osc_sb_hotplug_enabled_support_acked; > > > > > +bool osc_sb_hotplug_present_support_acked; > > > > > + > > > > > static u8 sb_uuid_str[] = "0811B06E-4A27-44F9-8D60-3CBBC22E7B48"; > > > > > static void acpi_bus_osc_negotiate_platform_control(void) > > > > > { > > > > > @@ -346,6 +353,11 @@ static void > > > > > acpi_bus_osc_negotiate_platform_control(void) > > > > > > > > > > if (!ghes_disable) > > > > > capbuf[OSC_SUPPORT_DWORD] |= OSC_SB_APEI_SUPPORT; > > > > > + > > > > > + capbuf[OSC_SUPPORT_DWORD] |= > > > > OSC_SB_HOTPLUG_ENABLED_SUPPORT; > > > > > + if (IS_ENABLED(CONFIG_ACPI_HOTPLUG_PRESENT_CPU)) > > > > > + capbuf[OSC_SUPPORT_DWORD] |= > > > > OSC_SB_HOTPLUG_PRESENT_SUPPORT; > > > > > + > > > > > if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle))) > > > > > return; > > > > > > > > > > @@ -383,6 +395,10 @@ static void > > > > acpi_bus_osc_negotiate_platform_control(void) > > > > > capbuf_ret[OSC_SUPPORT_DWORD] & > > > > OSC_SB_NATIVE_USB4_SUPPORT; > > > > > osc_cpc_flexible_adr_space_confirmed = > > > > > capbuf_ret[OSC_SUPPORT_DWORD] & > > > > OSC_SB_CPC_FLEXIBLE_ADR_SPACE; > > > > > + osc_sb_hotplug_enabled_support_acked = > > > > > + capbuf_ret[OSC_SUPPORT_DWORD] & > > > > OSC_SB_HOTPLUG_ENABLED_SUPPORT; > > > > > + osc_sb_hotplug_present_support_acked = > > > > > + capbuf_ret[OSC_SUPPORT_DWORD] & > > > > OSC_SB_HOTPLUG_PRESENT_SUPPORT; > > > > > } > > > > > > > > > > kfree(context.ret.pointer); > > > > > diff --git a/include/linux/acpi.h b/include/linux/acpi.h index > > > > > 00be66683505..c572abac803c 100644 > > > > > --- a/include/linux/acpi.h > > > > > +++ b/include/linux/acpi.h > > > > > @@ -559,12 +559,16 @@ acpi_status acpi_run_osc(acpi_handle handle, > > > > struct acpi_osc_context *context); > > > > > #define OSC_SB_NATIVE_USB4_SUPPORT 0x00040000 > > > > > #define OSC_SB_PRM_SUPPORT 0x00200000 > > > > > #define OSC_SB_FFH_OPR_SUPPORT 0x00400000 > > > > > +#define OSC_SB_HOTPLUG_ENABLED_SUPPORT 0x00800000 > > > > > +#define OSC_SB_HOTPLUG_PRESENT_SUPPORT 0x01000000 > > > > > > > > > > extern bool osc_sb_apei_support_acked; extern bool > > > > > osc_pc_lpi_support_confirmed; extern bool > > > > > osc_sb_native_usb4_support_confirmed; > > > > > extern bool osc_sb_cppc2_support_acked; extern bool > > > > > osc_cpc_flexible_adr_space_confirmed; > > > > > +extern bool osc_sb_hotplug_enabled_support_acked; > > > > > +extern bool osc_sb_hotplug_present_support_acked; > > > > > > > > > > /* USB4 Capabilities */ > > > > > #define OSC_USB_USB3_TUNNELING 0x00000001 > > > >