Re: [PATCH] ACPICA: Export mutex functions

[Guenter Roeck <linux@roeck-us.net>]

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