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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 63FF5C43381 for ; Wed, 27 Jan 2021 12:59:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1D383207B1 for ; Wed, 27 Jan 2021 12:59:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S313129AbhAZWt0 (ORCPT ); Tue, 26 Jan 2021 17:49:26 -0500 Received: from mga04.intel.com ([192.55.52.120]:36382 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731383AbhAZRyg (ORCPT ); Tue, 26 Jan 2021 12:54:36 -0500 IronPort-SDR: L/uIIItjI/LsSYtI9Q9Zmmt+FMszO/mthjHDQVylSjZXxUAuc0g+u2hdHRZ5M4kinZtckaf8gd OkvaU9hIHWDw== X-IronPort-AV: E=McAfee;i="6000,8403,9876"; a="177372717" X-IronPort-AV: E=Sophos;i="5.79,377,1602572400"; d="scan'208";a="177372717" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2021 09:46:55 -0800 IronPort-SDR: 9BOZyjjP+wxn+s2WqjrByA6IhdwaBxr36rjbSTSKPNfWFL2a9iQRmsy3zDtDd+tOU4Upl5wCqq YpuFtUeqFGbg== X-IronPort-AV: E=Sophos;i="5.79,377,1602572400"; d="scan'208";a="362068232" 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; 26 Jan 2021 09:46:51 -0800 Received: by lahna (sSMTP sendmail emulation); Tue, 26 Jan 2021 19:46:49 +0200 Date: Tue, 26 Jan 2021 19:46:49 +0200 From: Mika Westerberg To: "Rafael J. Wysocki" Cc: "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" , Michael Jamet , Yehezkel Bernat , Andreas Noever , Lukas Wunner , Mario Limonciello , "Rafael J. Wysocki" , Christian Kellner , Len Brown , Greg Kroah-Hartman , ACPI Devel Maling List Subject: Re: [PATCH 5/6] ACPI: Add support for native USB4 control _OSC Message-ID: <20210126174649.GE1988617@lahna.fi.intel.com> References: <20210126155723.9388-1-mika.westerberg@linux.intel.com> <20210126155723.9388-6-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Jan 26, 2021 at 06:35:20PM +0100, Rafael J. Wysocki wrote: > > + capbuf[OSC_QUERY_DWORD] = 0; > > + capbuf[OSC_SUPPORT_DWORD] = 0; > > + capbuf[OSC_CONTROL_DWORD] = control; > > + > > + status = acpi_run_osc(handle, &context); > > This is the same _OSC that is evaluated in > acpi_bus_osc_negotiate_platform_control(), right? Yes, but different UUID. > So shouldn't the capbuf[OSC_SUPPORT_DWORD] be whatever is negotiated > through acpi_bus_osc_negotiate_platform_control()? At least that > would be consistent with acpi_pci_osc_control_set(). The ACPI 6.4 spec says that the support field for this _OSC is reserved (table 6.14 in the spec). So as far as I can tell this is not the same as what we pass for the platform _OSC.