Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755157AbdDQXnV convert rfc822-to-8bit (ORCPT ); Mon, 17 Apr 2017 19:43:21 -0400 Received: from mga11.intel.com ([192.55.52.93]:48961 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752636AbdDQXnS (ORCPT ); Mon, 17 Apr 2017 19:43:18 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,217,1488873600"; d="scan'208";a="1157260939" From: "Zheng, Lv" To: "Moore, Robert" , "'Guenter Roeck'" CC: "Wysocki, Rafael J" , "'Len Brown'" , "'linux-acpi@vger.kernel.org'" , "'devel@acpica.org'" , "'linux-kernel@vger.kernel.org'" , "Box, David E" Subject: RE: [PATCH] ACPICA: Export mutex functions Thread-Topic: [PATCH] ACPICA: Export mutex functions Thread-Index: AQHSs59oLKDye/87Hky1otWNl0fbrKHBVeqAgABikICAB5zPIP//48oAgAAVSYCAACWggIAAzMyw Date: Mon, 17 Apr 2017 23:43:12 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E886CE93CFF@SHSMSX101.ccr.corp.intel.com> References: <1492009990-3539-1-git-send-email-linux@roeck-us.net> <94F2FBAB4432B54E8AACC7DFDE6C92E37E5924DB@ORSMSX110.amr.corp.intel.com> <20170412212241.GA12384@roeck-us.net> <1AE640813FDE7649BE1B193DEA596E886CE92A85@SHSMSX101.ccr.corp.intel.com> <20170417155646.GA8730@roeck-us.net> <94F2FBAB4432B54E8AACC7DFDE6C92E37E59332C@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E37E59345B@ORSMSX110.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E37E59345B@ORSMSX110.amr.corp.intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2EzZWEwMWYtYzg1OC00MTNkLWFhOTYtNjcwOWMzYmVmYTQzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImxLVzlmVGl0MU92MlwvYU1oQnIrUGgzUGp3V2N4SFNicWJwdFFRSjJmRENZPSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1704 Lines: 49 Hi, > -----Original Message----- > From: Moore, Robert > Sent: Tuesday, April 18, 2017 3:28 AM > To: 'Guenter Roeck' ; Zheng, Lv > Cc: Wysocki, Rafael J ; 'Len Brown' ; 'linux- > acpi@vger.kernel.org' ; 'devel@acpica.org' ; 'linux- > kernel@vger.kernel.org' ; Box, David E > Subject: RE: [PATCH] ACPICA: Export mutex functions > > > > -----Original Message----- > > From: Moore, Robert > > Sent: Monday, April 17, 2017 10:13 AM > > To: Guenter Roeck ; Zheng, Lv > > Cc: Wysocki, Rafael J ; Len Brown > > ; linux-acpi@vger.kernel.org; devel@acpica.org; linux- > > kernel@vger.kernel.org > > Subject: RE: [PATCH] ACPICA: Export mutex functions > > > > There is a model for the drivers to directly acquire an AML mutex > > object. That is why the acquire/release public interfaces were added to > > ACPICA. > > > > I forget all of the details, but the model was developed with MS and > > others during the ACPI 6.0 timeframe. > > > > > [Moore, Robert] > > > Here is the case where the OS may need to directly acquire an AML mutex: > > From the ACPI spec: > > 19.6.2 Acquire (Acquire a Mutex) > > Note: For Mutex objects referenced by a _DLM object, the host OS may also contend for ownership. > > > > > Other than this case, the OS/drivers should never need to directly acquire an AML mutex. That sounds reasonable but the driver might invoke an ACPICA API accessing the _DLM returned mutexes. Thanks and best regards Lv