Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1622232 > unrolled thread

[PATCH] ACPICA: Export mutex functions

Back to article view | Back to linux.kernel

Contents

  [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-12 17:20 +0200
    RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-12 17:40 +0200
      Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-12 23:30 +0200
        RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-13 00:00 +0200
          Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-13 03:00 +0200
          Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-15 00:40 +0200
            RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-15 01:40 +0200
        RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-17 11:40 +0200
          RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-17 11:50 +0200
            Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 16:10 +0200
              RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 01:40 +0200
          Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 18:00 +0200
            RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 19:20 +0200
              RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 21:30 +0200
                Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 21:50 +0200
                  RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 22:50 +0200
                    Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-17 23:10 +0200
                      Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-17 23:30 +0200
                        Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-18 00:40 +0200
                          Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-18 01:00 +0200
                          RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 02:00 +0200
                            Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-18 06:40 +0200
                              RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 09:10 +0200
                              RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 09:20 +0200
                                Re: [PATCH] ACPICA: Export mutex functions Guenter Roeck <linux@roeck-us.net> - 2017-04-18 16:00 +0200
                                  Re: [PATCH] ACPICA: Export mutex functions "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-04-18 16:30 +0200
                                    RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-18 18:10 +0200
                                  RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-19 03:30 +0200
                                    RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-19 03:40 +0200
                  RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 02:00 +0200
                RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 01:50 +0200
              RE: [PATCH] ACPICA: Export mutex functions "Moore, Robert" <robert.moore@intel.com> - 2017-04-17 21:40 +0200
            RE: [PATCH] ACPICA: Export mutex functions "Zheng, Lv" <lv.zheng@intel.com> - 2017-04-18 01:40 +0200

Page 1 of 2  [1] 2  Next page →

#1622232 — [PATCH] ACPICA: Export mutex functions

Mutex functions may be needed by drivers. Examples are accesses to Super-IO
SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO environmental monitor
registers, both which may also be accessed through DSDT.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
 drivers/acpi/acpica/utxfmutex.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/acpica/utxfmutex.c b/drivers/acpi/acpica/utxfmutex.c
index c016211c35ae..5d20581f4b2f 100644
--- a/drivers/acpi/acpica/utxfmutex.c
+++ b/drivers/acpi/acpica/utxfmutex.c
@@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string pathname, u16 timeout)
 	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
 	return (status);
 }
+ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
 
 /*******************************************************************************
  *
@@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle, acpi_string pathname)
 	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
 	return (AE_OK);
 }
+ACPI_EXPORT_SYMBOL(acpi_release_mutex)
-- 
2.7.4

[toc] | [next] | [standalone]

#1622248

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.


> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: Wednesday, April 12, 2017 8:13 AM
> To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> Len Brown <lenb@kernel.org>
> Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
> kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
> Subject: [PATCH] ACPICA: Export mutex functions
> 
> Mutex functions may be needed by drivers. Examples are accesses to
> Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> environmental monitor registers, both which may also be accessed through
> DSDT.
> 
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
>  drivers/acpi/acpica/utxfmutex.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/acpi/acpica/utxfmutex.c
> b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> 100644
> --- a/drivers/acpi/acpica/utxfmutex.c
> +++ b/drivers/acpi/acpica/utxfmutex.c
> @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> pathname, u16 timeout)
>  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
>  	return (status);
>  }
> +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> 
> 
> /***********************************************************************
> ********
>   *
> @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> acpi_string pathname)
>  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
>  	return (AE_OK);
>  }
> +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> --
> 2.7.4

[toc] | [prev] | [next] | [standalone]

#1622565

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;
	}
	...

when used in conjunction with

	...
	Mutex (MUT0, 0x00)
	Method (ENFG, 1, NotSerialized)
	{
		Acquire (MUT0, 0x0FFF)
		...
	}

doesn't really provide exclusive access to the resource(s) protected
by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?

Outch. Really ?

Thanks,
Guenter

> 
> > -----Original Message-----
> > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > Sent: Wednesday, April 12, 2017 8:13 AM
> > To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> > <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> > Len Brown <lenb@kernel.org>
> > Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
> > kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
> > Subject: [PATCH] ACPICA: Export mutex functions
> > 
> > Mutex functions may be needed by drivers. Examples are accesses to
> > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > environmental monitor registers, both which may also be accessed through
> > DSDT.
> > 
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > ---
> >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > 100644
> > --- a/drivers/acpi/acpica/utxfmutex.c
> > +++ b/drivers/acpi/acpica/utxfmutex.c
> > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> > pathname, u16 timeout)
> >  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> >  	return (status);
> >  }
> > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > 
> > 
> > /***********************************************************************
> > ********
> >   *
> > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> > acpi_string pathname)
> >  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> >  	return (AE_OK);
> >  }
> > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > --
> > 2.7.4
> 

[toc] | [prev] | [next] | [standalone]

#1622579

> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: Wednesday, April 12, 2017 2:23 PM
> To: Moore, Robert <robert.moore@intel.com>
> Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>; linux-
> acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> 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() ?
> 
[Moore, Robert] 

OK, I understand now. Yes, these mutex interfaces are in fact intended for the purpose you mention:

* FUNCTION:    AcpiAcquireMutex
 *
 * PARAMETERS:  Handle              - Mutex or prefix handle (optional)
 *              Pathname            - Mutex pathname (optional)
 *              Timeout             - Max time to wait for the lock (millisec)
 *
 * RETURN:      Status
 *
 * DESCRIPTION: Acquire an AML mutex. This is a device driver interface to
 *              AML mutex objects, and allows for transaction locking between
 *              drivers and AML code. The mutex node is pointed to by
 *              Handle:Pathname. Either Handle or Pathname can be NULL, but
 *              not both.


And yes, both the acquire and release interfaces should be exported.





> 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;
> 	}
> 	...
> 
> when used in conjunction with
> 
> 	...
> 	Mutex (MUT0, 0x00)
> 	Method (ENFG, 1, NotSerialized)
> 	{
> 		Acquire (MUT0, 0x0FFF)
> 		...
> 	}
> 
> doesn't really provide exclusive access to the resource(s) protected by
> MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
> 
> Outch. Really ?
> 
> Thanks,
> Guenter
> 
> >
> > > -----Original Message-----
> > > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> > > <lv.zheng@intel.com>; Wysocki, Rafael J
> > > <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>
> > > Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
> > > kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
> > > Subject: [PATCH] ACPICA: Export mutex functions
> > >
> > > Mutex functions may be needed by drivers. Examples are accesses to
> > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > environmental monitor registers, both which may also be accessed
> > > through DSDT.
> > >
> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > ---
> > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > 100644
> > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle,
> > > acpi_string pathname, u16 timeout)
> > >  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > >  	return (status);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > >
> > >
> > > /*******************************************************************
> > > ****
> > > ********
> > >   *
> > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle
> > > handle, acpi_string pathname)
> > >  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > >  	return (AE_OK);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > --
> > > 2.7.4
> >

[toc] | [prev] | [next] | [standalone]

#1622652

On Wed, Apr 12, 2017 at 09:56:37PM +0000, Moore, Robert wrote:
> 
> 
> > -----Original Message-----
> > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > Sent: Wednesday, April 12, 2017 2:23 PM
> > To: Moore, Robert <robert.moore@intel.com>
> > Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
> > <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>; linux-
> > acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> > 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() ?
> > 
> [Moore, Robert] 
> 
> OK, I understand now. Yes, these mutex interfaces are in fact intended for the purpose you mention:
> 
> * FUNCTION:    AcpiAcquireMutex
>  *
>  * PARAMETERS:  Handle              - Mutex or prefix handle (optional)
>  *              Pathname            - Mutex pathname (optional)
>  *              Timeout             - Max time to wait for the lock (millisec)
>  *
>  * RETURN:      Status
>  *
>  * DESCRIPTION: Acquire an AML mutex. This is a device driver interface to
>  *              AML mutex objects, and allows for transaction locking between
>  *              drivers and AML code. The mutex node is pointed to by
>  *              Handle:Pathname. Either Handle or Pathname can be NULL, but
>  *              not both.
> 
> 
> And yes, both the acquire and release interfaces should be exported.
> 

Puh, I am relieved ...

Thanks,
Guenter

> 
> > 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;
> > 	}
> > 	...
> > 
> > when used in conjunction with
> > 
> > 	...
> > 	Mutex (MUT0, 0x00)
> > 	Method (ENFG, 1, NotSerialized)
> > 	{
> > 		Acquire (MUT0, 0x0FFF)
> > 		...
> > 	}
> > 
> > doesn't really provide exclusive access to the resource(s) protected by
> > MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
> > 
> > Outch. Really ?
> > 
> > Thanks,
> > Guenter
> > 
> > >
> > > > -----Original Message-----
> > > > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > > To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> > > > <lv.zheng@intel.com>; Wysocki, Rafael J
> > > > <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>
> > > > Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
> > > > kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
> > > > Subject: [PATCH] ACPICA: Export mutex functions
> > > >
> > > > Mutex functions may be needed by drivers. Examples are accesses to
> > > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > > environmental monitor registers, both which may also be accessed
> > > > through DSDT.
> > > >
> > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > > ---
> > > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > > 100644
> > > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle,
> > > > acpi_string pathname, u16 timeout)
> > > >  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > > >  	return (status);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > > >
> > > >
> > > > /*******************************************************************
> > > > ****
> > > > ********
> > > >   *
> > > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle
> > > > handle, acpi_string pathname)
> > > >  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > > >  	return (AE_OK);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > > --
> > > > 2.7.4
> > >

[toc] | [prev] | [next] | [standalone]

#1623938

On Wednesday, April 12, 2017 09:56:37 PM Moore, Robert wrote:
> 
> > -----Original Message-----
> > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > Sent: Wednesday, April 12, 2017 2:23 PM
> > To: Moore, Robert <robert.moore@intel.com>
> > Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
> > <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>; linux-
> > acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> > 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() ?
> > 
> [Moore, Robert] 
> 
> OK, I understand now. Yes, these mutex interfaces are in fact intended for the purpose you mention:
> 
> * FUNCTION:    AcpiAcquireMutex
>  *
>  * PARAMETERS:  Handle              - Mutex or prefix handle (optional)
>  *              Pathname            - Mutex pathname (optional)
>  *              Timeout             - Max time to wait for the lock (millisec)
>  *
>  * RETURN:      Status
>  *
>  * DESCRIPTION: Acquire an AML mutex. This is a device driver interface to
>  *              AML mutex objects, and allows for transaction locking between
>  *              drivers and AML code. The mutex node is pointed to by
>  *              Handle:Pathname. Either Handle or Pathname can be NULL, but
>  *              not both.
> 
> 
> And yes, both the acquire and release interfaces should be exported.

OK, so I'm assuming this will go in through the upstream ACPICA.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1623960

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Friday, April 14, 2017 3:30 PM
> To: Moore, Robert
> Cc: Guenter Roeck; Zheng, Lv; 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
> 
> On Wednesday, April 12, 2017 09:56:37 PM Moore, Robert wrote:
> >
> > > -----Original Message-----
> > > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > > Sent: Wednesday, April 12, 2017 2:23 PM
> > > To: Moore, Robert <robert.moore@intel.com>
> > > Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
> > > <rafael.j.wysocki@intel.com>; Len Brown <lenb@kernel.org>; linux-
> > > acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org
> > > 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() ?
> > >
> > [Moore, Robert]
> >
> > OK, I understand now. Yes, these mutex interfaces are in fact intended
> for the purpose you mention:
> >
> > * FUNCTION:    AcpiAcquireMutex
> >  *
> >  * PARAMETERS:  Handle              - Mutex or prefix handle (optional)
> >  *              Pathname            - Mutex pathname (optional)
> >  *              Timeout             - Max time to wait for the lock
> (millisec)
> >  *
> >  * RETURN:      Status
> >  *
> >  * DESCRIPTION: Acquire an AML mutex. This is a device driver interface
> to
> >  *              AML mutex objects, and allows for transaction locking
> between
> >  *              drivers and AML code. The mutex node is pointed to by
> >  *              Handle:Pathname. Either Handle or Pathname can be NULL,
> but
> >  *              not both.
> >
> >
> > And yes, both the acquire and release interfaces should be exported.
> 
> OK, so I'm assuming this will go in through the upstream ACPICA.
> 

Yes, done for next release.
Bob



> Thanks,
> Rafael

[toc] | [prev] | [next] | [standalone]

#1624616

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.

Thanks
Lv

> 	...
> 
> when used in conjunction with
> 
> 	...
> 	Mutex (MUT0, 0x00)
> 	Method (ENFG, 1, NotSerialized)
> 	{
> 		Acquire (MUT0, 0x0FFF)
> 		...
> 	}
> 
> doesn't really provide exclusive access to the resource(s) protected
> by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
> 
> Outch. Really ?
> 
> Thanks,
> Guenter
> 
> >
> > > -----Original Message-----
> > > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> > > <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> > > Len Brown <lenb@kernel.org>
> > > Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
> > > kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
> > > Subject: [PATCH] ACPICA: Export mutex functions
> > >
> > > Mutex functions may be needed by drivers. Examples are accesses to
> > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > environmental monitor registers, both which may also be accessed through
> > > DSDT.
> > >
> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > ---
> > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > 100644
> > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> > > pathname, u16 timeout)
> > >  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > >  	return (status);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > >
> > >
> > > /***********************************************************************
> > > ********
> > >   *
> > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> > > acpi_string pathname)
> > >  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > >  	return (AE_OK);
> > >  }
> > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > --
> > > 2.7.4
> >

[toc] | [prev] | [next] | [standalone]

#1624620

Hi,

> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Zheng, Lv
> Sent: Monday, April 17, 2017 5:40 PM
> To: Guenter Roeck <linux@roeck-us.net>; Moore, Robert <robert.moore@intel.com>
> Cc: linux-acpi@vger.kernel.org; devel@acpica.org; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> linux-kernel@vger.kernel.org
> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
> 
> 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.
> 
> Thanks
> Lv
> 
> > 	...
> >
> > when used in conjunction with
> >
> > 	...
> > 	Mutex (MUT0, 0x00)
> > 	Method (ENFG, 1, NotSerialized)
> > 	{
> > 		Acquire (MUT0, 0x0FFF)
> > 		...
> > 	}
> >
> > doesn't really provide exclusive access to the resource(s) protected
> > by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?

IMO, the use case you are talking about is commonly seen in an operation region access code.
Most likely, we'll prepare a driver own lock, and use it for both driver initiated accesses and AML initiated accesses.

Finally, how can the driver writer know which mutex he should acquire?
AML mutexes should be invisible to the OS (except the global lock).

So I'm really confused by your argument.
Please explain in details - what the resource is.

Thanks
Lv


> >
> > Outch. Really ?
> >
> > Thanks,
> > Guenter
> >
> > >
> > > > -----Original Message-----
> > > > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > > To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> > > > <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> > > > Len Brown <lenb@kernel.org>
> > > > Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
> > > > kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
> > > > Subject: [PATCH] ACPICA: Export mutex functions
> > > >
> > > > Mutex functions may be needed by drivers. Examples are accesses to
> > > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > > environmental monitor registers, both which may also be accessed through
> > > > DSDT.
> > > >
> > > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > > ---
> > > >  drivers/acpi/acpica/utxfmutex.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > > 100644
> > > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> > > > pathname, u16 timeout)
> > > >  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > > >  	return (status);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > > >
> > > >
> > > > /***********************************************************************
> > > > ********
> > > >   *
> > > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> > > > acpi_string pathname)
> > > >  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > > >  	return (AE_OK);
> > > >  }
> > > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > > --
> > > > 2.7.4
> > >
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel

[toc] | [prev] | [next] | [standalone]

#1624677

On 04/17/2017 02:48 AM, Zheng, Lv wrote:
> Hi,
>
>> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Zheng, Lv
>> Sent: Monday, April 17, 2017 5:40 PM
>> To: Guenter Roeck <linux@roeck-us.net>; Moore, Robert <robert.moore@intel.com>
>> Cc: linux-acpi@vger.kernel.org; devel@acpica.org; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
>>
>> 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.
>>
>> Thanks
>> Lv
>>
>>> 	...
>>>
>>> when used in conjunction with
>>>
>>> 	...
>>> 	Mutex (MUT0, 0x00)
>>> 	Method (ENFG, 1, NotSerialized)
>>> 	{
>>> 		Acquire (MUT0, 0x0FFF)
>>> 		...
>>> 	}
>>>
>>> doesn't really provide exclusive access to the resource(s) protected
>>> by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
>
> IMO, the use case you are talking about is commonly seen in an operation region access code.
> Most likely, we'll prepare a driver own lock, and use it for both driver initiated accesses and AML initiated accesses.
>
> Finally, how can the driver writer know which mutex he should acquire?
> AML mutexes should be invisible to the OS (except the global lock).
>
In my experimental code I am using DMI to determine the platform and provide
the mutex name to the kernel driver needing it.

> So I'm really confused by your argument.
> Please explain in details - what the resource is.
>

Super-IO ports 0x2e, 0x2f. If you look through the Linux kernel, and search for
superio_enter(), you'll see where that address space is used (for the most part
in watchdog, hwmon, and gpio drivers).

You are correct, the resource is in operation region access code.

Are you saying that the mutex (and other mutexes) may not be accessed from the OS,
ie that the respective ACPI mutex functions are not really supposed to be available
for the OS ?

Thanks,
Guenter

> Thanks
> Lv
>
>
>>>
>>> Outch. Really ?
>>>
>>> Thanks,
>>> Guenter
>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Guenter Roeck [mailto:linux@roeck-us.net]
>>>>> Sent: Wednesday, April 12, 2017 8:13 AM
>>>>> To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
>>>>> <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
>>>>> Len Brown <lenb@kernel.org>
>>>>> Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
>>>>> kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
>>>>> Subject: [PATCH] ACPICA: Export mutex functions
>>>>>
>>>>> Mutex functions may be needed by drivers. Examples are accesses to
>>>>> Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
>>>>> environmental monitor registers, both which may also be accessed through
>>>>> DSDT.
>>>>>
>>>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>>>>> ---
>>>>>  drivers/acpi/acpica/utxfmutex.c | 2 ++
>>>>>  1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/drivers/acpi/acpica/utxfmutex.c
>>>>> b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
>>>>> 100644
>>>>> --- a/drivers/acpi/acpica/utxfmutex.c
>>>>> +++ b/drivers/acpi/acpica/utxfmutex.c
>>>>> @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
>>>>> pathname, u16 timeout)
>>>>>  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
>>>>>  	return (status);
>>>>>  }
>>>>> +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
>>>>>
>>>>>
>>>>> /***********************************************************************
>>>>> ********
>>>>>   *
>>>>> @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
>>>>> acpi_string pathname)
>>>>>  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
>>>>>  	return (AE_OK);
>>>>>  }
>>>>> +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
>>>>> --
>>>>> 2.7.4
>>>>
>> _______________________________________________
>> Devel mailing list
>> Devel@acpica.org
>> https://lists.acpica.org/mailman/listinfo/devel
>

[toc] | [prev] | [next] | [standalone]

#1624920

Hi,

> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Guenter
> Roeck
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> On 04/17/2017 02:48 AM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Zheng, Lv
> >> Sent: Monday, April 17, 2017 5:40 PM
> >> To: Guenter Roeck <linux@roeck-us.net>; Moore, Robert <robert.moore@intel.com>
> >> Cc: linux-acpi@vger.kernel.org; devel@acpica.org; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> >> linux-kernel@vger.kernel.org
> >> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
> >>
> >> 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.
> >>
> >> Thanks
> >> Lv
> >>
> >>> 	...
> >>>
> >>> when used in conjunction with
> >>>
> >>> 	...
> >>> 	Mutex (MUT0, 0x00)
> >>> 	Method (ENFG, 1, NotSerialized)
> >>> 	{
> >>> 		Acquire (MUT0, 0x0FFF)
> >>> 		...
> >>> 	}
> >>>
> >>> doesn't really provide exclusive access to the resource(s) protected
> >>> by MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
> >
> > IMO, the use case you are talking about is commonly seen in an operation region access code.
> > Most likely, we'll prepare a driver own lock, and use it for both driver initiated accesses and AML
> initiated accesses.
> >
> > Finally, how can the driver writer know which mutex he should acquire?
> > AML mutexes should be invisible to the OS (except the global lock).
> >
> In my experimental code I am using DMI to determine the platform and provide
> the mutex name to the kernel driver needing it.
> 
> > So I'm really confused by your argument.
> > Please explain in details - what the resource is.
> >
> 
> Super-IO ports 0x2e, 0x2f. If you look through the Linux kernel, and search for
> superio_enter(), you'll see where that address space is used (for the most part
> in watchdog, hwmon, and gpio drivers).
> 
> You are correct, the resource is in operation region access code.
> 
> Are you saying that the mutex (and other mutexes) may not be accessed from the OS,
> ie that the respective ACPI mutex functions are not really supposed to be available
> for the OS ?
> 

First, the super-IO access driver itself should make sure that Super-IO ports accesses are atomic.
It may lock around a transactional access including read-modify-write.
Let me call it L(SIO)/U(SIO).

Then the operation region driver need to lock around an entire AML opregion field read/write initiated by Store().
It may include several read-modify-write transactions.
Let me call it L(SOR)/U(SOR).
There might be one problem here as ACPICA cannot pass an entire AML opregion access to the address space callback once.
That might be the root cause of your problem.
But may not affect your use case.
You should know this better than me.
In case of EC driver (drivers/acpi/ec.c), I noticed that it is safe without improve this in ACPICA.
However for other operation regions, I have no idea.
Maybe you can tell me if we need to make this improvement in ACPICA.

Then the mutexes provided in AML is meant serialize accesses in AML.
Let me call it L(SMX)/U(SMX).
Not for the purpose to replace the SIO/SOR.

So from the AML point of view, the entire functionality may be performed in this way:
L(SMX)
  Read(some requests)
    L(SOR)
      L(SIO)
        Read(super IO)
      U(SIO)
    U(SOR)
  Write(some responses)
    L(SOR)
      L(SIO)
        Read(super IO)
      U(SIO)
      L(SIO)
        Read(super IO)
        Modify
        Write(super IO)
      U(SIO)
      ...
    U(SOR)
U(SMX)

It should work without allowing the OS driver to access the mutex provided in AML.
IMO, that could be the original design aspect for AML mutexes.

Thanks and best regards
Lv

> Thanks,
> Guenter
> 
> > Thanks
> > Lv
> >
> >
> >>>
> >>> Outch. Really ?
> >>>
> >>> Thanks,
> >>> Guenter
> >>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Guenter Roeck [mailto:linux@roeck-us.net]
> >>>>> Sent: Wednesday, April 12, 2017 8:13 AM
> >>>>> To: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> >>>>> <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> >>>>> Len Brown <lenb@kernel.org>
> >>>>> Cc: linux-acpi@vger.kernel.org; devel@acpica.org; linux-
> >>>>> kernel@vger.kernel.org; Guenter Roeck <linux@roeck-us.net>
> >>>>> Subject: [PATCH] ACPICA: Export mutex functions
> >>>>>
> >>>>> Mutex functions may be needed by drivers. Examples are accesses to
> >>>>> Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> >>>>> environmental monitor registers, both which may also be accessed through
> >>>>> DSDT.
> >>>>>
> >>>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> >>>>> ---
> >>>>>  drivers/acpi/acpica/utxfmutex.c | 2 ++
> >>>>>  1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/acpi/acpica/utxfmutex.c
> >>>>> b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> >>>>> 100644
> >>>>> --- a/drivers/acpi/acpica/utxfmutex.c
> >>>>> +++ b/drivers/acpi/acpica/utxfmutex.c
> >>>>> @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string
> >>>>> pathname, u16 timeout)
> >>>>>  	status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> >>>>>  	return (status);
> >>>>>  }
> >>>>> +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> >>>>>
> >>>>>
> >>>>> /***********************************************************************
> >>>>> ********
> >>>>>   *
> >>>>> @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle,
> >>>>> acpi_string pathname)
> >>>>>  	acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> >>>>>  	return (AE_OK);
> >>>>>  }
> >>>>> +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> >>>>> --
> >>>>> 2.7.4
> >>>>
> >> _______________________________________________
> >> Devel mailing list
> >> Devel@acpica.org
> >> https://lists.acpica.org/mailman/listinfo/devel
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1624727

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

[toc] | [prev] | [next] | [standalone]

#1624749

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.


> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: Monday, April 17, 2017 8:57 AM
> 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
> 
> 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

[toc] | [prev] | [next] | [standalone]

#1624847

> -----Original Message-----
> From: Moore, Robert
> Sent: Monday, April 17, 2017 10:13 AM
> To: Guenter Roeck <linux@roeck-us.net>; Zheng, Lv <lv.zheng@intel.com>
> Cc: Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
> <lenb@kernel.org>; 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.
Bob

[toc] | [prev] | [next] | [standalone]

#1624859

On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> 
> > -----Original Message-----
> > From: Moore, Robert
> > Sent: Monday, April 17, 2017 10:13 AM
> > To: Guenter Roeck <linux@roeck-us.net>; Zheng, Lv <lv.zheng@intel.com>
> > Cc: Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
> > <lenb@kernel.org>; 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.
> 
From the context in the dsdt, and from description of expected use cases for
_DLM objects I can find, this is what the mutex is used for (to serialize
access to a resource on a low pin count serial interconnect, aka LPC).

What does that mean in practice ? That I am not supposed to use it because
it doesn't follow standard ACPI mutex declaration rules ?

Thanks,
Guenter

> 
> 
> 
> Other than this case, the OS/drivers should never need to directly acquire an AML mutex.
> Bob
> 

[toc] | [prev] | [next] | [standalone]

#1624869

> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: Monday, April 17, 2017 12:45 PM
> To: Moore, Robert <robert.moore@intel.com>
> Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki@intel.com>; 'Len Brown' <lenb@kernel.org>; 'linux-
> acpi@vger.kernel.org' <linux-acpi@vger.kernel.org>; 'devel@acpica.org'
> <devel@acpica.org>; 'linux-kernel@vger.kernel.org' <linux-
> kernel@vger.kernel.org>; Box, David E <david.e.box@intel.com>
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> >
> > > -----Original Message-----
> > > From: Moore, Robert
> > > Sent: Monday, April 17, 2017 10:13 AM
> > > To: Guenter Roeck <linux@roeck-us.net>; Zheng, Lv
> > > <lv.zheng@intel.com>
> > > Cc: Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
> > > <lenb@kernel.org>; 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.
> >
> From the context in the dsdt, and from description of expected use cases
> for _DLM objects I can find, this is what the mutex is used for (to
> serialize access to a resource on a low pin count serial interconnect,
> aka LPC).
> 
> What does that mean in practice ? That I am not supposed to use it
> because it doesn't follow standard ACPI mutex declaration rules ?
> 
> Thanks,
> Guenter
> 
> >
[Moore, Robert] 

I'm not an expert on the _DLM method, but I would point you to the description section in the ACPI spec, 5.7.5 _DLM (DeviceLock Mutex).





> >
> >
> > Other than this case, the OS/drivers should never need to directly
> acquire an AML mutex.
> > Bob
> >

[toc] | [prev] | [next] | [standalone]

#1624875

On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> 
> 
> > -----Original Message-----
> > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > Sent: Monday, April 17, 2017 12:45 PM
> > To: Moore, Robert <robert.moore@intel.com>
> > Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
> > <rafael.j.wysocki@intel.com>; 'Len Brown' <lenb@kernel.org>; 'linux-
> > acpi@vger.kernel.org' <linux-acpi@vger.kernel.org>; 'devel@acpica.org'
> > <devel@acpica.org>; 'linux-kernel@vger.kernel.org' <linux-
> > kernel@vger.kernel.org>; Box, David E <david.e.box@intel.com>
> > Subject: Re: [PATCH] ACPICA: Export mutex functions
> > 
> > On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> > >
> > > > -----Original Message-----
> > > > From: Moore, Robert
> > > > Sent: Monday, April 17, 2017 10:13 AM
> > > > To: Guenter Roeck <linux@roeck-us.net>; Zheng, Lv
> > > > <lv.zheng@intel.com>
> > > > Cc: Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
> > > > <lenb@kernel.org>; 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.
> > >
> > From the context in the dsdt, and from description of expected use cases
> > for _DLM objects I can find, this is what the mutex is used for (to
> > serialize access to a resource on a low pin count serial interconnect,
> > aka LPC).
> > 
> > What does that mean in practice ? That I am not supposed to use it
> > because it doesn't follow standard ACPI mutex declaration rules ?
> > 
> > Thanks,
> > Guenter
> > 
> > >
> [Moore, Robert] 
> 
> I'm not an expert on the _DLM method, but I would point you to the description section in the ACPI spec, 5.7.5 _DLM (DeviceLock Mutex).
> 

I did. However, not being an ACPI expert, that doesn't tell me anything.

Guenter

> 
> 
> > >
> > >
> > > Other than this case, the OS/drivers should never need to directly
> > acquire an AML mutex.
> > > Bob
> > >

[toc] | [prev] | [next] | [standalone]

#1624877

On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
>>
>>
>> > -----Original Message-----
>> > From: Guenter Roeck [mailto:linux@roeck-us.net]
>> > Sent: Monday, April 17, 2017 12:45 PM
>> > To: Moore, Robert <robert.moore@intel.com>
>> > Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
>> > <rafael.j.wysocki@intel.com>; 'Len Brown' <lenb@kernel.org>; 'linux-
>> > acpi@vger.kernel.org' <linux-acpi@vger.kernel.org>; 'devel@acpica.org'
>> > <devel@acpica.org>; 'linux-kernel@vger.kernel.org' <linux-
>> > kernel@vger.kernel.org>; Box, David E <david.e.box@intel.com>
>> > Subject: Re: [PATCH] ACPICA: Export mutex functions
>> >
>> > On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
>> > >
>> > > > -----Original Message-----
>> > > > From: Moore, Robert
>> > > > Sent: Monday, April 17, 2017 10:13 AM
>> > > > To: Guenter Roeck <linux@roeck-us.net>; Zheng, Lv
>> > > > <lv.zheng@intel.com>
>> > > > Cc: Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
>> > > > <lenb@kernel.org>; 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.
>> > >
>> > From the context in the dsdt, and from description of expected use cases
>> > for _DLM objects I can find, this is what the mutex is used for (to
>> > serialize access to a resource on a low pin count serial interconnect,
>> > aka LPC).
>> >
>> > What does that mean in practice ? That I am not supposed to use it
>> > because it doesn't follow standard ACPI mutex declaration rules ?
>> >
>> > Thanks,
>> > Guenter
>> >
>> > >
>> [Moore, Robert]
>>
>> I'm not an expert on the _DLM method, but I would point you to the description section in the ACPI spec, 5.7.5 _DLM (DeviceLock Mutex).
>>
>
> I did. However, not being an ACPI expert, that doesn't tell me anything.

Basically, if the kernel and AML need to access a device concurrently,
there should be a _DLM object under that device in the ACPI tables.
In that case it is expected to return a list of (AML) mutexes that can
be acquired by the kernel in order to synchronize device access with
respect to AML (and for each mutex it may also return a description of
the specific resources to be protected by it).

Bottom line: without _DLM, the kernel cannot synchronize things with
respect to AML properly, because it has no information how to do that
then.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1624891

On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote:
> On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> >>
> >>
> >> > -----Original Message-----
> >> > From: Guenter Roeck [mailto:linux@roeck-us.net]
> >> > Sent: Monday, April 17, 2017 12:45 PM
> >> > To: Moore, Robert <robert.moore@intel.com>
> >> > Cc: Zheng, Lv <lv.zheng@intel.com>; Wysocki, Rafael J
> >> > <rafael.j.wysocki@intel.com>; 'Len Brown' <lenb@kernel.org>; 'linux-
> >> > acpi@vger.kernel.org' <linux-acpi@vger.kernel.org>; 'devel@acpica.org'
> >> > <devel@acpica.org>; 'linux-kernel@vger.kernel.org' <linux-
> >> > kernel@vger.kernel.org>; Box, David E <david.e.box@intel.com>
> >> > Subject: Re: [PATCH] ACPICA: Export mutex functions
> >> >
> >> > On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: Moore, Robert
> >> > > > Sent: Monday, April 17, 2017 10:13 AM
> >> > > > To: Guenter Roeck <linux@roeck-us.net>; Zheng, Lv
> >> > > > <lv.zheng@intel.com>
> >> > > > Cc: Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
> >> > > > <lenb@kernel.org>; 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.
> >> > >
> >> > From the context in the dsdt, and from description of expected use cases
> >> > for _DLM objects I can find, this is what the mutex is used for (to
> >> > serialize access to a resource on a low pin count serial interconnect,
> >> > aka LPC).
> >> >
> >> > What does that mean in practice ? That I am not supposed to use it
> >> > because it doesn't follow standard ACPI mutex declaration rules ?
> >> >
> >> > Thanks,
> >> > Guenter
> >> >
> >> > >
> >> [Moore, Robert]
> >>
> >> I'm not an expert on the _DLM method, but I would point you to the description section in the ACPI spec, 5.7.5 _DLM (DeviceLock Mutex).
> >>
> >
> > I did. However, not being an ACPI expert, that doesn't tell me anything.
> 
> Basically, if the kernel and AML need to access a device concurrently,
> there should be a _DLM object under that device in the ACPI tables.
> In that case it is expected to return a list of (AML) mutexes that can
> be acquired by the kernel in order to synchronize device access with
> respect to AML (and for each mutex it may also return a description of
> the specific resources to be protected by it).
> 
> Bottom line: without _DLM, the kernel cannot synchronize things with
> respect to AML properly, because it has no information how to do that
> then.

That is all quite interesting. I do see the mutex in question used on various
motherboards from various vendors (I checked boards from Gigabyte, MSI, and
Intel). Interestingly, the naming seems to be consistent - it is always named
"MUT0". For the most part, it seems to be available on more recent
motherboards; older motherboards tend to use the resource without locking.
However, I don't see any mention of "_DLM" in any of the DSDTs.

At the same time, access to ports 0x2e/0x2f is widely used in the kernel.
As mentioned before, it is used in watchdog, hardware monitoring, and gpio
drivers, but also in parallel port and infrared driver code. Effectively
that means that all this code is inherently unsafe on systems with ACPI
support.

I had thought about implementing a set of utility functions to make the kernel
code safer to use if the mutex is found to exist. Right now I wonder, though,
if such code would have a chance to be accepted. Any thoughts on that ?

Thanks,
Guenter

> 
> Thanks,
> Rafael

[toc] | [prev] | [next] | [standalone]

#1624897

On Tue, Apr 18, 2017 at 12:32 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote:
>> On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
>> >>

[cut]

>> >> [Moore, Robert]
>> >>
>> >> I'm not an expert on the _DLM method, but I would point you to the description section in the ACPI spec, 5.7.5 _DLM (DeviceLock Mutex).
>> >>
>> >
>> > I did. However, not being an ACPI expert, that doesn't tell me anything.
>>
>> Basically, if the kernel and AML need to access a device concurrently,
>> there should be a _DLM object under that device in the ACPI tables.
>> In that case it is expected to return a list of (AML) mutexes that can
>> be acquired by the kernel in order to synchronize device access with
>> respect to AML (and for each mutex it may also return a description of
>> the specific resources to be protected by it).
>>
>> Bottom line: without _DLM, the kernel cannot synchronize things with
>> respect to AML properly, because it has no information how to do that
>> then.
>
> That is all quite interesting. I do see the mutex in question used on various
> motherboards from various vendors (I checked boards from Gigabyte, MSI, and
> Intel). Interestingly, the naming seems to be consistent - it is always named
> "MUT0". For the most part, it seems to be available on more recent
> motherboards; older motherboards tend to use the resource without locking.
> However, I don't see any mention of "_DLM" in any of the DSDTs.
>
> At the same time, access to ports 0x2e/0x2f is widely used in the kernel.
> As mentioned before, it is used in watchdog, hardware monitoring, and gpio
> drivers, but also in parallel port and infrared driver code. Effectively
> that means that all this code is inherently unsafe on systems with ACPI
> support.

If AML accesses those ports via operation regions, then it is unsafe.

Note, however, that the mere existence of operation regions covering
them doesn't automatically mean that they are accessed by any AML on
the given platform.

> I had thought about implementing a set of utility functions to make the kernel
> code safer to use if the mutex is found to exist. Right now I wonder, though,
> if such code would have a chance to be accepted. Any thoughts on that ?

You can argue that there should be _DLM objects in the ACPI tables on
those platforms, but they are missing, so platform quirks (or
something else to that effect) are needed to ensure mutual exclusion
between AML accesses and direct accesses in drivers etc.

Unlike in the DT case, we have no influence on what the vendors put
into the ACPI tables on their systems, so we need to live with what is
in there and possibly fix up things as needed.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web