Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754127AbdDQP4w (ORCPT ); Mon, 17 Apr 2017 11:56:52 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:33359 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751295AbdDQP4t (ORCPT ); Mon, 17 Apr 2017 11:56:49 -0400 Date: Mon, 17 Apr 2017 08:56:46 -0700 From: Guenter Roeck To: "Zheng, Lv" Cc: "Moore, Robert" , "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 Message-ID: <20170417155646.GA8730@roeck-us.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AE640813FDE7649BE1B193DEA596E886CE92A85@SHSMSX101.ccr.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1902 Lines: 47 Hi, On Mon, Apr 17, 2017 at 09:39:35AM +0000, Zheng, Lv wrote: > Hi, > > > From: Guenter Roeck [mailto:linux@roeck-us.net] > > Subject: Re: [PATCH] ACPICA: Export mutex functions > > > > On Wed, Apr 12, 2017 at 03:29:55PM +0000, Moore, Robert wrote: > > > The ACPICA mutex functions are based on the host OS functions, so they don't really buy you anything. > > You should just use the native Linux functions. > > > > > > > You mean they don't really acquire the requested ACPI mutex, > > and the underlying DSDT which declares and uses the mutex > > just ignores if the mutex was acquired by acpi_acquire_mutex() ? > > > > To clarify: You are saying that code such as > > > > acpi_status status; > > > > status = acpi_acquire_mutex(NULL, "\\_SB.PCI0.SBRG.SIO1.MUT0", 0x10); > > if (ACPI_FAILURE(status)) { > > pr_err("Failed to acquire ACPI mutex\n"); > > return -EBUSY; > > } > > Why do you need to access \_SB.PCI0.SBRG.SIO1.MUT0? > OSPM should only invoke entry methods predefined by ACPI spec or whatever specs. > There shouldn't be any needs that a driver acquires an arbitrary AML mutex. > You do not seem to have justified the usage model, IMO. > I am sorry, I have no idea how to do that. I can see that the resource in question (IO address 0x2e/0x2f) is accessed from the DSDT, that the resource is mutex protected, and that accesses to the same IO address from the Linux kernel are unreliable unless I acquire the mutex in question. At the same time, I can see that request_muxed_region() succeeds, so presumably ACPI does not reserve the region for its exclusive use. It may well be that the "official" response to this problem is "you must not instantiate a watchdog, environmental monitor, or gpio driver (or anything else provided by the Super-IO chip that requires access to those ports) on this platform in Linux". Is that what you are suggesting ? Thanks, Guenter