From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97977C4743D for ; Tue, 8 Jun 2021 11:45:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7EF6461359 for ; Tue, 8 Jun 2021 11:45:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231768AbhFHLq5 (ORCPT ); Tue, 8 Jun 2021 07:46:57 -0400 Received: from mga06.intel.com ([134.134.136.31]:7106 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230190AbhFHLq4 (ORCPT ); Tue, 8 Jun 2021 07:46:56 -0400 IronPort-SDR: lDNG5bpd95285+z04ivn0UJqFiSrB4bu5q4EUxrnYZ0KfX+q4Z3ZyC6ET8hk08xsSqtQlFUJq+ FPySbtR7AukQ== X-IronPort-AV: E=McAfee;i="6200,9189,10008"; a="265978143" X-IronPort-AV: E=Sophos;i="5.83,257,1616482800"; d="scan'208";a="265978143" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2021 04:45:03 -0700 IronPort-SDR: jAtMKuhg+I9WV3IGFWVu2zEGJz6QQ2Xl9o9ELt6peQQj7LJUeaV4MvXmHSOByi1kJS3hG8wnM/ cC+cHxBm9x7w== X-IronPort-AV: E=Sophos;i="5.83,257,1616482800"; d="scan'208";a="449491593" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2021 04:45:00 -0700 Received: by lahna (sSMTP sendmail emulation); Tue, 08 Jun 2021 14:44:58 +0300 Date: Tue, 8 Jun 2021 14:44:58 +0300 From: Mika Westerberg To: Hans de Goede Cc: Mario Limonciello , "Rafael J. Wysocki" , "Rafael J . Wysocki" , linux-acpi Subject: Re: Some SSDT tables are not loading with kernel >= 5.12 Message-ID: References: <93d783c4-4468-023b-193e-3fc6eca35445@redhat.com> <209a230c-a7a6-7a8e-0515-97fb534d7401@redhat.com> <0f733402-ae3b-b4e7-13c4-e6161f9c7e81@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f733402-ae3b-b4e7-13c4-e6161f9c7e81@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi, On Tue, Jun 08, 2021 at 11:50:15AM +0200, Hans de Goede wrote: > Hi, > > On 6/7/21 9:18 PM, Hans de Goede wrote: > > Hi, > > > > On 6/7/21 6:08 PM, Mika Westerberg wrote: > >> Hi, > >> > >> Tried now on ADL-P and TGL systems and the _OSC still works properly. > >> > >> Thanks Hans for fixing! > >> > >> Feel free to add my Tested-by. > > > > Thank you for testing, unfortunately so far from the comments here: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=213023 > > > > it seems that my patch does not help resolve the issues caused > > by commit 719e1f561afb ("ACPI: Execute platform _OSC also with query > > bit clear"), where as reverting that commit does resolve them :| > > > > Does anyone have any other ideas how to fix this ? > > The reporter who has done the bisect has commented out the new/second > _OSC call and that fixes things for them. So I've written a new fix > (attached), note just as before this is untested ATM. > > Mika, if you can test this one (it replaces the previous one) > on machines with native USB4 support to check those don't regress then > that would be great. I can test it sure, but first let's try to understand what the problem is :) > I've asked the various reporters from the 2 bugzilla's for this to also > test this new patch. I'll let you know how that goes. The _OSC on at least one of the affected platforms look like this: If ((Arg0 == ToUUID ("0811b06e-4a27-44f9-8d60-3cbbc22e7b48") /* Platform-wide Capabilities */)) { If ((Arg1 == One)) { OSCP = CAP0 /* \_SB_._OSC.CAP0 */ If ((CAP0 & 0x04)) { OSCO = 0x04 If (((SGMD & 0x0F) != 0x02)) { If ((RTD3 == Zero)) { CAP0 &= 0x3B STS0 |= 0x10 } } } } Else { STS0 &= 0xFFFFFF00 STS0 |= 0x0A } } Else { STS0 &= 0xFFFFFF00 STS0 |= 0x06 } Probably it is fine to call it several times but the issue is with the mask that it does: CAP0 &= 0x3B This clears out the upper bits. I think this is actually a BIOS bug as it ends up clearing OSC_SB_PCLPI_SUPPORT which is probably not intented, and that seems to cause skipping of the LPI tables or something like that. The alternative is to pass the original caps to the second _OSC call. I think this is safe too. While looking at the code, I found a couple of other issues that should be fixed with the below hack patch. What do you think about this approach? diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index be7da23fad76..80ff81bb668b 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -290,7 +290,7 @@ static void acpi_bus_osc_negotiate_platform_control(void) struct acpi_osc_context context = { .uuid_str = sb_uuid_str, .rev = 1, - .cap.length = 8, + .cap.length = sizeof(capbuf), .cap.pointer = capbuf, }; acpi_handle handle; @@ -330,32 +330,21 @@ static void acpi_bus_osc_negotiate_platform_control(void) if (ACPI_FAILURE(acpi_run_osc(handle, &context))) return; - capbuf_ret = context.ret.pointer; - if (context.ret.length <= OSC_SUPPORT_DWORD) { - kfree(context.ret.pointer); - return; - } + kfree(context.ret.pointer); - /* - * Now run _OSC again with query flag clear and with the caps - * supported by both the OS and the platform. - */ + /* Now run _OSC again with query flag clear */ capbuf[OSC_QUERY_DWORD] = 0; - capbuf[OSC_SUPPORT_DWORD] = capbuf_ret[OSC_SUPPORT_DWORD]; - kfree(context.ret.pointer); if (ACPI_FAILURE(acpi_run_osc(handle, &context))) return; capbuf_ret = context.ret.pointer; - if (context.ret.length > OSC_SUPPORT_DWORD) { - osc_sb_apei_support_acked = - capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT; - osc_pc_lpi_support_confirmed = - capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_PCLPI_SUPPORT; - osc_sb_native_usb4_support_confirmed = - capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT; - } + osc_sb_apei_support_acked = + capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT; + osc_pc_lpi_support_confirmed = + capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_PCLPI_SUPPORT; + osc_sb_native_usb4_support_confirmed = + capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT; kfree(context.ret.pointer); }