ACPICA: Export mutex functions

Commit Message

Guenter Roeck April 12, 2017, 3:13 p.m. UTC

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 <[e-mail]>
---
 drivers/acpi/acpica/utxfmutex.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Moore, Robert April 12, 2017, 3:29 p.m. UTC | #1

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:[e-mail]]
> Sent: Wednesday, April 12, 2017 8:13 AM
> To: Moore, Robert <[e-mail]>; Zheng, Lv
> <[e-mail]>; Wysocki, Rafael J <[e-mail]>;
> Len Brown <[e-mail]>
> Cc: [e-mail]; [e-mail]; linux-
> [e-mail]; Guenter Roeck <[e-mail]>
> 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 <[e-mail]>
> ---
>  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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 12, 2017, 9:22 p.m. UTC | #2

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:[e-mail]]
> > Sent: Wednesday, April 12, 2017 8:13 AM
> > To: Moore, Robert <[e-mail]>; Zheng, Lv
> > <[e-mail]>; Wysocki, Rafael J <[e-mail]>;
> > Len Brown <[e-mail]>
> > Cc: [e-mail]; [e-mail]; linux-
> > [e-mail]; Guenter Roeck <[e-mail]>
> > 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 <[e-mail]>
> > ---
> >  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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moore, Robert April 12, 2017, 9:56 p.m. UTC | #3

> -----Original Message-----
> From: Guenter Roeck [mailto:[e-mail]]
> Sent: Wednesday, April 12, 2017 2:23 PM
> To: Moore, Robert <[e-mail]>
> Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
> <[e-mail]>; Len Brown <[e-mail]>; linux-
> [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]]
> > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > To: Moore, Robert <[e-mail]>; Zheng, Lv
> > > <[e-mail]>; Wysocki, Rafael J
> > > <[e-mail]>; Len Brown <[e-mail]>
> > > Cc: [e-mail]; [e-mail]; linux-
> > > [e-mail]; Guenter Roeck <[e-mail]>
> > > 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 <[e-mail]>
> > > ---
> > >  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
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 13, 2017, 12:55 a.m. UTC | #4

On Wed, Apr 12, 2017 at 09:56:37PM +0000, Moore, Robert wrote:
> 
> 
> > -----Original Message-----
> > From: Guenter Roeck [mailto:[e-mail]]
> > Sent: Wednesday, April 12, 2017 2:23 PM
> > To: Moore, Robert <[e-mail]>
> > Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
> > <[e-mail]>; Len Brown <[e-mail]>; linux-
> > [e-mail]; [e-mail]; [e-mail]
> > 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:[e-mail]]
> > > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > > To: Moore, Robert <[e-mail]>; Zheng, Lv
> > > > <[e-mail]>; Wysocki, Rafael J
> > > > <[e-mail]>; Len Brown <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]; linux-
> > > > [e-mail]; Guenter Roeck <[e-mail]>
> > > > 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 <[e-mail]>
> > > > ---
> > > >  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
> > >
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki April 14, 2017, 10:30 p.m. UTC | #5

On Wednesday, April 12, 2017 09:56:37 PM Moore, Robert wrote:
> 
> > -----Original Message-----
> > From: Guenter Roeck [mailto:[e-mail]]
> > Sent: Wednesday, April 12, 2017 2:23 PM
> > To: Moore, Robert <[e-mail]>
> > Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
> > <[e-mail]>; Len Brown <[e-mail]>; linux-
> > [e-mail]; [e-mail]; [e-mail]
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moore, Robert April 14, 2017, 11:32 p.m. UTC | #6

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:[e-mail]]
> Sent: Friday, April 14, 2017 3:30 PM
> To: Moore, Robert
> Cc: Guenter Roeck; Zheng, Lv; Wysocki, Rafael J; Len Brown; linux-
> [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]]
> > > Sent: Wednesday, April 12, 2017 2:23 PM
> > > To: Moore, Robert <[e-mail]>
> > > Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
> > > <[e-mail]>; Len Brown <[e-mail]>; linux-
> > > [e-mail]; [e-mail]; [e-mail]
> > > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 17, 2017, 9:39 a.m. UTC | #7

Hi,

> From: Guenter Roeck [mailto:[e-mail]]
> 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:[e-mail]]
> > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > To: Moore, Robert <[e-mail]>; Zheng, Lv
> > > <[e-mail]>; Wysocki, Rafael J <[e-mail]>;
> > > Len Brown <[e-mail]>
> > > Cc: [e-mail]; [e-mail]; linux-
> > > [e-mail]; Guenter Roeck <[e-mail]>
> > > 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 <[e-mail]>
> > > ---
> > >  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
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 17, 2017, 9:48 a.m. UTC | #8

Hi,

> From: Devel [mailto:[e-mail]] On Behalf Of Zheng, Lv
> Sent: Monday, April 17, 2017 5:40 PM
> To: Guenter Roeck <[e-mail]>; Moore, Robert <[e-mail]>
> Cc: [e-mail]; [e-mail]; Wysocki, Rafael J <[e-mail]>;
> [e-mail]
> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
> 
> Hi,
> 
> > From: Guenter Roeck [mailto:[e-mail]]
> > 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:[e-mail]]
> > > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > > To: Moore, Robert <[e-mail]>; Zheng, Lv
> > > > <[e-mail]>; Wysocki, Rafael J <[e-mail]>;
> > > > Len Brown <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]; linux-
> > > > [e-mail]; Guenter Roeck <[e-mail]>
> > > > 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 <[e-mail]>
> > > > ---
> > > >  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
> [e-mail]
> 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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 17, 2017, 2:05 p.m. UTC | #9

On 04/17/2017 02:48 AM, Zheng, Lv wrote:
> Hi,
>
>> From: Devel [mailto:[e-mail]] On Behalf Of Zheng, Lv
>> Sent: Monday, April 17, 2017 5:40 PM
>> To: Guenter Roeck <[e-mail]>; Moore, Robert <[e-mail]>
>> Cc: [e-mail]; [e-mail]; Wysocki, Rafael J <[e-mail]>;
>> [e-mail]
>> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
>>
>> Hi,
>>
>>> From: Guenter Roeck [mailto:[e-mail]]
>>> 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:[e-mail]]
>>>>> Sent: Wednesday, April 12, 2017 8:13 AM
>>>>> To: Moore, Robert <[e-mail]>; Zheng, Lv
>>>>> <[e-mail]>; Wysocki, Rafael J <[e-mail]>;
>>>>> Len Brown <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail]; linux-
>>>>> [e-mail]; Guenter Roeck <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>> ---
>>>>>  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
>> [e-mail]
>> 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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 17, 2017, 3:56 p.m. UTC | #10

Hi,

On Mon, Apr 17, 2017 at 09:39:35AM +0000, Zheng, Lv wrote:
> Hi,
> 
> > From: Guenter Roeck [mailto:[e-mail]]
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moore, Robert April 17, 2017, 5:12 p.m. UTC | #11

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:[e-mail]]
> Sent: Monday, April 17, 2017 8:57 AM
> To: Zheng, Lv
> Cc: Moore, Robert; Wysocki, Rafael J; Len Brown; linux-
> [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]]
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moore, Robert April 17, 2017, 7:27 p.m. UTC | #12

> -----Original Message-----
> From: Moore, Robert
> Sent: Monday, April 17, 2017 10:13 AM
> To: Guenter Roeck <[e-mail]>; Zheng, Lv <[e-mail]>
> Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> <[e-mail]>; [e-mail]; [e-mail]; linux-
> [e-mail]
> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moore, Robert April 17, 2017, 7:35 p.m. UTC | #13

> -----Original Message-----
> From: Moore, Robert
> Sent: Monday, April 17, 2017 12:28 PM
> To: 'Guenter Roeck' <[e-mail]>; Zheng, Lv <[e-mail]>
> Cc: Wysocki, Rafael J <[e-mail]>; 'Len Brown'
> <[e-mail]>; '[e-mail]' <linux-
> [e-mail]>; '[e-mail]' <[e-mail]>; 'linux-
> [e-mail]' <[e-mail]>; Box, David E
> ([e-mail]) <[e-mail]>
> Subject: RE: [PATCH] ACPICA: Export mutex functions
> 
> 
> > -----Original Message-----
> > From: Moore, Robert
> > Sent: Monday, April 17, 2017 10:13 AM
> > To: Guenter Roeck <[e-mail]>; Zheng, Lv <[e-mail]>
> > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> > <[e-mail]>; [e-mail]; [e-mail];
> > linux- [e-mail]
> > 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

[Moore, Robert] 
Here is more information, from the ACPICA reference:

8.3.15 AcpiAcquireMutex

This function is intended to be used in conjunction with the _DLM (Device Lock Method) predefined name to directly acquire a mutex object that is defined in the ACPI namespace. The purpose of this is to provide a mutual exclusion mechanism between the AML interpreter and an ACPI-related device driver, in order to support multiple-operation transactions.

From the ACPI Specification: "The _DLM object appears in a device scope when AML access to the device must be synchronized with the OS environment. It is used in conjunction with a standard Mutex object. With _DLM, the standard Mutex provides synchronization within the AML environment as usual, but also synchronizes with the OS environment."

The AML mutex node is pointed to by Parent:Pathname. Either the Parent or the Pathname can be NULL, but not both.

If the operation fails an appropriate status will be returned.


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 17, 2017, 7:45 p.m. UTC | #14

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 <[e-mail]>; Zheng, Lv <[e-mail]>
> > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> > <[e-mail]>; [e-mail]; [e-mail]; linux-
> > [e-mail]
> > 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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moore, Robert April 17, 2017, 8:40 p.m. UTC | #15

> -----Original Message-----
> From: Guenter Roeck [mailto:[e-mail]]
> Sent: Monday, April 17, 2017 12:45 PM
> To: Moore, Robert <[e-mail]>
> Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
> <[e-mail]>; 'Len Brown' <[e-mail]>; 'linux-
> [e-mail]' <[e-mail]>; '[e-mail]'
> <[e-mail]>; '[e-mail]' <linux-
> [e-mail]>; Box, David E <[e-mail]>
> 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 <[e-mail]>; Zheng, Lv
> > > <[e-mail]>
> > > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> > > <[e-mail]>; [e-mail]; [e-mail];
> > > linux- [e-mail]
> > > 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
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 17, 2017, 9:03 p.m. UTC | #16

On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> 
> 
> > -----Original Message-----
> > From: Guenter Roeck [mailto:[e-mail]]
> > Sent: Monday, April 17, 2017 12:45 PM
> > To: Moore, Robert <[e-mail]>
> > Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
> > <[e-mail]>; 'Len Brown' <[e-mail]>; 'linux-
> > [e-mail]' <[e-mail]>; '[e-mail]'
> > <[e-mail]>; '[e-mail]' <linux-
> > [e-mail]>; Box, David E <[e-mail]>
> > 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 <[e-mail]>; Zheng, Lv
> > > > <[e-mail]>
> > > > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> > > > <[e-mail]>; [e-mail]; [e-mail];
> > > > linux- [e-mail]
> > > > 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
> > >
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki April 17, 2017, 9:29 p.m. UTC | #17

On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck <[e-mail]> wrote:
> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
>>
>>
>> > -----Original Message-----
>> > From: Guenter Roeck [mailto:[e-mail]]
>> > Sent: Monday, April 17, 2017 12:45 PM
>> > To: Moore, Robert <[e-mail]>
>> > Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
>> > <[e-mail]>; 'Len Brown' <[e-mail]>; 'linux-
>> > [e-mail]' <[e-mail]>; '[e-mail]'
>> > <[e-mail]>; '[e-mail]' <linux-
>> > [e-mail]>; Box, David E <[e-mail]>
>> > 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 <[e-mail]>; Zheng, Lv
>> > > > <[e-mail]>
>> > > > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
>> > > > <[e-mail]>; [e-mail]; [e-mail];
>> > > > linux- [e-mail]
>> > > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 17, 2017, 10:32 p.m. UTC | #18

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 <[e-mail]> wrote:
> > On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> >>
> >>
> >> > -----Original Message-----
> >> > From: Guenter Roeck [mailto:[e-mail]]
> >> > Sent: Monday, April 17, 2017 12:45 PM
> >> > To: Moore, Robert <[e-mail]>
> >> > Cc: Zheng, Lv <[e-mail]>; Wysocki, Rafael J
> >> > <[e-mail]>; 'Len Brown' <[e-mail]>; 'linux-
> >> > [e-mail]' <[e-mail]>; '[e-mail]'
> >> > <[e-mail]>; '[e-mail]' <linux-
> >> > [e-mail]>; Box, David E <[e-mail]>
> >> > 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 <[e-mail]>; Zheng, Lv
> >> > > > <[e-mail]>
> >> > > > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> >> > > > <[e-mail]>; [e-mail]; [e-mail];
> >> > > > linux- [e-mail]
> >> > > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki April 17, 2017, 10:56 p.m. UTC | #19

On Tue, Apr 18, 2017 at 12:32 AM, Guenter Roeck <[e-mail]> 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 <[e-mail]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 17, 2017, 11:35 p.m. UTC | #20

Hi,

> From: [e-mail] [mailto:[e-mail]] 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:[e-mail]] On Behalf Of Zheng, Lv
> >> Sent: Monday, April 17, 2017 5:40 PM
> >> To: Guenter Roeck <[e-mail]>; Moore, Robert <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; Wysocki, Rafael J <[e-mail]>;
> >> [e-mail]
> >> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
> >>
> >> Hi,
> >>
> >>> From: Guenter Roeck [mailto:[e-mail]]
> >>> 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:[e-mail]]
> >>>>> Sent: Wednesday, April 12, 2017 8:13 AM
> >>>>> To: Moore, Robert <[e-mail]>; Zheng, Lv
> >>>>> <[e-mail]>; Wysocki, Rafael J <[e-mail]>;
> >>>>> Len Brown <[e-mail]>
> >>>>> Cc: [e-mail]; [e-mail]; linux-
> >>>>> [e-mail]; Guenter Roeck <[e-mail]>
> >>>>> 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 <[e-mail]>
> >>>>> ---
> >>>>>  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
> >> [e-mail]
> >> 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 [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 17, 2017, 11:37 p.m. UTC | #21

Hi,

> From: Guenter Roeck [mailto:[e-mail]]
> 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:[e-mail]]
> > > 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.

Please refer to my previous reply.
Why don't you make it safe in super IO driver and the opregion driver in first place.
Then check if you still need to acquire the mutex.

> 
> 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 ?
> 

I didn't mean that.
Probably you have synchronization problems in the OS driver.

Thanks and best regards
Lv

> Thanks,
> Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 17, 2017, 11:43 p.m. UTC | #22

Hi,

> -----Original Message-----
> From: Moore, Robert
> Sent: Tuesday, April 18, 2017 3:28 AM
> To: 'Guenter Roeck' <[e-mail]>; Zheng, Lv <[e-mail]>
> Cc: Wysocki, Rafael J <[e-mail]>; 'Len Brown' <[e-mail]>; 'linux-
> [e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>; 'linux-
> [e-mail]' <[e-mail]>; Box, David E <[e-mail]>
> Subject: RE: [PATCH] ACPICA: Export mutex functions
> 
> 
> > -----Original Message-----
> > From: Moore, Robert
> > Sent: Monday, April 17, 2017 10:13 AM
> > To: Guenter Roeck <[e-mail]>; Zheng, Lv <[e-mail]>
> > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> > <[e-mail]>; [e-mail]; [e-mail]; linux-
> > [e-mail]
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 17, 2017, 11:46 p.m. UTC | #23

Hi,

> From: Guenter Roeck [mailto:[e-mail]]
> Sent: Tuesday, April 18, 2017 3:45 AM
> 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 <[e-mail]>; Zheng, Lv <[e-mail]>
> > > Cc: Wysocki, Rafael J <[e-mail]>; Len Brown
> > > <[e-mail]>; [e-mail]; [e-mail]; linux-
> > > [e-mail]
> > > 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 ?
> 

Could you find related _DLMs in your DSDT?
If there is any, could you please post it here for reference?

Thanks
Lv

> Thanks,
> Guenter
> 
> >
> >
> >
> > Other than this case, the OS/drivers should never need to directly acquire an AML mutex.
> > Bob
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 17, 2017, 11:53 p.m. UTC | #24

Hi,

> From: Guenter Roeck [mailto:[e-mail]]
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> 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 <[e-mail]> wrote:
> > > On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> > >>
> > >>
> > >> > From: Guenter Roeck [mailto:[e-mail]]
> > >> > Subject: Re: [PATCH] ACPICA: Export mutex functions
> > >> >
> > >> > On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> > >> > >
> > >> > > > From: Moore, Robert
> > >> > > > 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.
> 

OK, then you might be having problems in your opregion driver.

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

As what you've mentioned, there are already lots of parallel accesses in kernel without enabling ACPI.
Are these accesses mutually exclusive (safe)?
If so, why do you need to invent a new synchronization mechanism?

> Right now I wonder, though,
> if such code would have a chance to be accepted. Any thoughts on that ?

Is that possible to make it safe in the opregion driver?

Thanks
Lv
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 18, 2017, 4:35 a.m. UTC | #25

On 04/17/2017 04:53 PM, Zheng, Lv wrote:
> Hi,
>
>> From: Guenter Roeck [mailto:[e-mail]]
>> Subject: Re: [PATCH] ACPICA: Export mutex functions
>>
>> 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 <[e-mail]> wrote:
>>>> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
>>>>>
>>>>>
>>>>>> From: Guenter Roeck [mailto:[e-mail]]
>>>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
>>>>>>
>>>>>> On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
>>>>>>>
>>>>>>>> From: Moore, Robert
>>>>>>>> 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.
>>
>
> OK, then you might be having problems in your opregion driver.
>
>> 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.
>
> As what you've mentioned, there are already lots of parallel accesses in kernel without enabling ACPI.
> Are these accesses mutually exclusive (safe)?

In-kernel, yes (using request_muxed_region). Against ACPI, no.

> If so, why do you need to invent a new synchronization mechanism?
>

Because I am seeing a problem with the current code (more specifically,
with the it87 hwmon driver) on new Gigabyte boards.

>> Right now I wonder, though,
>> if such code would have a chance to be accepted. Any thoughts on that ?
>
> Is that possible to make it safe in the opregion driver?
>

Sorry, I don't think I understand what you mean with "opregion driver".
Do you refer to the drivers accessing the memory region in question,
or in other words replicating the necessary code in every driver accessing
that region ? Sure, I can do that, if that is the preferred solution;
I have no problem with that. However, that would require exporting
the ACPI mutex functions. My understanding is that you are opposed to
exporting those, so I assume that is not what you refer to.
Can you clarify ?

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 18, 2017, 7:06 a.m. UTC | #26

Hi,

> From: Guenter Roeck [mailto:[e-mail]]
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> On 04/17/2017 04:53 PM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Guenter Roeck [mailto:[e-mail]]
> >> Subject: Re: [PATCH] ACPICA: Export mutex functions
> >>
> >> 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 <[e-mail]> wrote:
> >>>> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> >>>>>
> >>>>>
> >>>>>> From: Guenter Roeck [mailto:[e-mail]]
> >>>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> >>>>>>
> >>>>>> On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> >>>>>>>
> >>>>>>>> From: Moore, Robert
> >>>>>>>> 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.
> >>
> >
> > OK, then you might be having problems in your opregion driver.
> >
> >> 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.
> >
> > As what you've mentioned, there are already lots of parallel accesses in kernel without enabling
> ACPI.
> > Are these accesses mutually exclusive (safe)?
> 
> In-kernel, yes (using request_muxed_region). Against ACPI, no.
> 
> > If so, why do you need to invent a new synchronization mechanism?
> >
> 
> Because I am seeing a problem with the current code (more specifically,
> with the it87 hwmon driver) on new Gigabyte boards.

I checked superio_enter()/superio_exit(), IMO, the mutual exclusion
might be handled using 1 of the following 2 solutions:

1. _DLM, then you can find superio related mutex from _DLM and
   acquire/release it in superio_enter()/superio_exit().
   You really need a set of new APIs to acquire the _DLM related mutex.
   If you don't have _DLM in your DSDT, directly exporting ACPICA mutex
   functions seem to be a reasonable solution.
2. Normally, AML developer should abstract superio accesses into customized
   opregion, then you can prepare a superio opregion driver.

> 
> >> Right now I wonder, though,
> >> if such code would have a chance to be accepted. Any thoughts on that ?
> >
> > Is that possible to make it safe in the opregion driver?
> >
> 
> Sorry, I don't think I understand what you mean with "opregion driver".
> Do you refer to the drivers accessing the memory region in question,
> or in other words replicating the necessary code in every driver accessing
> that region ? Sure, I can do that, if that is the preferred solution;
> I have no problem with that. However, that would require exporting
> the ACPI mutex functions. My understanding is that you are opposed to
> exporting those, so I assume that is not what you refer to.
> Can you clarify ?

I mean solution 2.
From it87_find() I really couldn't see a possibility to convert superio
accesses into opregions. Could you paste some example superio access AML
code from your DSDT here.

Thanks and best regards
Lv
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 18, 2017, 7:14 a.m. UTC | #27

Hi,

> From: Zheng, Lv
> Subject: RE: [PATCH] ACPICA: Export mutex functions
> 
> Hi,
> 
> > From: Guenter Roeck [mailto:[e-mail]]
> > Subject: Re: [PATCH] ACPICA: Export mutex functions
> >
> > On 04/17/2017 04:53 PM, Zheng, Lv wrote:
> > > Hi,
> > >
> > >> From: Guenter Roeck [mailto:[e-mail]]
> > >> Subject: Re: [PATCH] ACPICA: Export mutex functions
> > >>
> > >> 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 <[e-mail]> wrote:
> > >>>> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> > >>>>>
> > >>>>>
> > >>>>>> From: Guenter Roeck [mailto:[e-mail]]
> > >>>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> > >>>>>>
> > >>>>>> On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> > >>>>>>>
> > >>>>>>>> From: Moore, Robert
> > >>>>>>>> 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.
> > >>
> > >
> > > OK, then you might be having problems in your opregion driver.
> > >
> > >> 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.
> > >
> > > As what you've mentioned, there are already lots of parallel accesses in kernel without enabling
> > ACPI.
> > > Are these accesses mutually exclusive (safe)?
> >
> > In-kernel, yes (using request_muxed_region). Against ACPI, no.
> >
> > > If so, why do you need to invent a new synchronization mechanism?
> > >
> >
> > Because I am seeing a problem with the current code (more specifically,
> > with the it87 hwmon driver) on new Gigabyte boards.
> 
> I checked superio_enter()/superio_exit(), IMO, the mutual exclusion
> might be handled using 1 of the following 2 solutions:
> 
> 1. _DLM, then you can find superio related mutex from _DLM and
>    acquire/release it in superio_enter()/superio_exit().
>    You really need a set of new APIs to acquire the _DLM related mutex.
>    If you don't have _DLM in your DSDT, directly exporting ACPICA mutex
>    functions seem to be a reasonable solution.
> 2. Normally, AML developer should abstract superio accesses into customized
>    opregion, then you can prepare a superio opregion driver.
> 
> >
> > >> Right now I wonder, though,
> > >> if such code would have a chance to be accepted. Any thoughts on that ?
> > >
> > > Is that possible to make it safe in the opregion driver?
> > >
> >
> > Sorry, I don't think I understand what you mean with "opregion driver".
> > Do you refer to the drivers accessing the memory region in question,
> > or in other words replicating the necessary code in every driver accessing
> > that region ? Sure, I can do that, if that is the preferred solution;
> > I have no problem with that. However, that would require exporting
> > the ACPI mutex functions. My understanding is that you are opposed to
> > exporting those, so I assume that is not what you refer to.
> > Can you clarify ?
> 
> I mean solution 2.

Maybe I should provide more detailed examples for this solution.

For example:
OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100)
Field (SIOT, ByteAcc, Lock, Preserve)
{
    FNC1, 8,
    FNC2, 8,
    ...
}

Acquire (MUX0)
Store (0, FNC1)
Release (MUX0)

Then you can call (let me use casual pseudo code)
acpi_install_operation_region(SuperIOAddressSpace, superio_opregion_handler) from OS side.
In its callback superio_opregion_handler(), you can:

superio_enter();
If (address == 0) {
   /* mean FNC1 */
   Perform the locked superior accesses
} else if (address == 1) {
   /* mean FNC2 */
   Perform the locked superior accesses
}
superio_exit();

Are there similar approach in your DSDT?

Thanks and best regards
Lv

> From it87_find() I really couldn't see a possibility to convert superio
> accesses into opregions. Could you paste some example superio access AML
> code from your DSDT here.
> 
> Thanks and best regards
> Lv
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Guenter Roeck April 18, 2017, 1:50 p.m. UTC | #28

On 04/18/2017 12:14 AM, Zheng, Lv wrote:
> Hi,
>
>> From: Zheng, Lv
>> Subject: RE: [PATCH] ACPICA: Export mutex functions
>>
>> Hi,
>>
>>> From: Guenter Roeck [mailto:[e-mail]]
>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
>>>
>>> On 04/17/2017 04:53 PM, Zheng, Lv wrote:
>>>> Hi,
>>>>
>>>>> From: Guenter Roeck [mailto:[e-mail]]
>>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
>>>>>
>>>>> 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 <[e-mail]> wrote:
>>>>>>> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> From: Guenter Roeck [mailto:[e-mail]]
>>>>>>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
>>>>>>>>>
>>>>>>>>> On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
>>>>>>>>>>
>>>>>>>>>>> From: Moore, Robert
>>>>>>>>>>> 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.
>>>>>
>>>>
>>>> OK, then you might be having problems in your opregion driver.
>>>>
>>>>> 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.
>>>>
>>>> As what you've mentioned, there are already lots of parallel accesses in kernel without enabling
>>> ACPI.
>>>> Are these accesses mutually exclusive (safe)?
>>>
>>> In-kernel, yes (using request_muxed_region). Against ACPI, no.
>>>
>>>> If so, why do you need to invent a new synchronization mechanism?
>>>>
>>>
>>> Because I am seeing a problem with the current code (more specifically,
>>> with the it87 hwmon driver) on new Gigabyte boards.
>>
>> I checked superio_enter()/superio_exit(), IMO, the mutual exclusion
>> might be handled using 1 of the following 2 solutions:
>>
>> 1. _DLM, then you can find superio related mutex from _DLM and
>>    acquire/release it in superio_enter()/superio_exit().
>>    You really need a set of new APIs to acquire the _DLM related mutex.
>>    If you don't have _DLM in your DSDT, directly exporting ACPICA mutex
>>    functions seem to be a reasonable solution.
>> 2. Normally, AML developer should abstract superio accesses into customized
>>    opregion, then you can prepare a superio opregion driver.
>>
>>>
>>>>> Right now I wonder, though,
>>>>> if such code would have a chance to be accepted. Any thoughts on that ?
>>>>
>>>> Is that possible to make it safe in the opregion driver?
>>>>
>>>
>>> Sorry, I don't think I understand what you mean with "opregion driver".
>>> Do you refer to the drivers accessing the memory region in question,
>>> or in other words replicating the necessary code in every driver accessing
>>> that region ? Sure, I can do that, if that is the preferred solution;
>>> I have no problem with that. However, that would require exporting
>>> the ACPI mutex functions. My understanding is that you are opposed to
>>> exporting those, so I assume that is not what you refer to.
>>> Can you clarify ?
>>
>> I mean solution 2.
>
> Maybe I should provide more detailed examples for this solution.
>
> For example:
> OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100)
> Field (SIOT, ByteAcc, Lock, Preserve)
> {
>     FNC1, 8,
>     FNC2, 8,
>     ...
> }
>
> Acquire (MUX0)
> Store (0, FNC1)
> Release (MUX0)
>
> Then you can call (let me use casual pseudo code)
> acpi_install_operation_region(SuperIOAddressSpace, superio_opregion_handler) from OS side.
> In its callback superio_opregion_handler(), you can:
>
> superio_enter();
> If (address == 0) {
>    /* mean FNC1 */
>    Perform the locked superior accesses
> } else if (address == 1) {
>    /* mean FNC2 */
>    Perform the locked superior accesses
> }
> superio_exit();
>
> Are there similar approach in your DSDT?
>

Some snippets from the DSDT:

	Device (SIO1)
            {
         	Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard Resources */)  // _HID: Hardware ID
         	Name (_UID, Zero)  // _UID: Unique ID
		...
		Mutex (MUT0, 0x00)
		Method (ENFG, 1, NotSerialized)
                     {
                         Acquire (MUT0, 0x0FFF)
                         INDX = 0x87
                         INDX = One
                         INDX = 0x55
                         If ((SP1O == 0x2E))
                         {
                             INDX = 0x55
                         }
                         Else
                         {
                             INDX = 0xAA
                         }

                         LDN = Arg0
                     }

                     Method (EXFG, 0, NotSerialized)
                     {
                         INDX = 0x02
                         DATA = 0x02
                         Release (MUT0)
                     }

		    OperationRegion (IOID, SystemIO, SP1O, 0x02)	/* SP1O is 0x2e */
                     Field (IOID, ByteAcc, NoLock, Preserve)
                     {
                         INDX,   8,
                         DATA,   8
                     }
		    ...

Example for use:
		Method (DCNT, 2, NotSerialized)
                     {
                         ENFG (CGLD (Arg0))
                         If (((DMCH < 0x04) && ((Local1 = (DMCH & 0x03)) != Zero)))
                         {
                             RDMA (Arg0, Arg1, Local1++)
                         }

                         ACTR = Arg1
                         Local1 = (IOAH << 0x08)
                         Local1 |= IOAL
                         RRIO (Arg0, Arg1, Local1, 0x08)
                         EXFG ()
                     }

Can there be more than one address space handler for a given region ?
Each driver accessing the resource would need that handler.

Thanks,
Guenter

> Thanks and best regards
> Lv
>
>> From it87_find() I really couldn't see a possibility to convert superio
>> accesses into opregions. Could you paste some example superio access AML
>> code from your DSDT here.
>>
>> Thanks and best regards
>> Lv
>

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki April 18, 2017, 2:15 p.m. UTC | #29

On Tuesday, April 18, 2017 06:50:26 AM Guenter Roeck wrote:
> On 04/18/2017 12:14 AM, Zheng, Lv wrote:
> > Hi,

[cut]

> >
> > Maybe I should provide more detailed examples for this solution.
> >
> > For example:
> > OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100)
> > Field (SIOT, ByteAcc, Lock, Preserve)
> > {
> >     FNC1, 8,
> >     FNC2, 8,
> >     ...
> > }
> >
> > Acquire (MUX0)
> > Store (0, FNC1)
> > Release (MUX0)
> >
> > Then you can call (let me use casual pseudo code)
> > acpi_install_operation_region(SuperIOAddressSpace, superio_opregion_handler) from OS side.
> > In its callback superio_opregion_handler(), you can:
> >
> > superio_enter();
> > If (address == 0) {
> >    /* mean FNC1 */
> >    Perform the locked superior accesses
> > } else if (address == 1) {
> >    /* mean FNC2 */
> >    Perform the locked superior accesses
> > }
> > superio_exit();
> >
> > Are there similar approach in your DSDT?
> >
> 
> Some snippets from the DSDT:
> 
> 	Device (SIO1)
>             {
>          	Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard Resources */)  // _HID: Hardware ID
>          	Name (_UID, Zero)  // _UID: Unique ID
> 		...
> 		Mutex (MUT0, 0x00)
> 		Method (ENFG, 1, NotSerialized)
>                      {
>                          Acquire (MUT0, 0x0FFF)
>                          INDX = 0x87
>                          INDX = One
>                          INDX = 0x55
>                          If ((SP1O == 0x2E))
>                          {
>                              INDX = 0x55
>                          }
>                          Else
>                          {
>                              INDX = 0xAA
>                          }
> 
>                          LDN = Arg0
>                      }
> 
>                      Method (EXFG, 0, NotSerialized)
>                      {
>                          INDX = 0x02
>                          DATA = 0x02
>                          Release (MUT0)
>                      }
> 
> 		    OperationRegion (IOID, SystemIO, SP1O, 0x02)	/* SP1O is 0x2e */
>                      Field (IOID, ByteAcc, NoLock, Preserve)
>                      {
>                          INDX,   8,
>                          DATA,   8
>                      }
> 		    ...
> 
> Example for use:
> 		Method (DCNT, 2, NotSerialized)
>                      {
>                          ENFG (CGLD (Arg0))
>                          If (((DMCH < 0x04) && ((Local1 = (DMCH & 0x03)) != Zero)))
>                          {
>                              RDMA (Arg0, Arg1, Local1++)
>                          }
> 
>                          ACTR = Arg1
>                          Local1 = (IOAH << 0x08)
>                          Local1 |= IOAL
>                          RRIO (Arg0, Arg1, Local1, 0x08)
>                          EXFG ()
>                      }
> 
> Can there be more than one address space handler for a given region ?
> Each driver accessing the resource would need that handler.

Rather, every driver accessing the resource would need to be aware of the
existence of the operation region handler and would need to use the mutual
exclusion mechanism used by that handler, if my understanding here is correct.

The existence of an operation region for a specific section of address space is
a declaration that AML is going to access locations in that section.  It allows
the OS to install a handler for that region to intercept AML accesses and do
what it likes with them.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moore, Robert April 18, 2017, 4:07 p.m. UTC | #30

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:[e-mail]]
> Sent: Tuesday, April 18, 2017 7:15 AM
> To: Guenter Roeck <[e-mail]>
> Cc: Zheng, Lv <[e-mail]>; Rafael J. Wysocki
> <[e-mail]>; Moore, Robert <[e-mail]>; Wysocki,
> Rafael J <[e-mail]>; Len Brown <[e-mail]>;
> [e-mail]; [e-mail]; linux-
> [e-mail]; Box, David E <[e-mail]>
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> On Tuesday, April 18, 2017 06:50:26 AM Guenter Roeck wrote:
> > On 04/18/2017 12:14 AM, Zheng, Lv wrote:
> > > Hi,
> 
> [cut]
> 
> > >
> > > Maybe I should provide more detailed examples for this solution.
> > >
> > > For example:
> > > OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100) Field (SIOT,
> > > ByteAcc, Lock, Preserve) {
> > >     FNC1, 8,
> > >     FNC2, 8,
> > >     ...
> > > }
> > >
> > > Acquire (MUX0)
> > > Store (0, FNC1)
> > > Release (MUX0)
> > >
> > > Then you can call (let me use casual pseudo code)
> > > acpi_install_operation_region(SuperIOAddressSpace,
> superio_opregion_handler) from OS side.
> > > In its callback superio_opregion_handler(), you can:
> > >
> > > superio_enter();
> > > If (address == 0) {
> > >    /* mean FNC1 */
> > >    Perform the locked superior accesses } else if (address == 1) {
> > >    /* mean FNC2 */
> > >    Perform the locked superior accesses } superio_exit();
> > >
> > > Are there similar approach in your DSDT?
> > >
> >
> > Some snippets from the DSDT:
> >
> > 	Device (SIO1)
> >             {
> >          	Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard
> Resources */)  // _HID: Hardware ID
> >          	Name (_UID, Zero)  // _UID: Unique ID
> > 		...
> > 		Mutex (MUT0, 0x00)
> > 		Method (ENFG, 1, NotSerialized)
> >                      {
> >                          Acquire (MUT0, 0x0FFF)
> >                          INDX = 0x87
> >                          INDX = One
> >                          INDX = 0x55
> >                          If ((SP1O == 0x2E))
> >                          {
> >                              INDX = 0x55
> >                          }
> >                          Else
> >                          {
> >                              INDX = 0xAA
> >                          }
> >
> >                          LDN = Arg0
> >                      }
> >
> >                      Method (EXFG, 0, NotSerialized)
> >                      {
> >                          INDX = 0x02
> >                          DATA = 0x02
> >                          Release (MUT0)
> >                      }
> >
> > 		    OperationRegion (IOID, SystemIO, SP1O, 0x02)	/* SP1O
> is 0x2e */
> >                      Field (IOID, ByteAcc, NoLock, Preserve)
> >                      {
> >                          INDX,   8,
> >                          DATA,   8
> >                      }
> > 		    ...
> >
> > Example for use:
> > 		Method (DCNT, 2, NotSerialized)
> >                      {
> >                          ENFG (CGLD (Arg0))
> >                          If (((DMCH < 0x04) && ((Local1 = (DMCH &
> 0x03)) != Zero)))
> >                          {
> >                              RDMA (Arg0, Arg1, Local1++)
> >                          }
> >
> >                          ACTR = Arg1
> >                          Local1 = (IOAH << 0x08)
> >                          Local1 |= IOAL
> >                          RRIO (Arg0, Arg1, Local1, 0x08)
> >                          EXFG ()
> >                      }
> >
> > Can there be more than one address space handler for a given region ?
> > Each driver accessing the resource would need that handler.
> 
> Rather, every driver accessing the resource would need to be aware of
> the existence of the operation region handler and would need to use the
> mutual exclusion mechanism used by that handler, if my understanding
> here is correct.
> 
> The existence of an operation region for a specific section of address
> space is a declaration that AML is going to access locations in that
> section.  It allows the OS to install a handler for that region to
> intercept AML accesses and do what it likes with them.
> 
> Thanks,
> Rafael

Yes, agreed.
Bob

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 19, 2017, 1:26 a.m. UTC | #31

Hi,

> From: Guenter Roeck [mailto:[e-mail]]
> Subject: Re: [PATCH] ACPICA: Export mutex functions
> 
> On 04/18/2017 12:14 AM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Zheng, Lv
> >> Subject: RE: [PATCH] ACPICA: Export mutex functions
> >>
> >> Hi,
> >>
> >>> From: Guenter Roeck [mailto:[e-mail]]
> >>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> >>>
> >>> On 04/17/2017 04:53 PM, Zheng, Lv wrote:
> >>>> Hi,
> >>>>
> >>>>> From: Guenter Roeck [mailto:[e-mail]]
> >>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> >>>>>
> >>>>> 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 <[e-mail]> wrote:
> >>>>>>> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> From: Guenter Roeck [mailto:[e-mail]]
> >>>>>>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> >>>>>>>>>
> >>>>>>>>> On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> >>>>>>>>>>
> >>>>>>>>>>> From: Moore, Robert
> >>>>>>>>>>> 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.
> >>>>>
> >>>>
> >>>> OK, then you might be having problems in your opregion driver.
> >>>>
> >>>>> 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.
> >>>>
> >>>> As what you've mentioned, there are already lots of parallel accesses in kernel without enabling
> >>> ACPI.
> >>>> Are these accesses mutually exclusive (safe)?
> >>>
> >>> In-kernel, yes (using request_muxed_region). Against ACPI, no.
> >>>
> >>>> If so, why do you need to invent a new synchronization mechanism?
> >>>>
> >>>
> >>> Because I am seeing a problem with the current code (more specifically,
> >>> with the it87 hwmon driver) on new Gigabyte boards.
> >>
> >> I checked superio_enter()/superio_exit(), IMO, the mutual exclusion
> >> might be handled using 1 of the following 2 solutions:
> >>
> >> 1. _DLM, then you can find superio related mutex from _DLM and
> >>    acquire/release it in superio_enter()/superio_exit().
> >>    You really need a set of new APIs to acquire the _DLM related mutex.
> >>    If you don't have _DLM in your DSDT, directly exporting ACPICA mutex
> >>    functions seem to be a reasonable solution.
> >> 2. Normally, AML developer should abstract superio accesses into customized
> >>    opregion, then you can prepare a superio opregion driver.
> >>
> >>>
> >>>>> Right now I wonder, though,
> >>>>> if such code would have a chance to be accepted. Any thoughts on that ?
> >>>>
> >>>> Is that possible to make it safe in the opregion driver?
> >>>>
> >>>
> >>> Sorry, I don't think I understand what you mean with "opregion driver".
> >>> Do you refer to the drivers accessing the memory region in question,
> >>> or in other words replicating the necessary code in every driver accessing
> >>> that region ? Sure, I can do that, if that is the preferred solution;
> >>> I have no problem with that. However, that would require exporting
> >>> the ACPI mutex functions. My understanding is that you are opposed to
> >>> exporting those, so I assume that is not what you refer to.
> >>> Can you clarify ?
> >>
> >> I mean solution 2.
> >
> > Maybe I should provide more detailed examples for this solution.
> >
> > For example:
> > OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100)
> > Field (SIOT, ByteAcc, Lock, Preserve)
> > {
> >     FNC1, 8,
> >     FNC2, 8,
> >     ...
> > }
> >
> > Acquire (MUX0)
> > Store (0, FNC1)
> > Release (MUX0)
> >
> > Then you can call (let me use casual pseudo code)
> > acpi_install_operation_region(SuperIOAddressSpace, superio_opregion_handler) from OS side.
> > In its callback superio_opregion_handler(), you can:
> >
> > superio_enter();
> > If (address == 0) {
> >    /* mean FNC1 */
> >    Perform the locked superior accesses
> > } else if (address == 1) {
> >    /* mean FNC2 */
> >    Perform the locked superior accesses
> > }
> > superio_exit();
> >
> > Are there similar approach in your DSDT?
> >
> 
> Some snippets from the DSDT:
> 
> 	Device (SIO1)
>             {
>          	Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard Resources */)  // _HID: Hardware ID
>          	Name (_UID, Zero)  // _UID: Unique ID
> 		...
> 		Mutex (MUT0, 0x00)
> 		Method (ENFG, 1, NotSerialized)
>                      {
>                          Acquire (MUT0, 0x0FFF)
>                          INDX = 0x87
>                          INDX = One
>                          INDX = 0x55
>                          If ((SP1O == 0x2E))
>                          {
>                              INDX = 0x55
>                          }
>                          Else
>                          {
>                              INDX = 0xAA
>                          }
> 
>                          LDN = Arg0
>                      }
> 
>                      Method (EXFG, 0, NotSerialized)
>                      {
>                          INDX = 0x02
>                          DATA = 0x02
>                          Release (MUT0)
>                      }
> 
> 		    OperationRegion (IOID, SystemIO, SP1O, 0x02)	/* SP1O is 0x2e */
>                      Field (IOID, ByteAcc, NoLock, Preserve)
>                      {
>                          INDX,   8,
>                          DATA,   8
>                      }
> 		    ...
> 
> Example for use:
> 		Method (DCNT, 2, NotSerialized)
>                      {
>                          ENFG (CGLD (Arg0))
>                          If (((DMCH < 0x04) && ((Local1 = (DMCH & 0x03)) != Zero)))
>                          {
>                              RDMA (Arg0, Arg1, Local1++)
>                          }
> 
>                          ACTR = Arg1
>                          Local1 = (IOAH << 0x08)
>                          Local1 |= IOAL
>                          RRIO (Arg0, Arg1, Local1, 0x08)
>                          EXFG ()
>                      }
> 
> Can there be more than one address space handler for a given region ?
> Each driver accessing the resource would need that handler.

From the above AML code, the solution 2 is not possible for ensuring the
mutual exclusion of accessing the resources.
Because the mutual exclusion must be ensured for the entire transaction
including ENFG() and EXFG() rather than a single SystemIo operation
region field access.

So you really need the solution 1 and the new API.

Thanks and best regards
Lv

> 
> Thanks,
> Guenter
> 
> > Thanks and best regards
> > Lv
> >
> >> From it87_find() I really couldn't see a possibility to convert superio
> >> accesses into opregions. Could you paste some example superio access AML
> >> code from your DSDT here.
> >>
> >> Thanks and best regards
> >> Lv

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Lv Zheng April 19, 2017, 1:35 a.m. UTC | #32

Hi,

> From: Devel [mailto:[e-mail]] On Behalf Of Zheng, Lv
> Subject: Re: [Devel] [PATCH] ACPICA: Export mutex functions
> 
> Hi,
> 
> > From: Guenter Roeck [mailto:[e-mail]]
> > Subject: Re: [PATCH] ACPICA: Export mutex functions
> >
> > On 04/18/2017 12:14 AM, Zheng, Lv wrote:
> > > Hi,
> > >
> > >> From: Zheng, Lv
> > >> Subject: RE: [PATCH] ACPICA: Export mutex functions
> > >>
> > >> Hi,
> > >>
> > >>> From: Guenter Roeck [mailto:[e-mail]]
> > >>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> > >>>
> > >>> On 04/17/2017 04:53 PM, Zheng, Lv wrote:
> > >>>> Hi,
> > >>>>
> > >>>>> From: Guenter Roeck [mailto:[e-mail]]
> > >>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> > >>>>>
> > >>>>> 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 <[e-mail]> wrote:
> > >>>>>>> On Mon, Apr 17, 2017 at 08:40:38PM +0000, Moore, Robert wrote:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> From: Guenter Roeck [mailto:[e-mail]]
> > >>>>>>>>> Subject: Re: [PATCH] ACPICA: Export mutex functions
> > >>>>>>>>>
> > >>>>>>>>> On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> From: Moore, Robert
> > >>>>>>>>>>> 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.
> > >>>>>
> > >>>>
> > >>>> OK, then you might be having problems in your opregion driver.
> > >>>>
> > >>>>> 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.
> > >>>>
> > >>>> As what you've mentioned, there are already lots of parallel accesses in kernel without
> enabling
> > >>> ACPI.
> > >>>> Are these accesses mutually exclusive (safe)?
> > >>>
> > >>> In-kernel, yes (using request_muxed_region). Against ACPI, no.
> > >>>
> > >>>> If so, why do you need to invent a new synchronization mechanism?
> > >>>>
> > >>>
> > >>> Because I am seeing a problem with the current code (more specifically,
> > >>> with the it87 hwmon driver) on new Gigabyte boards.
> > >>
> > >> I checked superio_enter()/superio_exit(), IMO, the mutual exclusion
> > >> might be handled using 1 of the following 2 solutions:
> > >>
> > >> 1. _DLM, then you can find superio related mutex from _DLM and
> > >>    acquire/release it in superio_enter()/superio_exit().
> > >>    You really need a set of new APIs to acquire the _DLM related mutex.
> > >>    If you don't have _DLM in your DSDT, directly exporting ACPICA mutex
> > >>    functions seem to be a reasonable solution.
> > >> 2. Normally, AML developer should abstract superio accesses into customized
> > >>    opregion, then you can prepare a superio opregion driver.
> > >>
> > >>>
> > >>>>> Right now I wonder, though,
> > >>>>> if such code would have a chance to be accepted. Any thoughts on that ?
> > >>>>
> > >>>> Is that possible to make it safe in the opregion driver?
> > >>>>
> > >>>
> > >>> Sorry, I don't think I understand what you mean with "opregion driver".
> > >>> Do you refer to the drivers accessing the memory region in question,
> > >>> or in other words replicating the necessary code in every driver accessing
> > >>> that region ? Sure, I can do that, if that is the preferred solution;
> > >>> I have no problem with that. However, that would require exporting
> > >>> the ACPI mutex functions. My understanding is that you are opposed to
> > >>> exporting those, so I assume that is not what you refer to.
> > >>> Can you clarify ?
> > >>
> > >> I mean solution 2.
> > >
> > > Maybe I should provide more detailed examples for this solution.
> > >
> > > For example:
> > > OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100)
> > > Field (SIOT, ByteAcc, Lock, Preserve)
> > > {
> > >     FNC1, 8,
> > >     FNC2, 8,
> > >     ...
> > > }
> > >
> > > Acquire (MUX0)
> > > Store (0, FNC1)
> > > Release (MUX0)
> > >
> > > Then you can call (let me use casual pseudo code)
> > > acpi_install_operation_region(SuperIOAddressSpace, superio_opregion_handler) from OS side.
> > > In its callback superio_opregion_handler(), you can:
> > >
> > > superio_enter();
> > > If (address == 0) {
> > >    /* mean FNC1 */
> > >    Perform the locked superior accesses
> > > } else if (address == 1) {
> > >    /* mean FNC2 */
> > >    Perform the locked superior accesses
> > > }
> > > superio_exit();
> > >
> > > Are there similar approach in your DSDT?
> > >
> >
> > Some snippets from the DSDT:
> >
> > 	Device (SIO1)
> >             {
> >          	Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard Resources */)  // _HID: Hardware ID
> >          	Name (_UID, Zero)  // _UID: Unique ID
> > 		...
> > 		Mutex (MUT0, 0x00)
> > 		Method (ENFG, 1, NotSerialized)
> >                      {
> >                          Acquire (MUT0, 0x0FFF)
> >                          INDX = 0x87
> >                          INDX = One
> >                          INDX = 0x55
> >                          If ((SP1O == 0x2E))
> >                          {
> >                              INDX = 0x55
> >                          }
> >                          Else
> >                          {
> >                              INDX = 0xAA
> >                          }
> >
> >                          LDN = Arg0
> >                      }
> >
> >                      Method (EXFG, 0, NotSerialized)
> >                      {
> >                          INDX = 0x02
> >                          DATA = 0x02
> >                          Release (MUT0)
> >                      }
> >
> > 		    OperationRegion (IOID, SystemIO, SP1O, 0x02)	/* SP1O is 0x2e */
> >                      Field (IOID, ByteAcc, NoLock, Preserve)
> >                      {
> >                          INDX,   8,
> >                          DATA,   8
> >                      }
> > 		    ...
> >
> > Example for use:
> > 		Method (DCNT, 2, NotSerialized)
> >                      {
> >                          ENFG (CGLD (Arg0))
> >                          If (((DMCH < 0x04) && ((Local1 = (DMCH & 0x03)) != Zero)))
> >                          {
> >                              RDMA (Arg0, Arg1, Local1++)
> >                          }
> >
> >                          ACTR = Arg1
> >                          Local1 = (IOAH << 0x08)
> >                          Local1 |= IOAL
> >                          RRIO (Arg0, Arg1, Local1, 0x08)
> >                          EXFG ()
> >                      }
> >
> > Can there be more than one address space handler for a given region ?
> > Each driver accessing the resource would need that handler.
> 
> From the above AML code, the solution 2 is not possible for ensuring the
> mutual exclusion of accessing the resources.
> Because the mutual exclusion must be ensured for the entire transaction
> including ENFG() and EXFG() rather than a single SystemIo operation
> region field access.
> 
> So you really need the solution 1 and the new API.

Sorry, there is still another solution besides of the above 2 that
Can possibly solve your problem.

Let me explain.
Here for the DCNT method, there must be entry methods (those with
underscore prefixed, let me use _XXXX as an example) invoking it.
And OS will invoke those entry methods. So is that possible to add
request_muxed_region() before invoking those entry control methods.

For example:
superio_enter()
acpi_evaluate_object(_XXXX)
superio_exit()

Thanks and best regards
Lv

> 
> Thanks and best regards
> Lv
> 
> >
> > Thanks,
> > Guenter
> >
> > > Thanks and best regards
> > > Lv
> > >
> > >> From it87_find() I really couldn't see a possibility to convert superio
> > >> accesses into opregions. Could you paste some example superio access AML
> > >> code from your DSDT here.
> > >>
> > >> Thanks and best regards
> > >> Lv
> 
> _______________________________________________
> Devel mailing list
> [e-mail]
> 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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

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)