RE: [PATCH] acpi: remove length check for large registers
Linn,
We will integrate this change into ACPICA for the next release, later in March
2013.
Thanks,
Bob
> -Original Message-
> From: Linn Crosetto [mailto:l...@hp.com]
> Sent: Friday, March 15, 2013 12:56 PM
> To: r...@sisk.pl; Moore, Robert; ming.m@intel.com; Zheng, Lv; linux-
> a...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Linn Crosetto
> Subject: [PATCH] acpi: remove length check for large registers
>
> The legacy bit width field in the Generic Address Structure is 1 byte,
> limiting the reportable register width to 255 bits. Larger registers will
> cause a length mismatch warning to be printed in acpi_tb_validate_fadt().
>
> To avoid the warning, disable the length mismatch check for registers
> larger than 255 bits.
>
> Signed-off-by: Linn Crosetto
> ---
> drivers/acpi/acpica/tbfadt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
> index 74181bf..e87abcd 100644
> --- a/drivers/acpi/acpica/tbfadt.c
> +++ b/drivers/acpi/acpica/tbfadt.c
> @@ -561,6 +561,7 @@ static void acpi_tb_validate_fadt(void)
>* legacy length field and the corresponding 64-bit X length
> field.
>*/
> if (address64->address &&
> + ACPI_MUL_8(length) <= ACPI_UINT8_MAX &&
> (address64->bit_width != ACPI_MUL_8(length))) {
> ACPI_BIOS_WARNING((AE_INFO,
> "32/64X length mismatch in FADT/%s:
> %u/%u",
> --
> 1.7.11.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpi: remove length check for large registers
Linn,
Can you explain in a bit more detail what brings this up?
I'm aware of the limitation of the generic address structure, but we are forced
by the (current) ACPI specification to use it if it is present for a given
register.
Thanks,
Bob
> -Original Message-
> From: Linn Crosetto [mailto:l...@hp.com]
> Sent: Friday, March 15, 2013 12:56 PM
> To: r...@sisk.pl; Moore, Robert; ming.m@intel.com; Zheng, Lv; linux-
> a...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Linn Crosetto
> Subject: [PATCH] acpi: remove length check for large registers
>
> The legacy bit width field in the Generic Address Structure is 1 byte,
> limiting the reportable register width to 255 bits. Larger registers will
> cause a length mismatch warning to be printed in acpi_tb_validate_fadt().
>
> To avoid the warning, disable the length mismatch check for registers
> larger than 255 bits.
>
> Signed-off-by: Linn Crosetto
> ---
> drivers/acpi/acpica/tbfadt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
> index 74181bf..e87abcd 100644
> --- a/drivers/acpi/acpica/tbfadt.c
> +++ b/drivers/acpi/acpica/tbfadt.c
> @@ -561,6 +561,7 @@ static void acpi_tb_validate_fadt(void)
>* legacy length field and the corresponding 64-bit X length
> field.
>*/
> if (address64->address &&
> + ACPI_MUL_8(length) <= ACPI_UINT8_MAX &&
> (address64->bit_width != ACPI_MUL_8(length))) {
> ACPI_BIOS_WARNING((AE_INFO,
> "32/64X length mismatch in FADT/%s:
> %u/%u",
> --
> 1.7.11.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] ACPI: Check for any matching CID when walking namespace.
Ok, I've rolled this in:
/* Walk the CID list */
found = FALSE;
for (i = 0; i < cid->count; i++) {
if (ACPI_STRNCMP (cid->id[i].value,
info->hid,
sizeof (struct
acpi_compatible_id)) == 0) {
/* Found a matching CID */
found = TRUE;
break;
}
}
ACPI_FREE (cid);
if (!found) {
return (AE_OK);
}
}
}
/* We have a valid device, invoke the user function */
status = info->user_function (obj_handle, nesting_level,
info->context,
return_value);
return (status);
}
Thanks,
Bob
>-Original Message-
>From: Len Brown [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, January 23, 2008 11:40 AM
>To: Andrew Patterson; Moore, Robert
>Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; Nguyen, Tom L;
[EMAIL PROTECTED]
>Subject: Re: [PATCH 3/4] ACPI: Check for any matching CID when walking
>namespace.
>
>Right Greg, this is not only an ACPI patch,
>but a patch that touches the ACPICA core.
>Lets get Bob to see if it applies to the latest upstream ACPICA code.
>
>Andrew,
>Do you give Intel permission to accept this patch under
>both licenses on the top of the file, such that we can
>re-distribute it in ACPICA to all the OSs that use ACPICA?
>
>(hey, and check out the spiffy new acpica home page: http://acpica.org/
)
>
>thanks,
>-Len
>
>On Tuesday 22 January 2008 19:18, Andrew Patterson wrote:
>> From: Andrew Patterson <[EMAIL PROTECTED]>
>>
>> The callback function acpi_ns_get_device_callback called from
>> acpi_get_devices() will check CID's if the HID does not match. This
code
>> has a bug where it requires that all CIDs match the HID. Changed the
code
>> so that any CID match will do.
>>
>> Signed-off-by: Andrew Patterson <[EMAIL PROTECTED]>
>> ---
>>
>> drivers/acpi/namespace/nsxfeval.c | 11 ---
>> 1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/namespace/nsxfeval.c
>b/drivers/acpi/namespace/nsxfeval.c
>> index f39fbc6..e562b24 100644
>> --- a/drivers/acpi/namespace/nsxfeval.c
>> +++ b/drivers/acpi/namespace/nsxfeval.c
>> @@ -443,6 +443,7 @@ acpi_ns_get_device_callback(acpi_handle
obj_handle,
>> struct acpica_device_id hid;
>> struct acpi_compatible_id_list *cid;
>> acpi_native_uint i;
>> +int found;
>>
>> status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
>> if (ACPI_FAILURE(status)) {
>> @@ -496,16 +497,20 @@ acpi_ns_get_device_callback(acpi_handle
obj_handle,
>>
>> /* Walk the CID list */
>>
>> +found = 0;
>> for (i = 0; i < cid->count; i++) {
>> if (ACPI_STRNCMP(cid->id[i].value,
info->hid,
>> sizeof(struct
>> -
acpi_compatible_id)) !=
>> +
acpi_compatible_id)) ==
>> 0) {
>> -ACPI_FREE(cid);
>> -return (AE_OK);
>> +found = 1;
>> +break;
>> }
>> }
>> ACPI_FREE(cid);
>> +if (!found) {
>> +return (AE_OK);
>> +}
>> }
>> }
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3.7-rc8] ACPICA: Fix ACPI mutex object allocation memory leak on error
Tim,
Thanks. We will need to backport this change to the ACPICA source code.
Bob
> -Original Message-
> From: Tim Gardner [mailto:tim.gard...@canonical.com]
> Sent: Wednesday, December 05, 2012 9:39 AM
> To: linux-kernel@vger.kernel.org
> Cc: Tim Gardner; Len Brown; Rafael J. Wysocki; Lin Ming; Moore, Robert;
> linux-a...@vger.kernel.org
> Subject: [PATCH 3.7-rc8] ACPICA: Fix ACPI mutex object allocation memory
> leak on error
>
> An unattached mutex object is not released on error, thereby orphaning
> memory.
>
> I stumbled on this when looking at the output of smatch:
>
> drivers/acpi/acpica/dsmethod.c:225 acpi_ds_begin_method_execution() error:
> we previously assumed 'obj_desc->method.mutex' could be null (see line
> 209)
>
> which led me to have a look at acpi_ds_create_method_mutex().
>
> Cc: Len Brown
> Cc: "Rafael J. Wysocki"
> Cc: Lin Ming
> Cc: Bob Moore
> Cc: linux-a...@vger.kernel.org
> Cc: sta...@vger.kernel.org #2.6.29+
> Signed-off-by: Tim Gardner
> ---
>
> This applied to the original version of dsmethod.c which was introduced in
> 95b482a8d31116f3f5c2a5089569393234d06385 (2.6.29).
>
> drivers/acpi/acpica/dsmethod.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/acpica/dsmethod.c
> b/drivers/acpi/acpica/dsmethod.c index aa9a5d4..fe89ea9 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -151,6 +151,7 @@ acpi_ds_create_method_mutex(union acpi_operand_object
> *method_desc)
>
> status = acpi_os_create_mutex(&mutex_desc->mutex.os_mutex);
> if (ACPI_FAILURE(status)) {
> + acpi_ut_delete_object_desc(mutex_desc);
> return_ACPI_STATUS(status);
> }
>
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI errors with 3.7-rc3
Actually, it is not the address of the global lock, the FACS contains the actual global lock: From acpi5.0 spec: ROM BIOS. The Global Lock is a 32-bit (DWORD) value in read/write memory located within the FACS and is accessed and updated by both the OS environment and the SMI environment in a defined manner to provide an exclusive lock. Note: this is not a pointer to the Global Lock, it is the actual memory location of the lock. The FACS and Global Lock may be located anywhere in physical memory. > -Original Message- > From: a3at.m...@gmail.com [mailto:a3at.m...@gmail.com] On Behalf Of Azat > Khuzhin > Sent: Sunday, November 11, 2012 2:01 AM > To: Moore, Robert > Cc: Tang, Feng; Rafael J. Wysocki; Greg KH; linux-a...@vger.kernel.org; > Linux Kernel Mailing List; Zheng, Lv; Len Brown > Subject: Re: ACPI errors with 3.7-rc3 > > Robert, > > You say that FACS table contains the address of the global lock. > But in my case https://gist.github.com/4037687 it seems to be empty, so > this means that my laptop don't have global lock? > > On Fri, Nov 9, 2012 at 8:45 PM, Moore, Robert > wrote: > >> And per my check, most of ACPI FW don't implement this lock, say > >> after driver probe, the ec->global_lock will be 0 > > > > Take a look at the FACS table, it contains the address of the global > lock. > > > > I believe that the ACPI specification requires that the global lock be > present. > > > > > > > >> -Original Message- > >> From: Tang, Feng > >> Sent: Friday, November 09, 2012 8:36 AM > >> To: Moore, Robert > >> Cc: Rafael J. Wysocki; Greg KH; Azat Khuzhin; > >> linux-a...@vger.kernel.org; Linux Kernel Mailing List; Zheng, Lv; Len > >> Brown > >> Subject: Re: ACPI errors with 3.7-rc3 > >> > >> On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: > >> > The ACPI Global Lock is in fact intended to provide exclusion > >> > between > >> the BIOS and the OS. > >> > Bob > >> > >> Thanks for the info. > >> > >> And per my check, most of ACPI FW don't implement this lock, say > >> after driver probe, the ec->global_lock will be 0. > >> > >> - Feng > >> > >> > > >> > > >> > > -Original Message- > >> > > From: Tang, Feng > >> > > Sent: Friday, November 09, 2012 1:29 AM > >> > > To: Rafael J. Wysocki > >> > > Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux > >> > > Kernel Mailing List; Zheng, Lv; Len Brown; Moore, Robert > >> > > Subject: Re: ACPI errors with 3.7-rc3 > >> > > > >> > > On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: > >> > > > On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: > >> > > > > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: > >> > > > > > I'v also have such errors on my macbook pro. > >> > > > > > > >> > > > > > $ dmesg | tail > >> > > > > > [17056.008564] ACPI Error: Method parse/execution failed > >> > > > > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), > >> > > > > > AE_TIME > >> > > > > > (20120711/psparse-536) > >> > > > > > [17056.011194] ACPI Error: Method parse/execution failed > >> > > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME > >> > > > > > (20120711/psparse-536) > >> > > > > > [17056.013793] ACPI Error: Method parse/execution failed > >> > > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME > >> > > > > > (20120711/psparse-536) > >> > > > > > [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST > >> > > > > > (20120711/battery-464) [17056.511373] ACPI: EC: input > >> > > > > > buffer is not empty, aborting transaction [17056.512672] > >> > > > > > ACPI > >> Exception: > >> > > > > > AE_TIME, Returned by Handler for [EmbeddedControl] > >> > > > > > (20120711/evregion-501) [17056.515256] ACPI Error: Method > >> > > > > > parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] > >> > > > > > (Node 88026547ea10), AE_TIME > >> > > > > > (20120711/psparse-536) >
RE: [PATCH ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
Ethan,
Does this actually solve a problem that you have seen?
I ask because of the code that converts the FADT to the common internal format:
acpi_tb_convert_fadt (
...
/*
* Expand the 32-bit FACS and DSDT addresses to 64-bit as necessary.
* Later code will always use the X 64-bit field.
*/
if (!acpi_gbl_FADT.Xfacs) {
acpi_gbl_FADT.Xfacs = (u64) acpi_gbl_FADT.facs;
}
if (!acpi_gbl_FADT.Xdsdt) {
acpi_gbl_FADT.Xdsdt = (u64) acpi_gbl_FADT.dsdt;
}
This function is called before the call to validate_fadt, so if the 64-bit
address was originally zero, it is set to be equal to the 32-bit address.
Later, only the 64-bit address field is used.
So, after convert_fadt, we have the following possible conditions:
1) Both facs and Xfacs are zero
2) facs is zero, but Xfacs in non-zero
3) Both facs and Xfacs are non-zero but equal
4) Both facs and Xfacs are non-zero and not equal
Issues for each condition above:
1) There is no FACS
2) No error, we are going to use Xfacs anyway
3) No error, we will use Xfacs
4) This is the error condition, Xfacs != facs
The check for case (4) is what appears in validate_facs:
If ((facs > 0) && (facs != Xfacs))
I don't think we need to check the value of Xfacs against zero because we know
we are in case (3) or (4) after the check for facs nonzero:
if
(facs > 0) - if true, we are in case (3) or (4)
if
(facs != Xfacs) - if true, we now know we are in case (4) --> error.
Unless I'm missing something early this morning.
Bob
> -Original Message-
> From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
> Sent: Monday, November 12, 2012 7:32 PM
> To: Brown, Len
> Cc: Moore, Robert; Zheng, Lv; LKML
> Subject: [PATCH ] tbfadt.c: output warning only when 64bit 32bit address
> of FACS/DSDT all have value but not equal to each other
>
> Hi, Len, Robert,
>
>Please help to check the following patch, add more conditions when
> validate the 64bit 32bit FACS/DSDT address in FADT to follow ACPI spec, In
> the meantime, keep the compatibility and latitude.
>
>
> Thanks,
> Ethan
>
>
>
> From c1116211a7b329c26b0370565c36b084ceb08f71 Mon Sep 17 00:00:00 2001
> From: ethan.zhao
> Date: Tue, 13 Nov 2012 22:21:12 -0800
> Subject: [PATCH 642/642] To follow the ACPI spec 3,4&5 and keep the
> compatibility and latitude,only output mismatch warning when 64bit
> address and 32bit address of FACS/DSDT are all valid but not equal to
> each other.
>
>
> Signed-off-by: ethan.zhao
> ---
> drivers/acpi/acpica/tbfadt.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
> index 3906518..f23f512 100644
> --- a/drivers/acpi/acpica/tbfadt.c
> +++ b/drivers/acpi/acpica/tbfadt.c
> @@ -512,7 +512,7 @@ static void acpi_tb_validate_fadt(void)
> * the 32-bit and 64-bit address fields
> (FIRMWARE_CTRL/X_FIRMWARE_CTRL and
> * DSDT/X_DSDT) would indicate the presence of two FACS or two
> DSDT tables.
> */
> - if (acpi_gbl_FADT.facs &&
> + if ((acpi_gbl_FADT.facs && acpi_gbl_FADT.Xfacs) &&
> (acpi_gbl_FADT.Xfacs != (u64)acpi_gbl_FADT.facs)) {
> ACPI_BIOS_WARNING((AE_INFO,
>"32/64X FACS address mismatch in FADT -
> "
> @@ -523,7 +523,7 @@ static void acpi_tb_validate_fadt(void)
> acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
> }
>
> - if (acpi_gbl_FADT.dsdt &&
> + if ((acpi_gbl_FADT.dsdt && acpi_gbl_FADT.Xdsdt) &&
> (acpi_gbl_FADT.Xdsdt != (u64)acpi_gbl_FADT.dsdt)) {
> ACPI_BIOS_WARNING((AE_INFO,
>"32/64X DSDT address mismatch in FADT -
> "
> --
> 1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects
> I suppose we can just do acpi_get_current_resources() and play with
> the buffer returned by it. That won't be nice, but still better than
> what we have.
A couple of the reasons we created the ACPICA resource manager was to:
1) Simplify host access to the various resource fields, especially packed flags.
2) Avoid alignment issues, especially on machines that don't support misaligned
transfers.
If there are issues with the current resource manager, we can discuss them. But
I would hope that you really don't want to be fussing around with the raw data
coming back from the AML. It is not pretty and we have gone to some lengths to
make the entire conversion table-driven to minimize bugs and simplify
maintenance.
Bob
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Monday, November 12, 2012 11:12 PM
> To: Rafael J. Wysocki
> Cc: mathias.ny...@linux.intel.com; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; l...@kernel.org; Wysocki, Rafael J;
> broo...@opensource.wolfsonmicro.com; grant.lik...@secretlab.ca;
> linus.wall...@linaro.org; kh...@linux-fr.org; Bjorn Helgaas; Moore, Robert
> Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node
> objects
>
> On Mon, Nov 12, 2012 at 10:03:56PM +0100, Rafael J. Wysocki wrote:
> > > > +static acpi_status acpi_bus_add_resource(struct acpi_resource *res,
> > > > +void *context)
> > > > +{
> > > > + struct list_head *list = context;
> > > > + struct acpi_resource_list_entry *entry;
> > > > +
> > > > + entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> > > > + if (!entry)
> > > > + return AE_NO_MEMORY;
> > > > +
> > > > + entry->resource = *res;
> > >
> > > This does not work well with all resource types - specifically those
> > > that contain pointers, like acpi_resource_gpio and
> acpi_resource_source.
> >
> > Good point.
> >
> > Well, this pretty much means we can't copy those things.
>
> Yeah. I only noticed this yesterday when I tested the GPIO translation in
> a custom driver (since it uses the acpi_resource_gpio).
>
> > > The memory for the resources gets freed once acpi_walk_resources() is
> done.
> >
> > I know that.
> >
> > Having to evaluate _CRS and creating a buffer, converting the output
> > into ACPI resources and so on every time we need to look into the
> > device's current resources is totally inefficient. We _need_ to cache
> the _CRS output.
>
> I agree and besides having adev->resources is much easier to use than
> calling acpi_walk_resources() everytime.
>
> > Now, because of the pointers in certain types of resources, we can't
> > make copies of the resource objects used by acpi_walk_resources()
> > which makes that function totally unuseful to us.
> >
> > I suppose we can just do acpi_get_current_resources() and play with
> > the buffer returned by it. That won't be nice, but still better than
> > what we have.
>
> I don't know any better option.
>
> Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects
I may not quite understand what you are asking for, but I will try. It seems like we already have much of what you want/need, so maybe I'm missing something. > So what I would like to have, in general terms, is something like > acpi_walk_resources() split into three parts: > > (1) One that processes the _CRS output and creates a list of > struct acpi_resource objects for us to play with. I suppose > it's OK if that's just a buffer filled with resource objects, > but a linked list might be more convenient. > This sounds like AcpiGetCurrentResources. It executes _CRS and formats the data into acpi_resource objects. > (2) One that allows us to access (read/write) resources in the > list returned by (1). We don't need to open code walking > the list and I probably wouldn't event want to do that. What > we need is to be able to walk the same list for a number of > times and possibly to modify values in the resource objects > if there are conflicts. This sounds like AcpiWalkResources. I suppose a possible issue is that currently, AcpiWalkResources actually invokes the _CRS, _PRS, or _AEI method on behalf of the caller. It might make more sense to allow the caller to pass in the resource buffer returned from a call to _CRS, etc. > > (3) One allowing us to free the list returned by (1) if not needed > any more. > AcpiGetCurrentResources: Currently, everything is returned in a single buffer to minimize the number of allocations. A buffer you can free when you are done with it. I think I saw where you mentioned that you cannot copy this buffer because of internal pointers to other areas of the buffer. Yes. However, we can build linked lists all day if you really want them :-) > And it would be great if we could take the list returned by (1), modify > the resources in it and feed it back to _SRS (after conversion back to the > format that _SRS understands). > AcpiSetCurrentResources. The AML debugger already has a command that illustrates the use of the various resource interfaces, see dbcmds.c > Thanks, > Rafael Bob > -Original Message- > From: Rafael J. Wysocki [mailto:r...@sisk.pl] > Sent: Tuesday, November 13, 2012 12:44 PM > To: Moore, Robert > Cc: Mika Westerberg; mathias.ny...@linux.intel.com; linux- > a...@vger.kernel.org; linux-kernel@vger.kernel.org; l...@kernel.org; > Wysocki, Rafael J; broo...@opensource.wolfsonmicro.com; > grant.lik...@secretlab.ca; linus.wall...@linaro.org; kh...@linux-fr.org; > Bjorn Helgaas; Zheng, Lv > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node > objects > > On Tuesday, November 13, 2012 04:34:07 PM Moore, Robert wrote: > > > I suppose we can just do acpi_get_current_resources() and play with > > > the buffer returned by it. That won't be nice, but still better > > > than what we have. > > > > A couple of the reasons we created the ACPICA resource manager was to: > > 1) Simplify host access to the various resource fields, especially > packed flags. > > 2) Avoid alignment issues, especially on machines that don't support > misaligned transfers. > > That's fine. > > > If there are issues with the current resource manager, we can discuss > them. > > But I would hope that you really don't want to be fussing around with > > the raw data coming back from the AML. > > No, I don't. :-) > > I'd like to be able to do more things with struct acpi_resource objects. > > Pretty much the output of acpi_get_current_resources() is what I'm > interested in, but there doesn't seem to be any convenient way to access > things in the return buffer from the outside of ACPICA now. > > > It is not pretty and we have gone to some lengths to make the entire > > conversion table-driven to minimize bugs and simplify maintenance. > > OK > > So what I would like to have, in general terms, is something like > acpi_walk_resources() split into three parts: > > (1) One that processes the _CRS output and creates a list of > struct acpi_resource objects for us to play with. I suppose > it's OK if that's just a buffer filled with resource objects, > but a linked list might be more convenient. > > (2) One that allows us to access (read/write) resources in the > list returned by (1). We don't need to open code walking > the list and I probably wouldn't event want to do that. What > we need is to be able to walk the same list for a number of > times and possibly to modify values in the resource objects > if there are conflicts. > > (3) One allowing us to free the
RE: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects
Rafael,
I sounds like with a few changes, we can enhance this mechanism to be more
useful to you and others. Some comments below. I need to look at the code in
question a bit more, but I see no insurmountable issues.
Bob
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Tuesday, November 13, 2012 2:57 PM
> To: Moore, Robert
> Cc: Mika Westerberg; mathias.ny...@linux.intel.com; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; l...@kernel.org;
> Wysocki, Rafael J; broo...@opensource.wolfsonmicro.com;
> grant.lik...@secretlab.ca; linus.wall...@linaro.org; kh...@linux-fr.org;
> Bjorn Helgaas; Zheng, Lv
> Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node
> objects
>
> On Tuesday, November 13, 2012 10:06:03 PM Moore, Robert wrote:
> > I may not quite understand what you are asking for, but I will try.
> > It seems like we already have much of what you want/need, so maybe I'm
> > missing something.
>
> I think all of the necessary pieces are there.
>
> > > So what I would like to have, in general terms, is something like
> > > acpi_walk_resources() split into three parts:
> > >
> > > (1) One that processes the _CRS output and creates a list of
> > > struct acpi_resource objects for us to play with. I suppose
> > > it's OK if that's just a buffer filled with resource objects,
> > > but a linked list might be more convenient.
> > >
> >
> > This sounds like AcpiGetCurrentResources. It executes _CRS and formats
> > the data into acpi_resource objects.
>
> Yes, it does. However, it is not completely clear to me if/how the caller
> is supposed to prepare the buffer object pointed to by the second arg.
>
> If the buffer is initialized by AcpiGetCurrentResources, then that's what
> I need for (1).
It looks to me that at least AcpiGetCurrentResources does not actually ever
allocate a buffer for the resource template, it expects the caller to
eventually provide one of at least the size of the returned resource template.
This is really quite a bit out-of-date as far as the memory allocation model.
It should also support the option to just allocate the buffer of the
appropriate size before returning it to the caller.
>
> > > (2) One that allows us to access (read/write) resources in the
> > > list returned by (1). We don't need to open code walking
> > > the list and I probably wouldn't event want to do that. What
> > > we need is to be able to walk the same list for a number of
> > > times and possibly to modify values in the resource objects
> > > if there are conflicts.
> >
> > This sounds like AcpiWalkResources. I suppose a possible issue is that
> > currently, AcpiWalkResources actually invokes the _CRS, _PRS, or _AEI
> > method on behalf of the caller.
>
> Yes, that exactly is the problem.
>
> > It might make more sense to allow the caller to pass in the resource
> > buffer returned from a call to _CRS, etc.
>
> Yes! :-)
I'll take a closer look at this tomorrow.
>
> > >
> > > (3) One allowing us to free the list returned by (1) if not needed
> > > any more.
> > >
> >
> > AcpiGetCurrentResources: Currently, everything is returned in a single
> > buffer to minimize the number of allocations. A buffer you can free
> > when you are done with it.
>
> I suppose I should use ACPI_FREE(buffer.pointer) for that, but isn't it
> for the ACPICA's internal use only?
>
> Besides, I would prefer to be able to pass just "buffer" for freeing,
> without having to touch its internals. No big deal, but it would be
> nicer. :-)
The ACPI_BUFFER type is in fact a public type that is meant to return both the
buffer and the (actual) length. You will find many instances of
ACPI_FREE(buffer.pointer) within existing linux code, since it also used for
objects returned by control method execution/object evaluation.
>
> > I think I saw where you mentioned that you cannot copy this buffer
> > because of internal pointers to other areas of the buffer. Yes.
> > However, we can build linked lists all day if you really want them :-)
>
> I really won't care if I can pass a resource buffer to a "walker" routine.
> :-)
>
> > > And it would be great if we could take the list returned by (1),
> > > modify the resources in it and feed it back to _SRS (after
> > > conversion back to the format that _SRS understands).
> > >
> >
> > AcpiSetCurrentResources.
> >
> > The AML debugger already has a command that illustrates the use of the
> > various resource interfaces, see dbcmds.c
>
> I will.
>
> Thanks,
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects
> And I can define acpi_free_buffer() in the Linux-specific code too. > > Thanks, > Rafael I'll be glad to add an ACPI_FREE_BUFFER macro, although we've had complaints over the years that ACPICA uses too many macros. (Not so many complaints in the last 5 years, however.) Bob > -Original Message- > From: Rafael J. Wysocki [mailto:r...@sisk.pl] > Sent: Wednesday, November 14, 2012 1:33 AM > To: Moore, Robert > Cc: Mika Westerberg; mathias.ny...@linux.intel.com; linux- > a...@vger.kernel.org; linux-kernel@vger.kernel.org; l...@kernel.org; > Wysocki, Rafael J; broo...@opensource.wolfsonmicro.com; > grant.lik...@secretlab.ca; linus.wall...@linaro.org; kh...@linux-fr.org; > Bjorn Helgaas; Zheng, Lv > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device node > objects > > On Wednesday, November 14, 2012 10:18:46 AM Rafael J. Wysocki wrote: > > On Wednesday, November 14, 2012 02:23:51 AM Moore, Robert wrote: > > > Rafael, > > > > > > I sounds like with a few changes, we can enhance this mechanism to > > > be more useful to you and others. Some comments below. I need to > > > look at the code in question a bit more, but I see no insurmountable > issues. > > > > Great, thanks! > > > > > > > > -Original Message- > > > > From: Rafael J. Wysocki [mailto:r...@sisk.pl] > > > > Sent: Tuesday, November 13, 2012 2:57 PM > > > > To: Moore, Robert > > > > Cc: Mika Westerberg; mathias.ny...@linux.intel.com; linux- > > > > a...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > > l...@kernel.org; Wysocki, Rafael J; > > > > broo...@opensource.wolfsonmicro.com; > > > > grant.lik...@secretlab.ca; linus.wall...@linaro.org; > > > > kh...@linux-fr.org; Bjorn Helgaas; Zheng, Lv > > > > Subject: Re: [PATCH 3/3] ACPI: Evaluate _CRS while creating device > > > > node objects > > > > > > > > On Tuesday, November 13, 2012 10:06:03 PM Moore, Robert wrote: > > > > > I may not quite understand what you are asking for, but I will > try. > > > > > It seems like we already have much of what you want/need, so > > > > > maybe I'm missing something. > > > > > > > > I think all of the necessary pieces are there. > > > > > > > > > > So what I would like to have, in general terms, is something > > > > > > like > > > > > > acpi_walk_resources() split into three parts: > > > > > > > > > > > > (1) One that processes the _CRS output and creates a list of > > > > > > struct acpi_resource objects for us to play with. I > suppose > > > > > > it's OK if that's just a buffer filled with resource > objects, > > > > > > but a linked list might be more convenient. > > > > > > > > > > > > > > > > This sounds like AcpiGetCurrentResources. It executes _CRS and > > > > > formats the data into acpi_resource objects. > > > > > > > > Yes, it does. However, it is not completely clear to me if/how > > > > the caller is supposed to prepare the buffer object pointed to by > the second arg. > > > > > > > > If the buffer is initialized by AcpiGetCurrentResources, then > > > > that's what I need for (1). > > > > > > > > > It looks to me that at least AcpiGetCurrentResources does not > > > actually ever allocate a buffer for the resource template, it > > > expects the caller to eventually provide one of at least the size of > the returned resource template. > > > > > > This is really quite a bit out-of-date as far as the memory allocation > model. > > > It should also support the option to just allocate the buffer of the > > > appropriate size before returning it to the caller. > > > > Yes, that would be really useful. > > > > Ideally, I'd like to be able to pass a pointer to an uninitialized > > buffer structure to it (or to a wrapper around it) and get a buffer > > full of struct acpi_resource objects (if _CRS returns any) back from > > it. :-) > > Of course, I can add such a wrapper in the Linux-specific code just fine. > > > > > > > > (2) One that allows us to access (read/write) resources in the > > > > > > list returned by (1). We don't need to open code walking > > > > > > the list and I probably wouldn'
RE: ACPI errors with 3.7-rc3
The ACPI Global Lock is in fact intended to provide exclusion between the BIOS and the OS. Bob > -Original Message- > From: Tang, Feng > Sent: Friday, November 09, 2012 1:29 AM > To: Rafael J. Wysocki > Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux Kernel > Mailing List; Zheng, Lv; Len Brown; Moore, Robert > Subject: Re: ACPI errors with 3.7-rc3 > > On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: > > On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: > > > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: > > > > I'v also have such errors on my macbook pro. > > > > > > > > $ dmesg | tail > > > > [17056.008564] ACPI Error: Method parse/execution failed > > > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), AE_TIME > > > > (20120711/psparse-536) > > > > [17056.011194] ACPI Error: Method parse/execution failed > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME > > > > (20120711/psparse-536) > > > > [17056.013793] ACPI Error: Method parse/execution failed > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME > > > > (20120711/psparse-536) > > > > [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST > > > > (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is > > > > not empty, aborting transaction [17056.512672] ACPI Exception: > > > > AE_TIME, Returned by Handler for [EmbeddedControl] > > > > (20120711/evregion-501) [17056.515256] ACPI Error: Method > > > > parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node > > > > 88026547ea10), AE_TIME > > > > (20120711/psparse-536) > > > > [17056.517886] ACPI Error: Method parse/execution failed > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME > > > > (20120711/psparse-536) > > > > [17056.520479] ACPI Error: Method parse/execution failed > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME > > > > (20120711/psparse-536) > > > > [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST > > > > (20120711/battery-464) > > > > > > I'm seeing this again right now. I'm wondering if it's because I'm > > > running on battery power at the moment: > > > > > > [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for > > > [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI Error: > > > Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node > > > 88045cc64618), AE_TIME (20120913/psparse-536) [41694.309300] > > > ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node > > > 88045cc64988), AE_TIME (20120913/psparse-536) [41694.309310] > > > ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node > > > 88045cc648c0), AE_TIME (20120913/psparse-536) [41694.309324] > > > ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) > > > [41694.809093] ACPI: EC: input buffer is not empty, aborting > > > transaction > > > > > > ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ > > > so that's not the issue here. > > > > > > > And also loadavg is too high ~ 10 > > > > While there is no process that load CPU up to 100% or like that. > > > > I think that this because of processes that is done in kernel space. > > > > (basically that one who write such errors) > > > > > > > > $ uname -a > > > > Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 > > > > 12:39:03 UTC 2012 x86_64 GNU/Linux > > > > > > Ah, ok, that means it's not something new in 3.7-rc, so maybe it's > > > just never worked properly for this hardware :) > > > > > > So it's not a regression, just an ACPI issue, any ACPI developer > > > have an idea about this? > > > > Can you please send the output of acpidump from the affected machine(s)? > > I doubt this problem is sometimes inevitable for some machines, because > AFAIK most modern machines have the race problem for EC HW controller, as > both OS side and the BIOS may access the EC HW at the same time > without any race control. > > For this case, usually the battery and thermal modules (which may be > controlled through EC) are always monitored by BIOS, when OS also > frequently visit them too, the EC's own state machine may be broken and > not responsive due to the race, then cause the timeout error. > And how severe the problem will be depends on the EC HW, the quality of > BIOS code and OS/driver code. > > Myself have seen the similar "ACPI: EC: input buffer is not empty, > aborting transaction" error message on one laptop when its EC is busy > visited by OS. > > btw, in EC driver I see a "ec->global_lock", don't know if it was designed > to control the race between OS and BIOS. > > Thanks, > Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI errors with 3.7-rc3
> And per my check, most of ACPI FW don't implement this lock, say after > driver probe, the ec->global_lock will be 0 Take a look at the FACS table, it contains the address of the global lock. I believe that the ACPI specification requires that the global lock be present. > -Original Message- > From: Tang, Feng > Sent: Friday, November 09, 2012 8:36 AM > To: Moore, Robert > Cc: Rafael J. Wysocki; Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; > Linux Kernel Mailing List; Zheng, Lv; Len Brown > Subject: Re: ACPI errors with 3.7-rc3 > > On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: > > The ACPI Global Lock is in fact intended to provide exclusion between > the BIOS and the OS. > > Bob > > Thanks for the info. > > And per my check, most of ACPI FW don't implement this lock, say after > driver probe, the ec->global_lock will be 0. > > - Feng > > > > > > > > -Original Message- > > > From: Tang, Feng > > > Sent: Friday, November 09, 2012 1:29 AM > > > To: Rafael J. Wysocki > > > Cc: Greg KH; Azat Khuzhin; linux-a...@vger.kernel.org; Linux Kernel > > > Mailing List; Zheng, Lv; Len Brown; Moore, Robert > > > Subject: Re: ACPI errors with 3.7-rc3 > > > > > > On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: > > > > On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: > > > > > On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: > > > > > > I'v also have such errors on my macbook pro. > > > > > > > > > > > > $ dmesg | tail > > > > > > [17056.008564] ACPI Error: Method parse/execution failed > > > > > > [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 88026547ea10), > > > > > > AE_TIME > > > > > > (20120711/psparse-536) > > > > > > [17056.011194] ACPI Error: Method parse/execution failed > > > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME > > > > > > (20120711/psparse-536) > > > > > > [17056.013793] ACPI Error: Method parse/execution failed > > > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME > > > > > > (20120711/psparse-536) > > > > > > [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST > > > > > > (20120711/battery-464) [17056.511373] ACPI: EC: input buffer > > > > > > is not empty, aborting transaction [17056.512672] ACPI > Exception: > > > > > > AE_TIME, Returned by Handler for [EmbeddedControl] > > > > > > (20120711/evregion-501) [17056.515256] ACPI Error: Method > > > > > > parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node > > > > > > 88026547ea10), AE_TIME > > > > > > (20120711/psparse-536) > > > > > > [17056.517886] ACPI Error: Method parse/execution failed > > > > > > [\_SB_.BAT0.UBST] (Node 88026547e678), AE_TIME > > > > > > (20120711/psparse-536) > > > > > > [17056.520479] ACPI Error: Method parse/execution failed > > > > > > [\_SB_.BAT0._BST] (Node 88026547e740), AE_TIME > > > > > > (20120711/psparse-536) > > > > > > [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST > > > > > > (20120711/battery-464) > > > > > > > > > > I'm seeing this again right now. I'm wondering if it's because > > > > > I'm running on battery power at the moment: > > > > > > > > > > [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for > > > > > [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI > Error: > > > > > Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] > > > > > (Node 88045cc64618), AE_TIME (20120913/psparse-536) > > > > > [41694.309300] ACPI Error: Method parse/execution failed > > > > > [\_SB_.BAT0.UBST] (Node 88045cc64988), AE_TIME > > > > > (20120913/psparse-536) [41694.309310] ACPI Error: Method > > > > > parse/execution failed [\_SB_.BAT0._BST] (Node > > > > > 88045cc648c0), AE_TIME (20120913/psparse-536) [41694.309324] > > > > > ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) > > > > > [41694.809093] ACPI: EC: input buffer is not empty, aborting > > > > > transaction > > > > > > > > > > ec_storm_threshold is stil
RE: [PATCH ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
Basically, the flow goes like this: 1) We convert the original FADT (multiple versions) to a common internal FADT. 2) Then we check the common internal FADT for errors/inconsistencies. In this way, we don't need to have different error checking for different versions of the FADT, and this is probably not going to change. One thing we are going to add is to make a decision on whether to favor a 32-bit address or a 64-bit address (if they are different) based upon the age of the machine/BIOS. This is for Windows compatibility. Bob > -Original Message- > From: Ethan Zhao [mailto:ethan.ker...@gmail.com] > Sent: Thursday, November 15, 2012 6:29 PM > To: Moore, Robert > Cc: Brown, Len; Zheng, Lv; LKML > Subject: Re: [PATCH ] tbfadt.c: output warning only when 64bit 32bit > address of FACS/DSDT all have value but not equal to each other > > Bob, >Thanks for your detailed reviewing about the whole possible > conditions. >I.C. So that is impossible zero value for Xfacs /Xdsdt if > facs/dsdt >0, for they are assigned in acpi_tb_convert_fadt(), I need to > move my eyes one line code higher to see why it yelled twice but not using > the 32bit address at once in acpi_tb_convert_fadt(). >Do you agree to move the checking code warning and into > acpi_tb_convert_fadt to make the code more simple and clear ? Or just keep > it for more rework, more bug? > > > Thanks, > Ethan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH ] tbfadt.c: output warning only when 64bit 32bit address of FACS/DSDT all have value but not equal to each other
As I mentioned, we are going to be rewriting this part of the code, so I would
rather wait to until then to make changes. However, this looks like a
reasonable approach to the error check, at first glance.
Thanks,
Bob
> -Original Message-
> From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
> Sent: Thursday, November 15, 2012 9:47 PM
> To: Moore, Robert
> Cc: LKML
> Subject: Re: [PATCH ] tbfadt.c: output warning only when 64bit 32bit
> address of FACS/DSDT all have value but not equal to each other
>
> Bob,
> How about moving some checking code as following patch ?
>
> From f46d539d81c763aa4e3e98f9fc1e94e0af48bd15 Mon Sep 17 00:00:00
> 2001
> From: ethan.zhao
> Date: Sat, 17 Nov 2012 00:48:41 -0800
> Subject: [PATCH]acpica/tbfadt.c Move some checking and 32bit to 64bit
> assignment code from acpi_tb_validate_fadt() to acpi_tb_convert_fadt to
> make the logic clearer and void multiple same kind of warning.
>
>
> Signed-off-by: ethan.zhao
> ---
> drivers/acpi/acpica/tbfadt.c | 51 ++---
>
> 1 files changed, 18 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
> index f23f512..dd18aba 100644
> --- a/drivers/acpi/acpica/tbfadt.c
> +++ b/drivers/acpi/acpica/tbfadt.c
> @@ -388,18 +388,30 @@ static void acpi_tb_convert_fadt(void)
>*/
> if (!acpi_gbl_FADT.Xfacs) {
> acpi_gbl_FADT.Xfacs = (u64) acpi_gbl_FADT.facs;
> - } else if (acpi_gbl_FADT.facs &&
> + } else if ((acpi_gbl_FADT.facs && acpi_gbl_FADT.Xfacs) &&
> (acpi_gbl_FADT.Xfacs != (u64) acpi_gbl_FADT.facs)) {
> - ACPI_WARNING((AE_INFO,
> - "32/64 FACS address mismatch in FADT - two FACS
> tables!"));
> + ACPI_BIOS_WARNING((AE_INFO,
> + "32/64X FACS address mismatch in FADT
> - "
> + "0x%8.8X/0x%8.8X%8.8X, using 32",
> + acpi_gbl_FADT.facs,
> +
> +ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xfacs)));
> +
> + acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
> +
> }
>
> if (!acpi_gbl_FADT.Xdsdt) {
> acpi_gbl_FADT.Xdsdt = (u64) acpi_gbl_FADT.dsdt;
> - } else if (acpi_gbl_FADT.dsdt &&
> + } else if ((acpi_gbl_FADT.dsdt && acpi_gbl_FADT.Xdsdt) &&
> (acpi_gbl_FADT.Xdsdt != (u64) acpi_gbl_FADT.dsdt)) {
> - ACPI_WARNING((AE_INFO,
> - "32/64 DSDT address mismatch in FADT - two DSDT
> tables!"));
> + ACPI_BIOS_WARNING((AE_INFO,
> + "32/64X DSDT address mismatch in FADT
> - "
> + "0x%8.8X/0x%8.8X%8.8X, using 32",
> + acpi_gbl_FADT.dsdt,
> +
> +ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xdsdt)));
> +
> +acpi_gbl_FADT.Xdsdt = (u64)acpi_gbl_FADT.dsdt;
> +
> }
>
> /*
> @@ -507,33 +519,6 @@ static void acpi_tb_validate_fadt(void)
> u8 length;
> u32 i;
>
> - /*
> - * Check for FACS and DSDT address mismatches. An address mismatch
> between
> - * the 32-bit and 64-bit address fields
> (FIRMWARE_CTRL/X_FIRMWARE_CTRL and
> - * DSDT/X_DSDT) would indicate the presence of two FACS or two DSDT
> tables.
> - */
> - if (acpi_gbl_FADT.facs &&
> - (acpi_gbl_FADT.Xfacs != (u64)acpi_gbl_FADT.facs)) {
> - ACPI_BIOS_WARNING((AE_INFO,
> -"32/64X FACS address mismatch in FADT - "
> -"0x%8.8X/0x%8.8X%8.8X, using 32",
> -acpi_gbl_FADT.facs,
> -ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xfacs)));
> -
> - acpi_gbl_FADT.Xfacs = (u64)acpi_gbl_FADT.facs;
> - }
> -
> - if (acpi_gbl_FADT.dsdt &&
> - (acpi_gbl_FADT.Xdsdt != (u64)acpi_gbl_FADT.dsdt)) {
> - ACPI_BIOS_WARNING((AE_INFO,
> -"32/64X DSDT address mismatch in FADT - "
> - "0x%8.8X/0x%8.8X%8.8X, using 32",
> -acpi_gbl_FADT.dsdt,
> -ACPI_FORMAT_UINT64(acpi_gbl_FADT.Xdsdt)));
> -
> - acpi_gbl_FADT.Xdsdt = (u64)acpi_gbl_FADT.dsdt;
> - }
> -
> /* If Hardware Reduced flag is set, we are all done */
>
> if (acpi_gbl_reduced_hardware) {
> --
> 1.7.1
>
RE: [PATCH v4 3/5] acpi: Adjust linux acpi OS functions to new extended parameter
I have not seen a discussion of the details on this, so can someone explain to
me just why acpi_os_prepare_sleep is needed, what does it do, and why these
changes are being made to ACPICA code?
Thanks,
Bob
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, June 27, 2013 8:12 AM
> To: Ben Guthro
> Cc: Moore, Robert; xen-de...@lists.xen.org; Konrad Rzeszutek Wilk; Rafaell
> J . Wysocki; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v4 3/5] acpi: Adjust linux acpi OS functions to new
> extended parameter
>
> >>> On 27.06.13 at 17:02, Ben Guthro wrote:
> > Change the function definitions of acpi_os_prepare_sleep() and
> > acpi_os_set_prepare_sleep() to pass along the new extended sleep
> > parameter.
> >
> > Signed-off-by: Jan Beulich
> > Signed-off-by: Ben Guthro
> > Cc: Bob Moore
> > Cc: Rafaell J. Wysocki
> > Cc: linux-a...@vger.kernel.org
> > ---
> > drivers/acpi/osl.c | 16
> > include/linux/acpi.h |6 +++---
> > 2 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index
> > e721863..0251c9b 100644
> > --- a/drivers/acpi/osl.c
> > +++ b/drivers/acpi/osl.c
> > @@ -77,8 +77,8 @@ EXPORT_SYMBOL(acpi_in_debugger); extern char
> > line_buf[80];
> > #endif /*ENABLE_DEBUGGER */
> >
> > -static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 pm1a_ctrl,
> > - u32 pm1b_ctrl);
> > +static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 val_a, u32
> val_b,
> > + bool extended);
>
> So from here till patch 5 the build will be half broken because of the
> type mismatches? I think at least the types of the consumers need to be
> changed in this patch; leaving the meat of the Xen change to patch 4 is
> perhaps fine.
>
> Jan
>
> >
> > static acpi_osd_handler acpi_irq_handler; static void
> > *acpi_irq_context; @@ -1757,13 +1757,13 @@ acpi_status
> > acpi_os_terminate(void)
> > return AE_OK;
> > }
> >
> > -acpi_status acpi_os_prepare_sleep(u8 sleep_state, u32 pm1a_control,
> > - u32 pm1b_control)
> > +acpi_status acpi_os_prepare_sleep(u8 sleep_state, u32 val_a, u32 val_b,
> > + u8 extended)
> > {
> > int rc = 0;
> > if (__acpi_os_prepare_sleep)
> > - rc = __acpi_os_prepare_sleep(sleep_state,
> > -pm1a_control, pm1b_control);
> > + rc = __acpi_os_prepare_sleep(sleep_state, val_a, val_b,
> > +extended);
> > if (rc < 0)
> > return AE_ERROR;
> > else if (rc > 0)
> > @@ -1772,8 +1772,8 @@ acpi_status acpi_os_prepare_sleep(u8
> > sleep_state, u32 pm1a_control,
> > return AE_OK;
> > }
> >
> > -void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
> > - u32 pm1a_ctrl, u32 pm1b_ctrl))
> > +void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state, u32 val_a,
> > + u32 val_b, bool extended))
> > {
> > __acpi_os_prepare_sleep = func;
> > }
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h index
> > 709a2f2..26f9996 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -477,8 +477,8 @@ static inline bool acpi_driver_match_device(struct
> > device *dev,
> > #endif /* !CONFIG_ACPI */
> >
> > #ifdef CONFIG_ACPI
> > -void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
> > - u32 pm1a_ctrl, u32 pm1b_ctrl));
> > +void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state, u32 val_a,
> > + u32 val_b, bool extended));
> > #ifdef CONFIG_X86
> > void arch_reserve_mem_area(acpi_physical_address addr, size_t size);
> > #else @@ -488,7 +488,7 @@ static inline void
> > arch_reserve_mem_area(acpi_physical_address addr, } #endif /*
> > CONFIG_X86 */ #else -#define acpi_os_set_prepare_sleep(func,
> > pm1a_ctrl, pm1b_ctrl) do { } while
> > (0)
> > +#define acpi_os_set_prepare_sleep(func, val_a, val_b, ext) do { }
> > +while (0)
> > #endif
> >
> > #if defined(CONFIG_ACPI) && defined(CONFIG_PM_RUNTIME)
> > --
> > 1.7.9.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 3/5] acpi: Adjust linux acpi OS functions to new extended parameter
I'm the ACPICA owner. The issue I have is that acpi_os_prepare_sleep causes a divergence between the raw ACPICA source code and the "linux" version of the ACPICA code. If it is possible to implement the functionality that is needed without changes to ACPICA, then that would be best. If not, we are willing to integrate this interface into ACPICA. However, this has an impact on all operating systems that use ACPICA, so this is always the last resort. Bob > -Original Message- > From: Ben Guthro [mailto:benjamin.gut...@citrix.com] > Sent: Thursday, June 27, 2013 9:13 AM > To: Moore, Robert > Cc: Jan Beulich; Zheng, Lv; Box, David E; Brown, Len; xen- > de...@lists.xen.org; Konrad Rzeszutek Wilk; Rafaell J . Wysocki; linux- > a...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v4 3/5] acpi: Adjust linux acpi OS functions to new > extended parameter > > > > On 06/27/2013 11:59 AM, Moore, Robert wrote: > > I have not seen a discussion of the details on this, so can someone > explain to me just why acpi_os_prepare_sleep is needed, what does it do, > and why these changes are being made to ACPICA code? > > Hi Bob, > > I'm not familiar with your background here, so I apologize if I am stating > obvious things below. > > acpi_os_prepare_sleep() has been in the acpica code for some time now, > allowing for OS specific hooks to account for differences between OS > architectures. > > Specifically, it has been in since: > > commit 09f98a825a821f7a3f1b162f9ed023f37213a63b > Author: Tang Liang > Date: Fri Dec 9 10:05:54 2011 +0800 > > x86, acpi, tboot: Have a ACPI os prepare sleep instead of calling > tboot_sleep. > > The ACPI suspend path makes a call to tboot_sleep right before > it writes the PM1A, PM1B values. We replace the direct call to > tboot via an registration callback similar to __acpi_register_gsi. > > CC: Len Brown > Acked-by: Joseph Cihula > Acked-by: Rafael J. Wysocki > [v1: Added __attribute__ ((unused))] > [v2: Introduced a wrapper instead of changing tboot_sleep return > values] > [v3: Added return value AE_CTRL_SKIP for acpi_os_sleep_prepare] > Signed-off-by: Tang Liang > [v1: Fix compile issues on IA64 and PPC64] > [v2: Fix where __acpi_os_prepare_sleep==NULL and did not go in sleep > properly] > Signed-off-by: Konrad Rzeszutek Wilk > > > > In this case, the Xen hypervisor, and not linux needs to actually put the > system into S3, so this hook gives the architecture to do so. > > This change does not introduce this functionality, but simply moves the > code around into the proper locations, such that the acpica code no longer > need to include linux specific headers. > > I hope this helps. > If you have specific questions, please let me know. > > Regards, > Ben > > > > > Thanks, > > Bob > > > > > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Thursday, June 27, 2013 8:12 AM > >> To: Ben Guthro > >> Cc: Moore, Robert; xen-de...@lists.xen.org; Konrad Rzeszutek Wilk; > >> Rafaell J . Wysocki; linux-a...@vger.kernel.org; > >> linux-kernel@vger.kernel.org > >> Subject: Re: [PATCH v4 3/5] acpi: Adjust linux acpi OS functions to > >> new extended parameter > >> > >>>>> On 27.06.13 at 17:02, Ben Guthro wrote: > >>> Change the function definitions of acpi_os_prepare_sleep() and > >>> acpi_os_set_prepare_sleep() to pass along the new extended sleep > >>> parameter. > >>> > >>> Signed-off-by: Jan Beulich > >>> Signed-off-by: Ben Guthro > >>> Cc: Bob Moore > >>> Cc: Rafaell J. Wysocki > >>> Cc: linux-a...@vger.kernel.org > >>> --- > >>> drivers/acpi/osl.c | 16 > >>> include/linux/acpi.h |6 +++--- > >>> 2 files changed, 11 insertions(+), 11 deletions(-) > >>> > >>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index > >>> e721863..0251c9b 100644 > >>> --- a/drivers/acpi/osl.c > >>> +++ b/drivers/acpi/osl.c > >>> @@ -77,8 +77,8 @@ EXPORT_SYMBOL(acpi_in_debugger); extern char > >>> line_buf[80]; > >>> #endif /*ENABLE_DEBUGGER */ > >>> > >>> -static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 pm1a_ctrl, > >>> - u32 pm1b_ctrl); > >>> +static int (*__acpi_os_prepare_s
RE: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.
While we're at it: Can someone send me the acpidump for this machine? We very much would like to test all of ACPICA with such a large DSDT. Thanks, Bob > -Original Message- > From: chen tang [mailto:imtangc...@gmail.com] > Sent: Friday, August 23, 2013 2:51 PM > To: Yinghai Lu > Cc: Russ Anderson; H. Peter Anvin; Zhang Yanfei; Toshi Kani; Tejun Heo; > Tang Chen; Konrad Rzeszutek Wilk; Moore, Robert; Zheng, Lv; Rafael J. > Wysocki; Ingo Molnar; Andrew Morton; Thomas Renninger; Yasuaki Ishimatsu; > Mel Gorman; Linux Kernel Mailing List > Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier. > > Hi Yinghai, > > 2013/8/24 Yinghai Lu : > > On Fri, Aug 23, 2013 at 1:30 PM, Russ Anderson wrote: > >> On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote: > >>> On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin > wrote: > > > >>> Russ, What is ACPI table size on your big machine? > >> > >> This is from a 256 socket 32TB system. > >> > >> Reserving 256MB of memory at 66973408MB for crashkernel (System RAM: > 32501719MB) > >> ACPI: RSDP 7ef3d014 00024 (v02 INTEL ) > >> ACPI: XSDT 7ef3d120 0007C (v01 INTEL TIANO > 0113) > >> ACPI: FACP 7ef3a000 000F4 (v04 INTEL TIANO MSFT > 0113) > >> ACPI: DSDT 7e6c3000 7F493E (v02 SGI2 UVX 0002 MSFT > 0113) > >> ACPI: FACS 7d147000 00040 > >> ACPI: UEFI 7ef3c000 0012A (v01 INTEL RstScuO > ) > >> ACPI: UEFI 7ef3b000 0005C (v01 INTEL RstScuV > ) > >> ACPI: HPET 7ef39000 00038 (v01 INTEL TIANO0001 MSFT > 0113) > >> ACPI: SSDT 7ef33000 05352 (v02 INTEL ROSECITY 0003 INTL > 20070508) > >> ACPI: SLIT 7ef1 1002C (v01 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: APIC 7000 10070 (v03 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: SRAT 7eeb8000 1A830 (v03 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: MCFG 7d6d4000 0105C (v01 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: SPCR 7e6c2000 00050 (v01 > ) > >> ACPI: DMAR 7d6d3000 0013C (v01 INTEL TIANO0001 MSFT > 0113) > >> > > > > so the DSDT is 7F493E, and total is more than 8M. > > > > that will need BRK to be extended 16M? > > > > Then how about use early_ioremap(), and don't do it that early in > head_32 and head64 ? > > Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
I have not looked closely at this, but we typically do things like this in ACPICA so that they only need to be implemented once to support all of the various acpica-hosted operating systems - linux, solaris, hp-ux, apple, freebsd, etc. -- even if they could be implemented "cleaner" in some way on any given host. > -Original Message- > From: Ben Guthro [mailto:benjamin.gut...@citrix.com] > Sent: Wednesday, July 24, 2013 5:01 AM > To: Zheng, Lv > Cc: Konrad Rzeszutek Wilk; Jan Beulich; Rafael J . Wysocki; linux- > ker...@vger.kernel.org; linux-a...@vger.kernel.org; xen- > de...@lists.xen.org; Moore, Robert > Subject: Re: [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in > reduced hardware sleep path > > > > On 07/24/2013 02:24 AM, Zheng, Lv wrote: > > Hi, > > > > Sorry for the delayed response. > > > >> From: Ben Guthro [mailto:benjamin.gut...@citrix.com] > >> Sent: Tuesday, July 02, 2013 7:43 PM > >> > >> > >> On 07/02/2013 02:19 AM, Zheng, Lv wrote: > >>> Thanks for your efforts! > >>> > >>> I wonder if it is possible to remove the argument - "u8 extended" > >>> and convert > >> "pm1a_control, pm1b_control" into some u8 values that are equivalent > >> to "acpi_gbl_sleep_type_a, acpi_gbl_sleep_type_b" in the legacy sleep > path. > >>> It can also simplify Xen codes. > >> > >> Thanks for your time to review this. > >> > >> I'm not sure that this simplifies things. I think that, in fact, it > >> would make them quite a bit more complicated, but perhaps I > misunderstand. > >> > >> Is it not preferred to use the reduced hardware sleep, over the old > method? > >> While these register definitions may be equivalent below, doing the > >> translation in linux, only to translate them back again at a lower > layer seems unnecessary. > >> > > > > Yes, it would require tboot layer to be able to be aware of how such > fields locate in the PM registers. > > So I think you can pass the register address of the field and the field > name/value pair to the tboot, this could simplify things, no lower layer > effort will be needed. > > Please don't worry about the case that a register field could be split > into PM1a and PM1b, it could be a hardware design issue. > > IMO, one field should always be in one register, either PM1a or PM1b. > > Or there could be hardware issues cannot be addressed by the ACPICA > architecture (something like natural atomicity). > > But maybe I'm wrong. > > Again, I don't think this simplifies things, but complicates them > unnecessarily. Converting the reduced hardware sleep to the legacy sleep > seems like it would be an unnecessary layer of translation. > > The interface now simply passes the information from ACPICA down to the > lower layers (xen, tboot) - and then lets them worry about the reduced > hardware implementation. > > FWIW, xen has shipped with this implemetation, and enterprise kernels > using the traditional xen kernel (like Suse) are making use of it. > > It may benefit tboot, in this case, but not Xen. > > I personally see it as an undesirable complication. > > Best regards, > Ben > > > > > Thanks and best regards > > -Lv > > > >> The hypervisor knows how to deal with both the reduced hardware sleep > >> as well as the legacy sleep path - it merely need to distinguish > >> these two paths, when performing the hypercall. > >> > >> Since there are two paths through the higher level ACPICA code - that > >> in hwsleep.c, and hwesleep.c - there needs to be some distinction > >> between the two paths, when calling through to the lower level > >> acpi_os_prepare_sleep() call. > >> > >> An alternate method would be to create another interface named > >> acpi_os_prepare_esleep() which would do the equivalent of this patch > >> series, with an "extended" parameter hidden from upper level > interfaces. > >> > >> This, however, would also add another function to > >> include/acpi/acpiosxf.h - which, I thought was undesirable, in the > >> impression that I got from Bob Moore, and Rafael Wysocki (though, > >> please correct me on this point, if I have > >> misunderstood) > >> > >> Best Regards > >> > >> Ben > >> > >>> > >>> As in ACPI specification, the bit definitions between the legacy > >>> sleep registers > >> and t
RE: [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path
I haven't found a high-level description of "acpi_os_prepare_sleep", perhaps I missed it. Can someone point me to the overall description of this change and why it is being considered? Thanks, Bob > -Original Message- > From: Ben Guthro [mailto:benjamin.gut...@citrix.com] > Sent: Wednesday, July 24, 2013 6:23 AM > To: Moore, Robert > Cc: Zheng, Lv; Konrad Rzeszutek Wilk; Jan Beulich; Rafael J . Wysocki; > linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; xen- > de...@lists.xen.org > Subject: Re: [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in > reduced hardware sleep path > > On 07/24/2013 09:18 AM, Moore, Robert wrote: > > I have not looked closely at this, but we typically do things like this > in ACPICA so that they only need to be implemented once to support all of > the various acpica-hosted operating systems - linux, solaris, hp-ux, > apple, freebsd, etc. -- even if they could be implemented "cleaner" in > some way on any given host. > > Even when the resulting "simplification" results in reduced functionality? > > Maybe I am misunderstanding the suggestion...but it sounded like it was > basically to mimic the traditional behavior, and mask out the reduced > hardware capabilities on these system types. > > It seems to me that if the system supports the reduced hardware ACPI > sleep, you would want to make use of it... > > > > > > > > > > >> -Original Message- > >> From: Ben Guthro [mailto:benjamin.gut...@citrix.com] > >> Sent: Wednesday, July 24, 2013 5:01 AM > >> To: Zheng, Lv > >> Cc: Konrad Rzeszutek Wilk; Jan Beulich; Rafael J . Wysocki; linux- > >> ker...@vger.kernel.org; linux-a...@vger.kernel.org; xen- > >> de...@lists.xen.org; Moore, Robert > >> Subject: Re: [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in > >> reduced hardware sleep path > >> > >> > >> > >> On 07/24/2013 02:24 AM, Zheng, Lv wrote: > >>> Hi, > >>> > >>> Sorry for the delayed response. > >>> > >>>> From: Ben Guthro [mailto:benjamin.gut...@citrix.com] > >>>> Sent: Tuesday, July 02, 2013 7:43 PM > >>>> > >>>> > >>>> On 07/02/2013 02:19 AM, Zheng, Lv wrote: > >>>>> Thanks for your efforts! > >>>>> > >>>>> I wonder if it is possible to remove the argument - "u8 extended" > >>>>> and convert > >>>> "pm1a_control, pm1b_control" into some u8 values that are > >>>> equivalent to "acpi_gbl_sleep_type_a, acpi_gbl_sleep_type_b" in the > >>>> legacy sleep > >> path. > >>>>> It can also simplify Xen codes. > >>>> > >>>> Thanks for your time to review this. > >>>> > >>>> I'm not sure that this simplifies things. I think that, in fact, it > >>>> would make them quite a bit more complicated, but perhaps I > >> misunderstand. > >>>> > >>>> Is it not preferred to use the reduced hardware sleep, over the old > >> method? > >>>> While these register definitions may be equivalent below, doing the > >>>> translation in linux, only to translate them back again at a lower > >> layer seems unnecessary. > >>>> > >>> > >>> Yes, it would require tboot layer to be able to be aware of how such > >> fields locate in the PM registers. > >>> So I think you can pass the register address of the field and the > >>> field > >> name/value pair to the tboot, this could simplify things, no lower > >> layer effort will be needed. > >>> Please don't worry about the case that a register field could be > >>> split > >> into PM1a and PM1b, it could be a hardware design issue. > >>> IMO, one field should always be in one register, either PM1a or PM1b. > >>> Or there could be hardware issues cannot be addressed by the ACPICA > >> architecture (something like natural atomicity). > >>> But maybe I'm wrong. > >> > >> Again, I don't think this simplifies things, but complicates them > >> unnecessarily. Converting the reduced hardware sleep to the legacy > >> sleep seems like it would be an unnecessary layer of translation. > >> > >> The interface now simply passes the information from ACPICA down to > >> the lower layers (xen, tboot) - and then lets them w
RE: [Update][PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks
> > > I thought about that, but actually there's no guarantee that the > > > handle will be valid after _EJ0 as far as I can say. So the race > > > condition is going to be there anyway and using struct acpi_device > > > just makes it easier to avoid it. > > > > In theory, yes, a stale handle could be a problem, if _EJ0 performs > > unload table and if ACPICA frees up its internal data structure > > pointed by the handle as a result. But we should not see such issue > > now since we do not support dynamic ACPI namespace yet. > > I'm waiting for information from Bob about that. If we can assume ACPI > handles to be always valid, that will simplify things quite a bit. If a table is unloaded, all the namespace nodes for that table are removed from the namespace, and thus any ACPI_HANDLE pointers go stale and invalid. Bob
RE: [Update][PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Thursday, February 14, 2013 4:04 AM
> To: Moore, Robert
> Cc: Toshi Kani; ACPI Devel Maling List; LKML; Bjorn Helgaas; Jiang Liu;
> Yinghai Lu; Yasuaki Ishimatsu; Myron Stowe; linux-...@vger.kernel.org
> Subject: Re: [Update][PATCH] ACPI / hotplug: Fix concurrency issues and
> memory leaks
>
> On Thursday, February 14, 2013 02:31:22 AM Moore, Robert wrote:
> > > > > I thought about that, but actually there's no guarantee that the
> > > > > handle will be valid after _EJ0 as far as I can say. So the
> > > > > race condition is going to be there anyway and using struct
> > > > > acpi_device just makes it easier to avoid it.
> > > >
> > > > In theory, yes, a stale handle could be a problem, if _EJ0
> > > > performs unload table and if ACPICA frees up its internal data
> > > > structure pointed by the handle as a result. But we should not
> > > > see such issue now since we do not support dynamic ACPI namespace
> yet.
> > >
> > > I'm waiting for information from Bob about that. If we can assume
> > > ACPI handles to be always valid, that will simplify things quite a
> bit.
> >
> > If a table is unloaded, all the namespace nodes for that table are
> > removed from the namespace, and thus any ACPI_HANDLE pointers go stale
> and invalid.
>
> OK, thanks!
>
> To me this means that we cannot assume a handle to stay valid between a
> notify handler and acpi_bus_hot_remove_device() run from a workqueue.
>
> Is there a mechanism in ACPICA to ensure that a handle won't become stale
> while a notify handler is running for it or is the OS responsible for
> ensuring that
> _EJ0 won't be run in parallel with notify handlers for device objects
> being ejected?
>
It is up to the host.
Bob
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [Update][PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Thursday, February 14, 2013 12:59 PM
> To: Moore, Robert
> Cc: Toshi Kani; ACPI Devel Maling List; LKML; Bjorn Helgaas; Jiang Liu;
> Yinghai Lu; Yasuaki Ishimatsu; Myron Stowe; linux-...@vger.kernel.org
> Subject: Re: [Update][PATCH] ACPI / hotplug: Fix concurrency issues and
> memory leaks
>
> On Thursday, February 14, 2013 08:45:14 PM Moore, Robert wrote:
> >
> > > -Original Message-
> > > From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> > > Sent: Thursday, February 14, 2013 4:04 AM
> > > To: Moore, Robert
> > > Cc: Toshi Kani; ACPI Devel Maling List; LKML; Bjorn Helgaas; Jiang
> > > Liu; Yinghai Lu; Yasuaki Ishimatsu; Myron Stowe;
> > > linux-...@vger.kernel.org
> > > Subject: Re: [Update][PATCH] ACPI / hotplug: Fix concurrency issues
> > > and memory leaks
> > >
> > > On Thursday, February 14, 2013 02:31:22 AM Moore, Robert wrote:
> > > > > > > I thought about that, but actually there's no guarantee that
> > > > > > > the handle will be valid after _EJ0 as far as I can say. So
> > > > > > > the race condition is going to be there anyway and using
> > > > > > > struct acpi_device just makes it easier to avoid it.
> > > > > >
> > > > > > In theory, yes, a stale handle could be a problem, if _EJ0
> > > > > > performs unload table and if ACPICA frees up its internal data
> > > > > > structure pointed by the handle as a result. But we should
> > > > > > not see such issue now since we do not support dynamic ACPI
> > > > > > namespace
> > > yet.
> > > > >
> > > > > I'm waiting for information from Bob about that. If we can
> > > > > assume ACPI handles to be always valid, that will simplify
> > > > > things quite a
> > > bit.
> > > >
> > > > If a table is unloaded, all the namespace nodes for that table are
> > > > removed from the namespace, and thus any ACPI_HANDLE pointers go
> > > > stale
> > > and invalid.
> > >
> > > OK, thanks!
> > >
> > > To me this means that we cannot assume a handle to stay valid
> > > between a notify handler and acpi_bus_hot_remove_device() run from a
> workqueue.
> > >
> > > Is there a mechanism in ACPICA to ensure that a handle won't become
> > > stale while a notify handler is running for it or is the OS
> > > responsible for ensuring that
> > > _EJ0 won't be run in parallel with notify handlers for device
> > > objects being ejected?
> > >
> >
> > It is up to the host.
>
> I was afraid that that might be the case. :-)
>
> So far the (Linux) host has been happily ignoring that potential problem,
> so I guess it can still be ignored for a while, although we'll need to
> address it eventually at one point.
I would think it should be fairly simple to setup a mechanism to either tell
the driver or for the driver to figure it out -- such that the driver knows
that all handles associated with the device are now invalid. Another way to
look at it is that when the device is re-installed, the driver should
reinitialize such that it obtains new handles for the devices and subobjects in
question.
Bob
>
> Thanks,
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [Update][PATCH] ACPI / hotplug: Fix concurrency issues and memory leaks
> > > > > > > > Is there a mechanism in ACPICA to ensure that a handle > > > > > > > > won't become stale while a notify handler is running for > > > > > > > > it or is the OS responsible for ensuring that > > > > > > > > _EJ0 won't be run in parallel with notify handlers for > > > > > > > > device objects being ejected? > > > > > > > > > > > > > > > > > > > > > > It is up to the host. > > > > > > > > > > > > I was afraid that that might be the case. :-) > > > > > > > > > > > > So far the (Linux) host has been happily ignoring that > > > > > > potential problem, so I guess it can still be ignored for a > > > > > > while, although we'll need to address it eventually at one > point. > > > > > > > > > > I would think it should be fairly simple to setup a mechanism to > > > > > either tell the driver or for the driver to figure it out -- > > > > > such that the driver knows that all handles associated with the > > > > > device are now invalid. Another way to look at it is that when > > > > > the device is re-installed, the driver should reinitialize such > > > > > that it obtains new handles for the devices and subobjects in > question. > > > > > > > > Unfortunately, there is quite strong assumption in our code that > > > > ACPI handles will not become stale before the device objects > > > > associated with them are removed. For this reason, we need to > > > > know in advance which handles will become stale as a result of a > > > > table unload and remove their device objects beforehand. > > > > > > > > Moreover, when there's a notify handler installed for a given ACPI > > > > handle and that handle becomes stale while the notify handler is > > > > running, we'll be in trouble. To avoid that we need to ensure > > > > that table unloads and notifies will always be mutually exclusive. > > > > > > I wonder if we can make acpi_ns_validate_handle() to actually be > > > able to verify if a given handle is valid. This way, ACPICA can > > > fail gracefully > > > (AE_BAD_PARAMETER) when a stable handle is passed to the interfaces. > > > > That'd be good, but to implement it, I think, it would be necessary to > > introduce some reference counting of namespace objects such that the > > given object would only be deleted after the last reference to it had > been dropped. > > On table unload it would just be marked as invalid, but it would stay > > in memory as long as there were any references to it. > > > > So, for example, a notify handler would start from something like > > acpi_add_reference(handle), which would guarantee that the object > > pointed to by handle would stay in memory, and it would finish by > > doing > > acpi_drop_reference(handle) or a work item scheduled by it would do > that. > > > > We do that for objects based on struct device and it works well. > > There is other way to implement it. Since acpi_handle is defined as an > opaque value, this could be changed to an index to an array of pointers, > instead of a direct pointer. Then we can safely invalidate an index by > invalidating the pointer associated with the index. We have of course thought about adding a mechanism to validate/invalidate acpica namespace handles. In fact, this is why the ACPI_HANDLE data type was introduced in the first place, so that if we ever wanted or needed to implement something like this, it would not break a lot of existing code. However, we have never had a real need to implement such a mechanism, nor has the ever been a request from any of the operating systems that run ACPICA. The existing model is that the host has knowledge of what objects will go away when a table is unloaded, and can simply assume that all related acpi handles will go bad after the unload (and table unload is the only case where parts of the namespace go away, as far as I remember). Upon a reload of the table, the host knows to reinitialize all handles associated with the table/device. ACPCI has a table handler mechanism, where the host handler is invoked *before* an ACPI table is actually unloaded, so the host can prepare for the unload. For example, before returning from the table handler, the host may want to synchronize by waiting for any outstanding notifies to complete, then simply ignoring any further notifies from any devices associated with the table. In summary, it has always been felt that the fairly large overhead of implementing a mechanism like this is not worth the cost, as well as not really needed. I suggest that the implementation of eject support proceed by using the existing mechanisms such as the table handler. If additional support/interfaces are needed in ACPICA, we can discuss it. However, just about the last thing I would like to do is add a level of indirection between the ACPI_HANDLE and the ACPI_NAMESPACE_NODE -- which would require a large, global change to ACPICA that would be only applicable for a single rather rare issue, the unloading of an ACPI table. Just the fact that we are di
RE: [PATCH v2] ACPI: Leave Bus Master Arbitration enabled for suspend/resume
> Bob, I think we should incorporate this into ACPICA, shouldn't we?
>
> Rafael
We are looking at it. Probably one of the Linux/ACPICA divergences that end up
causing us grief.
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Sunday, July 08, 2012 1:08 PM
> To: Jonathan Nieder; Moore, Robert
> Cc: Octavio Alvarez; Adrian Knoth; Shaohua Li; Brown, Len; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] ACPI: Leave Bus Master Arbitration enabled for
> suspend/resume
>
> On Sunday, July 08, 2012, Jonathan Nieder wrote:
> > This is an old suspend/resume lockup fix:
> >
> > commit 2780cc4660e1
> > Author: Len Brown
> > Date: Thu Dec 23 13:43:30 2004 -0500
> >
> > [ACPI] Fix suspend/resume lockup issue
> > by leaving Bus Master Arbitration enabled.
> > The ACPI spec mandates it be disabled only for C3.
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=3599
> >
> > Signed-off-by: David Shaohua Li
> > Signed-off-by: Len Brown
> >
> > The bug snuck back in in commit 2feec47d4c5f (ACPICA: ACPI 5: Support
> > for new FADT SleepStatus, SleepControl registers, 2012-02-14),
> > presumably by copy/pasting a copy of the code without that fix for
> the
> > legacy case.
> >
> > On affected machines, after that commit, the machine locks up hard on
> > resume from suspend. The same fix as seven years ago still works.
> >
> > Addresses <https://bugzilla.kernel.org/show_bug.cgi?id=43641>.
> >
> > Reported-bisected-and-tested-by: Octavio Alvarez
> >
> > Reported-by: Adrian Knoth
> > Signed-off-by: Jonathan Nieder
> > Cc: # 3.4
> > ---
> > Rafael J. Wysocki wrote:
> >
> > > Can you please repost it with _both_ the changelog and the patch?
> >
> > Here you go. Sorry about that.
>
> Thanks!
>
> Applied to the linux-next branch of the linux-pm.git tree.
>
> I think I'll push it for v3.6, since the bug is serious and is a
> regression.
>
> Bob, I think we should incorporate this into ACPICA, shouldn't we?
>
> Rafael
>
>
> > drivers/acpi/acpica/hwsleep.c | 22 --
> > 1 file changed, 22 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/hwsleep.c
> > b/drivers/acpi/acpica/hwsleep.c index 0ed85cac3231..615996a36bed
> > 100644
> > --- a/drivers/acpi/acpica/hwsleep.c
> > +++ b/drivers/acpi/acpica/hwsleep.c
> > @@ -95,18 +95,6 @@ acpi_status acpi_hw_legacy_sleep(u8 sleep_state,
> u8 flags)
> > return_ACPI_STATUS(status);
> > }
> >
> > - if (sleep_state != ACPI_STATE_S5) {
> > - /*
> > -* Disable BM arbitration. This feature is contained within
> an
> > -* optional register (PM2 Control), so ignore a BAD_ADDRESS
> > -* exception.
> > -*/
> > - status = acpi_write_bit_register(ACPI_BITREG_ARB_DISABLE,
> 1);
> > - if (ACPI_FAILURE(status) && (status != AE_BAD_ADDRESS)) {
> > - return_ACPI_STATUS(status);
> > - }
> > - }
> > -
> > /*
> > * 1) Disable/Clear all GPEs
> > * 2) Enable all wakeup GPEs
> > @@ -364,16 +352,6 @@ acpi_status acpi_hw_legacy_wake(u8 sleep_state,
> u8 flags)
> > [ACPI_EVENT_POWER_BUTTON].
> > status_register_id, ACPI_CLEAR_STATUS);
> >
> > - /*
> > -* Enable BM arbitration. This feature is contained within an
> > -* optional register (PM2 Control), so ignore a BAD_ADDRESS
> > -* exception.
> > -*/
> > - status = acpi_write_bit_register(ACPI_BITREG_ARB_DISABLE, 0);
> > - if (ACPI_FAILURE(status) && (status != AE_BAD_ADDRESS)) {
> > - return_ACPI_STATUS(status);
> > - }
> > -
> > acpi_hw_execute_sleep_method(METHOD_PATHNAME__SST,
> ACPI_SST_WORKING);
> > return_ACPI_STATUS(status);
> > }
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Fwd: Hid over I2C and ACPI interaction
These are already defined in acpica - in the file acrestyp.h ACPI_RESOURCE_FIXED_DMA FixedDma; ACPI_RESOURCE_GPIO Gpio; ACPI_RESOURCE_I2C_SERIALBUS I2cSerialBus; ACPI_RESOURCE_SPI_SERIALBUS SpiSerialBus; ACPI_RESOURCE_UART_SERIALBUSUartSerialBus; ACPI_RESOURCE_COMMON_SERIALBUS CommonSerialBus; >-Original Message- >From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- >ow...@vger.kernel.org] On Behalf Of Lan Tianyu >Sent: Sunday, July 08, 2012 8:25 PM >To: Mika Westerberg >Cc: Zhang, Rui; kh...@linux-fr.org; ben-li...@fluff.org; >w.s...@pengutronix.de; l...@kernel.org; linux-a...@vger.kernel.org; linux- >i...@vger.kernel.org; linux-kernel@vger.kernel.org; jkos...@suse.cz; >cha...@enac.fr; jj_d...@emc.com.tw; bhelg...@google.com; abe...@mit.edu >Subject: Re: Fwd: Hid over I2C and ACPI interaction > >On 2012年07月06日 13:52, Mika Westerberg wrote: >> On Thu, Jul 05, 2012 at 03:01:57PM +0800, Zhang Rui wrote: >>> +Note that although these are ACPI devices, we prefer to use PnP drivers >>> for them, >>> +this is because: >>> +1. all the non-ACPI-predefined Devices are exported as PnP devices as >>> well >>> +2. PnP bus is a well designed bus. Probing via PnP layer saves a lot of >>> work >>> + for the device driver, e.g. getting& parsing ACPI resources. >> >> (Nice BKM, thanks for sharing) >> >> I have few questions about using PnP drivers instead of pure ACPI >drivers. >> >> ACPI 5.0 defined some new resources, for example "Fixed DMA descriptor" >> that has information about the request line + channel for the device to >> use. Hovewer, PnP drivers pass resources as 'struct resource', which >> basically only has start and end - how do you represent all this new >stuff >> using 'struct resource'? >> >I think we can add new interface to get acpi specific resources. e.g >struct acpi_resource pnp_get_acpi_resource(...). When the pnp acpi devices >were initialized, put those acpi specific resources into a new resource >list >pnpdev->acpi_resources. What pnp_get_acpi_resource does is to get specified >type acpi resources and return. We also need to define some acpi resource >types. > >ACPI_RESOURCE_DMA >ACPI_RESOURCE_I2C_SERIALBUS >ACPI_RESOURCE_SPI_SERIALBUS >ACPI_RESOURCE_UART_SERIALBUS >ACPI_RESOURCE_COMMON_SERIALBUS >... > >How about this? welcome to comments. > >> Or should we use acpi_walk_resources() where 'struct resource' is not >> suitable? >> > >-- >Best Regards >Tianyu Lan >linux kernel enabling team >-- >To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ACPI] RE: ACPI oddity
And in fact, some BIOS vendors purposely run their code through an obfuscator which changes everything to things like ABC9 and XYZ4 or C001, C002, etc. > -Original Message- > From: [EMAIL PROTECTED] [mailto:acpi-devel- > [EMAIL PROTECTED] On Behalf Of Brown, Len > Sent: Monday, July 25, 2005 10:02 PM > To: Bill Davidsen; Linux Kernel Mailing List > Cc: [EMAIL PROTECTED] > Subject: [ACPI] RE: ACPI oddity > > >On a HT system, why does ACPI recognize CPU0 and CPU1, refer > >to them as such in dmesg > > This is the Linux CPU number. ie the namespace where 0 > is the boot processor and the others are numbered in > the order that they were started. > > > and then call them CPU1 and CPU2 in > >/proc/acpi/processor? > > These are arbitrary device identifiers written > by the BIOS developer and foolishly advertised > to the user by Linux. The BIOS writer could have > also called them ABC9 and XYZ4 and it would be > equally valid. > > We're planning to get rid of all the ACPI stuff > in /proc and move to sysfs. At that time we'll > use device identifies that are deterministic, > like cpu%d that /sys/devices/system uses today. > > cheers, > -Len > > > --- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick > ___ > Acpi-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acpi-devel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ACPI] Re: 2.6.13-rc3-mm3
+ACPI-0287: *** Error: Region SystemMemory(0) has no handler +ACPI-0127: *** Error: acpi_load_tables: Could not load namespace: AE_NOT_EXIST +ACPI-0136: *** Error: acpi_load_tables: Could not load tables: This looks like a nasty case where some executable code in the table is attempting to access a SystemMemory operation region before any OpRegion handlers are initialized. We certainly want to see the output of acpidump to attempt to diagnose and/or reproduce the problem. Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [ACPI] utilities/: Compliment va_start() with va_end().
This is an interesting one to me.
>From various documentation:
After all arguments have been retrieved, va_end resets the pointer to
NULL.
va_end
Each invocation of va_start must be matched by a corresponding
invocation of va_end in the same function. After the call va_end(ap) the
variable ap is undefined. Multiple transversals of the list, each
bracketed by va_start and va_end are possible. va_end may be a macro or
a function.
Now, I'm all for defensive programming, but I don't really see the point
of va_end when the list will be only traversed once.
We don't set all local pointers to NULL at function exit, what is the
point of doing it here?
I suppose some implementation could allocate memory at va_start, but in
practice, does this happen?
Bob
>-Original Message-
>From: Len Brown [mailto:[EMAIL PROTECTED]
>Sent: Saturday, November 24, 2007 11:06 PM
>To: Moore, Robert
>Subject: Fwd: [PATCH] [ACPI] utilities/: Compliment va_start() with
>va_end().
>
>
>
>-- Forwarded Message --
>
>Subject: [PATCH] [ACPI] utilities/: Compliment va_start() with
va_end().
>Date: Saturday 24 November 2007 15:43
>From: Richard Knutsson <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Richard
>Knutsson <[EMAIL PROTECTED]>
>
>Compliment va_start() with va_end().
>
>Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
>---
>Compile-tested on i386 with allyesconfig & allmodconfig.
>
> utdebug.c |2 ++
> utmisc.c |4
> 2 files changed, 6 insertions(+)
>
>
>diff --git a/drivers/acpi/utilities/utdebug.c
>b/drivers/acpi/utilities/utdebug.c
>index c7e128e..f45e3d5 100644
>--- a/drivers/acpi/utilities/utdebug.c
>+++ b/drivers/acpi/utilities/utdebug.c
>@@ -203,6 +203,7 @@ acpi_ut_debug_print(u32 requested_debug_level,
>
> va_start(args, format);
> acpi_os_vprintf(format, args);
>+ va_end(args);
> }
>
> ACPI_EXPORT_SYMBOL(acpi_ut_debug_print)
>@@ -240,6 +241,7 @@ acpi_ut_debug_print_raw(u32 requested_debug_level,
>
> va_start(args, format);
> acpi_os_vprintf(format, args);
>+ va_end(args);
> }
>
> ACPI_EXPORT_SYMBOL(acpi_ut_debug_print_raw)
>diff --git a/drivers/acpi/utilities/utmisc.c
>b/drivers/acpi/utilities/utmisc.c
>index 2d19f71..ca4904c 100644
>--- a/drivers/acpi/utilities/utmisc.c
>+++ b/drivers/acpi/utilities/utmisc.c
>@@ -1032,6 +1032,7 @@ acpi_ut_error(char *module_name, u32 line_number,
>char *format, ...)
>
> va_start(args, format);
> acpi_os_vprintf(format, args);
>+ va_end(args);
> acpi_os_printf(" [%X]\n", ACPI_CA_VERSION);
> }
>
>@@ -1046,6 +1047,7 @@ acpi_ut_exception(char *module_name,
>
> va_start(args, format);
> acpi_os_vprintf(format, args);
>+ va_end(args);
> acpi_os_printf(" [%X]\n", ACPI_CA_VERSION);
> }
>
>@@ -1060,6 +1062,7 @@ acpi_ut_warning(char *module_name, u32
line_number,
>char *format, ...)
>
> va_start(args, format);
> acpi_os_vprintf(format, args);
>+ va_end(args);
> acpi_os_printf(" [%X]\n", ACPI_CA_VERSION);
> }
>
>@@ -1076,5 +1079,6 @@ acpi_ut_info(char *module_name, u32 line_number,
char
>*format, ...)
>
> va_start(args, format);
> acpi_os_vprintf(format, args);
>+ va_end(args);
> acpi_os_printf("\n");
> }
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [ACPI] utilities/: Compliment va_start() with va_end().
Yes, it's official ANSI C, so I agree with the portability. I'm probably asking more about the history of the thing. >-Original Message- >From: Richard Knutsson [mailto:[EMAIL PROTECTED] >Sent: Monday, November 26, 2007 4:16 PM >To: Moore, Robert >Cc: Len Brown; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] >Subject: Re: [PATCH] [ACPI] utilities/: Compliment va_start() with >va_end(). > >Moore, Robert wrote: >> This is an interesting one to me. >> >> From various documentation: >> >> After all arguments have been retrieved, va_end resets the pointer to >> NULL. >> >> va_end >> Each invocation of va_start must be matched by a corresponding >> invocation of va_end in the same function. After the call va_end(ap) the >> variable ap is undefined. Multiple transversals of the list, each >> bracketed by va_start and va_end are possible. va_end may be a macro or >> a function. >> >> Now, I'm all for defensive programming, but I don't really see the point >> of va_end when the list will be only traversed once. >> >> >First off, I think it is a good idea to follow the documentation, which >stated: >"va_end >Each invocation of va_start must be matched by a corresponding >invocation of va_end in the same function." > >Then if it is not really needed, does it take up extra cycles? >"In practice, with most C compilers, calling |va_end| does nothing >and you do not really need to call it. This is always true in the GNU C >compiler."[1] > >Portability: >"But you might as well call |va_end| just in case your >program is someday compiled with a peculiar compiler."[2] >This argument is not as likely thou, but who knows? (Since I guess Intel's >compiler is included in the 'most C compilers') > >> >> We don't set all local pointers to NULL at function exit, what is the >> point of doing it here? >> >I think it is a good thing if the code follows the documentation, both >for the person who tries >to understand the code (to see when the 'args' is no longer needed and >not getting confused >by the absent of va_end(), after all, IMHO we should write the code how >we want things to >work and let the compiler do the optimizations (it usually does a better >job at it then we do)) >and to automated searches (that is how I found this one). >> I suppose some implementation could allocate memory at va_start, but in >> practice, does this happen? >> >Not sure what you mean. >> Bob >> >> >cu >Richard Knutsson > >[1] >http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_28.ht ml >[2] The rest of [1]'s line. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: down_timeout
I see this as the kind of function that should be implemented within the
semaphore interface itself. Very simple - Just wake me up when either 1) I
get the semaphore, or 2) I timed out.
A single implementation saves everyone from attempting to implement this
over and over and over.
Bob
-Original Message-
From: Ingo Oeser
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 25, 2001 4:49 PM
To: Grover, Andrew
Cc: '[EMAIL PROTECTED]'; Moore, Robert
Subject:Re: down_timeout
On Wed, Apr 25, 2001 at 04:21:22PM -0700, Grover, Andrew
wrote:
> It seems like we need to implement down_timeout (and
> down_timeout_interruptible) to fully flesh out the
semaphore implementation.
> It is difficult and inefficient to emulate this using
wrapper functions, as
> far as I can see.
>
> Seems like this is a fairly standard interface to have for
OS semaphores. We
> have a prototype implementation, and could contribute
this, if desired.
>
> Thoughts?
Sure you can't implement this via waitqueues? semaphores use
them
internally anyway.
I use this for interrupt or polling based waiting:
/* IO polling waits */
/* Timeout after this amount of jiffies */
#define IO_POLL_TIMEOUT (HZ)
/* Split timeout while polling into chunks of that many
jiffies */
#define IO_POLL_SPLIT 2
/* generic interrupt based wait with timeouts! */
#define __wait_event_timeout_int(wq, condition, timeout,
ret) \
do { \
struct wait_queue __wait; \
signed long __expire=timeout; \
__wait.task=current; \
add_wait_queue(wq, &__wait); \
for (;;) { \
current->state=TASK_UNINTERRUPTIBLE;
\
mb(); \
if (condition) break; \
__expire=schedule_timeout(__expire);
\
if (__expire == 0) { \
ret=-ETIMEDOUT; \
break; \
} \
} \
current->state = TASK_RUNNING; \
remove_wait_queue(wq, &__wait); \
} while (0)
/* polling wait, if we shouldn't use interrupts for this */
#define __wait_event_timeout_poll(wq, condition, timeout,
ret) \
do { \
unsigned int __tries=0; \
unsigned int __maxtry=timeout /
IO_POLL_SPLIT; \
do { \
schedule_timeout(IO_POLL_SPLIT); \
if (condition) \
break; \
} while (++__tries < __maxtry); \
if (__tries == __maxtry && !condition) \
ret=-ETIMEDOUT; \
} while (0)
#ifdef INTS_ARE_CHEAP
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_int(wq, condition, timeout,
ret)
#else /* INTS_ARE_CHEAP */
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_poll(wq, condition, timeout,
ret)
#endif /* INTS_ARE_CHEAP */
#define wait_event_timeout(wq, condition, timeout, ret) \
do { \
if (condition) \
break; \
__wait_event_timeout(wq, condition, timeout,
ret); \
} while (0)
What about that?
Use it just as you use wait_event() but check for -ETIMEDOUT
as
value in ret.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag
<http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun
>>>>>>>>>>>>
-
To unsubscribe
RE: [PATCH -mm 3/3] PM: Improve handling of ACPI system state indicator (rev. 3)
Since these changes appear to affect the ACPICA core in a fairly big way, I would like to see a short, concise description of each change and why it is necessary. Thanks, Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael J. Wysocki Sent: Monday, August 27, 2007 2:53 PM To: Andrew Morton Cc: ACPI Devel Maling List; Len Brown; LKML; Pavel Machek; pm list Subject: [PATCH -mm 3/3] PM: Improve handling of ACPI system state indicator (rev. 3) From: Rafael J. Wysocki <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -mm 3/3] PM: Improve handling of ACPI system state indicator (rev. 3)
No, it's not safe to run the AML interpreter with interrupts disabled. I don't have any problem with introducing finer granularity enter/exit sleep interfaces if they are required. I would suggest that we rename things a bit however. Currently: acpi_enter_sleep_state_prep acpi_enter_sleep_state_prep_late acpi_enter_sleep_state acpi_leave_sleep_state_prep acpi_leave_sleep_state I think we can truncate and clarify: acpi_sleep_setup1 acpi_sleep_setup2 acpi_sleep acpi_wake_setup1 acpi_wake acpi_set_sleep_state_indicator: I'm not sure if we have any external interfaces that simply execute a control method, seems like overkill. Please give me more information as to why _SSI needs to be moved (other than executing it after _BFS) Thanks, Bob -Original Message- From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 3:05 PM To: Moore, Robert Cc: Andrew Morton; ACPI Devel Maling List; Len Brown; LKML; Pavel Machek; pm list Subject: Re: [PATCH -mm 3/3] PM: Improve handling of ACPI system state indicator (rev. 3) On Tuesday, 28 August 2007 21:57, Moore, Robert wrote: > Since these changes appear to affect the ACPICA core in a fairly big > way, I would like to see a short, concise description of each change and > why it is necessary. All right. I'll describe the changes made by the current version of the patches, but please note that if it's safe to run the AML interpreter with IRQs disabled, it's better to do some of them in a different way. 1. Remove the execution of _GTS from acpi_enter_sleep_state_prep() acpi_enter_sleep_state_prep() is called before disabling the nonboot CPUs and _GTS should be executed after that, according to the spec. 2. Introduce acpi_enter_sleep_state_prep_late() that will execute _GTS Necessary because of 1. 3. Split acpi_leave_sleep_state() into two functions: acpi_leave_sleep_state_prep() and acpi_leave_sleep_state(). acpi_leave_sleep_state_prep() contains the code that should be executed before enabling the nonboot CPUs, most importantly the execution of _BFS, and acpi_leave_sleep_state() contains the remaining code (the enabling of GPEs, the execution of _WAK and the enabling of power buttons) 4. Change the code ordering in acpi_leave_sleep_state_prep() (introduced in 3.) so that _SST is executed after _BFS According to the spec, _BFS should be the first ACPI method executed after leaving a sleep state 5. Introduce acpi_set_sleep_state_indicator() that will execute _SST for given ACPI sleep state Needed so that we can set the state indicator independently of the other lower-level operations. 6. Remove the execution of _SST from acpi_leave_sleep_state() No longer needed, because we can use acpi_set_sleep_state_indicator() to set the state indicator appropriately from higher level routines. The other changes affect only drivers/acpi/sleep/main.c and the files in kernel/power . Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.21-rc1: more ACPI errors (EC__)
This exception appears to be originating somewhere in the EC driver: ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for [EmbeddedControl] [20070126] > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-acpi- > [EMAIL PROTECTED] On Behalf Of Meelis Roos > Sent: Tuesday, February 27, 2007 12:50 PM > To: Linux Kernel list; linux-acpi@vger.kernel.org > Subject: 2.6.21-rc1: more ACPI errors (EC__) > > I tested 2.6.21-rc1 on my laptop (IBM X20 with 440BX) and found two > problems: > > First, a seemingly harmless one - ACPI error messages during bootup: > > ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for > [EmbeddedControl] [20070126] > ACPI Exception (dswexec-0462): AE_NOT_FOUND, While resolving operands for > [OpcodeName unavailable] [20070126] > ACPI Error (psparse-0537): Method parse/execution failed > [\_SB_.PCI0.ISA_.EC__.BAT0._STA] (Node d3c435e0), AE_NOT_FOUND > ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for > [EmbeddedControl] [20070126] > ACPI Error (psparse-0537): Method parse/execution failed > [\_SB_.PCI0.ISA_.EC__.AC__._PSR] (Node d3c43540), AE_NOT_FOUND > ACPI Exception (ac-0095): AE_NOT_FOUND, Error reading AC Adapter state > [20070126] > > And second, there were ACPI error messages about EC__ during shutdown. > These messages appeared, then the "acpi_power_off called" message > appeared, then it waited for about 5 seconds (this does not happen > normally) and then it succeeded shutting down. Captured a screenshot of > these messages, temporarily available at > http://www.cs.ut.ee/~mroos/x20-shutdown-acpi-errors.jpg > > -- > Meelis Roos ([EMAIL PROTECTED]) > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] - increase acpi owner_id max
The OwnerId field within a namespace node is 8 bits, and this is the main constraint on the maximum OwnerId. You can't simply bump up the number of owner ids without changing this field. If we need more than 255 owner Ids, the width of this field will have to be increased, or we will need to use a pointer for the field in order to maintain a linked list of all nodes owned by a particular owner. Bob > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-acpi- > [EMAIL PROTECTED] On Behalf Of John Keller > Sent: Friday, January 26, 2007 2:40 PM > To: linux-acpi@vger.kernel.org > Cc: [EMAIL PROTECTED]; linux-ia64@vger.kernel.org; linux- > [EMAIL PROTECTED]; John Keller > Subject: [PATCH 1/1] - increase acpi owner_id max > > To support systems with large IO configurations, > this patch increases the number of available ACPI > owner ids to 1023. > > On SN platforms, we represent every populated root > bus slot with an ACPI SSDT table containing info > for every device and PPB attached to the slot. > Each SSDT requires a unique ACPI owner id. > > Signed-off-by: John Keller <[EMAIL PROTECTED]> > --- > > drivers/acpi/utilities/utmisc.c |6 +++--- > include/acpi/acconfig.h |4 ++-- > include/acpi/aclocal.h |4 ++-- > 3 files changed, 7 insertions(+), 7 deletions(-) > > > Index: linux/drivers/acpi/utilities/utmisc.c > === > --- linux.orig/drivers/acpi/utilities/utmisc.c2007-01-25 > 11:27:25.509259412 -0600 > +++ linux/drivers/acpi/utilities/utmisc.c 2007-01-26 13:16:09.551081284 - > 0600 > @@ -147,7 +147,7 @@ acpi_status acpi_ut_allocate_owner_id(ac > /* >* Construct encoded ID from the index and bit > position >* > - * Note: Last [j].k (bit 255) is never used and is > marked > + * Note: Last [j].k (bit 1023) is never used and > is marked >* permanently allocated (prevents +1 overflow) >*/ > *owner_id = > @@ -175,7 +175,7 @@ acpi_status acpi_ut_allocate_owner_id(ac >*/ > status = AE_OWNER_ID_LIMIT; > ACPI_ERROR((AE_INFO, > - "Could not allocate new OwnerId (255 max), > AE_OWNER_ID_LIMIT")); > + "Could not allocate new OwnerId (1023 max), > AE_OWNER_ID_LIMIT")); > >exit: > (void)acpi_ut_release_mutex(ACPI_MTX_CACHES); > @@ -192,7 +192,7 @@ acpi_status acpi_ut_allocate_owner_id(ac > * control method or unloading a table. Either way, we would > * ignore any error anyway. > * > - * DESCRIPTION: Release a table or method owner ID. Valid IDs are 1 - > 255 > + * DESCRIPTION: Release a table or method owner ID. Valid IDs are 1 - > 1023 > * > > ** > / > > Index: linux/include/acpi/acconfig.h > === > --- linux.orig/include/acpi/acconfig.h2007-01-25 11:27:25.577267818 - > 0600 > +++ linux/include/acpi/acconfig.h 2007-01-26 13:17:14.111002597 -0600 > @@ -111,9 +111,9 @@ > > #define ACPI_SYSMEM_REGION_WINDOW_SIZE 4096 > > -/* owner_id tracking. 8 entries allows for 255 owner_ids */ > +/* owner_id tracking. 32 entries allow for 1023 owner_ids */ > > -#define ACPI_NUM_OWNERID_MASKS 8 > +#define ACPI_NUM_OWNERID_MASKS 32 > > > /*** ** > * > * > Index: linux/include/acpi/aclocal.h > === > --- linux.orig/include/acpi/aclocal.h 2007-01-25 11:27:25.585268807 - > 0600 > +++ linux/include/acpi/aclocal.h 2007-01-26 13:20:06.148115848 -0600 > @@ -122,8 +122,8 @@ static char *acpi_gbl_mutex_names[ACPI_N > > /* Owner IDs are used to track namespace nodes for selective deletion */ > > -typedef u8 acpi_owner_id; > -#define ACPI_OWNER_ID_MAX 0xFF > +typedef u16 acpi_owner_id; > +#define ACPI_OWNER_ID_MAX 0x3FF > > /* This Thread ID means that the mutex is not in use (unlocked) */ > > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] - increase acpi owner_id max
OK, I missed that. Can you give us some idea of just how many SSDTs this machine loads? Does it dynamically delete SSDTs also? Thanks, Bob > -Original Message- > From: Aaron Young [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 4:03 PM > To: Moore, Robert > Cc: John Keller; linux-acpi@vger.kernel.org; [EMAIL PROTECTED]; linux- > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Alexey Starikovskiy; > Brown, Len > Subject: Re: [PATCH 1/1] - increase acpi owner_id max > > > > > The OwnerId field within a namespace node is 8 bits, and this is the > > main constraint on the maximum OwnerId. You can't simply bump up the > > number of owner ids without changing this field. > > Isn't this accomplished with the mod to aclocal.h below - i.e. > by making a acpi_owner_id a u16 instead of a u8?: > > -typedef u8 acpi_owner_id; > -#define ACPI_OWNER_ID_MAX 0xFF > +typedef u16 acpi_owner_id; > +#define ACPI_OWNER_ID_MAX 0x3FF > > > > > If we need more than 255 owner Ids, the width of this field will have to > > be increased, or we will need to use a pointer for the field in order to > > maintain a linked list of all nodes owned by a particular owner. > > > > Bob > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:linux-acpi- > > > [EMAIL PROTECTED] On Behalf Of John Keller > > > Sent: Friday, January 26, 2007 2:40 PM > > > To: linux-acpi@vger.kernel.org > > > Cc: [EMAIL PROTECTED]; linux-ia64@vger.kernel.org; linux- > > > [EMAIL PROTECTED]; John Keller > > > Subject: [PATCH 1/1] - increase acpi owner_id max > > > > > > To support systems with large IO configurations, > > > this patch increases the number of available ACPI > > > owner ids to 1023. > > > > > > On SN platforms, we represent every populated root > > > bus slot with an ACPI SSDT table containing info > > > for every device and PPB attached to the slot. > > > Each SSDT requires a unique ACPI owner id. > > > > > > Signed-off-by: John Keller <[EMAIL PROTECTED]> > > > --- > > > > > > drivers/acpi/utilities/utmisc.c |6 +++--- > > > include/acpi/acconfig.h |4 ++-- > > > include/acpi/aclocal.h |4 ++-- > > > 3 files changed, 7 insertions(+), 7 deletions(-) > > > > > > > > > Index: linux/drivers/acpi/utilities/utmisc.c > > > === > > > --- linux.orig/drivers/acpi/utilities/utmisc.c2007-01-25 > > > 11:27:25.509259412 -0600 > > > +++ linux/drivers/acpi/utilities/utmisc.c 2007-01-26 > > 13:16:09.551081284 - > > > 0600 > > > @@ -147,7 +147,7 @@ acpi_status acpi_ut_allocate_owner_id(ac > > > /* > > >* Construct encoded ID from the index > > and bit > > > position > > >* > > > - * Note: Last [j].k (bit 255) is never > > used and is > > > marked > > > + * Note: Last [j].k (bit 1023) is never > > used and > > > is marked > > >* permanently allocated (prevents +1 > > overflow) > > >*/ > > > *owner_id = > > > @@ -175,7 +175,7 @@ acpi_status acpi_ut_allocate_owner_id(ac > > >*/ > > > status = AE_OWNER_ID_LIMIT; > > > ACPI_ERROR((AE_INFO, > > > - "Could not allocate new OwnerId (255 max), > > > AE_OWNER_ID_LIMIT")); > > > + "Could not allocate new OwnerId (1023 max), > > > AE_OWNER_ID_LIMIT")); > > > > > >exit: > > > (void)acpi_ut_release_mutex(ACPI_MTX_CACHES); > > > @@ -192,7 +192,7 @@ acpi_status acpi_ut_allocate_owner_id(ac > > > * control method or unloading a table. Either way, we > > would > > > * ignore any error anyway. > > > * > > > - * DESCRIPTION: Release a table or method owner ID. Valid IDs are 1 > > - > > > 255 > > > + * DESCRIPTION: Release a table or method owner ID. Valid IDs are 1 > > - > > > 1023 > > > * > > > > > > > > > > ** > > > / > > > > > > Index: linux/include/acpi/acconfig.h &g
RE: [PATCH 1/1] - increase acpi owner_id max
I'm not sure that it is a great idea to increase the number of owner IDs "just in case", rather than in response to the needs of a specific machine. Increasing the size of this field increases the size of every namespace node in the namespace. Remember, there can be thousands of namespace nodes, so this size increase may not be trivial. Also, the existing namespace node has been optimized for alignment and size such that increasing the size by 8 bits probably increases it by 32 bits as far as the memory manager is concerned (at least on some operating systems.) Our feeling (the ACPICA team) has been that the existing 8-bit owner ID is sufficient for current machines; If and when this becomes truly insufficient, we are prepared to go to a linked list model to track namespace nodes owned by a particular table or control method. Bob > -Original Message- > From: Aaron Young [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 30, 2007 12:39 PM > To: Moore, Robert > Cc: John Keller; linux-acpi@vger.kernel.org; [EMAIL PROTECTED]; linux- > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Alexey Starikovskiy; > Brown, Len > Subject: Re: [PATCH 1/1] - increase acpi owner_id max > > > > > OK, I missed that. > > > > Can you give us some idea of just how many SSDTs this machine loads? > > It depends. SGI SN configs can vary dramatically. We create a unique > SSDT for each populated PCI slot. The previous 255 SSDT id maximum > could theoretically be surpassed on machines with huge amounts of IO - > although configs with that much IO are extremely rare. We were > just trying to avoid any (future) configuration limitations. > > > > > Does it dynamically delete SSDTs also? > > Yes. Our SN hotplug driver will add or remove SSDTs from the system > upon hotplugs/hotunplugs. > > > > > Thanks, > > Bob > > > > > > > -Original Message- > > > From: Aaron Young [mailto:[EMAIL PROTECTED] > > > Sent: Friday, January 26, 2007 4:03 PM > > > To: Moore, Robert > > > Cc: John Keller; linux-acpi@vger.kernel.org; [EMAIL PROTECTED]; linux- > > > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Alexey > > Starikovskiy; > > > Brown, Len > > > Subject: Re: [PATCH 1/1] - increase acpi owner_id max > > > > > > > > > > > The OwnerId field within a namespace node is 8 bits, and this is the > > > > main constraint on the maximum OwnerId. You can't simply bump up the > > > > number of owner ids without changing this field. > > > > > > Isn't this accomplished with the mod to aclocal.h below - i.e. > > > by making a acpi_owner_id a u16 instead of a u8?: > > > > > > -typedef u8 acpi_owner_id; > > > -#define ACPI_OWNER_ID_MAX 0xFF > > > +typedef u16 acpi_owner_id; > > > +#define ACPI_OWNER_ID_MAX 0x3FF > > > > > > > > > > > If we need more than 255 owner Ids, the width of this field will > > have to > > > > be increased, or we will need to use a pointer for the field in > > order to > > > > maintain a linked list of all nodes owned by a particular owner. > > > > > > > > Bob > > > > > > > > > -Original Message- > > > > > From: [EMAIL PROTECTED] [mailto:linux-acpi- > > > > > [EMAIL PROTECTED] On Behalf Of John Keller > > > > > Sent: Friday, January 26, 2007 2:40 PM > > > > > To: linux-acpi@vger.kernel.org > > > > > Cc: [EMAIL PROTECTED]; linux-ia64@vger.kernel.org; linux- > > > > > [EMAIL PROTECTED]; John Keller > > > > > Subject: [PATCH 1/1] - increase acpi owner_id max > > > > > > > > > > To support systems with large IO configurations, > > > > > this patch increases the number of available ACPI > > > > > owner ids to 1023. > > > > > > > > > > On SN platforms, we represent every populated root > > > > > bus slot with an ACPI SSDT table containing info > > > > > for every device and PPB attached to the slot. > > > > > Each SSDT requires a unique ACPI owner id. > > > > > > > > > > Signed-off-by: John Keller <[EMAIL PROTECTED]> > > > > > --- > > > > > > > > > > drivers/acpi/utilities/utmisc.c |6 +++--- > > > > > include/acpi/acconfig.h |4 ++-- > > > > > include/acpi/aclocal.h |4 ++-- > > > > > 3 files changed, 7
RE: [lm-sensors] Could the k8temp driver be interfering with ACPI?
Included the Intel ACPI spec representative. I have heard that Windows is somehow restricting the ports and memory locations that are accessible via AML; I don't know any of the details. Also, there are fears of an "AML virus" attacking the machine. Bob > -Original Message- > From: Pavel Machek [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 08, 2007 11:19 PM > To: Moore, Robert > Cc: Jean Delvare; Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > [EMAIL PROTECTED]; linux-kernel; [EMAIL PROTECTED] > Subject: Re: [lm-sensors] Could the k8temp driver be interfering with > ACPI? > > Hi! > > > Port (and memory) addresses can be dynamically generated by the AML code > > and thus, there is no way that the ACPI subsystem can statically predict > > any addresses that will be accessed by the AML. > > Can you take this as a wishlist item? > > It would be nice if next version of acpi specs supported table > > 'AML / SMM BIOS will access these ports' > > ...so we can get it correct with acpi4 or something..? > > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [lm-sensors] Could the k8temp driver be interfering with ACPI?
No ACPI discussion can be complete without mentioning Microsoft and Microsoft compatibility -- Windows does not fully support ACPI 2.0 to this day, even though it was released in the year 2000, and ACPI 3.0 has been out since 2004. > -Original Message- > From: Alexey Starikovskiy [mailto:[EMAIL PROTECTED] > Sent: Friday, March 09, 2007 9:35 AM > To: Jean Delvare > Cc: Pavel Machek; Moore, Robert; Matthew Garrett; Chuck Ebbert; Rudolf > Marek; linux-acpi@vger.kernel.org; linux-kernel; [EMAIL PROTECTED] > Subject: Re: [lm-sensors] Could the k8temp driver be interfering with > ACPI? > > Jean Delvare wrote: > > Hi Alexey, > > > > On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote: > > > >> Jean Delvare wrote: > >> > >>> I can only second Pavel's wish here. This would be highly convenient > >>> for OS developers to at least know which resources are accessed by AML > >>> and SMM. Without this information, we can never be sure that OS-level > >>> code won't conflict with ACPI or SMM. > >>> > >> BIOS vendors are not required to support latest and greatest ACPI spec. > >> So even if some future spec version > >> will include this ports description, we will still have majority of > >> hardware not exporting it... > >> > > > > Your reasoning is amazing. So we should refrain from proposing any > > improvement which we aren't certain 100% of the systems will support > > tomorrow? Then let's all stay away from our keyboards forever, as the > > evolution of computer technology is based on exactly that - > > improvements which not all systems implement. > > > > It's friday evening, let's have some more for fun. With a similar > > logic, ten years ago we'd have come up with the following conclusions: > > > > The majority of computers have a single CPU, there is no point in > > adding SMP support to Linux. > > > > Let's not add a new instruction set in our next CPU family. The > > majority of systems will not implement it so it will be useless anyway. > > > > There's no point in supporting PnP in Linux, there are a majority of > > legacy ISA cards out there which do not support it anyway! > > > > See my point? Just because not every hardware out there supports a > > given standard doesn't make that standard necessarily useless. > > > > Just make the next version of ACPI better than the previous one (not > > necessarily a challenge) and everyone will embrace it. > > > > > You get me wrong, I'm not against the proposal, so keep your breath. > I'm just saying that you get old waiting for BIOS vendors to export this > info, even if it's in spec. > > Regards, > Alex. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Could the k8temp driver be interfering with ACPI?
> Could regular Linux device drivers install such handlers for a specific > I/O region? No. ACPICA only supports operation region handlers on a per-address-space basis, not per-region. > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. As far as the AML interpreter is concerned, access to the SMBus is via an operation region. So, each access to such a region would encompass a single SMBus transaction. Also, the interpreter remains locked during this access (I'm fairly sure) even though the EC driver is involved. > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? I think the spec is referring to any global namespace object. This includes operation regions, so the answer is yes, as long as access to the region does not block and cause the interpreter to be released. As far as ACPICA, none of the default handlers for operation regions will block. Bob > -Original Message- > From: Jean Delvare [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 03, 2007 12:21 AM > To: Moore, Robert > Cc: Pavel Machek; Brown, Len; Matthew Garrett; Chuck Ebbert; Rudolf Marek; > linux-acpi@vger.kernel.org; linux-kernel; [EMAIL PROTECTED] > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Hi Bob, > > On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote: > > The ACPI specification allows concurrent execution of control methods > > although methods cannot be preempted. The ACPICA interpreter mutex is > > used to implement this model. > > > > From section 5.5.2, "Control Method Execution": Interpretation of a > > Control Method is not preemptive, but it can block. When a control > > method does block, the operating software can initiate or continue the > > execution of a different control method. A control method can only > > assume that access to global objects is exclusive for any period the > > control method does not block. > > Do I/O regions count as "global objects"? > > > Therefore, the interpreter lock is acquired and a control method is > > allowed to execute to completion unless it blocks on one of the events > > described below. If the method blocks, the interpreter is unlocked and > > other control methods may execute. > > > > I'm not sure what you mean by "in the middle of an SMBus transaction", I > > don't know how long such a transaction is valid. I might guess that a > > single transaction can only span a single operation region access, but > > I'm not sure of this. > > Basically an SMBus transaction looks like this: > 1* Prepare the transaction. > 2* Start the transaction. > 3* Wait for the transaction to complete, typically a few ms. > 4* Read the result of the transaction. > > Steps 1 and 2 require writing to the SMBus I/O region. Step 4 requires > reading from it, and so does step 3 if the wait loop is poll-based. The > transaction is only safe if we have an exclusive access to the I/O > region during all the 4 steps. My fear is that step 3 could be > implemented by ACPI using either a Sleep() or Acquire() or Wait() > opcode. If it is, we're doomed. OTOH, if it does, it is probably not > even safe for itself, unless there's an additional, > implementation-specific mutex to protect SMBus transactions. I yet have > to get my hands on the DSDT of ACPI implementations which actually > access the SMBus to see exactly how they do it. > > > A user-installed operation region handler is an operation region handler > > that is installed by a device driver. This feature would probably only > > be used for custom (OEM-defined) operation region address spaces. (I > > have not seen one yet.) For the standard address spaces (memory, I/O, > > etc.), usually only the default handlers are used. > > Could regular Linux device drivers install such handlers for a specific > I/O region? I'm asking because Rudolf Marek's proposal [1] to solve the > concurrent access problem involved extending struct resource with > callbacks to driver-specific routines to handle external access to an > I/O region. This sounds somewhat similar to these "user-installed > operation region handler" defined by ACPI, doesn't it? If ACPI already > has an infrastructure to handle this problem, we probably want to use > it rather than implementing our own. > > [1] http://marc.info/?l=linux-kernel&m=117302946017204&w=2 > > -- > Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI interpreter errors
Status 5 from ACPICA is AE_NOT_FOUND. _OSC is an optional control method, so whatever code is squawking about it probably handle it and shut up. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Udo A. Steinberg Sent: Friday, April 27, 2007 5:08 AM To: Linux Kernel Mailing List Cc: Linux ACPI Mailing List Subject: ACPI interpreter errors Hello, With 2.6.21 I am getting the following errors from the ACPI interpreter on an Intel S5000PSL board: Allocate Port Service[:02:02.0:pcie20] Allocate Port Service[:02:02.0:pcie21] Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:02.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:03.0:pcie01 failed with error 1 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:04.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:05.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:06.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:07.0:pcie01 failed with error 1 The complete dmesg output is attached. If you need more information, please let me know. Cheers, - Udo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [lm-sensors] Could the k8temp driver be interfering with ACPI?
Port (and memory) addresses can be dynamically generated by the AML code and thus, there is no way that the ACPI subsystem can statically predict any addresses that will be accessed by the AML. > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-acpi- > [EMAIL PROTECTED] On Behalf Of Jean Delvare > Sent: Friday, March 02, 2007 1:05 PM > To: Matthew Garrett > Cc: Pavel Machek; Chuck Ebbert; Rudolf Marek; linux-acpi@vger.kernel.org; > linux-kernel; [EMAIL PROTECTED] > Subject: Re: [lm-sensors] Could the k8temp driver be interfering with > ACPI? > > On Fri, 2 Mar 2007 14:18:40 +, Matthew Garrett wrote: > > On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote: > > > > > I'm not familiar with APCI at all so I didn't know, but what you write > > > here brings some hope. Would it be possible to parse all the DSDT code > > > at boot time and deduce all the ports which ACPI would need to request > > > to be safe? Or do we have to wait for the accesses to actually happen? > > > > In theory I /think/ so, but it would probably end up being an > > overestimate of the coverage actually needed. Trapping at runtime is > > arguably more elegant? > > It might be more elegant but it won't work. We don't want to prevent > ACPI from accessing these I/O ports. If we need to choose only one > "driver" accessing the I/O port, it must be acpi, at leat for now, > despite the fact that acpi provides very weak hardware monitoring > capabilities compared to the specific drivers. > > Why would we end up with an overestimation if we check the I/O ports at > boot time? Do you have concrete cases in mind? > > Thanks, > -- > Jean Delvare > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [lm-sensors] Could the k8temp driver be interfering with ACPI?
In other words, as per my earlier message: Port addresses can be dynamically generated by the AML code and thus, there is no way that the ACPI subsystem can statically predict any addresses that will be accessed by the AML. Bob > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-acpi- > [EMAIL PROTECTED] On Behalf Of Pavel Machek > Sent: Tuesday, March 06, 2007 1:21 PM > To: Jean Delvare > Cc: Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > [EMAIL PROTECTED]; linux-kernel; [EMAIL PROTECTED] > Subject: Re: [lm-sensors] Could the k8temp driver be interfering with > ACPI? > > Hi! > > > > > Is there anything preventing us from doing such a walk and pre- > allocate > > > > all the I/O ranges? I am not familiar with the ACPI code at all, > would > > > > you possibly propose a patch doing that? > > > > > > ACPI AML is probably turing-complete: I'm afraid you are trying to > > > solve the halting problem (-> impossible). > > > > Can you please translate this into something mere humans like myself > > have a chance to understand? > > ACPI AML is turing-complete -- that means it is as powerful any > programming language. It can do arbitrary computation. That means it > is theoretically impossible to analyze its accesses using any program. > > Now... may be possible to introduce _some_ ACPI BIOSes, but doing it > would certainly be very complex -- we are talking "put gcc into > kernel" here. > > So no, it is not possible to preallocate the ranges. > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Could the k8temp driver be interfering with ACPI?
The ACPI specification allows concurrent execution of control methods although methods cannot be preempted. The ACPICA interpreter mutex is used to implement this model. >From section 5.5.2, "Control Method Execution": Interpretation of a Control Method is not preemptive, but it can block. When a control method does block, the operating software can initiate or continue the execution of a different control method. A control method can only assume that access to global objects is exclusive for any period the control method does not block. Therefore, the interpreter lock is acquired and a control method is allowed to execute to completion unless it blocks on one of the events described below. If the method blocks, the interpreter is unlocked and other control methods may execute. I'm not sure what you mean by "in the middle of an SMBus transaction", I don't know how long such a transaction is valid. I might guess that a single transaction can only span a single operation region access, but I'm not sure of this. A user-installed operation region handler is an operation region handler that is installed by a device driver. This feature would probably only be used for custom (OEM-defined) operation region address spaces. (I have not seen one yet.) For the standard address spaces (memory, I/O, etc.), usually only the default handlers are used. Bob > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-acpi- > [EMAIL PROTECTED] On Behalf Of Jean Delvare > Sent: Monday, April 02, 2007 8:49 AM > To: Pavel Machek; Brown, Len > Cc: Matthew Garrett; Chuck Ebbert; Rudolf Marek; linux- > [EMAIL PROTECTED]; linux-kernel; [EMAIL PROTECTED] > Subject: Re: Could the k8temp driver be interfering with ACPI? > > Looking at the comment before acpi_ex_exit_interpreter raises two > questions though: > > > * Cases where the interpreter is unlocked: > > * 1) Completion of the execution of a control method > > * 2) Method blocked on a Sleep() AML opcode > > * 3) Method blocked on an Acquire() AML opcode > > * 4) Method blocked on a Wait() AML opcode > > * 5) Method blocked to acquire the global lock > > * 6) Method blocked to execute a serialized control method that is > > * already executing > > * 7) About to invoke a user-installed opregion handler > > 1* This suggests that the mutex could be released by the AML > interpreter in the middle of an SMBus transaction. If so, and if it > happens in practice, this means that we unfortunately cannot use this > mutex to reliably protect the SMBus drivers from concurrent accesses. > This even suggests that it's simply not possible to have a mutex we > take at the beginning when entering the AML interpreter and we release > when leaving the AML interpreter, as it looks like ACPI itself allows > interlaced execution of AML functions. Len, is this true? > > What is the purpose of the ACPI_MTX_INTERPRETER mutex in the first > place, given that it seems it will be released on numerous occasions? > Is it to prevent concurrent AML execution while still allowing > interlaced execution? > > 2* What are "user-installed opregion handlers"? Are they something that > could help solve the ACPI vs. other drivers problem? > > Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ACPICA / Interpreter: Remove redundant newline
> -Original Message-
> From: Zheng, Lv
> Sent: Tuesday, September 13, 2016 8:11 PM
> To: Moore, Robert ; Moore, Robert
> ; Borislav Petkov ; LKML ker...@vger.kernel.org>
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; Wysocki, Rafael J
> ; Box, David E
> Subject: RE: [PATCH] ACPICA / Interpreter: Remove redundant newline
>
> Hi,
>
> > From: linux-acpi-ow...@vger.kernel.org
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Moore, Robert
> > David E
> > Subject: RE: [PATCH] ACPICA / Interpreter: Remove redundant newline
> >
> > Well, I never thought I would write a couple lines of code like this,
> > but here is a solution that should make everyone happy.
> >
> > diff --git a/source/components/tables/tbxfload.c
> > b/source/components/tables/tbxfload.c
> > index 6a937b1..73ee1a2 100644
> > --- a/source/components/tables/tbxfload.c
> > +++ b/source/components/tables/tbxfload.c
> > @@ -334,7 +334,7 @@ AcpiTbLoadNamespace (
> > if (!TablesFailed)
> > {
> > ACPI_INFO ((
> > -"%u ACPI AML tables successfully acquired and loaded\n",
> > +"%u ACPI AML tables successfully acquired and loaded",
> > TablesLoaded));
> > }
> > else
> > @@ -348,6 +348,11 @@ AcpiTbLoadNamespace (
> > Status = AE_CTRL_TERMINATE;
> > }
> >
> > +#ifdef ACPI_APPLICATION
> > +ACPI_DEBUG_PRINT_RAW ((ACPI_DB_INIT, "\n")); #endif
> > +
> > +
>
[Moore, Robert]
I have no problem with this, I just want to get it over with.
It is not a big deal, let's leave it at that and not make it a big issue.
> IMO, these lines should be in ACPICA upstream, in a file under
> tools/acpiexec.
>
> Thanks
> Lv
>
> > UnlockAndExit:
> > (void) AcpiUtReleaseMutex (ACPI_MTX_TABLES);
> > return_ACPI_STATUS (Status);
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ACPICA: Remove unnecessary '\n' in the end of ACPI_INFO output
I put that \n in there to break up the output from AcpiExec. This comes up
every year or so, I think I'll give up -- without really seeing the harm in an
extra \n.
> -Original Message-
> From: Zheng, Lv
> Sent: Sunday, August 7, 2016 5:56 PM
> To: Alexander Kuleshov ; Moore, Robert
>
> Cc: Wysocki, Rafael J ; Len Brown
> ; linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH] ACPICA: Remove unnecessary '\n' in the end of
> ACPI_INFO output
>
> > From: Alexander Kuleshov [mailto:kuleshovm...@gmail.com]
> > Subject: [PATCH] ACPICA: Remove unnecessary '\n' in the end of
> > ACPI_INFO output
> >
> > as the ACPI_INFO already prints `\n` in the end itself.
> [Lv Zheng]
> Looks good.
> Acked-by: Lv Zheng
> However this patch should go through ACPICA upstream.
>
> Thanks
> -Lv
>
> >
> > Signed-off-by: Alexander Kuleshov
> > ---
> > drivers/acpi/acpica/tbxfload.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpica/tbxfload.c
> > b/drivers/acpi/acpica/tbxfload.c index ac71abc..e7119b7 100644
> > --- a/drivers/acpi/acpica/tbxfload.c
> > +++ b/drivers/acpi/acpica/tbxfload.c
> > @@ -240,7 +240,7 @@ acpi_status acpi_tb_load_namespace(void)
> > }
> >
> > if (!tables_failed) {
> > - ACPI_INFO(("%u ACPI AML tables successfully acquired and
> > loaded\n", tables_loaded));
> > + ACPI_INFO(("%u ACPI AML tables successfully acquired and
> > loaded", tables_loaded));
> > } else {
> > ACPI_ERROR((AE_INFO,
> > "%u table load failures, %u successful",
> > --
> > 2.8.0.rc3.1353.gea9bdc0
RE: [PATCH]: acpica/nfit: Rename not-armed bit definition
+#define ACPI_NFIT_MEM_NOT_ARMED (1<<3) /* 03: Memory Device observed
to be not armed */
I'll add this to ACPICA immediately, for the next release in mid-september.
> -Original Message-
> From: Toshi Kani [mailto:toshi.k...@hp.com]
> Sent: Friday, August 28, 2015 7:40 AM
> To: Williams, Dan J; Wysocki, Rafael J; Moore, Robert
> Cc: de...@acpica.org; linux-nvd...@lists.01.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; Toshi Kani
> Subject: [PATCH]: acpica/nfit: Rename not-armed bit definition
>
> ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines bit 3 as
> follows.
>
> Bit [3] set to 1 to indicate that the Memory Device is observed
> to be not armed prior to OSPM hand off. A Memory Device is
> considered armed if it is able to accept persistent writes.
>
> This bit is currently defined as ACPI_NFIT_MEM_ARMED, which can be
> confusing as if the Memory Device is armed when this bit is set.
>
> Change the name to ACPI_NFIT_MEM_NOT_ARMED per the spec.
>
> Signed-off-by: Toshi Kani
> Cc: Bob Moore
> Cc: Dan Williams
> Cc: Rafael J. Wysocki
> ---
> This patch is based on the linus's tree.
> ---
> drivers/acpi/nfit.c |6 +++---
> drivers/acpi/nfit.h |2 +-
> include/acpi/actbl1.h|2 +-
> tools/testing/nvdimm/test/nfit.c |2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c index
> cf0fd96..4596e0a 100644
> --- a/drivers/acpi/nfit.c
> +++ b/drivers/acpi/nfit.c
> @@ -705,7 +705,7 @@ static ssize_t flags_show(struct device *dev,
> flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "",
> flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail " : "",
> flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "",
> - flags & ACPI_NFIT_MEM_ARMED ? "not_armed " : "",
> + flags & ACPI_NFIT_MEM_NOT_ARMED ? "not_armed " : "",
> flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart_event " : "");
> } static DEVICE_ATTR_RO(flags); @@ -830,7 +830,7 @@ static int
> acpi_nfit_register_dimms(struct acpi_nfit_desc *acpi_desc)
> flags |= NDD_ALIASING;
>
> mem_flags = __to_nfit_memdev(nfit_mem)->flags;
> - if (mem_flags & ACPI_NFIT_MEM_ARMED)
> + if (mem_flags & ACPI_NFIT_MEM_NOT_ARMED)
> flags |= NDD_UNARMED;
>
> rc = acpi_nfit_add_dimm(acpi_desc, nfit_mem, device_handle);
> @@ -854,7 +854,7 @@ static int acpi_nfit_register_dimms(struct
> acpi_nfit_desc *acpi_desc)
> mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? " save_fail" : "",
> mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "
> restore_fail":"",
> mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? " flush_fail" : "",
> - mem_flags & ACPI_NFIT_MEM_ARMED ? " not_armed" : "");
> + mem_flags & ACPI_NFIT_MEM_NOT_ARMED ? " not_armed" : "");
>
> }
>
> diff --git a/drivers/acpi/nfit.h b/drivers/acpi/nfit.h index
> 79b6d83..90505e3 100644
> --- a/drivers/acpi/nfit.h
> +++ b/drivers/acpi/nfit.h
> @@ -24,7 +24,7 @@
> #define UUID_NFIT_DIMM "4309ac30-0d11-11e4-9191-0800200c9a66"
> #define ACPI_NFIT_MEM_FAILED_MASK (ACPI_NFIT_MEM_SAVE_FAILED \
> | ACPI_NFIT_MEM_RESTORE_FAILED | ACPI_NFIT_MEM_FLUSH_FAILED \
> - | ACPI_NFIT_MEM_ARMED)
> + | ACPI_NFIT_MEM_NOT_ARMED)
>
> enum nfit_uuids {
> NFIT_SPA_VOLATILE,
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index
> fcd5709..238754e 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -1012,7 +1012,7 @@ struct acpi_nfit_memory_map {
> #define ACPI_NFIT_MEM_SAVE_FAILED (1) /* 00: Last SAVE to Memory
> Device failed */
> #define ACPI_NFIT_MEM_RESTORE_FAILED(1<<1) /* 01: Last RESTORE from
> Memory Device failed */
> #define ACPI_NFIT_MEM_FLUSH_FAILED (1<<2) /* 02: Platform flush
> failed */
> -#define ACPI_NFIT_MEM_ARMED (1<<3) /* 03: Memory Device
> observed to be not armed */
> +#define ACPI_NFIT_MEM_NOT_ARMED (1<<3) /* 03: Memory Device
> observed to be not armed */
> #define ACPI_NFIT_MEM_HEALTH_OBSERVED (1<<4) /* 04: Memory Device
> observed SMART/health e
RE: [PATCH] acpi: set return value to const char for some functions
In ACPICA, we tend to be very careful concerning the "const" keyword in order
to avoid a phenomenon known as "const pollution".
That is not to say that we won't use const in some limited cases.
Bob
> -Original Message-
> From: LABBE Corentin [mailto:clabbe.montj...@gmail.com]
> Sent: Wednesday, October 14, 2015 12:07 PM
> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org; LABBE Corentin
> Subject: [PATCH] acpi: set return value to const char for some functions
>
> This patch set some array of const char as const.
> In the same time, some function return pointer to thoses array without
> properly giving the information that the data is const.
> This patch set the return type of thoses functions as const char *
>
> Signed-off-by: LABBE Corentin
> ---
> drivers/acpi/acpica/acutils.h | 12 ++--
> drivers/acpi/acpica/utdecode.c | 24
> drivers/acpi/acpica/uthex.c| 4 ++--
> drivers/acpi/tables.c | 6 --
> 4 files changed, 24 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
> index fb2aa50..e5d9d4f 100644
> --- a/drivers/acpi/acpica/acutils.h
> +++ b/drivers/acpi/acpica/acutils.h
> @@ -189,21 +189,21 @@ char *acpi_ut_get_mutex_name(u32 mutex_id); const
> char *acpi_ut_get_notify_name(u32 notify_value, acpi_object_type type);
> #endif
>
> -char *acpi_ut_get_type_name(acpi_object_type type);
> +const char *acpi_ut_get_type_name(acpi_object_type type);
>
> char *acpi_ut_get_node_name(void *object);
>
> -char *acpi_ut_get_descriptor_name(void *object);
> +const char *acpi_ut_get_descriptor_name(void *object);
>
> const char *acpi_ut_get_reference_name(union acpi_operand_object
> *object);
>
> -char *acpi_ut_get_object_type_name(union acpi_operand_object *obj_desc);
> +const char *acpi_ut_get_object_type_name(union acpi_operand_object
> +*obj_desc);
>
> -char *acpi_ut_get_region_name(u8 space_id);
> +const char *acpi_ut_get_region_name(u8 space_id);
>
> -char *acpi_ut_get_event_name(u32 event_id);
> +const char *acpi_ut_get_event_name(u32 event_id);
>
> -char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
> +const char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
>
> u8 acpi_ut_ascii_char_to_hex(int hex_char);
>
> diff --git a/drivers/acpi/acpica/utdecode.c
> b/drivers/acpi/acpica/utdecode.c index 988e23b..e08cdb1 100644
> --- a/drivers/acpi/acpica/utdecode.c
> +++ b/drivers/acpi/acpica/utdecode.c
> @@ -114,7 +114,7 @@ const char
> *acpi_gbl_region_types[ACPI_NUM_PREDEFINED_REGIONS] = {
> "PCC" /* 0x0A */
> };
>
> -char *acpi_ut_get_region_name(u8 space_id)
> +const char *acpi_ut_get_region_name(u8 space_id)
> {
>
> if (space_id >= ACPI_USER_REGION_BEGIN) { @@ -127,7 +127,7 @@ char
> *acpi_ut_get_region_name(u8 space_id)
> return ("InvalidSpaceId");
> }
>
> - return (ACPI_CAST_PTR(char, acpi_gbl_region_types[space_id]));
> + return (ACPI_CAST_PTR(const char, acpi_gbl_region_types[space_id]));
> }
>
>
> /*
> **
> @@ -152,14 +152,14 @@ static const char
> *acpi_gbl_event_types[ACPI_NUM_FIXED_EVENTS] = {
> "RealTimeClock",
> };
>
> -char *acpi_ut_get_event_name(u32 event_id)
> +const char *acpi_ut_get_event_name(u32 event_id)
> {
>
> if (event_id > ACPI_EVENT_MAX) {
> return ("InvalidEventID");
> }
>
> - return (ACPI_CAST_PTR(char, acpi_gbl_event_types[event_id]));
> + return (ACPI_CAST_PTR(const char, acpi_gbl_event_types[event_id]));
> }
>
>
> /*
> **
> @@ -220,17 +220,17 @@ static const char *acpi_gbl_ns_type_names[] = {
> /* 30 */ "Invalid"
> };
>
> -char *acpi_ut_get_type_name(acpi_object_type type)
> +const char *acpi_ut_get_type_name(acpi_object_type type)
> {
>
> if (type > ACPI_TYPE_INVALID) {
> - return (ACPI_CAST_PTR(char, acpi_gbl_bad_type));
> + return (ACPI_CAST_PTR(const char, acpi_gbl_bad_type));
> }
>
> - return (ACPI_CAST_PTR(char, acpi_gbl_ns_type_names[type]));
> + return (ACPI_CAST_PTR(const char, acpi_gbl_ns_type_names[type]));
> }
>
> -char *acpi_ut_get_object_type_name(union acpi_operand_object *obj_desc)
> +const char *acpi_ut_get_object_type_name(union acpi_operand_object
> +*obj_d
RE: [PATCH 01/13] ACPICA: Remove unnecessary conditional compilation.
This appears as though it is related to this conditional:
#if defined(ACPI_DEBUG_OUTPUT) || defined(ACPI_DEBUGGER)
/*
* rsinfo
*/
extern ACPI_RSDUMP_INFO *AcpiGbl_DumpResourceDispatch[];
extern ACPI_RSDUMP_INFO *AcpiGbl_DumpSerialBusDispatch[];
So, I'm going to let Lv take a look at this.
Bob
> -Original Message-
> From: lkp
> Sent: Thursday, October 15, 2015 8:51 AM
> To: Zheng, Lv
> Cc: kbuild-...@01.org; Wysocki, Rafael J; Brown, Len; Zheng, Lv; Lv Zheng;
> linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Moore, Robert
> Subject: Re: [PATCH 01/13] ACPICA: Remove unnecessary conditional
> compilation.
>
> Hi Bob,
>
> [auto build test ERROR on pm/linux-next -- if it's inappropriate base,
> please suggest rules for selecting the more suitable base]
>
> url:https://github.com/0day-ci/linux/commits/Lv-Zheng/ACPICA-20150930-
> Release/20151015-101636
> config: x86_64-lkp (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>drivers/acpi/acpica/rsdump.c: In function 'acpi_rs_dump_resource_list':
> >> drivers/acpi/acpica/rsdump.c:136:7: error:
> >> 'acpi_gbl_dump_serial_bus_dispatch' undeclared (first use in this
> >> function)
> acpi_gbl_dump_serial_bus_dispatch
> ^
>drivers/acpi/acpica/rsdump.c:136:7: note: each undeclared identifier is
> reported only once for each function it appears in
> >> drivers/acpi/acpica/rsdump.c:141:7: error:
> >> 'acpi_gbl_dump_resource_dispatch' undeclared (first use in this
> >> function)
> acpi_gbl_dump_resource_dispatch
> ^
>drivers/acpi/acpica/rsdump.c: In function 'acpi_rs_dump_irq_list':
> >> drivers/acpi/acpica/rsdump.c:186:40: error: 'acpi_rs_dump_prt'
> >> undeclared (first use in this function)
> acpi_rs_dump_descriptor(prt_element, acpi_rs_dump_prt);
>^
>drivers/acpi/acpica/rsdump.c: In function
> 'acpi_rs_dump_address_common':
> >> drivers/acpi/acpica/rsdump.c:445:37: error:
> >> 'acpi_rs_dump_memory_flags' undeclared (first use in this function)
> acpi_rs_dump_descriptor(resource, acpi_rs_dump_memory_flags);
> ^
> >> drivers/acpi/acpica/rsdump.c:450:37: error: 'acpi_rs_dump_io_flags'
> >> undeclared (first use in this function)
> acpi_rs_dump_descriptor(resource, acpi_rs_dump_io_flags);
> ^
> >> drivers/acpi/acpica/rsdump.c:467:36: error:
> >> 'acpi_rs_dump_general_flags' undeclared (first use in this function)
> acpi_rs_dump_descriptor(resource, acpi_rs_dump_general_flags);
>^
>
> vim +/acpi_gbl_dump_serial_bus_dispatch +136 drivers/acpi/acpica/rsdump.c
>
> 39239fed Bob Moore 2015-04-13 130}
> 39239fed Bob Moore 2015-04-13 131
> 39239fed Bob Moore 2015-04-13 132/* Dump the resource
> descriptor */
> 39239fed Bob Moore 2015-04-13 133
> 39239fed Bob Moore 2015-04-13 134if (type ==
> ACPI_RESOURCE_TYPE_SERIAL_BUS) {
> 39239fed Bob Moore 2015-04-13 135
> acpi_rs_dump_descriptor(&resource_list->data,
> 39239fed Bob Moore 2015-04-13 @136
> acpi_gbl_dump_serial_bus_dispatch
> 39239fed Bob Moore 2015-04-13 137
> [resource_list->data.
> 39239fed Bob Moore 2015-04-13 138
> common_serial_bus.type]);
> 39239fed Bob Moore 2015-04-13 139} else {
> 39239fed Bob Moore 2015-04-13 140
> acpi_rs_dump_descriptor(&resource_list->data,
> 39239fed Bob Moore 2015-04-13 @141
> acpi_gbl_dump_resource_dispatch
> 39239fed Bob Moore 2015-04-13 142
> [type]);
> 39239fed Bob Moore 2015-04-13 143}
> 39239fed Bob Moore 2015-04-13 144
> 39239fed Bob Moore 2015-04-13 145/* Point to the next
> resource structure */
> 39239fed Bob Moore 2015-04-13 146
> 39239fed Bob Moore 2015-04-13 147resource_list =
> ACPI_NEXT_RESOURCE(resource_list);
> 39239fed Bob Moore 2015-04-13 148
> 39239fed Bob Moore 2015-04-13 149/* Exit when END_TAG
> descriptor is reached */
> 39239fed Bob Moore 2015-04-13 150
> 39239fed Bob Moore 2015-04-13 151} while (type !=
> ACPI_RESOURCE_TYPE_END_TAG);
> 39239fed Bob Moore 2015-04-13 152 }
> 39239fed Bob Moore 2015-04-13 153
> 39239fed Bob Moore 2015-04-13 154
> /*
&
RE: [PATCH] acpi: set return value to const char for some functions
> Please describe the effects of "const pollution".
>
> Why isn't it useful to update the functions that don't modify function
> pointer arguments to const?
It's not that const isn't useful, but it can create problems, especially in
existing code. It can bubble up to higher functions, causing lots of changes to
existing variables and the definition of existing functions. Not to mention
lots of casting and recasting.
Example quote:
"if you started to use "const" for some methods you usually forced to use this
in most of your code. But the time spent for maintaining (typing, recompiling
when some const is missing, etc.) of const-correctness in code seems greater
than for fixing of possible (very rare) problems caused by not using of
const-correctness at all."
Also, ACPICA has to be additionally careful because it must compile with many
different C compilers.
All that being said, I went ahead and made the actual ACPICA changes
corresponding to your patches. There were no pollution issues, and it actually
simplified the code by eliminating the need for some uses of ACPI_CAST_PTR.
The only issue I found was here, so we won't do this one:
const char
AcpiUtHexToAsciiChar
\acpica\source\include\acutils.h(322) :
warning C4180: qualifier applied to function type has no meaning; ignored
Here is the current patch to the actual ACPICA code (which is in a different
format than the Linux version of the code):
diff --git a/source/components/namespace/nsxfname.c
b/source/components/namespace/nsxfname.c
index 51cc4f4..c368c1f 100644
--- a/source/components/namespace/nsxfname.c
+++ b/source/components/namespace/nsxfname.c
@@ -249,7 +249,7 @@ AcpiGetName (
{
ACPI_STATUS Status;
ACPI_NAMESPACE_NODE *Node;
-char*NodeName;
+const char *NodeName;
/* Parameter validation */
diff --git a/source/components/utilities/utdecode.c
b/source/components/utilities/utdecode.c
index 580f891..3d927f5 100644
--- a/source/components/utilities/utdecode.c
+++ b/source/components/utilities/utdecode.c
@@ -191,7 +191,7 @@ const char
*AcpiGbl_RegionTypes[ACPI_NUM_PREDEFINED_REGIONS] =
};
-char *
+const char *
AcpiUtGetRegionName (
UINT8 SpaceId)
{
@@ -213,7 +213,7 @@ AcpiUtGetRegionName (
return ("InvalidSpaceId");
}
-return (ACPI_CAST_PTR (char, AcpiGbl_RegionTypes[SpaceId]));
+return (AcpiGbl_RegionTypes[SpaceId]);
}
@@ -241,7 +241,7 @@ static const char
*AcpiGbl_EventTypes[ACPI_NUM_FIXED_EVENTS] =
};
-char *
+const char *
AcpiUtGetEventName (
UINT32 EventId)
{
@@ -251,7 +251,7 @@ AcpiUtGetEventName (
return ("InvalidEventID");
}
-return (ACPI_CAST_PTR (char, AcpiGbl_EventTypes[EventId]));
+return (AcpiGbl_EventTypes[EventId]);
}
@@ -316,21 +316,21 @@ static const char *AcpiGbl_NsTypeNames[] =
};
-char *
+const char *
AcpiUtGetTypeName (
ACPI_OBJECT_TYPEType)
{
if (Type > ACPI_TYPE_INVALID)
{
-return (ACPI_CAST_PTR (char, AcpiGbl_BadType));
+return (AcpiGbl_BadType);
}
-return (ACPI_CAST_PTR (char, AcpiGbl_NsTypeNames[Type]));
+return (AcpiGbl_NsTypeNames[Type]);
}
-char *
+const char *
AcpiUtGetObjectTypeName (
ACPI_OPERAND_OBJECT *ObjDesc)
{
@@ -372,7 +372,7 @@ AcpiUtGetObjectTypeName (
*
**/
-char *
+const char *
AcpiUtGetNodeName (
void*Object)
{
@@ -448,7 +448,7 @@ static const char *AcpiGbl_DescTypeNames[] =
};
-char *
+const char *
AcpiUtGetDescriptorName (
void*Object)
{
@@ -463,9 +463,7 @@ AcpiUtGetDescriptorName (
return ("Not a Descriptor");
}
-return (ACPI_CAST_PTR (char,
-AcpiGbl_DescTypeNames[ACPI_GET_DESCRIPTOR_TYPE (Object)]));
-
+return (AcpiGbl_DescTypeNames[ACPI_GET_DESCRIPTOR_TYPE (Object)]);
}
@@ -542,7 +540,7 @@ AcpiUtGetReferenceName (
/* Names for internal mutex objects, used for debug output */
-static char *AcpiGbl_MutexNames[ACPI_NUM_MUTEX] =
+static const char *AcpiGbl_MutexNames[ACPI_NUM_MUTEX] =
{
"ACPI_MTX_Interpreter",
"ACPI_MTX_Namespace",
@@ -552,7 +550,7 @@ static char
*AcpiGbl_MutexNames[ACPI_NUM_MUTEX] =
"ACPI_MTX_Memory",
};
-char *
+const char *
AcpiUtGetMutexName (
UINT32 MutexId)
{
diff --git a/source/components/utilities/uthex.c
b/source/components/utilities/uthex.c
index c652f6a..3a32003 100644
--- a/source/components/utilities/uthex.c
+++ b/source/components/utilities/uthex.c
@@ -122,7 +122,7 @@
/* Hex to ASCII conversion table */
-static char AcpiGbl_HexToAscii[] =
+static const char AcpiGbl_HexToAscii[] =
{
'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F
RE: [PATCH] acpi: set return value to const char for some functions
If you don't like the quote, just stick with my first assessment. > -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Thursday, October 15, 2015 5:00 PM > To: Moore, Robert > Cc: LABBE Corentin; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org; linux- > a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Box, > David E > Subject: Re: [PATCH] acpi: set return value to const char for some > functions > > On Thu, 2015-10-15 at 19:32 +, Moore, Robert wrote: > > if you started to use "const" for some methods you usually forced to > > use this in most of your code. But the time spent for maintaining > > (typing, recompiling when some const is missing, etc.) of > > const-correctness in code seems greater than for fixing of possible > > (very rare) problems caused by not using of const-correctness at all > > c is not c++. > > "seems" is a dubious statement. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Devel] [PATCH] acpi: set return value to const char for some functions
I think we have everything applied. As I said, we try to be careful about
const, but that doesn't mean we are against it.
So, thanks for your help.
Bob
> -Original Message-
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
> Sent: Monday, October 19, 2015 10:16 AM
> To: LABBE Corentin
> Cc: Wysocki, Rafael J; linux-kernel@vger.kernel.org; linux-
> a...@vger.kernel.org; LABBE Corentin; de...@acpica.org
> Subject: Re: [Devel] [PATCH] acpi: set return value to const char for some
> functions
>
> You may have missed this, from last week:
>
>
> > All that being said, I went ahead and made the actual ACPICA changes
> > corresponding to your patches. There were no pollution issues, and it
> > actually simplified the code by eliminating the need for some uses of
> > ACPI_CAST_PTR.
> >
> > The only issue I found was here, so we won't do this one:
> >
> > const char
> > AcpiUtHexToAsciiChar
> >
> > \acpica\source\include\acutils.h(322) :
> > warning C4180: qualifier applied to function type has no meaning;
> > ignored
> >
>
>
>
>
>
>
>
> > -Original Message-
> > From: Moore, Robert
> > Sent: Monday, October 19, 2015 10:05 AM
> > To: 'LABBE Corentin'
> > Cc: LABBE Corentin; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org;
> > linux- a...@vger.kernel.org; de...@acpica.org;
> > linux-kernel@vger.kernel.org
> > Subject: RE: [PATCH] acpi: set return value to const char for some
> > functions
> >
> > Actually, I thought I got most of the changes.
> >
> > Again, ACPICA code is in a different format than the Linux version of
> > the code, so your patch cannot be directly applied.
> >
> > Bob
> >
> >
> > > -Original Message-
> > > From: LABBE Corentin [mailto:montjoie.mail...@gmail.com]
> > > Sent: Monday, October 19, 2015 5:03 AM
> > > To: Moore, Robert
> > > Cc: LABBE Corentin; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org;
> > > linux- a...@vger.kernel.org; de...@acpica.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH] acpi: set return value to const char for some
> > > functions
> > >
> > > On Wed, Oct 14, 2015 at 08:53:19PM +, Moore, Robert wrote:
> > > > In ACPICA, we tend to be very careful concerning the "const"
> > > > keyword in
> > > order to avoid a phenomenon known as "const pollution".
> > > >
> > > > That is not to say that we won't use const in some limited cases.
> > > >
> > > > Bob
> > > >
> > >
> > > Hello
> > >
> > > The problem is that all function in this patch return a pointer to
> > > string literal without giving that information.
> > > I am sad to see that you seems to agree with that but, for resuming
> > > your conversation with Joe Perches, you reject this patch just
> > > because you worry that perhaps in the future it will make you more
> > > works do deal with it.
> > >
> > > Does you will accept the subset of this patch for adding const to
> > > "static char xxx[] = {}" ?
> > >
> > > Regards
> > >
> > > >
> > > > > -Original Message-
> > > > > From: LABBE Corentin [mailto:clabbe.montj...@gmail.com]
> > > > > Sent: Wednesday, October 14, 2015 12:07 PM
> > > > > To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org
> > > > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > > > ker...@vger.kernel.org; LABBE Corentin
> > > > > Subject: [PATCH] acpi: set return value to const char for some
> > > > > functions
> > > > >
> > > > > This patch set some array of const char as const.
> > > > > In the same time, some function return pointer to thoses array
> > > > > without properly giving the information that the data is const.
> > > > > This patch set the return type of thoses functions as const char
> > > > > *
> > > > >
> > > > > Signed-off-by: LABBE Corentin
> > > > > ---
> > > > > drivers/acpi/acpica/acutils.h | 12 ++--
> > > > > drivers/acpi/acpica/utdecode.c | 24
> > > > > drivers/acpi/acpica/uthex.c| 4 ++--
> > > > > drivers/acpi/tables.c | 6 --
> > > > &
RE: [PATCH] acpi: set return value to const char for some functions
Actually, I thought I got most of the changes.
Again, ACPICA code is in a different format than the Linux version of the code,
so your patch cannot be directly applied.
Bob
> -Original Message-
> From: LABBE Corentin [mailto:montjoie.mail...@gmail.com]
> Sent: Monday, October 19, 2015 5:03 AM
> To: Moore, Robert
> Cc: LABBE Corentin; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org; linux-
> a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] acpi: set return value to const char for some
> functions
>
> On Wed, Oct 14, 2015 at 08:53:19PM +, Moore, Robert wrote:
> > In ACPICA, we tend to be very careful concerning the "const" keyword in
> order to avoid a phenomenon known as "const pollution".
> >
> > That is not to say that we won't use const in some limited cases.
> >
> > Bob
> >
>
> Hello
>
> The problem is that all function in this patch return a pointer to string
> literal without giving that information.
> I am sad to see that you seems to agree with that but, for resuming your
> conversation with Joe Perches, you reject this patch just because you
> worry that perhaps in the future it will make you more works do deal with
> it.
>
> Does you will accept the subset of this patch for adding const to "static
> char xxx[] = {}" ?
>
> Regards
>
> >
> > > -Original Message-
> > > From: LABBE Corentin [mailto:clabbe.montj...@gmail.com]
> > > Sent: Wednesday, October 14, 2015 12:07 PM
> > > To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org
> > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > ker...@vger.kernel.org; LABBE Corentin
> > > Subject: [PATCH] acpi: set return value to const char for some
> > > functions
> > >
> > > This patch set some array of const char as const.
> > > In the same time, some function return pointer to thoses array
> > > without properly giving the information that the data is const.
> > > This patch set the return type of thoses functions as const char *
> > >
> > > Signed-off-by: LABBE Corentin
> > > ---
> > > drivers/acpi/acpica/acutils.h | 12 ++--
> > > drivers/acpi/acpica/utdecode.c | 24
> > > drivers/acpi/acpica/uthex.c| 4 ++--
> > > drivers/acpi/tables.c | 6 --
> > > 4 files changed, 24 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/acpi/acpica/acutils.h
> > > b/drivers/acpi/acpica/acutils.h index fb2aa50..e5d9d4f 100644
> > > --- a/drivers/acpi/acpica/acutils.h
> > > +++ b/drivers/acpi/acpica/acutils.h
> > > @@ -189,21 +189,21 @@ char *acpi_ut_get_mutex_name(u32 mutex_id);
> > > const char *acpi_ut_get_notify_name(u32 notify_value,
> > > acpi_object_type type); #endif
> > >
> > > -char *acpi_ut_get_type_name(acpi_object_type type);
> > > +const char *acpi_ut_get_type_name(acpi_object_type type);
> > >
> > > char *acpi_ut_get_node_name(void *object);
> > >
> > > -char *acpi_ut_get_descriptor_name(void *object);
> > > +const char *acpi_ut_get_descriptor_name(void *object);
> > >
> > > const char *acpi_ut_get_reference_name(union acpi_operand_object
> > > *object);
> > >
> > > -char *acpi_ut_get_object_type_name(union acpi_operand_object
> > > *obj_desc);
> > > +const char *acpi_ut_get_object_type_name(union acpi_operand_object
> > > +*obj_desc);
> > >
> > > -char *acpi_ut_get_region_name(u8 space_id);
> > > +const char *acpi_ut_get_region_name(u8 space_id);
> > >
> > > -char *acpi_ut_get_event_name(u32 event_id);
> > > +const char *acpi_ut_get_event_name(u32 event_id);
> > >
> > > -char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
> > > +const char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
> > >
> > > u8 acpi_ut_ascii_char_to_hex(int hex_char);
> > >
> > > diff --git a/drivers/acpi/acpica/utdecode.c
> > > b/drivers/acpi/acpica/utdecode.c index 988e23b..e08cdb1 100644
> > > --- a/drivers/acpi/acpica/utdecode.c
> > > +++ b/drivers/acpi/acpica/utdecode.c
> > > @@ -114,7 +114,7 @@ const char
> > > *acpi_gbl_region_types[ACPI_NUM_PREDEFINED_REGIONS] = {
> > > "PCC" /* 0x0A */
> > > };
> > >
> > > -char *acpi_ut_get_region_name(u8 space_id)
> > > +const char *acpi_ut_get_region_name(u8 spa
RE: [PATCH] acpi: set return value to const char for some functions
You may have missed this, from last week:
> All that being said, I went ahead and made the actual ACPICA changes
> corresponding to your patches. There were no pollution issues, and it
> actually simplified the code by eliminating the need for some uses of
> ACPI_CAST_PTR.
>
> The only issue I found was here, so we won't do this one:
>
> const char
> AcpiUtHexToAsciiChar
>
> \acpica\source\include\acutils.h(322) :
> warning C4180: qualifier applied to function type has no meaning;
> ignored
>
> -Original Message-
> From: Moore, Robert
> Sent: Monday, October 19, 2015 10:05 AM
> To: 'LABBE Corentin'
> Cc: LABBE Corentin; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org; linux-
> a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] acpi: set return value to const char for some
> functions
>
> Actually, I thought I got most of the changes.
>
> Again, ACPICA code is in a different format than the Linux version of the
> code, so your patch cannot be directly applied.
>
> Bob
>
>
> > -Original Message-
> > From: LABBE Corentin [mailto:montjoie.mail...@gmail.com]
> > Sent: Monday, October 19, 2015 5:03 AM
> > To: Moore, Robert
> > Cc: LABBE Corentin; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org;
> > linux- a...@vger.kernel.org; de...@acpica.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] acpi: set return value to const char for some
> > functions
> >
> > On Wed, Oct 14, 2015 at 08:53:19PM +, Moore, Robert wrote:
> > > In ACPICA, we tend to be very careful concerning the "const" keyword
> > > in
> > order to avoid a phenomenon known as "const pollution".
> > >
> > > That is not to say that we won't use const in some limited cases.
> > >
> > > Bob
> > >
> >
> > Hello
> >
> > The problem is that all function in this patch return a pointer to
> > string literal without giving that information.
> > I am sad to see that you seems to agree with that but, for resuming
> > your conversation with Joe Perches, you reject this patch just because
> > you worry that perhaps in the future it will make you more works do
> > deal with it.
> >
> > Does you will accept the subset of this patch for adding const to
> > "static char xxx[] = {}" ?
> >
> > Regards
> >
> > >
> > > > -Original Message-
> > > > From: LABBE Corentin [mailto:clabbe.montj...@gmail.com]
> > > > Sent: Wednesday, October 14, 2015 12:07 PM
> > > > To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org
> > > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > > ker...@vger.kernel.org; LABBE Corentin
> > > > Subject: [PATCH] acpi: set return value to const char for some
> > > > functions
> > > >
> > > > This patch set some array of const char as const.
> > > > In the same time, some function return pointer to thoses array
> > > > without properly giving the information that the data is const.
> > > > This patch set the return type of thoses functions as const char *
> > > >
> > > > Signed-off-by: LABBE Corentin
> > > > ---
> > > > drivers/acpi/acpica/acutils.h | 12 ++--
> > > > drivers/acpi/acpica/utdecode.c | 24
> > > > drivers/acpi/acpica/uthex.c| 4 ++--
> > > > drivers/acpi/tables.c | 6 --
> > > > 4 files changed, 24 insertions(+), 22 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/acpica/acutils.h
> > > > b/drivers/acpi/acpica/acutils.h index fb2aa50..e5d9d4f 100644
> > > > --- a/drivers/acpi/acpica/acutils.h
> > > > +++ b/drivers/acpi/acpica/acutils.h
> > > > @@ -189,21 +189,21 @@ char *acpi_ut_get_mutex_name(u32 mutex_id);
> > > > const char *acpi_ut_get_notify_name(u32 notify_value,
> > > > acpi_object_type type); #endif
> > > >
> > > > -char *acpi_ut_get_type_name(acpi_object_type type);
> > > > +const char *acpi_ut_get_type_name(acpi_object_type type);
> > > >
> > > > char *acpi_ut_get_node_name(void *object);
> > > >
> > > > -char *acpi_ut_get_descriptor_name(void *object);
> > > > +const char *acpi_ut_get_descriptor_name(void *object);
> > > >
> > > > const char *acpi_ut_get_reference_name(union acpi_operand_object
> > > > *
RE: [PATCH 3.4 52/65] ACPICA: Tables: Fix an issue that FACS initialization is performed twice
> -Original Message-
> From: l...@kernel.org [mailto:l...@kernel.org]
> Sent: Monday, October 19, 2015 5:48 PM
> To: sta...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Zheng, Lv; Moore, Robert; Wysocki,
> Rafael J; Zefan Li
> Subject: [PATCH 3.4 52/65] ACPICA: Tables: Fix an issue that FACS
> initialization is performed twice
>
> From: Lv Zheng
>
> 3.4.110-rc1 review patch. If anyone has any objections, please let me
> know.
>
> --
>
>
> commit c04be18448355441a0c424362df65b6422e27bda upstream.
>
> ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658
>
> This patch adds a new FACS initialization flag for acpi_tb_initialize().
> acpi_enable_subsystem() might be invoked several times in OS bootup
> process, and we don't want FACS initialization to be invoked twice. Lv
> Zheng.
>
Isn't calling acpi_enable_subsystem more than once essentially an OS bug?
> Link: https://github.com/acpica/acpica/commit/90f5332a
> Signed-off-by: Lv Zheng
> Signed-off-by: Bob Moore
> Signed-off-by: Rafael J. Wysocki
> [lizf: Backported to 3.4: adjust filename]
> Signed-off-by: Zefan Li
> ---
> drivers/acpi/acpica/utxface.c | 10 ++
> include/acpi/actypes.h| 1 +
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
> index afa94f5..0985ab7 100644
> --- a/drivers/acpi/acpica/utxface.c
> +++ b/drivers/acpi/acpica/utxface.c
> @@ -166,10 +166,12 @@ acpi_status acpi_enable_subsystem(u32 flags)
>* Obtain a permanent mapping for the FACS. This is required for the
>* Global Lock and the Firmware Waking Vector
>*/
> - status = acpi_tb_initialize_facs();
> - if (ACPI_FAILURE(status)) {
> - ACPI_WARNING((AE_INFO, "Could not map the FACS table"));
> - return_ACPI_STATUS(status);
> + if (!(flags & ACPI_NO_FACS_INIT)) {
> + status = acpi_tb_initialize_facs();
> + if (ACPI_FAILURE(status)) {
> + ACPI_WARNING((AE_INFO, "Could not map the FACS table"));
> + return_ACPI_STATUS(status);
> + }
> }
> #endif /* !ACPI_REDUCED_HARDWARE */
>
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> 6d52429..0460073 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -495,6 +495,7 @@ typedef u64 acpi_integer;
> #define ACPI_NO_ACPI_ENABLE 0x10
> #define ACPI_NO_DEVICE_INIT 0x20
> #define ACPI_NO_OBJECT_INIT 0x40
> +#define ACPI_NO_FACS_INIT 0x80
>
> /*
> * Initialization state
> --
> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ACPI: Parse entire table as a term_list for Dell XPS 9570 and Precision M5530
> -Original Message-
> From: mario.limoncie...@dell.com [mailto:mario.limoncie...@dell.com]
> Sent: Tuesday, January 30, 2018 11:03 AM
> To: Schmauss, Erik ; andy.shevche...@gmail.com;
> kai.heng.f...@canonical.com
> Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Moore, Robert
> Subject: RE: [PATCH] ACPI: Parse entire table as a term_list for Dell
> XPS 9570 and Precision M5530
>
>
>
> > -Original Message-
> > From: Schmauss, Erik [mailto:erik.schma...@intel.com]
> > Sent: Tuesday, January 30, 2018 12:38 PM
> > To: Andy Shevchenko ; Kai-Heng Feng
> >
> > Cc: Rafael J. Wysocki ; Len Brown
> > ; ACPI Devel Maling List
> > ; Linux Kernel Mailing List > ker...@vger.kernel.org>; Limonciello, Mario
> > ; Moore, Robert
> > Subject: RE: [PATCH] ACPI: Parse entire table as a term_list for Dell
> > XPS 9570 and Precision M5530
> >
> > Hi,
> > > -Original Message-
> > > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> > > ow...@vger.kernel.org] On Behalf Of Andy Shevchenko
> > > Sent: Tuesday, January 30, 2018 10:18 AM
> > > To: Kai-Heng Feng
> > > Cc: Rafael J. Wysocki ; Len Brown
> > > ; ACPI Devel Maling List
> > > ; Linux Kernel Mailing List > > ker...@vger.kernel.org>; Mario Limonciello
> > >
> > > Subject: Re: [PATCH] ACPI: Parse entire table as a term_list for
> > > Dell XPS 9570 and Precision M5530
> > >
> > > On Tue, Jan 30, 2018 at 8:07 AM, Kai-Heng Feng
> > > wrote:
> > > > The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work
> > > > out of box.
> > > >
> > > > The touchpad relies on its _INI method to update its _HID value
> > > > from
> > > > to SYNA2393.
> > > > Also, the _STA relies on value of I2CN to report correct status.
> > > >
> > > > Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
> > > > correctly set up, and _INI can get run. The ACPI table in this
> > > > machine is designed to get parsed this way.
> >
> > I thought I would give everyone an update: we are getting close to
> > finishing patches to enable this term list parsing by default as well
> > as a few other fixes with forward referencing of package elements.
> > Once we have established that these patches are stable, we will get
> > rid of acpi_gbl_parse_table_as_term_list. So this quirk may not be
> needed in the near future...
>
> Rafael,
>
> Would you be opposed to carrying a patch similar to this (proposed)
> quirk patch in kernel and reverting when Erik submits patches that get
> rid of acpi_gbl_parse_table_as_term_list?
>
> The reason being, I think this could also be a candidate to bring back
> to @stable and fix this problem on earlier kernels too.
>
> I don’t believe the patches that get rid of
> acpi_gbl_parse_table_as_term_list likely will be good candidates for
> @stable.
>
Does anyone remember what was the exact problem that forced the creation of
parse_table_as_term_list in the first place?
Bob
>
> >
> > Erik
> > > >
> > > > Also, change the quirk table to a more generic name.
> > >
> > > > +static int set_gbl_term_list(const struct dmi_system_id *id) {
> > > > + pr_notice("%s detected - parse the entire table as a
> term_list\n",
> > > > + id->ident);
> > > > + acpi_gbl_parse_table_as_term_list = 1;
> > > > + return 0;
> > > > +}
> > > > #endif
> > >
> > > The above should be outside of another #ifdef. Basically after the
> above #endif.
> > >
> > > > #else
> > >
> > > > #endif
> > >
> > > > @@ -1005,7 +1034,7 @@ void __init acpi_early_init(void)
> > >
> > > > * If the machine falls into the DMI check table,
> > > > * DSDT will be copied to memory
> > > > */
> > >
> > > It might make sense to adjust comment above that it's about quirks
> in general.
> > > And, if needed, move current content to actual DMI group of records.
> > >
> > > > - dmi_check_system(dsdt_dmi_table);
> > > > + dmi_check_system(acpi_quirks_dmi_table);
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
> > > linux-acpi" in the body of a message to majord...@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
-Original Message- From: Kaneda, Erik Sent: Monday, April 19, 2021 3:56 PM To: Williams, Dan J ; Andy Shevchenko ; Moore, Robert ; Wysocki, Rafael J Cc: linux-nvdimm ; Linux Kernel Mailing List ; Verma, Vishal L ; Jiang, Dave ; Weiny, Ira Subject: RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer +Bob and Rafael > -Original Message- > From: Dan Williams > Sent: Friday, April 16, 2021 3:09 PM > To: Andy Shevchenko > Cc: linux-nvdimm ; Linux Kernel Mailing > List ; Verma, Vishal L > ; Jiang, Dave ; Weiny, > Ira ; Kaneda, Erik > Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw > buffer > > On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko > wrote: > > > > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote: > > > [ add Erik ] > > > > > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko > > > wrote: > > > > > > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote: > > > > > Strictly speaking the comparison between guid_t and raw buffer > > > > > is not correct. Return to plain memcmp() since the data > > > > > structures haven't changed to use uuid_t / guid_t the current > > > > > state of affairs is inconsistent. Either it should be changed > > > > > altogether or left as is. > > > > > > > > Dan, please review this one as well. I think here you may agree with me. > > > > > > You know, this is all a problem because ACPICA is using a raw buffer. > > > > And this is fine. It might be any other representation as well. > > > > > Erik, would it be possible to use the guid_t type in ACPICA? That > > > would allow NFIT to drop some ugly casts. > > > > guid_t is internal kernel type. If we ever decide to deviate from > > the current representation it wouldn't be possible in case a 3rd > > party is using it 1:1 (via typedef or so). > Hi Dan, > I'm thinking something like ACPICA defining that space as a union with > the correct typing just for Linux. I'm assuming that you mean using something like guid_t type for ACPI data table fields like NFIT rather than objects returned by ACPI namespace object such as _DSD. For ACPI data tables, we could to use macros so that different operating systems can provide their own definitions for a guid. For ACPICA, it will expands to a 16-byte array. Linux can have it's own definition that contains a union or their own guid type (guid_t). As long as the OS-supplied definition is 16bytes, I don't think there would be an issue. Erik, I don't like to add these kinds of macros, since it is simply another item that needs to be added to port ACPICA to different hosts. (And must be known by the porter.) Other than that, I suppose we can add such a macro. Bob, do you have any thoughts on this? Erik
RE: [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing
Yes, this is a good question that we should think about.
Bob
> -Original Message-
> From: Zheng, Lv
> Sent: Thursday, April 16, 2015 6:46 PM
> To: Suravee Suthikulpanit; r...@rjwysocki.net;
> mika.westerb...@linux.intel.com; Moore, Robert; hanjun@linaro.org
> Cc: l...@kernel.org; hdego...@redhat.com; t...@kernel.org;
> mj...@srcf.ucam.org; gre...@linuxfoundation.org; al.st...@linaro.org;
> graeme.greg...@linaro.org; leo.du...@amd.com; linux-...@vger.kernel.org;
> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org
> Subject: RE: [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing
>
> Before back porting this to ACPICA, let me ask one simple question.
> According to the spec, the _CLS is optional and PCI specific.
> So why should we implement it in ACPICA core not OSPM specific modules?
> If this need to be implemented in ACPICA, then what about the following
> device identification objects?
> _DDN, _HRV, _MLS, _PLD, _STR, _SUN
>
> Thanks and best regards
> -Lv
>
> > From: Suravee Suthikulpanit [mailto:suravee.suthikulpa...@amd.com]
> > Sent: Tuesday, March 31, 2015 5:56 AM
> >
> > ACPI Device configuration often contain _CLS object to suppy
> > PCI-defined class code for the device. This patch introduces logic to
> > process the _CLS object.
> >
> > Acked-by: Mika Westerberg
> > Reviewed-by: Hanjun Guo
> > Signed-off-by: Suravee Suthikulpanit
> > ---
> > drivers/acpi/acpica/acutils.h | 3 ++
> > drivers/acpi/acpica/nsxfname.c | 21 ++--
> > drivers/acpi/acpica/utids.c| 73
> ++
> > 3 files changed, 95 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/acutils.h
> > b/drivers/acpi/acpica/acutils.h index c2f03e8..2aef850 100644
> > --- a/drivers/acpi/acpica/acutils.h
> > +++ b/drivers/acpi/acpica/acutils.h
> > @@ -430,6 +430,9 @@ acpi_status
> > acpi_ut_execute_CID(struct acpi_namespace_node *device_node,
> > struct acpi_pnp_device_id_list ** return_cid_list);
> >
> > +acpi_status
> > +acpi_ut_execute_CLS(struct acpi_namespace_node *device_node,
> > + struct acpi_pnp_device_id **return_id);
> > /*
> > * utlock - reader/writer locks
> > */
> > diff --git a/drivers/acpi/acpica/nsxfname.c
> > b/drivers/acpi/acpica/nsxfname.c index d66c326..590ef06 100644
> > --- a/drivers/acpi/acpica/nsxfname.c
> > +++ b/drivers/acpi/acpica/nsxfname.c
> > @@ -276,11 +276,12 @@ acpi_get_object_info(acpi_handle handle,
> > struct acpi_pnp_device_id *hid = NULL;
> > struct acpi_pnp_device_id *uid = NULL;
> > struct acpi_pnp_device_id *sub = NULL;
> > + struct acpi_pnp_device_id *cls = NULL;
> > char *next_id_string;
> > acpi_object_type type;
> > acpi_name name;
> > u8 param_count = 0;
> > - u8 valid = 0;
> > + u16 valid = 0;
> > u32 info_size;
> > u32 i;
> > acpi_status status;
> > @@ -320,7 +321,7 @@ acpi_get_object_info(acpi_handle handle,
> > if ((type == ACPI_TYPE_DEVICE) || (type == ACPI_TYPE_PROCESSOR)) {
> > /*
> > * Get extra info for ACPI Device/Processor objects only:
> > -* Run the Device _HID, _UID, _SUB, and _CID methods.
> > +* Run the Device _HID, _UID, _SUB, _CID and _CLS methods.
> > *
> > * Note: none of these methods are required, so they may or
> may
> > * not be present for this device. The Info->Valid bitfield is
> used
> > @@ -351,6 +352,14 @@ acpi_get_object_info(acpi_handle handle,
> > valid |= ACPI_VALID_SUB;
> > }
> >
> > + /* Execute the Device._CLS method */
> > +
> > + status = acpi_ut_execute_CLS(node, &cls);
> > + if (ACPI_SUCCESS(status)) {
> > + info_size += cls->length;
> > + valid |= ACPI_VALID_CLS;
> > + }
> > +
> > /* Execute the Device._CID method */
> >
> > status = acpi_ut_execute_CID(node, &cid_list); @@ -468,6
> +477,11 @@
> > acpi_get_object_info(acpi_handle handle,
> > sub, next_id_string);
> > }
> >
> > + if (cls) {
> > + next_id_string = acpi_ns_copy_device_id(&info->cls,
> > + cls, next_id_string);
> > + }
> > +
> > if (cid_lis
RE: [V7 PATCH 1/3] ACPICA: Add ACPI _CLS processing
AE_AML_OPERAND_TYPE -- used to indicate an exception raised by a type issue
related to the AML code. Used to differentiate between a programmer error
(AE_TYPE).
> -Original Message-
> From: Suravee Suthikulanit [mailto:suravee.suthikulpa...@amd.com]
> Sent: Monday, March 30, 2015 7:17 AM
> To: Moore, Robert; r...@rjwysocki.net; mika.westerb...@linux.intel.com;
> Zheng, Lv; hanjun@linaro.org
> Cc: l...@kernel.org; hdego...@redhat.com; t...@kernel.org;
> mj...@srcf.ucam.org; gre...@linuxfoundation.org; al.st...@linaro.org;
> graeme.greg...@linaro.org; leo.du...@amd.com; linux-...@vger.kernel.org;
> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org
> Subject: Re: [V7 PATCH 1/3] ACPICA: Add ACPI _CLS processing
>
> On 3/27/2015 12:51 PM, Moore, Robert wrote:
> > + cls_objects = obj_desc->package.elements;
> > +
> > + if (obj_desc->common.type == ACPI_TYPE_PACKAGE &&
> > + obj_desc->package.count == 3 &&
> > + cls_objects[0]->common.type == ACPI_TYPE_INTEGER &&
> > + cls_objects[1]->common.type == ACPI_TYPE_INTEGER &&
> > + cls_objects[2]->common.type == ACPI_TYPE_INTEGER) {
> > +
> > + /* Allocate a buffer for the CLS */
> > + cls = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_pnp_device_id) +
> > +(acpi_size) 7);
> >
> > I would like to see an error returned if an object or subobject is of
> the incorrect type.
> > Then, the caller knows not to attempt to look at it.
> >
>
> Ok. I will return AE_TYPE if the condition is false here.
>
> Thanks,
>
> Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpica: modify a commit error in file drivers/acpi/acpica/nsxfeval.c
Yes, this comes up every now and then.
"iff" means "if and only if" by convention.
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Monday, April 13, 2015 6:38 AM
> To: Zhaogang Gong
> Cc: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; yanxiaof...@inspur.com
> Subject: Re: [PATCH] acpica: modify a commit error in file
> drivers/acpi/acpica/nsxfeval.c
>
> On Monday, April 13, 2015 05:05:07 PM Zhaogang Gong wrote:
> > Change "iff" in function acpi_evaluate_object() to "if".
> >
> > Signed-off-by: Zhaogang Gong
> > ---
> > drivers/acpi/acpica/nsxfeval.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpica/nsxfeval.c
> > b/drivers/acpi/acpica/nsxfeval.c index b6030a2..9571429 100644
> > --- a/drivers/acpi/acpica/nsxfeval.c
> > +++ b/drivers/acpi/acpica/nsxfeval.c
> > @@ -214,7 +214,7 @@ acpi_evaluate_object(acpi_handle handle,
> > info->prefix_node = NULL;
> > } else if (!handle) {
> > /*
> > -* A handle is optional iff a fully qualified pathname is
> specified.
> > +* A handle is optional if a fully qualified pathname is
> specified.
>
> This is not a mistake.
>
> > * Since we've already handled fully qualified names above,
> this is
> > * an error.
> > */
> >
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
RE: [PATCH 1/4] ACPI: Add acpi_pr_() interfaces
>> I wouldn't have a problem renaming a few of those to >> something like: >> >> #define ACPI_INFO(plist) acpi_old_info plist >> #define ACPI_WARNING(plist) acpi_old_warning plist >> #define ACPI_ERROR(plist)acpi_old_error plist >> >> The acpi folk might though. > >Hi Joe, > >ACPI CA is being developed by Intel as OS-neutral code, and is used by >multiple OSes including Linux. So, I am not sure how easy to make such >changes. I am copying to Lin Ming. Please don't even consider doing something like this. As we continue to develop and maintain the ACPICA code, these kinds of OS-specific divergences from the base ACPICA code cause us all kinds of grief, including the accidental creation of new bugs as it becomes more and more difficult to integrate the base ACPICA code back into Linux. In fact, we have a major project this year (and probably far into next year) to continue to minimize (i.e., fix) this type of Linux/ACPICA divergence -- of which many have crept in over the years that ACPICA has been present in the Linux kernel. Bob >-Original Message- >From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- >ow...@vger.kernel.org] On Behalf Of Toshi Kani >Sent: Wednesday, July 18, 2012 3:08 PM >To: Joe Perches; Lin, Ming M >Cc: l...@kernel.org; linux-a...@vger.kernel.org; linux- >ker...@vger.kernel.org; bhelg...@google.com; >isimatu.yasu...@jp.fujitsu.com; liu...@gmail.com; >srivatsa.b...@linux.vnet.ibm.com; pra...@redhat.com; imamm...@redhat.com; >vijaymohan.pandarat...@hp.com >Subject: Re: [PATCH 1/4] ACPI: Add acpi_pr_() interfaces > >On Wed, 2012-07-18 at 14:54 -0700, Joe Perches wrote: >> On Wed, 2012-07-18 at 15:41 -0600, Toshi Kani wrote: >> > On Wed, 2012-07-18 at 14:21 -0700, Joe Perches wrote: >> > > On Wed, 2012-07-18 at 14:40 -0600, Toshi Kani wrote: >> > > > This patch introduces acpi_pr_(), where is a message >> > > > level such as err/warn/info, to support improved logging messages >> > > > for ACPI, esp. in hotplug operations. acpi_pr_() appends >> > > > "ACPI" prefix and ACPI object path to the messages. This improves >> > > > diagnostics in hotplug operations since it identifies an object >that >> > > > caused an issue in a log file. >> [] >> > > I'd be tempted to instead make the calls more like >> > > other _ uses and rename these to >> > > acpi_ and change the existing acpi_info to >> > > another name. >> [] >> > I agree with you. Unfortunately, the ACPI CA (ACPI FW interpreter) >> > already uses them for its internal-use as follows, so I needed to come >> > up with some other name... Hence, acpi_pr_. >> > >> > /* >> > * Error reporting. Callers module and line number are inserted by >AE_INFO, >> > * the plist contains a set of parens to allow variable-length lists. >> > * These macros are used for both the debug and non-debug versions of >the code. >> > */ >> > #define ACPI_INFO(plist)acpi_info plist >> > #define ACPI_WARNING(plist) acpi_warning plist >> > #define ACPI_EXCEPTION(plist) acpi_exception plist >> > #define ACPI_ERROR(plist) acpi_error plist >> > #define ACPI_DEBUG_OBJECT(obj,l,i) >acpi_ex_do_debug_object(obj,l,i) >> >> I wouldn't have a problem renaming a few of those to >> something like: >> >> #define ACPI_INFO(plist) acpi_old_info plist >> #define ACPI_WARNING(plist) acpi_old_warning plist >> #define ACPI_ERROR(plist)acpi_old_error plist >> >> The acpi folk might though. > >Hi Joe, > >ACPI CA is being developed by Intel as OS-neutral code, and is used by >multiple OSes including Linux. So, I am not sure how easy to make such >changes. I am copying to Lin Ming. > > >> > > Other than that, seems fine to me. >> > Great! Can I consider it as Ack? :) >> >> Fix the kfree first. > >Please see my other email. Do you think the check should be added >despite of the warning message? > > >> I rarely ack stuff as other people generally have to >> pick up the changes and I think acks are overrated. > >That's fair enough. > >Thanks! >-Toshi > > >> cheers, Joe >> > > >-- >To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ACPICA: Delete an unnecessary check before the function call "acpi_ds_delete_walk_state"
Got it, thanks.
> -Original Message-
> From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net]
> Sent: Wednesday, June 24, 2015 4:46 AM
> To: Len Brown; Zheng, Lv; Wysocki, Rafael J; Moore, Robert; linux-
> a...@vger.kernel.org; de...@acpica.org
> Cc: LKML; kernel-janit...@vger.kernel.org; Julia Lawall
> Subject: [PATCH] ACPICA: Delete an unnecessary check before the function
> call "acpi_ds_delete_walk_state"
>
> From: Markus Elfring
> Date: Wed, 24 Jun 2015 13:33:47 +0200
>
> The acpi_ds_delete_walk_state() function tests whether its argument is
> NULL and then returns immediately. Thus the test around the call is not
> needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/acpi/acpica/dsmethod.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dsmethod.c
> b/drivers/acpi/acpica/dsmethod.c index 85bb951..188b254 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -574,10 +574,7 @@ cleanup:
> /* On error, we must terminate the method properly */
>
> acpi_ds_terminate_control_method(obj_desc, next_walk_state);
> - if (next_walk_state) {
> - acpi_ds_delete_walk_state(next_walk_state);
> - }
> -
> + acpi_ds_delete_walk_state(next_walk_state);
> return_ACPI_STATUS(status);
> }
>
> --
> 2.4.4
RE: [PATCH v2 16/28] ACPICA: Namespace: Add support of OSDT table.
It is the current plan to add this to the next revision of the ACPI
specification.
In the meantime, the OSDT looks exactly like a DSDT or SSDT (hence the "SDT"
suffix), with the only difference being the signature "OSDT":
DefinitionBlock ("osdt.aml", "OSDT", 2, "Intel", "Template", 0x0001)
{
The current iASL compiler will emit a template for you if you want:
iasl -T OSDT
We are working on the proposal/ECR for the ACPI spec.
Bob
> -Original Message-
> From: Al Stone [mailto:a...@redhat.com]
> Sent: Wednesday, June 24, 2015 12:09 PM
> To: Zheng, Lv; Wysocki, Rafael J; Brown, Len
> Cc: Lv Zheng; linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org;
> Moore, Robert
> Subject: Re: [PATCH v2 16/28] ACPICA: Namespace: Add support of OSDT
> table.
>
> On 06/23/2015 09:04 PM, Lv Zheng wrote:
> > From: Bob Moore
> >
> > ACPICA commit 27415c82fcecf467446f66d1007a0691cc5f3709
> >
> > This patch adds OSDT (Override System Definition Table) support.
> > When OSDT is loaded, conflict namespace objects will be overridden by
> > the AML interpreter. Bob Moore, Lv Zheng.
> >
> > Link: https://github.com/acpica/acpica/commit/27415c82
> > Signed-off-by: Lv Zheng
> > Signed-off-by: Bob Moore
> > ---
> > drivers/acpi/acpica/nsparse.c |7 +++
> > drivers/acpi/acpica/tbxfload.c |6 +-
> > drivers/acpi/acpica/utmisc.c |3 ++-
> > include/acpi/actbl.h |1 +
> > 4 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/nsparse.c
> > b/drivers/acpi/acpica/nsparse.c index c95a119..57a4cfe 100644
> > --- a/drivers/acpi/acpica/nsparse.c
> > +++ b/drivers/acpi/acpica/nsparse.c
> > @@ -117,6 +117,13 @@ acpi_ns_one_complete_parse(u32 pass_number,
> >(u8) pass_number);
> > }
> >
> > + /* Found OSDT table, enable the namespace override feature */
> > +
> > + if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_OSDT) &&
> > + pass_number == ACPI_IMODE_LOAD_PASS1) {
> > + walk_state->namespace_override = TRUE;
> > + }
> > +
> > if (ACPI_FAILURE(status)) {
> > acpi_ds_delete_walk_state(walk_state);
> > goto cleanup;
> > diff --git a/drivers/acpi/acpica/tbxfload.c
> > b/drivers/acpi/acpica/tbxfload.c index b63e35d..960bd99 100644
> > --- a/drivers/acpi/acpica/tbxfload.c
> > +++ b/drivers/acpi/acpica/tbxfload.c
> > @@ -173,7 +173,11 @@ static acpi_status acpi_tb_load_namespace(void)
> > &&
> > !ACPI_COMPARE_NAME(&
> > (acpi_gbl_root_table_list.tables[i].
> > -signature), ACPI_SIG_PSDT))
> > +signature), ACPI_SIG_PSDT)
> > +&&
> > +!ACPI_COMPARE_NAME(&
> > + (acpi_gbl_root_table_list.tables[i].
> > +signature), ACPI_SIG_OSDT))
> > ||
> > ACPI_FAILURE(acpi_tb_validate_table
> > (&acpi_gbl_root_table_list.tables[i]))) { diff
> > --
> git
> > a/drivers/acpi/acpica/utmisc.c b/drivers/acpi/acpica/utmisc.c index
> > cbb7034..28099e2 100644
> > --- a/drivers/acpi/acpica/utmisc.c
> > +++ b/drivers/acpi/acpica/utmisc.c
> > @@ -97,7 +97,8 @@ u8 acpi_ut_is_aml_table(struct acpi_table_header
> > *table)
> >
> > if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT) ||
> > ACPI_COMPARE_NAME(table->signature, ACPI_SIG_PSDT) ||
> > - ACPI_COMPARE_NAME(table->signature, ACPI_SIG_SSDT)) {
> > + ACPI_COMPARE_NAME(table->signature, ACPI_SIG_SSDT) ||
> > + ACPI_COMPARE_NAME(table->signature, ACPI_SIG_OSDT)) {
> > return (TRUE);
> > }
> >
> > diff --git a/include/acpi/actbl.h b/include/acpi/actbl.h index
> > cb8a6b9..2d5faf5 100644
> > --- a/include/acpi/actbl.h
> > +++ b/include/acpi/actbl.h
> > @@ -65,6 +65,7 @@
> > #define ACPI_SIG_DSDT "DSDT" /* Differentiated System
> Description Table */
> > #define ACPI_SIG_FADT "FACP" /* Fixed ACPI Description Table
> */
> > #define ACPI_SIG_FACS "FACS" /* Firmware ACPI Control
> Structure */
> > +#define ACPI_SIG_OSDT "OSDT" /* Override System Description
> Table */
> &g
RE: [PATCH] acpi: update struct acpi_table_tpm2
It looks like there is a change to the TCPA table also.
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Monday, June 08, 2015 6:38 AM
> To: Moore, Robert
> Cc: Jarkko Sakkinen; Zheng, Lv; Wysocki, Rafael J; Len Brown; open
> list:ACPI COMPONENT AR...; open list:ACPI COMPONENT AR...; open list
> Subject: [PATCH] acpi: update struct acpi_table_tpm2
>
> Updated struct acpi_table_tpm2 to conform to the official TCG ACPI spec.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> include/acpi/actbl3.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h index
> 440ca81..33df1dd 100644
> --- a/include/acpi/actbl3.h
> +++ b/include/acpi/actbl3.h
> @@ -688,13 +688,14 @@ enum acpi_rasf_status {
> * TPM2 - Trusted Platform Module (TPM) 2.0 Hardware Interface Table
> *Version 3
> *
> - * Conforms to "TPM 2.0 Hardware Interface Table (TPM2)" 29 November 2011
> + * Conforms to "TCG ACPI Specification for Family 1.2 and 2.0" 19
> + December 2014
> *
>
> **
> /
>
> struct acpi_table_tpm2 {
> struct acpi_table_header header;/* Common ACPI table header */
> - u32 flags;
> + u16 platform_class;
> + u16 reserved;
> u64 control_address;
> u32 start_method;
> };
> --
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpi: update struct acpi_table_tpm2
ACPICA usually defines any "related" data structures, just for user convenience. > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, June 09, 2015 2:18 AM > To: Moore, Robert > Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; open list:ACPI COMPONENT > AR...; open list:ACPI COMPONENT AR...; open list > Subject: Re: [PATCH] acpi: update struct acpi_table_tpm2 > > On Mon, Jun 08, 2015 at 08:52:02PM +, Moore, Robert wrote: > > It looks like there is a change to the TCPA table also. > > Right. I'll update that too. > > I strongly think that the struct acpi_tpm2_control should not be in > actbl3.h. It is not defined in the TCG ACPI specification. It is defined > in > > http://www.trustedcomputinggroup.org/resources/pc_client_platform_tpm_prof > ile_ptp_specification > > FIFO control structures are internal for to the TPM subsystem and so > should be CRB control structures (and we have already inside tpm_crb.c). > > The structure ended up there probably because it was combined with the > TPM2 table in that Microsoft specification. > > /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpi: update struct acpi_table_tpm2
Well, you don't have to use it. ACPICA has done this in several other places. Anyway, I'm hesitant to just remove it at this point. > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, June 09, 2015 8:43 AM > To: Moore, Robert > Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; open list:ACPI COMPONENT > AR...; open list:ACPI COMPONENT AR...; open list > Subject: Re: [PATCH] acpi: update struct acpi_table_tpm2 > > On Tue, Jun 09, 2015 at 06:19:19PM +0300, Jarkko Sakkinen wrote: > > On Tue, Jun 09, 2015 at 02:21:12PM +, Moore, Robert wrote: > > > ACPICA usually defines any "related" data structures, just for user > > > convenience. > > > > If you want to keep it, it's fine for me but we still probably use the > > internal structure for it in tpm_crb driver (as tpm_tis uses internal > > structure for CRB). > > Let me open this a little bit. Everytime we want to do some small change > to control area (lets say TCG adds some flag) we would have to cycle them > through you. > > And the changes are not coupled with ACPI in any possible way. This is > only adds more maintenance burden to you and also to us. This structure is > the main control structure for the CRB driver and will be refined many > times in the future. There is no any kind of use to its fields outside of > the CRB driver. > > /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpi: update struct acpi_table_tpm2
Looking at the TCG ACPI Specification today, it looks like there are major changes to the TCPA table. There is a whole bunch of new stuff after the Log Area Start Address. Perhaps I missed or didn't get part of your proposed change. > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, June 09, 2015 8:19 AM > To: Moore, Robert > Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; open list:ACPI COMPONENT > AR...; open list:ACPI COMPONENT AR...; open list > Subject: Re: [PATCH] acpi: update struct acpi_table_tpm2 > > On Tue, Jun 09, 2015 at 02:21:12PM +, Moore, Robert wrote: > > ACPICA usually defines any "related" data structures, just for user > > convenience. > > If you want to keep it, it's fine for me but we still probably use the > internal structure for it in tpm_crb driver (as tpm_tis uses internal > structure for CRB). > > Do other updates look fine? I'm looking into migrating to tpm_crb driver > to use actbl3.h. > > /Jarkko > > > > > > -Original Message- > > > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > > > Sent: Tuesday, June 09, 2015 2:18 AM > > > To: Moore, Robert > > > Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; open list:ACPI > > > COMPONENT AR...; open list:ACPI COMPONENT AR...; open list > > > Subject: Re: [PATCH] acpi: update struct acpi_table_tpm2 > > > > > > On Mon, Jun 08, 2015 at 08:52:02PM +, Moore, Robert wrote: > > > > It looks like there is a change to the TCPA table also. > > > > > > Right. I'll update that too. > > > > > > I strongly think that the struct acpi_tpm2_control should not be in > > > actbl3.h. It is not defined in the TCG ACPI specification. It is > > > defined in > > > > > > http://www.trustedcomputinggroup.org/resources/pc_client_platform_tp > > > m_prof > > > ile_ptp_specification > > > > > > FIFO control structures are internal for to the TPM subsystem and so > > > should be CRB control structures (and we have already inside > tpm_crb.c). > > > > > > The structure ended up there probably because it was combined with > > > the > > > TPM2 table in that Microsoft specification. > > > > > > /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] acpi: update ACPI tables to match TCG ACPI specification.
Yes, we will do it in ACPICA first.
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, June 09, 2015 3:16 PM
> To: Jarkko Sakkinen; Moore, Robert
> Cc: peterhu...@gmx.de; Len Brown; Zheng, Lv; open list:ACPI; open
> list:ACPI COMPONENT AR...; open list
> Subject: Re: [PATCH v2] acpi: update ACPI tables to match TCG ACPI
> specification.
>
> On Tuesday, June 09, 2015 07:25:25 PM Jarkko Sakkinen wrote:
> > Updated struct acpi_table_tpm2 and struct acpi_table_tcpa to match the
> > TCG ACPI specification.
> >
> > v2:
> >
> > - Do not remove struct acpi_tpm2_control
> >
> > Signed-off-by: Jarkko Sakkinen
>
> Bob, I'm assuming that we'll be routing this one through upstream ACPICA.
>
> If that's not the case and I should apply it directly, please let me know.
>
>
> > ---
> > include/acpi/actbl2.h | 5 ++---
> > include/acpi/actbl3.h | 17 +
> > 2 files changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
> > cafdeb5..2f2b8a6 100644
> > --- a/include/acpi/actbl2.h
> > +++ b/include/acpi/actbl2.h
> > @@ -1071,14 +1071,13 @@ enum acpi_spmi_interface_types {
> > * TCPA - Trusted Computing Platform Alliance table
> > *Version 1
> > *
> > - * Conforms to "TCG PC Specific Implementation Specification",
> > - * Version 1.1, August 18, 2003
> > + * Conforms to "TCG ACPI Specification for Family 1.2 and 2.0" 19
> > + December 2014
> > *
> >
> > **
> > /
> >
> > struct acpi_table_tcpa {
> > struct acpi_table_header header;/* Common ACPI table header */
> > - u16 reserved;
> > + u16 platform_class; /* 0 for client and 1 for server platforms.
> */
> > u32 max_log_length; /* Maximum length for the event log area */
> > u64 log_address;/* Address of the event log area */
> > };
> > diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h index
> > 440ca81..8dd625c 100644
> > --- a/include/acpi/actbl3.h
> > +++ b/include/acpi/actbl3.h
> > @@ -688,15 +688,24 @@ enum acpi_rasf_status {
> > * TPM2 - Trusted Platform Module (TPM) 2.0 Hardware Interface Table
> > *Version 3
> > *
> > - * Conforms to "TPM 2.0 Hardware Interface Table (TPM2)" 29 November
> > 2011
> > + * Conforms to "TCG ACPI Specification for Family 1.2 and 2.0" 19
> > + December 2014
> > *
> >
> > **
> > /
> >
> > +/* How to notify that there is a command available for processing. */
> > +
> > +enum acpi_tpm2_start_method {
> > + ACPI_TPM2_SM_ACPI = 2,
> > + ACPI_TPM2_SM_CRB = 7,
> > + ACPI_TPM2_SM_CRB_AND_ACPI = 8,
> > +};
> > +
> > struct acpi_table_tpm2 {
> > struct acpi_table_header header;/* Common ACPI table header */
> > - u32 flags;
> > - u64 control_address;
> > - u32 start_method;
> > + u16 platform_class; /* 0 for client and 1 for server platforms
> */
> > + u16 reserved;
> > + u64 control_address;/* Physical address of the control area */
> > + u32 start_method; /* Method to notify to start processing */
> > };
> >
> > /* Control area structure (not part of table, pointed to by
> > control_address) */
> >
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
RE: [PATCH v2] acpi: update ACPI tables to match TCG ACPI specification.
We may do a quick update for the TCPA and TPM2 tables; but having two different
ACPI tables with the same signature (TCPA client and TCPA server) throws a bit
of a monkey wrench into some of the ACPICA stuff. Not only do we support ACPI
tables in the headers, but we also support them in the table disassembler and
the table template generator.
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Wednesday, June 10, 2015 5:13 AM
> To: Rafael J. Wysocki; Moore, Robert
> Cc: peterhu...@gmx.de; Len Brown; Zheng, Lv; ACPI; open list:ACPI
> COMPONENT AR...; open list
> Subject: Re: [PATCH v2] acpi: update ACPI tables to match TCG ACPI
> specification.
>
> OK, thank you guys. We'll start to use it as soon as the changes get to
> the kernel tree from ACPICA.
>
> /Jarkko
>
> On 06/10/2015 01:15 AM, Rafael J. Wysocki wrote:
> > On Tuesday, June 09, 2015 07:25:25 PM Jarkko Sakkinen wrote:
> >> Updated struct acpi_table_tpm2 and struct acpi_table_tcpa to match
> >> the TCG ACPI specification.
> >>
> >> v2:
> >>
> >> - Do not remove struct acpi_tpm2_control
> >>
> >> Signed-off-by: Jarkko Sakkinen
> > Bob, I'm assuming that we'll be routing this one through upstream
> ACPICA.
> >
> > If that's not the case and I should apply it directly, please let me
> know.
> >
> >
> >> ---
> >> include/acpi/actbl2.h | 5 ++---
> >> include/acpi/actbl3.h | 17 +
> >> 2 files changed, 15 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
> >> cafdeb5..2f2b8a6 100644
> >> --- a/include/acpi/actbl2.h
> >> +++ b/include/acpi/actbl2.h
> >> @@ -1071,14 +1071,13 @@ enum acpi_spmi_interface_types {
> >>* TCPA - Trusted Computing Platform Alliance table
> >>*Version 1
> >>*
> >> - * Conforms to "TCG PC Specific Implementation Specification",
> >> - * Version 1.1, August 18, 2003
> >> + * Conforms to "TCG ACPI Specification for Family 1.2 and 2.0" 19
> >> + December 2014
> >>*
> >>
> >> *
> >> */
> >>
> >> struct acpi_table_tcpa {
> >>struct acpi_table_header header;/* Common ACPI table header */
> >> - u16 reserved;
> >> + u16 platform_class; /* 0 for client and 1 for server platforms.
> */
> >>u32 max_log_length; /* Maximum length for the event log area */
> >>u64 log_address;/* Address of the event log area */
> >> };
> >> diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h index
> >> 440ca81..8dd625c 100644
> >> --- a/include/acpi/actbl3.h
> >> +++ b/include/acpi/actbl3.h
> >> @@ -688,15 +688,24 @@ enum acpi_rasf_status {
> >>* TPM2 - Trusted Platform Module (TPM) 2.0 Hardware Interface Table
> >>*Version 3
> >>*
> >> - * Conforms to "TPM 2.0 Hardware Interface Table (TPM2)" 29 November
> >> 2011
> >> + * Conforms to "TCG ACPI Specification for Family 1.2 and 2.0" 19
> >> + December 2014
> >>*
> >>
> >> *
> >> */
> >>
> >> +/* How to notify that there is a command available for processing.
> >> +*/
> >> +
> >> +enum acpi_tpm2_start_method {
> >> + ACPI_TPM2_SM_ACPI = 2,
> >> + ACPI_TPM2_SM_CRB = 7,
> >> + ACPI_TPM2_SM_CRB_AND_ACPI = 8,
> >> +};
> >> +
> >> struct acpi_table_tpm2 {
> >>struct acpi_table_header header;/* Common ACPI table header */
> >> - u32 flags;
> >> - u64 control_address;
> >> - u32 start_method;
> >> + u16 platform_class; /* 0 for client and 1 for server platforms
> */
> >> + u16 reserved;
> >> + u64 control_address;/* Physical address of the control area */
> >> + u32 start_method; /* Method to notify to start processing */
> >> };
> >>
> >> /* Control area structure (not part of table, pointed to by
> >> control_address) */
> >>
RE: [PATCH 1/1 linux-next] ACPICA: use swap() in acpi_ns_sort_list()
I don't think this is portable across operating systems. Which is a requirement
for ACPICA.
> -Original Message-
> From: Fabian Frederick [mailto:f...@skynet.be]
> Sent: Wednesday, June 10, 2015 9:33 AM
> To: linux-kernel@vger.kernel.org
> Cc: Julia Lawall; Fabian Frederick; Moore, Robert; Zheng, Lv; Wysocki,
> Rafael J; Len Brown; linux-a...@vger.kernel.org; de...@acpica.org
> Subject: [PATCH 1/1 linux-next] ACPICA: use swap() in acpi_ns_sort_list()
>
> Use kernel.h macro definition.
>
> Thanks to Julia Lawall for Coccinelle scripting support.
>
> Signed-off-by: Fabian Frederick
> ---
> drivers/acpi/acpica/nsrepair2.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/acpica/nsrepair2.c
> b/drivers/acpi/acpica/nsrepair2.c index c30672d..7513799 100644
> --- a/drivers/acpi/acpica/nsrepair2.c
> +++ b/drivers/acpi/acpica/nsrepair2.c
> @@ -904,7 +904,6 @@ acpi_ns_sort_list(union acpi_operand_object
> **elements, {
> union acpi_operand_object *obj_desc1;
> union acpi_operand_object *obj_desc2;
> - union acpi_operand_object *temp_obj;
> u32 i;
> u32 j;
>
> @@ -920,11 +919,8 @@ acpi_ns_sort_list(union acpi_operand_object
> **elements,
> obj_desc2->integer.value))
> || ((sort_direction == ACPI_SORT_DESCENDING)
> && (obj_desc1->integer.value <
> - obj_desc2->integer.value))) {
> - temp_obj = elements[j - 1];
> - elements[j - 1] = elements[j];
> - elements[j] = temp_obj;
> - }
> + obj_desc2->integer.value)))
> + swap(elements[j - 1], elements[j]);
> }
> }
> }
> --
> 2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the Windows 10 version 1607 and 1703 OSI strings
> -Original Message-
> From: mario.limoncie...@dell.com [mailto:mario.limoncie...@dell.com]
> Sent: Monday, March 26, 2018 12:30 AM
> To: alexander.le...@microsoft.com; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Cc: Moore, Robert ; Schmauss, Erik
> ; Wysocki, Rafael J
>
> Subject: RE: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the
> Windows 10 version 1607 and 1703 OSI strings
>
> > -Original Message-
> > From: Sasha Levin [mailto:alexander.le...@microsoft.com]
> > Sent: Monday, March 19, 2018 11:07 AM
> > To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org
> > Cc: Limonciello, Mario ; Bob Moore
> > ; Erik Schmauss ;
> Rafael J .
> > Wysocki ; Sasha Levin
> >
> > Subject: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the Windows
> > 10 version 1607 and 1703 OSI strings
> >
> > From: Mario Limonciello
> >
> > [ Upstream commit bc4d413a819f9d0764a80a55875a5d7e1f4efed4 ]
> >
> > ACPICA commit 35a4a3ea723b3066f575e63e5f0116f7ce65e713
> >
> > The public Microsoft document listing recognized OSI strings [1] shows
> > that these two strings were introduced.
> > version 1607 / Anniversary Update / "Redstone 1"
> > version 1703 / Creators Update / "Redstone 2"
> >
> > [1]
> > http://download.microsoft.com/download/7/e/7/7e7662cf-cbea-470b-a97e-
> > ce7ce0d98dc2/winacpi_osi.docx
> >
> > Link: https://github.com/acpica/acpica/commit/35a4a3ea
> > Signed-off-by: Mario Limonciello
> > Signed-off-by: Bob Moore
> > Signed-off-by: Erik Schmauss
> > Signed-off-by: Rafael J. Wysocki
> > Signed-off-by: Sasha Levin
> > ---
> > drivers/acpi/acpica/utosi.c | 2 ++
> > include/acpi/actypes.h | 2 ++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/acpi/acpica/utosi.c b/drivers/acpi/acpica/utosi.c
> > index 8f3d203aed79..51d9011b5b33 100644
> > --- a/drivers/acpi/acpica/utosi.c
> > +++ b/drivers/acpi/acpica/utosi.c
> > @@ -101,6 +101,8 @@ static struct acpi_interface_info
> > acpi_default_supported_interfaces[] = {
> > {"Windows 2012", NULL, 0, ACPI_OSI_WIN_8}, /* Windows 8 and Server
> > 2012 - Added 08/2012 */
> > {"Windows 2013", NULL, 0, ACPI_OSI_WIN_8}, /* Windows 8.1 and
> Server
> > 2012 R2 - Added 01/2014 */
> > {"Windows 2015", NULL, 0, ACPI_OSI_WIN_10}, /* Windows 10 -
> Added
> > 03/2015 */
> > + {"Windows 2016", NULL, 0, ACPI_OSI_WIN_10_RS1}, /* Windows 10
> > version 1607 - Added 12/2017 */
> > + {"Windows 2017", NULL, 0, ACPI_OSI_WIN_10_RS2}, /* Windows 10
> > version 1703 - Added 12/2017 */
> >
> > /* Feature Group Strings */
> >
> > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> > f914958c4adb..d27bc051f47f 100644
> > --- a/include/acpi/actypes.h
> > +++ b/include/acpi/actypes.h
> > @@ -1284,6 +1284,8 @@ typedef enum {
> > #define ACPI_OSI_WIN_7 0x0B
> > #define ACPI_OSI_WIN_8 0x0C
> > #define ACPI_OSI_WIN_10 0x0D
> > +#define ACPI_OSI_WIN_10_RS1 0x0E
> > +#define ACPI_OSI_WIN_10_RS2 0x0F
> >
> > /* Definitions of file IO */
> >
> > --
> > 2.14.1
>
> I don't believe that it would be a good idea to bring back this patch to
> kernels older than 4.15. These strings do activate some extra features
> in Windows and some BIOS ASL has been written to only activate them when
> the newer Windows versions are detected. I have no concerns bringing
> them to 4.15 though.
>
> Bringing them back to stable may introduce other problems that requires
> backporting additional driver changes too.
[Moore, Robert]
There should be no problem with this change concerning older machines. The
firmware on these machines will simply never call _OSI with any strings newer
than when the firmware was written -- including this new one.
Bob
RE: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the Windows 10 version 1607 and 1703 OSI strings
> -Original Message-
> From: mario.limoncie...@dell.com [mailto:mario.limoncie...@dell.com]
> Sent: Wednesday, March 28, 2018 10:18 AM
> To: Moore, Robert ;
> alexander.le...@microsoft.com; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Cc: Schmauss, Erik ; Wysocki, Rafael J
>
> Subject: RE: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the
> Windows 10 version 1607 and 1703 OSI strings
>
> > -----Original Message-
> > From: Moore, Robert [mailto:robert.mo...@intel.com]
> > Sent: Wednesday, March 28, 2018 12:16 PM
> > To: Limonciello, Mario ;
> > alexander.le...@microsoft.com; linux-kernel@vger.kernel.org;
> > sta...@vger.kernel.org
> > Cc: Schmauss, Erik ; Wysocki, Rafael J
> >
> > Subject: RE: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the
> > Windows 10 version 1607 and 1703 OSI strings
> >
> >
> >
> > > -Original Message-
> > > From: mario.limoncie...@dell.com [mailto:mario.limoncie...@dell.com]
> > > Sent: Monday, March 26, 2018 12:30 AM
> > > To: alexander.le...@microsoft.com; linux-kernel@vger.kernel.org;
> > > sta...@vger.kernel.org
> > > Cc: Moore, Robert ; Schmauss, Erik
> > > ; Wysocki, Rafael J
> > >
> > > Subject: RE: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the
> > > Windows 10 version 1607 and 1703 OSI strings
> > >
> > > > -Original Message-
> > > > From: Sasha Levin [mailto:alexander.le...@microsoft.com]
> > > > Sent: Monday, March 19, 2018 11:07 AM
> > > > To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org
> > > > Cc: Limonciello, Mario ; Bob Moore
> > > > ; Erik Schmauss ;
> > > Rafael J .
> > > > Wysocki ; Sasha Levin
> > > >
> > > > Subject: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the
> > > > Windows
> > > > 10 version 1607 and 1703 OSI strings
> > > >
> > > > From: Mario Limonciello
> > > >
> > > > [ Upstream commit bc4d413a819f9d0764a80a55875a5d7e1f4efed4 ]
> > > >
> > > > ACPICA commit 35a4a3ea723b3066f575e63e5f0116f7ce65e713
> > > >
> > > > The public Microsoft document listing recognized OSI strings [1]
> > > > shows that these two strings were introduced.
> > > > version 1607 / Anniversary Update / "Redstone 1"
> > > > version 1703 / Creators Update / "Redstone 2"
> > > >
> > > > [1]
> > > > http://download.microsoft.com/download/7/e/7/7e7662cf-cbea-470b-a9
> > > > 7e-
> > > > ce7ce0d98dc2/winacpi_osi.docx
> > > >
> > > > Link: https://github.com/acpica/acpica/commit/35a4a3ea
> > > > Signed-off-by: Mario Limonciello
> > > > Signed-off-by: Bob Moore
> > > > Signed-off-by: Erik Schmauss
> > > > Signed-off-by: Rafael J. Wysocki
> > > > Signed-off-by: Sasha Levin
> > > > ---
> > > > drivers/acpi/acpica/utosi.c | 2 ++
> > > > include/acpi/actypes.h | 2 ++
> > > > 2 files changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/acpi/acpica/utosi.c
> > > > b/drivers/acpi/acpica/utosi.c index 8f3d203aed79..51d9011b5b33
> > > > 100644
> > > > --- a/drivers/acpi/acpica/utosi.c
> > > > +++ b/drivers/acpi/acpica/utosi.c
> > > > @@ -101,6 +101,8 @@ static struct acpi_interface_info
> > > > acpi_default_supported_interfaces[] = {
> > > > {"Windows 2012", NULL, 0, ACPI_OSI_WIN_8}, /* Windows 8 and
> Server
> > > > 2012 - Added 08/2012 */
> > > > {"Windows 2013", NULL, 0, ACPI_OSI_WIN_8}, /* Windows 8.1
> > > > and
> > > Server
> > > > 2012 R2 - Added 01/2014 */
> > > > {"Windows 2015", NULL, 0, ACPI_OSI_WIN_10}, /* Windows 10
> -
> > > Added
> > > > 03/2015 */
> > > > + {"Windows 2016", NULL, 0, ACPI_OSI_WIN_10_RS1}, /* Windows 10
> > > > version 1607 - Added 12/2017 */
> > > > + {"Windows 2017", NULL, 0, ACPI_OSI_WIN_10_RS2}, /* Windows 10
> > > > version 1703 - Added 12/2017 */
> > > >
> > > > /* Feature Group Strings */
> > > >
> > > > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> > > > f914958c4adb..d27bc051f47f 100644
> > > > --- a/include/acpi/actypes.h
>
RE: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()
I'm not sure why this is necessary, please explain.
Is the implication here that some driver is going to poll on acpi_dispatch_gpe?
Bob
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, May 16, 2018 5:12 AM
> To: Linux ACPI
> Cc: Zhang, Rui ; Linux PM p...@vger.kernel.org>; LKML ; Schmauss, Erik
> ; Moore, Robert ; Wang,
> Wendy
> Subject: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()
>
> From: Rafael J. Wysocki
>
> Introduce acpi_dispatch_gpe() as a wrapper around acpi_ev_detect_gpe()
> for checking if the given GPE (as represented by a GPE device handle and
> a GPE number) is currently active and dispatching it (if that's the
> case) outside of interrupt context.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/acpica/evgpe.c |6 ++
> drivers/acpi/acpica/evxfgpe.c | 22 ++
> include/acpi/acpixf.h |1 +
> 3 files changed, 29 insertions(+)
>
> Index: linux-pm/drivers/acpi/acpica/evgpe.c
> ===
> --- linux-pm.orig/drivers/acpi/acpica/evgpe.c
> +++ linux-pm/drivers/acpi/acpica/evgpe.c
> @@ -634,6 +634,12 @@ acpi_ev_detect_gpe(struct acpi_namespace
>
> flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
>
> + if (!gpe_event_info) {
> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device,
> gpe_number);
> + if (!gpe_event_info)
> + goto error_exit;
> + }
> +
> /* Get the info block for the entire GPE register */
>
> gpe_register_info = gpe_event_info->register_info;
> Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> ===
> --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> @@ -639,6 +639,28 @@ ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
>
>
> /***
>
> *
> + * FUNCTION:acpi_gispatch_gpe
> + *
> + * PARAMETERS: gpe_device - Parent GPE Device. NULL for
> GPE0/GPE1
> + * gpe_number - GPE level within the GPE block
> + *
> + * RETURN: None
> + *
> + * DESCRIPTION: Detect and dispatch a General Purpose Event to either a
> function
> + * (e.g. EC) or method (e.g. _Lxx/_Exx) handler.
> + *
> +
> +***
> +***/ void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number)
> +{
> + ACPI_FUNCTION_TRACE(acpi_dispatch_gpe);
> +
> + acpi_ev_detect_gpe(gpe_device, NULL, gpe_number); }
> +
> +ACPI_EXPORT_SYMBOL(acpi_dispatch_gpe)
> +
> +/**
> +*
> + *
> * FUNCTION:acpi_finish_gpe
> *
> * PARAMETERS: gpe_device - Namespace node for the GPE Block
> Index: linux-pm/include/acpi/acpixf.h
> ===
> --- linux-pm.orig/include/acpi/acpixf.h
> +++ linux-pm/include/acpi/acpixf.h
> @@ -753,6 +753,7 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_sta
>u32 gpe_number,
>acpi_event_status
>*event_status))
> +void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number);
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_disable_all_gpes(void))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_runtime_gpes(void))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_wakeup_gpes(void))
RE: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is defined
Well, I don't like the fact that PCI_CONFIGURED would have to be defined by
each current host:
> +#ifdef ACPI_PCI_CONFIGURED
I would rather the logic be reversed:
> +#ifdef ACPI_PCI_NOT_CONFIGURED
-Original Message-
From: Kaneda, Erik
Sent: Wednesday, March 03, 2021 10:29 AM
To: Weidong Cui ; Moore, Robert ;
Wysocki, Rafael J
Cc: Xinyang Ge ; linux-a...@vger.kernel.org;
de...@acpica.org; linux-kernel@vger.kernel.org; Len Brown
Subject: RE: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is defined
This looks good to me. Bob, do you have any comments?
Erik
> -Original Message-
> From: Weidong Cui
> Sent: Monday, February 8, 2021 7:18 PM
> To: Moore, Robert ; Kaneda, Erik
> ; Wysocki, Rafael J
> ; Len Brown
> Cc: Weidong Cui ; Xinyang Ge
> ; linux-a...@vger.kernel.org; de...@acpica.org;
> linux- ker...@vger.kernel.org
> Subject: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
> acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is
> defined
>
> Signed-off-by: Weidong Cui
> Signed-off-by: Xinyang Ge
> ---
> drivers/acpi/acpica/evhandler.c | 2 ++
> include/acpi/acconfig.h | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/acpi/acpica/evhandler.c
> b/drivers/acpi/acpica/evhandler.c index 5884eba04..4c25ad433 100644
> --- a/drivers/acpi/acpica/evhandler.c
> +++ b/drivers/acpi/acpica/evhandler.c
> @@ -26,7 +26,9 @@ acpi_ev_install_handler(acpi_handle obj_handle,
> u8 acpi_gbl_default_address_spaces[ACPI_NUM_DEFAULT_SPACES] = {
> ACPI_ADR_SPACE_SYSTEM_MEMORY,
> ACPI_ADR_SPACE_SYSTEM_IO,
> +#ifdef ACPI_PCI_CONFIGURED
> ACPI_ADR_SPACE_PCI_CONFIG,
> +#endif
> ACPI_ADR_SPACE_DATA_TABLE
> };
>
> diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index
> a225eff49..790999028 100644
> --- a/include/acpi/acconfig.h
> +++ b/include/acpi/acconfig.h
> @@ -162,7 +162,11 @@
> /* Maximum space_ids for Operation Regions */
>
> #define ACPI_MAX_ADDRESS_SPACE 255
> +#ifdef ACPI_PCI_CONFIGURED
> #define ACPI_NUM_DEFAULT_SPACES 4
> +#else
> +#define ACPI_NUM_DEFAULT_SPACES 3
> +#endif
>
> /* Array sizes. Used for range checking also */
>
> --
> 2.24.3 (Apple Git-128)
RE: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is defined
-Original Message-
From: Weidong Cui
Sent: Thursday, March 04, 2021 9:06 AM
To: Moore, Robert
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Xinyang Ge ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Len
Brown
Subject: Re: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is defined
> Well, I don't like the fact that PCI_CONFIGURED would have to be defined by
> each current host:
>
> > +#ifdef ACPI_PCI_CONFIGURED
>
> I would rather the logic be reversed:
>
> > +#ifdef ACPI_PCI_NOT_CONFIGURED
Thank you for the comments, Erik and Bob!
ACPI_PCI_CONFIGURED is defined in aclinux.h (see below) and used in several
places in evhandler.c and exregion.c.
I'm not sure why we want to introduce ACPI_PCI_NOT_CONFIGURED. Bob, I don't
understand your concerns about "have to be defined by each current host". Can
you please shed some light on it?
It is required in aclinux.h, and thus it is required in every host-dependent
configuration file (acfreebsd.h, acmacosx.h, acnetbsd.h, achaiku.h, etc.) I
would rather not force these host-specific header files to change.
Bob
#ifdef CONFIG_PCI
#define ACPI_PCI_CONFIGURED
#endif
> -Original Message-
> From: Kaneda, Erik
> Sent: Wednesday, March 03, 2021 10:29 AM
> To: Weidong Cui ; Moore, Robert
> ; Wysocki, Rafael J
>
> Cc: Xinyang Ge ; linux-a...@vger.kernel.org;
> de...@acpica.org; linux-kernel@vger.kernel.org; Len Brown
>
> Subject: RE: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
> acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is
> defined
>
> This looks good to me. Bob, do you have any comments?
>
> Erik
>
> > -----Original Message-
> > From: Weidong Cui
> > Sent: Monday, February 8, 2021 7:18 PM
> > To: Moore, Robert ; Kaneda, Erik
> > ; Wysocki, Rafael J
> > ; Len Brown
> > Cc: Weidong Cui ; Xinyang Ge
> > ; linux-a...@vger.kernel.org; de...@acpica.org;
> > linux- ker...@vger.kernel.org
> > Subject: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
> > acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is
> > defined
> >
> > Signed-off-by: Weidong Cui
> > Signed-off-by: Xinyang Ge
> > ---
> > drivers/acpi/acpica/evhandler.c | 2 ++
> > include/acpi/acconfig.h | 4
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/acpi/acpica/evhandler.c
> > b/drivers/acpi/acpica/evhandler.c index 5884eba04..4c25ad433 100644
> > --- a/drivers/acpi/acpica/evhandler.c
> > +++ b/drivers/acpi/acpica/evhandler.c
> > @@ -26,7 +26,9 @@ acpi_ev_install_handler(acpi_handle obj_handle,
> > u8 acpi_gbl_default_address_spaces[ACPI_NUM_DEFAULT_SPACES] = {
> > ACPI_ADR_SPACE_SYSTEM_MEMORY,
> > ACPI_ADR_SPACE_SYSTEM_IO,
> > +#ifdef ACPI_PCI_CONFIGURED
> > ACPI_ADR_SPACE_PCI_CONFIG,
> > +#endif
> > ACPI_ADR_SPACE_DATA_TABLE
> > };
> >
> > diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index
> > a225eff49..790999028 100644
> > --- a/include/acpi/acconfig.h
> > +++ b/include/acpi/acconfig.h
> > @@ -162,7 +162,11 @@
> > /* Maximum space_ids for Operation Regions */
> >
> > #define ACPI_MAX_ADDRESS_SPACE 255
> > +#ifdef ACPI_PCI_CONFIGURED
> > #define ACPI_NUM_DEFAULT_SPACES 4
> > +#else
> > +#define ACPI_NUM_DEFAULT_SPACES 3
> > +#endif
> >
> > /* Array sizes. Used for range checking also */
> >
> > --
> > 2.24.3 (Apple Git-128)
>
RE: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is defined
After giving this some thought, I think we can #define ACPI_PCI_CONFIGURED in
the global configuration file (I think it is acconfig.h) - and document why and
when it should be removed.
Bob
-Original Message-
From: Moore, Robert
Sent: Thursday, March 04, 2021 9:37 AM
To: weidong...@gmail.com
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Xinyang Ge ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: [Devel] Re: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is defined
-Original Message-
From: Weidong Cui
Sent: Thursday, March 04, 2021 9:06 AM
To: Moore, Robert
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Xinyang Ge ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Len
Brown
Subject: Re: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is defined
> Well, I don't like the fact that PCI_CONFIGURED would have to be defined by
> each current host:
>
> > +#ifdef ACPI_PCI_CONFIGURED
>
> I would rather the logic be reversed:
>
> > +#ifdef ACPI_PCI_NOT_CONFIGURED
Thank you for the comments, Erik and Bob!
ACPI_PCI_CONFIGURED is defined in aclinux.h (see below) and used in several
places in evhandler.c and exregion.c.
I'm not sure why we want to introduce ACPI_PCI_NOT_CONFIGURED. Bob, I don't
understand your concerns about "have to be defined by each current host". Can
you please shed some light on it?
It is required in aclinux.h, and thus it is required in every host-dependent
configuration file (acfreebsd.h, acmacosx.h, acnetbsd.h, achaiku.h, etc.) I
would rather not force these host-specific header files to change.
Bob
#ifdef CONFIG_PCI
#define ACPI_PCI_CONFIGURED
#endif
> -Original Message-
> From: Kaneda, Erik
> Sent: Wednesday, March 03, 2021 10:29 AM
> To: Weidong Cui ; Moore, Robert
> ; Wysocki, Rafael J
>
> Cc: Xinyang Ge ; linux-a...@vger.kernel.org;
> de...@acpica.org; linux-kernel@vger.kernel.org; Len Brown
>
> Subject: RE: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
> acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is
> defined
>
> This looks good to me. Bob, do you have any comments?
>
> Erik
>
> > -----Original Message-
> > From: Weidong Cui
> > Sent: Monday, February 8, 2021 7:18 PM
> > To: Moore, Robert ; Kaneda, Erik
> > ; Wysocki, Rafael J
> > ; Len Brown
> > Cc: Weidong Cui ; Xinyang Ge
> > ; linux-a...@vger.kernel.org; de...@acpica.org;
> > linux- ker...@vger.kernel.org
> > Subject: [PATCH] Enable ACPI_ADR_SPACE_PCI_CONFIG in
> > acpi_gbl_default_address_spaces only when ACPI_PCI_CONFIGURED is
> > defined
> >
> > Signed-off-by: Weidong Cui
> > Signed-off-by: Xinyang Ge
> > ---
> > drivers/acpi/acpica/evhandler.c | 2 ++
> > include/acpi/acconfig.h | 4
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/acpi/acpica/evhandler.c
> > b/drivers/acpi/acpica/evhandler.c index 5884eba04..4c25ad433 100644
> > --- a/drivers/acpi/acpica/evhandler.c
> > +++ b/drivers/acpi/acpica/evhandler.c
> > @@ -26,7 +26,9 @@ acpi_ev_install_handler(acpi_handle obj_handle,
> > u8 acpi_gbl_default_address_spaces[ACPI_NUM_DEFAULT_SPACES] = {
> > ACPI_ADR_SPACE_SYSTEM_MEMORY,
> > ACPI_ADR_SPACE_SYSTEM_IO,
> > +#ifdef ACPI_PCI_CONFIGURED
> > ACPI_ADR_SPACE_PCI_CONFIG,
> > +#endif
> > ACPI_ADR_SPACE_DATA_TABLE
> > };
> >
> > diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index
> > a225eff49..790999028 100644
> > --- a/include/acpi/acconfig.h
> > +++ b/include/acpi/acconfig.h
> > @@ -162,7 +162,11 @@
> > /* Maximum space_ids for Operation Regions */
> >
> > #define ACPI_MAX_ADDRESS_SPACE 255
> > +#ifdef ACPI_PCI_CONFIGURED
> > #define ACPI_NUM_DEFAULT_SPACES 4
> > +#else
> > +#define ACPI_NUM_DEFAULT_SPACES 3
> > +#endif
> >
> > /* Array sizes. Used for range checking also */
> >
> > --
> > 2.24.3 (Apple Git-128)
>
___
Devel mailing list -- de...@acpica.org
To unsubscribe send an email to devel-le...@acpica.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
RE: [PATCH] ACPICA: Fix a typo
Please make a pull request for this on our github. Thanks, Bob -Original Message- From: Bhaskar Chowdhury Sent: Thursday, March 25, 2021 5:19 PM To: Moore, Robert ; Kaneda, Erik ; Wysocki, Rafael J ; l...@kernel.org; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org Cc: rdun...@infradead.org; Bhaskar Chowdhury Subject: [PATCH] ACPICA: Fix a typo s/optimzation/optimization/ Signed-off-by: Bhaskar Chowdhury --- include/acpi/acoutput.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acoutput.h b/include/acpi/acoutput.h index 1538a6853822..1b4c45815695 100644 --- a/include/acpi/acoutput.h +++ b/include/acpi/acoutput.h @@ -362,7 +362,7 @@ * * A less-safe version of the macros is provided for optional use if the * compiler uses excessive CPU stack (for example, this may happen in the - * debug case if code optimzation is disabled.) + * debug case if code optimization is disabled.) */ /* Exit trace helper macro */ -- 2.26.2
RE: [PATCH] ACPICA: Events: support fixed pcie wake event
Can you send/point us to the spec that this change is based upon?
Thanks,
Bob
-Original Message-
From: Jianmin Lv
Sent: Thursday, April 01, 2021 5:06 AM
To: Moore, Robert ; Kaneda, Erik
; Wysocki, Rafael J ; Len
Brown
Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org;
lvjianmin
Subject: [PATCH] ACPICA: Events: support fixed pcie wake event
From: lvjianmin
Some chipsets support fixed pcie wake event which is defined in the PM1 block,
such as LS7A1000 of Loongson company, so we add code to handle it.
Signed-off-by: lvjianmin
diff --git a/drivers/acpi/acpica/evevent.c b/drivers/acpi/acpica/evevent.c
index 35385148fedb..08ba368beb2d 100644
--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -185,6 +185,10 @@ u32 acpi_ev_fixed_event_detect(void)
return (int_status);
}
+ if (fixed_enable & ACPI_BITMASK_PCIEXP_WAKE_DISABLE)
+ fixed_enable &= ~ACPI_BITMASK_PCIEXP_WAKE_DISABLE;
+ else
+ fixed_enable |= ACPI_BITMASK_PCIEXP_WAKE_DISABLE;
ACPI_DEBUG_PRINT((ACPI_DB_INTERRUPTS,
"Fixed Event Block: Enable %08X Status %08X\n",
fixed_enable, fixed_status));
@@ -250,8 +254,8 @@ static u32 acpi_ev_fixed_event_dispatch(u32 event)
if (!acpi_gbl_fixed_event_handlers[event].handler) {
(void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
enable_register_id,
- ACPI_DISABLE_EVENT);
-
+ event == ACPI_EVENT_PCIE_WAKE ?
+ ACPI_ENABLE_EVENT :
ACPI_DISABLE_EVENT);
ACPI_ERROR((AE_INFO,
"No installed handler for fixed event - %s (%u),
disabling",
acpi_ut_get_event_name(event), event)); diff --git
a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c index
14baa13bf848..7e7ea4c2e914 100644
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -312,6 +312,18 @@ acpi_status acpi_hw_legacy_wake(u8 sleep_state)
[ACPI_EVENT_SLEEP_BUTTON].
status_register_id, ACPI_CLEAR_STATUS);
+ /* Enable pcie wake event if support */
+ if ((acpi_gbl_FADT.flags & ACPI_FADT_PCI_EXPRESS_WAKE)) {
+ (void)
+ acpi_write_bit_register(acpi_gbl_fixed_event_info
+ [ACPI_EVENT_PCIE_WAKE].
+ enable_register_id, ACPI_DISABLE_EVENT);
+ (void)
+ acpi_write_bit_register(acpi_gbl_fixed_event_info
+ [ACPI_EVENT_PCIE_WAKE].
+ status_register_id, ACPI_CLEAR_STATUS);
+ }
+
acpi_hw_execute_sleep_method(METHOD_PATHNAME__SST, ACPI_SST_WORKING);
return_ACPI_STATUS(status);
}
diff --git a/drivers/acpi/acpica/utglobal.c b/drivers/acpi/acpica/utglobal.c
index 59a48371a7bc..68baf16d8a02 100644
--- a/drivers/acpi/acpica/utglobal.c
+++ b/drivers/acpi/acpica/utglobal.c
@@ -186,6 +186,10 @@ struct acpi_fixed_event_info
acpi_gbl_fixed_event_info[ACPI_NUM_FIXED_EVENTS] =
ACPI_BITREG_RT_CLOCK_ENABLE,
ACPI_BITMASK_RT_CLOCK_STATUS,
ACPI_BITMASK_RT_CLOCK_ENABLE},
+ /* ACPI_EVENT_PCIE_WAKE */ {ACPI_BITREG_PCIEXP_WAKE_STATUS,
+ ACPI_BITREG_PCIEXP_WAKE_DISABLE,
+ ACPI_BITMASK_PCIEXP_WAKE_STATUS,
+ ACPI_BITMASK_PCIEXP_WAKE_DISABLE},
};
#endif /* !ACPI_REDUCED_HARDWARE */
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
92c71dfce0d5..0b6c72033487 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -714,7 +714,8 @@ typedef u32 acpi_event_type;
#define ACPI_EVENT_POWER_BUTTON 2
#define ACPI_EVENT_SLEEP_BUTTON 3
#define ACPI_EVENT_RTC 4
-#define ACPI_EVENT_MAX 4
+#define ACPI_EVENT_PCIE_WAKE5
+#define ACPI_EVENT_MAX 5
#define ACPI_NUM_FIXED_EVENTS ACPI_EVENT_MAX + 1
/*
--
2.27.0
RE: ACPICA 20140214 auto-serialize weirds my machine...
Sabrina, Valdis:
Do either of you see any error messages like this:
ACPI Error: Mutex [0x1] is not acquired, cannot release (20140214/utmutex-437)
> -Original Message-
> From: Sabrina Dubroca [mailto:s...@queasysnail.net]
> Sent: Friday, March 14, 2014 10:38 AM
> To: Valdis Kletnieks
> Cc: Zheng, Lv; Wysocki, Rafael J; Moore, Robert; Len Brown; linux-
> ker...@vger.kernel.org; linux-a...@vger.kernel.org
> Subject: Re: ACPICA 20140214 auto-serialize weirds my machine...
>
> Hi,
>
> 2014-03-14, 12:05:01 -0400, Valdis Kletnieks wrote:
> > Surprisingly enough, this hasn't seemed to have bitten many Linux
> > people yet, Google only finds a BSD thread (where the same ACPICA code
> is in use):
> >
> > http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817
>
> I was about to report the same issue on a Dell Latitude D830. Boot
> failure, flood of these messages:
>
> ACPI Exception: AE_AML_MUTEX_ORDER, while evaluating GPE method [_L1C]
> (20140214/evgpe-580) ACPI Error: Method parse/execution failed [\GPE._L1C]
> (Node f5e0c9a8), AE_AML_MUTEX_ORDER (20140214/psparse-536) ACPI Error:
> Cannot acquire Mutex for method [SX30], current SyncLevel is too large (1)
> (20140214/dsmethod-362) ACPI Exception: AE_AML_MUTEX_ORDER, while
> evaluating GPE method [_L1C] (20140214/evgpe-580)
>
> With acpi_no_auto_serialize things look good.
>
>
> Before I tried that option, a bisection led me to remove "| AML_CREATE"
> from commit f56b05bd111b. That made the laptop boot,
>
> things seemed okay, except for the battery not being detected: the normal
> battery line was gone ("ACPI: Battery Slot [BAT0] (battery
> present)") and there's this instead:
>
> ACPI Error: Cannot acquire Mutex for method [SX45], current SyncLevel is
> too large (1) (20140214/dsmethod-362) ACPI Error: Method parse/execution
> failed [\_SB_.BIF_] (Node f5c250d8), AE_AML_MUTEX_ORDER (20140214/psparse-
> 536) ACPI Error: Method parse/execution failed [\_SB_.BAT0._BIF] (Node
> f5c25168), AE_AML_MUTEX_ORDER (20140214/psparse-536) ACPI Exception:
> AE_AML_MUTEX_ORDER, Evaluating _BIF (20140214/battery-416)
>
>
> --
> Sabrina
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: ACPICA 20140214 auto-serialize weirds my machine...
We have reproduced the problem here, and have reached an understanding of the problem. We are working on the solution, please disable auto-serialize for now. Thanks, Bob > -Original Message- > From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] > Sent: Friday, March 14, 2014 1:04 PM > To: Moore, Robert > Cc: Sabrina Dubroca; Zheng, Lv; Wysocki, Rafael J; Len Brown; linux- > ker...@vger.kernel.org; linux-a...@vger.kernel.org > Subject: Re: ACPICA 20140214 auto-serialize weirds my machine... > > On Fri, 14 Mar 2014 19:36:54 -, "Moore, Robert" said: > > Sabrina, Valdis: > > > > Do either of you see any error messages like this: > > > > ACPI Error: Mutex [0x1] is not acquired, cannot release > (20140214/utmutex-437) > > All of my "ACPI Error:" messages look like either: > > ACPI Error: Cannot acquire Mutex for method [SNVC], current SyncLevel is > too large (1) (20140214/dsmethod-362) > > or > > ACPI Error: Method parse/execution failed [\ECBT] (Node 88012d02d588), > AE_AML_MUTEX_ORDER (20140214/psparse-536) > > I should have a git bisect finished shortly... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPICA 20140214 auto-serialize weirds my machine...
> -Original Message- > From: Valdis Kletnieks [mailto:valdis.kletni...@vt.edu] > Sent: Friday, March 14, 2014 9:05 AM > To: Zheng, Lv; Wysocki, Rafael J; Moore, Robert; Len Brown > Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org > Subject: ACPICA 20140214 auto-serialize weirds my machine... > > Surprisingly enough, this hasn't seemed to have bitten many Linux people > yet, Google only finds a BSD thread (where the same ACPICA code is in > use): Yes, and the reason that it is rare to see this error is because the problem is related to the use of the ASL Sync Level mechanism, which is rarely used. Bob > > http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817 > > I found this, but haven't tried it yet: > > commit 5f1cb4a92e4c4aabd139ff9ca1e11c0e2db2ac59 > Author: Lv Zheng > Date: Wed Feb 26 10:32:01 2014 +0800 > > ACPICA: Remove global option to serialize all control methods. > > With the addition of the auto-serialization feature, this option > is obsolete and is completely removed. Lv Zheng. > > This patch also updates acpi_serialize kernel parameter using the > new auto-serialization feature - acpi_gbl_auto_serialize_methods. > > This looks like a user nightmare waiting to happen, because: > > - acpi_serialize [HW,ACPI] force serialization of AML methods > + acpi_serialize= [HW,ACPI] configure auto-serialization of AML > methods > > Re-using a kernel parameter name with different semantics is just asking > for trouble. > > I get this in my dmesg, and then I end up with all sorts of ACPI-related > weirdness - everything from 4 or 5 temperature sensors evaporating to it > claiming that my laptop doesn't have a battery bay (it may also be related > to an issue I'm seeing with multiple graphics monitors as well, but I > haven't verified that yet). > > We're going to need a better way to deal with this before it gets to > mainline > > [0.119344] ACPI: Executed 1 blocks of module-level executable AML code > [0.135282] ACPI Error: Cannot acquire Mutex for method [SNVC], current > SyncLevel is too large (1) (20140214/dsmethod-362) > [0.135288] ACPI Error: Method parse/execution failed [\SMBF] (Node > 88012d026ec0), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.135298] ACPI Error: Method parse/execution failed [\GENS] (Node > 88012d026e70), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.135307] ACPI Error: Method parse/execution failed [\EISC] (Node > 88012d02d560), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.135320] ACPI Error: Method parse/execution failed > [\_SB_.PCI0.LPCB.ECDV.ECR1] (Node 88012d02d470), AE_AML_MUTEX_ORDER > (20140214/psparse-536) > [0.135328] ACPI Error: Method parse/execution failed [\ECRB] (Node > 88012d02d5d8), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.135336] ACPI Error: Method parse/execution failed [\ECG5] (Node > 88012d02d740), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.135343] ACPI Error: Method parse/execution failed > [\_SB_.PCI0.LPCB.EINI] (Node 88012d02db00), AE_AML_MUTEX_ORDER > (20140214/psparse-536) > [0.135351] ACPI Error: Method parse/execution failed [\EV3_] (Node > 88012d0314c0), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.135359] ACPI Error: Method parse/execution failed [\_SB_.PCI0._INI] > (Node 88012d026920), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.135574] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored > [0.136283] ACPI: SSDT 0xCE789598 000523 (v01 PmRef Cpu0Cst > 3001 INTL 20051117) > [0.138312] ACPI: Dynamic OEM Table Load: > [0.138316] ACPI: SSDT 0x 000523 (v01 PmRef Cpu0Cst > 3001 INTL 20051117) > [0.141483] ACPI: SSDT 0xCE78AA98 000303 (v01 PmRef ApIst > 3000 INTL 20051117) > [0.143683] ACPI: Dynamic OEM Table Load: > [0.143687] ACPI: SSDT 0x 000303 (v01 PmRef ApIst > 3000 INTL 20051117) > [0.146215] ACPI: SSDT 0xCE790C18 000119 (v01 PmRef ApCst > 3000 INTL 20051117) > [0.148279] ACPI: Dynamic OEM Table Load: > [0.148282] ACPI: SSDT 0x 000119 (v01 PmRef ApCst > 3000 INTL 20051117) > [0.152678] ACPI Error: Cannot acquire Mutex for method [SNVC], current > SyncLevel is too large (1) (20140214/dsmethod-362) > [0.152684] ACPI Error: Method parse/execution failed [\SMBF] (Node > 88012d026ec0), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.152693] ACPI Error: Method parse/execution failed [\GENS] (Node > 88012d026e70), AE_AML_MUTEX_ORDER (20140214/psparse-536) > [0.152702] ACPI Error: Method parse/execution failed [\EI
RE: ACPICA 20140214 auto-serialize weirds my machine...
We have a fix for this and will send out a patch next week after additional testing. Thanks, Bob > -Original Message- > From: Moore, Robert > Sent: Friday, March 14, 2014 2:03 PM > To: 'Valdis Kletnieks'; Zheng, Lv; Wysocki, Rafael J; Len Brown > Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org > Subject: RE: ACPICA 20140214 auto-serialize weirds my machine... > > > > > -Original Message- > > From: Valdis Kletnieks [mailto:valdis.kletni...@vt.edu] > > Sent: Friday, March 14, 2014 9:05 AM > > To: Zheng, Lv; Wysocki, Rafael J; Moore, Robert; Len Brown > > Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org > > Subject: ACPICA 20140214 auto-serialize weirds my machine... > > > > Surprisingly enough, this hasn't seemed to have bitten many Linux > > people yet, Google only finds a BSD thread (where the same ACPICA code > > is in > > use): > > > Yes, and the reason that it is rare to see this error is because the > problem is related to the use of the ASL Sync Level mechanism, which is > rarely used. > > Bob > > > > > > > > > http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817 > > > > I found this, but haven't tried it yet: > > > > commit 5f1cb4a92e4c4aabd139ff9ca1e11c0e2db2ac59 > > Author: Lv Zheng > > Date: Wed Feb 26 10:32:01 2014 +0800 > > > > ACPICA: Remove global option to serialize all control methods. > > > > With the addition of the auto-serialization feature, this option > > is obsolete and is completely removed. Lv Zheng. > > > > This patch also updates acpi_serialize kernel parameter using the > > new auto-serialization feature - acpi_gbl_auto_serialize_methods. > > > > This looks like a user nightmare waiting to happen, because: > > > > - acpi_serialize [HW,ACPI] force serialization of AML methods > > + acpi_serialize= [HW,ACPI] configure auto-serialization of AML > > methods > > > > Re-using a kernel parameter name with different semantics is just > > asking for trouble. > > > > I get this in my dmesg, and then I end up with all sorts of > > ACPI-related weirdness - everything from 4 or 5 temperature sensors > > evaporating to it claiming that my laptop doesn't have a battery bay > > (it may also be related to an issue I'm seeing with multiple graphics > > monitors as well, but I haven't verified that yet). > > > > We're going to need a better way to deal with this before it gets to > > mainline > > > > [0.119344] ACPI: Executed 1 blocks of module-level executable AML > code > > [0.135282] ACPI Error: Cannot acquire Mutex for method [SNVC], > current > > SyncLevel is too large (1) (20140214/dsmethod-362) > > [0.135288] ACPI Error: Method parse/execution failed [\SMBF] (Node > > 88012d026ec0), AE_AML_MUTEX_ORDER (20140214/psparse-536) > > [0.135298] ACPI Error: Method parse/execution failed [\GENS] (Node > > 88012d026e70), AE_AML_MUTEX_ORDER (20140214/psparse-536) > > [0.135307] ACPI Error: Method parse/execution failed [\EISC] (Node > > 88012d02d560), AE_AML_MUTEX_ORDER (20140214/psparse-536) > > [0.135320] ACPI Error: Method parse/execution failed > > [\_SB_.PCI0.LPCB.ECDV.ECR1] (Node 88012d02d470), > > AE_AML_MUTEX_ORDER > > (20140214/psparse-536) > > [0.135328] ACPI Error: Method parse/execution failed [\ECRB] (Node > > 88012d02d5d8), AE_AML_MUTEX_ORDER (20140214/psparse-536) > > [0.135336] ACPI Error: Method parse/execution failed [\ECG5] (Node > > 88012d02d740), AE_AML_MUTEX_ORDER (20140214/psparse-536) > > [0.135343] ACPI Error: Method parse/execution failed > > [\_SB_.PCI0.LPCB.EINI] (Node 88012d02db00), AE_AML_MUTEX_ORDER > > (20140214/psparse-536) > > [0.135351] ACPI Error: Method parse/execution failed [\EV3_] (Node > > 88012d0314c0), AE_AML_MUTEX_ORDER (20140214/psparse-536) > > [0.135359] ACPI Error: Method parse/execution failed > [\_SB_.PCI0._INI] > > (Node 88012d026920), AE_AML_MUTEX_ORDER (20140214/psparse-536) > > [0.135574] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored > > [0.136283] ACPI: SSDT 0xCE789598 000523 (v01 PmRef Cpu0Cst > > 3001 INTL 20051117) > > [0.138312] ACPI: Dynamic OEM Table Load: > > [0.138316] ACPI: SSDT 0x 000523 (v01 PmRef Cpu0Cst > > 3001 INTL 20051117) > > [0.141483] ACPI: SSDT 0xCE78AA98 000303 (v01 PmRef ApIst > > 3000 INTL 20051117) >
RE: [Devel] ACPI: Also allow ACPI table adding via initrd not only overriding
acpi_load_table won't work? > -Original Message- > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Thomas > Renninger > Sent: Tuesday, February 18, 2014 10:23 AM > Cc: x...@kernel.org; c...@conrad-kostecki.de; linux-kernel@vger.kernel.org; > mi...@redhat.com; h...@zytor.com; t...@linutronix.de; de...@acpica.org > Subject: [Devel] ACPI: Also allow ACPI table adding via initrd not only > overriding > > The ACPICA patches have to go into separate acpica repository first. > It should also be checked in acpica whether the table signature the OS > likes to add already exists (from BIOS). In this case the table must not > be added. > > Worked here by trying to override a DSDT and addind a BGRT table. > > Thomas > > ___ > Devel mailing list > de...@acpica.org > https://lists.acpica.org/mailman/listinfo/devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Devel] ACPI: Also allow ACPI table adding via initrd not only overriding
Maybe not exactly "running", but at the very least, ACPICA must be initialized. All of this of course depends on how early the table needs to be loaded. > -Original Message- > From: Thomas Renninger [mailto:tr...@suse.de] > Sent: Tuesday, February 18, 2014 10:53 AM > To: Moore, Robert > Cc: x...@kernel.org; c...@conrad-kostecki.de; linux-kernel@vger.kernel.org; > mi...@redhat.com; h...@zytor.com; t...@linutronix.de; de...@acpica.org > Subject: Re: [Devel] ACPI: Also allow ACPI table adding via initrd not > only overriding > > On Tuesday, February 18, 2014 06:38:45 PM Moore, Robert wrote: > > acpi_load_table won't work? > > I guess not, there is: > /* Must acquire the interpreter lock during this operation */ > status = acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER); > > So the interpreter must be running already? > That would mean the adding can only happen much later. > This probably would eleminate most use cases for adding arbitrary ACPI > tables. Most tables (beside DSDT and SSDT) are needed really early, > otherwise the info could have been added as AML as well. > > Thomas > > > > -Original Message- > > > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Thomas > > > Renninger > > > Sent: Tuesday, February 18, 2014 10:23 AM > > > Cc: x...@kernel.org; c...@conrad-kostecki.de; > > > linux-kernel@vger.kernel.org; mi...@redhat.com; h...@zytor.com; > > > t...@linutronix.de; de...@acpica.org > > > Subject: [Devel] ACPI: Also allow ACPI table adding via initrd not > > > only overriding > > > > > > The ACPICA patches have to go into separate acpica repository first. > > > It should also be checked in acpica whether the table signature the > > > OS likes to add already exists (from BIOS). In this case the table > > > must not be added. > > > > > > Worked here by trying to override a DSDT and addind a BGRT table. > > > > > > Thomas > > > > > > ___ > > > Devel mailing list > > > de...@acpica.org > > > https://lists.acpica.org/mailman/listinfo/devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] ACPI / ACPICA: refactor acpi_evaluate_object() to reduce nesting if
Please file a bugzilla on this at:
https://bugs.acpica.org/
thanks.
Bob
> -Original Message-
> From: Hanjun Guo [mailto:hanjun@linaro.org]
> Sent: Friday, January 24, 2014 8:20 AM
> To: Zheng, Lv; Moore, Robert
> Cc: Rafael J. Wysocki; linux-a...@vger.kernel.org; de...@acpica.org;
> patc...@linaro.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; Hanjun Guo
> Subject: [PATCH 1/2] ACPI / ACPICA: refactor acpi_evaluate_object() to
> reduce nesting if
>
> acpi_evaluate_object() has nesting if judgement to make code a little bit
> complicated, refactor it to make things simple.
>
> Signed-off-by: Hanjun Guo
> ---
> drivers/acpi/acpica/nsxfeval.c | 104 +++
> -
> 1 file changed, 50 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/acpi/acpica/nsxfeval.c
> b/drivers/acpi/acpica/nsxfeval.c index 1f0c28b..a1b0b88 100644
> --- a/drivers/acpi/acpica/nsxfeval.c
> +++ b/drivers/acpi/acpica/nsxfeval.c
> @@ -370,68 +370,64 @@ acpi_evaluate_object(acpi_handle handle,
>* If we are expecting a return value, and all went well above,
>* copy the return value to an external object.
>*/
> - if (return_buffer) {
> - if (!info->return_object) {
> - return_buffer->length = 0;
> - } else {
> - if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
> - ACPI_DESC_TYPE_NAMED) {
> - /*
> - * If we received a NS Node as a return object,
> this means that
> - * the object we are evaluating has nothing
> interesting to
> - * return (such as a mutex, etc.) We return an
> error because
> - * these types are essentially unsupported by
> this
> interface.
> - * We don't check up front because this makes it
> easier to add
> - * support for various types at a later date if
> necessary.
> - */
> - status = AE_TYPE;
> - info->return_object = NULL; /* No need to
> delete
> a NS Node */
> - return_buffer->length = 0;
> - }
> + if (!return_buffer)
> + goto out;
>
> - if (ACPI_SUCCESS(status)) {
> + if (!info->return_object) {
> + return_buffer->length = 0;
> + goto out;
> + }
>
> - /* Dereference Index and ref_of references */
> + if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
> + ACPI_DESC_TYPE_NAMED) {
> + /*
> + * If we received a NS Node as a return object, this means
> that
> + * the object we are evaluating has nothing interesting to
> + * return (such as a mutex, etc.) We return an error because
> + * these types are essentially unsupported by this interface.
> + * We don't check up front because this makes it easier to add
> + * support for various types at a later date if necessary.
> + */
> + status = AE_TYPE;
> + info->return_object = NULL; /* No need to delete a NS Node
> */
> + return_buffer->length = 0;
> + }
>
> - acpi_ns_resolve_references(info);
> + if (ACPI_FAILURE(status))
> + goto out;
>
> - /* Get the size of the returned object */
> + /* Dereference Index and ref_of references */
>
> - status =
> - acpi_ut_get_object_size(info->return_object,
> -
> &buffer_space_needed);
> - if (ACPI_SUCCESS(status)) {
> -
> - /* Validate/Allocate/Clear caller
> buffer */
> -
> - status =
> - acpi_ut_initialize_buffer
> - (return_buffer,
> - buffer_space_needed);
> - if (ACPI_FAILURE(status)) {
> - /*
> - * Caller's buffer is too small
> or a
> new one can't
> - * be allocated
> -
RE: [PATCH V2] ACPI/Battery: Add a _BIX quirk for NEC LZ750/LS
If an object does not exist, AE_NOT_FOUND is returned by evaluate_object.
If the package is empty or has insufficient elements, something like
AE_AML_OPERAND_VALUE is returned.
> -Original Message-
> From: Lan, Tianyu
> Sent: Wednesday, January 15, 2014 7:07 AM
> To: Matthew Garrett
> Cc: Rafael J. Wysocki; Dmitry Torokhov; l...@kernel.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; f...@adinet.com.uy;
> l...@dorileo.org; Zheng, Lv; Moore, Robert
> Subject: Re: [PATCH V2] ACPI/Battery: Add a _BIX quirk for NEC LZ750/LS
>
> On 01/15/2014 10:47 PM, Matthew Garrett wrote:
> > On Wed, Jan 15, 2014 at 10:42:31PM +0800, Lan Tianyu wrote:
> >> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index
> >> fbf1ace..e98fa83 100644
> >> --- a/drivers/acpi/battery.c
> >> +++ b/drivers/acpi/battery.c
> >> @@ -770,7 +770,7 @@ static int acpi_battery_add(struct acpi_device
> *device)
> >> device->driver_data = battery;
> >> mutex_init(&battery->lock);
> >> mutex_init(&battery->sysfs_lock);
> >> - if (acpi_has_method(battery->device->handle, "_BIX"))
> >> + if (acpi_evaluate_object(device->handle, "_BIX", NULL,
> >> + &buffer);)
> >> set_bit(ACPI_BATTERY_XINFO_PRESENT,
> >> &battery->flags);
> >
> > Doesn't acpi_evaluate_object() return 0 on success? I think:
> >
> > if (ACPI_SUCESS(acpi_evaluate_object(device->handle, "_BIX", NULL,
> > &buffer))
> >
>
> Yes, Sorry for oops.
>
> > But maybe we should check for existence first and give an FW_BUG
> > message to indicate an invalid _BIX?
>
> Yes, this is a good idea.
>
> Another point, the acpi_evaluate_object should return different error code
> for these two cases(no _BIX and wrong size.). I wonder whether we can use
> the error code to determine it belong which case?
> >
>
>
> --
> Best Regards
> Tianyu Lan
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 4/5] ACPICA: Introduce acpi_enable_all_wakeup_gpes()
If you need it, sure.
Let me know when there is an ACPICA version
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Monday, September 29, 2014 5:26 PM
> To: ACPI Devel Maling List; Moore, Robert
> Cc: Linux Kernel Mailing List; Zhang, Rui; Linux PM list
> Subject: [PATCH 4/5] ACPICA: Introduce acpi_enable_all_wakeup_gpes()
>
> From: Rafael J. Wysocki
>
> Add a routine for host OSes to enable all wakeup GPEs and disable all of
> the non-wakeup ones at the same time.
>
> It will be used for the handling of GPE wakeup from suspend-to-idle in
> Linux.
>
> Signed-off-by: Rafael J. Wysocki
> ---
>
> Bob, please let me know if I can fast-track this one.
>
> ---
> drivers/acpi/acpica/evxfgpe.c | 32
> include/acpi/acpixf.h |1 +
> 2 files changed, 33 insertions(+)
>
> Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> ===
> --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> @@ -596,6 +596,38 @@ acpi_status acpi_enable_all_runtime_gpes
>
> ACPI_EXPORT_SYMBOL(acpi_enable_all_runtime_gpes)
>
> +/**
> +
> + *
> + * FUNCTION:acpi_enable_all_wakeup_gpes
> + *
> + * PARAMETERS: None
> + *
> + * RETURN: Status
> + *
> + * DESCRIPTION: Enable all "wakeup" GPEs and disable all of the other
> GPEs, in
> + * all GPE blocks.
> + *
> +
> +***
> +***/
> +
> +acpi_status acpi_enable_all_wakeup_gpes(void) {
> + acpi_status status;
> +
> + ACPI_FUNCTION_TRACE(acpi_enable_all_wakeup_gpes);
> +
> + status = acpi_ut_acquire_mutex(ACPI_MTX_EVENTS);
> + if (ACPI_FAILURE(status)) {
> + return_ACPI_STATUS(status);
> + }
> +
> + status = acpi_hw_enable_all_wakeup_gpes();
> + (void)acpi_ut_release_mutex(ACPI_MTX_EVENTS);
> +
> + return_ACPI_STATUS(status);
> +}
> +
> +ACPI_EXPORT_SYMBOL(acpi_enable_all_wakeup_gpes)
> +
>
> /*
> **
> *
> * FUNCTION:acpi_install_gpe_block
> Index: linux-pm/include/acpi/acpixf.h
> ===
> --- linux-pm.orig/include/acpi/acpixf.h
> +++ linux-pm/include/acpi/acpixf.h
> @@ -692,6 +692,7 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_sta
>*event_status))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_disable_all_gpes(void))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_runtime_gpes(void))
> +ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> +acpi_enable_all_wakeup_gpes(void))
>
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_get_gpe_device(u32 gpe_index,
RE: [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method
Since what is returned by this interface is essentially a piece of information
about the particular GPE, I think that it might be better to generalize this
interface to a "GetInfo" type of interface that returns a few pieces of
information about the GPE.
> -Original Message-
> From: Lan, Tianyu
> Sent: Monday, July 07, 2014 11:58 PM
> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org
> Cc: Lan, Tianyu; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE
> method
>
> This patch is to expose acpi_check_gpe_method() to check whether there is
> a GPE method for the given gpe. Enabling ACPI button devices' gpes will
> depend on the new function's result.
>
> Signed-off-by: Lan Tianyu
> ---
> drivers/acpi/acpica/evxface.c | 39
> ++-
> include/acpi/acpixf.h | 3 +++
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c
> index 11e5803..0fcb248 100644
> --- a/drivers/acpi/acpica/evxface.c
> +++ b/drivers/acpi/acpica/evxface.c
> @@ -717,6 +717,44 @@ ACPI_EXPORT_SYMBOL(acpi_remove_fixed_event_handler)
>
>
> /*
> **
> *
> + * FUNCTION:acpi_check_gpe_method
> + *
> + * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for
> FADT
> + *defined GPEs)
> + * gpe_number - The event to remove a handler
> + *
> + * RETURN: Status
> + *
> + * DESCRIPTION: Check whether the given GPE has associated event method.
> + *
> +
> +***
> +***/
> +acpi_status
> +acpi_check_gpe_method(acpi_handle gpe_device, u32 gpe_number) {
> + struct acpi_gpe_event_info *gpe_event_info;
> + acpi_status status = AE_NOT_EXIST;
> + acpi_cpu_flags flags;
> +
> + ACPI_FUNCTION_TRACE(acpi_check_gpe_method);
> +
> + flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
> + if (!gpe_event_info) {
> + status = AE_ERROR;
> + goto unlock_and_exit;
> + }
> +
> + if (gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD)
> + status = AE_OK;
> +
> +unlock_and_exit:
> + acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
> + return status;
> +}
> +ACPI_EXPORT_SYMBOL(acpi_check_gpe_method)
> +
> +/**
> +*
> + *
> * FUNCTION:acpi_install_gpe_handler
> *
> * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for
> FADT
> @@ -821,7 +859,6 @@ free_and_exit:
> ACPI_FREE(handler);
> goto unlock_and_exit;
> }
> -
> ACPI_EXPORT_SYMBOL(acpi_install_gpe_handler)
>
>
> /*
> **
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index
> 35b525c..5b475c6 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -554,6 +554,9 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> address,
> void *context))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> + acpi_check_gpe_method(acpi_handle gpe_device,
> + u32 gpe_number))
> +ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
>acpi_remove_gpe_handler(acpi_handle gpe_device,
>u32 gpe_number,
>acpi_gpe_handler
> --
> 1.8.4.rc0.1.g8f6a3e5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 05/11] drivers: acpi: Include appropriate header file in utstate.c
I'm not sure what version of ACPICA you are looking at, but in the master git
tree for ACPICA, the file accommon.h includes "acutils.h".
> -Original Message-
> From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
> Sent: Tuesday, December 17, 2013 1:22 AM
> To: linux-kernel@vger.kernel.org
> Cc: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown; linux-
> a...@vger.kernel.org; j...@joshtriplett.org; de...@acpica.org
> Subject: [PATCH 05/11] drivers: acpi: Include appropriate header file in
> utstate.c
>
> Include appropriate header file acutils.h in acpica/utstate.c because
> function acpi_ut_create_pkg_state_and_push() has its prototype declaration
> in acutils.h. Also, encloses the function in acpica/utstate.c in ifdef
> condition of ACPI_FUTURE_USAGE.
>
> This eliminates the following warning in utstate.c:
> drivers/acpi/acpica/utstate.c:64:1: warning: no previous prototype for
> ‘acpi_ut_create_pkg_state_and_push’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
> Reviewed-by: Josh Triplett
> ---
> drivers/acpi/acpica/utstate.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/acpi/acpica/utstate.c b/drivers/acpi/acpica/utstate.c
> index 03c4c2f..0920d23 100644
> --- a/drivers/acpi/acpica/utstate.c
> +++ b/drivers/acpi/acpica/utstate.c
> @@ -43,6 +43,7 @@
>
> #include
> #include "accommon.h"
> +#include "acutils.h"
>
> #define _COMPONENT ACPI_UTILITIES
> ACPI_MODULE_NAME("utstate")
> @@ -60,6 +61,7 @@ ACPI_MODULE_NAME("utstate")
> * DESCRIPTION: Create a new state and push it
> *
>
> **
> /
> +#ifdef ACPI_FUTURE_USAGE
> acpi_status
> acpi_ut_create_pkg_state_and_push(void *internal_object,
> void *external_object,
> @@ -79,6 +81,7 @@ acpi_ut_create_pkg_state_and_push(void *internal_object,
> acpi_ut_push_generic_state(state_list, state);
> return (AE_OK);
> }
> +#endif
>
>
> /*
> **
> *
> --
> 1.7.9.5
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v2 05/18] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
I should warn you that FADT version numbers are notoriously unreliable; In
fact, in ACPICA we were eventually forced to abandon them entirely. We use the
actual size of the FADT instead.
Bob
> -Original Message-
> From: Hanjun Guo [mailto:hanjun@linaro.org]
> Sent: Tuesday, August 19, 2014 5:14 AM
> To: Mark Rutland
> Cc: Catalin Marinas; Rafael J. Wysocki; graeme.greg...@linaro.org; Arnd
> Bergmann; Olof Johansson; grant.lik...@linaro.org; Sudeep Holla; Will
> Deacon; Jason Cooper; Marc Zyngier; Bjorn Helgaas; Daniel Lezcano; Mark
> Brown; Rob Herring; Robert Richter; Zheng, Lv; Moore, Robert; Lorenzo
> Pieralisi; Liviu Dudau; Randy Dunlap; Charles Garcia-Tobin; linux-
> a...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linaro-a...@lists.linaro.org
> Subject: Re: [PATCH v2 05/18] ARM64 / ACPI: Parse FADT table to get PSCI
> flags for PSCI init
>
> On 2014-8-19 19:10, Mark Rutland wrote:
> >>>> @@ -47,6 +49,26 @@ void __init __acpi_unmap_table(char *map, unsigned
> long size)
> >>>> early_memunmap(map, size);
> >>>> }
> >>>>
> >>>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> >>>> +{
> >>>> +struct acpi_table_fadt *fadt = (struct acpi_table_fadt
> *)table;
> >>>> +
> >>>> +/*
> >>>> + * Revision in table header is the FADT Major version,
> >>>> + * and there is a minor version of FADT which was introduced
> >>>> + * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> >>>> + * to get arm boot flags, or we will disable ACPI.
> >>>> + */
> >>>> +if (table->revision < 5 || fadt->minor_revision < 1) {
> >>>
> >>> If we ever get revision 6.0, this would trigger.
> >>
> >> Yes, good catch, actually I already fixed that in my local git repo,
> >>
> >> + if (table->revision > 5 ||
> >> + (table->revision == 5 && fadt->minor_revision >= 1)) {
> >> + return 0;
> >> + } else {
> >> + pr_info("FADT revision is %d.%d, no PSCI support,
> >> + should be 5.1
> >> or higher\n",
> >> + table->revision, fadt->minor_revision);
> >> + disable_acpi();
> >> + return -EINVAL;
> >> + }
> >
> > Given you return in the first path, you don't need the remaining code
> > to live in an else block.
>
> Agreed, I will update it, and move disable_acpi() outside this function
> and keep it in one place as Sudeep suggested.
>
> Thanks
> Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition
I don’t have any problem changing this in ACPICA if/when you all agree.
> -Original Message-
> From: Toshi Kani [mailto:toshi.k...@hp.com]
> Sent: Wednesday, August 26, 2015 4:36 PM
> To: Rafael J. Wysocki
> Cc: Williams, Dan J; Wysocki, Rafael J; Moore, Robert; linux-
> nvd...@lists.01.org; Linux ACPI; linux-kernel@vger.kernel.org; Elliott,
> Robert (Server Storage)
> Subject: Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition
>
> On Wed, 2015-08-26 at 17:29 -0600, Toshi Kani wrote:
> > On Thu, 2015-08-27 at 01:16 +0200, Rafael J. Wysocki wrote:
> > > On Wed, Aug 26, 2015 at 11:12 PM, Toshi Kani
> wrote:
> > > > On Wed, 2015-08-26 at 10:16 -0700, Dan Williams wrote:
> > > > > On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani
> > > > > wrote:
> > > > > > ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines
> > > > > > bit 3 as follows.
> > > > > >
> > > > > > Bit [3] set to 1 to indicate that the Memory Device is
> observed
> > > > > > to be not armed prior to OSPM hand off. A Memory Device is
> > > > > > considered armed if it is able to accept persistent writes.
> > > > > >
> > > > > > This bit is currently defined as ACPI_NFIT_MEM_ARMED, which
> > > > > > can be confusing as if the Memory Device is armed when this bit
> is set.
> > > > > >
> > > > > > Change the name to ACPI_NFIT_MEM_NOT_ARMED per the spec.
> > > > > >
> > > > > > Signed-off-by: Toshi Kani
> > > > > > Cc: Dan Williams
> > > > > > Cc: Bob Moore
> > > > > > Cc: Rafael J. Wysocki
> > > > > > ---
> > > > > > drivers/acpi/nfit.c |6 +++---
> > > > > > drivers/acpi/nfit.h |2 +-
> > > > > > include/acpi/actbl1.h|2 +-
> > > > >
> > > > > This file "include/acpi/actbl1.h" is owned by the ACPICA project
> > > > > so any changes need to come through them. But that said, I'm
> > > > > not sure we need friendly names at this level.
> > > >
> > > > I think the name is misleading, but I agree with the process and
> > > > this
> > > > patch2 can be dropped. It'd be nice if the ACPICA project can
> > > > pick it up later when they have a chance, though.
> > >
> > > A good way to cause that to happen would be to send a patch to the
> > > ACPICA development list + maintainers as per MAINTAINERS.
> >
> > Oh, I see. I did run get_maintainer.pl for this patch, but
> > de...@acpica.org did not come out in output... So, I did not realize
> > this email list.
>
> Sorry, it was listed in the output. I was simply blinded... :-(
>
> $ scripts/get_maintainer.pl patches-nd-flags/02*
> :
> linux-nvd...@lists.01.org (open list:LIBNVDIMM BLK: MMIO-APERTURE DRIVER)
> linux-a...@vger.kernel.org (open list:ACPI) linux-kernel@vger.kernel.org
> (open list) de...@acpica.org (open list:ACPI COMPONENT ARCHITECTURE
> (ACPICA))
>
> Thanks!
> -Toshi
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v2] acpi: Use kstrtoul() instead of strtoul()/simple_strtoul()
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: Monday, July 27, 2015 5:32 PM
> To: r...@rjwysocki.net
> Cc: l...@kernel.org; Moore, Robert; Zheng, Lv; linux-a...@vger.kernel.org;
> linux-kernel@vger.kernel.org; de...@acpica.org; Guenter Roeck
> Subject: [PATCH v2] acpi: Use kstrtoul() instead of
> strtoul()/simple_strtoul()
>
> simple_strtoul() is deprecated; replace with kstrtoul() and kstrtouint().
The ACPICA code is os-independent and cannot use these functions (at least not
directly).
> Return an error if the value passed to the sysfs attribute is not a
> number.
>
> Drop the definition of strtoul() since it is no longer needed.
>
> Signed-off-by: Guenter Roeck
> ---
> v2: An additional use of strtoul() was introduced with commit 4fa4616e.
> Replace it as well.
>
> drivers/acpi/acpica/evgpeinit.c | 5 +++--
> drivers/acpi/sysfs.c| 8 ++--
> include/acpi/platform/aclinux.h | 1 -
> 3 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/acpica/evgpeinit.c
> b/drivers/acpi/acpica/evgpeinit.c index ea4c0d3fca2d..aa1e8c1f2d4a 100644
> --- a/drivers/acpi/acpica/evgpeinit.c
> +++ b/drivers/acpi/acpica/evgpeinit.c
> @@ -326,6 +326,7 @@ acpi_ev_match_gpe_method(acpi_handle obj_handle,
> u32 gpe_number;
> char name[ACPI_NAME_SIZE + 1];
> u8 type;
> + int err;
>
> ACPI_FUNCTION_TRACE(ev_match_gpe_method);
>
> @@ -377,8 +378,8 @@ acpi_ev_match_gpe_method(acpi_handle obj_handle,
>
> /* 4) The last two characters of the name are the hex GPE Number */
>
> - gpe_number = strtoul(&name[2], NULL, 16);
> - if (gpe_number == ACPI_UINT32_MAX) {
> + er = kstrtouint(&name[2], 16, &gpe_number);
> + if (err < 0 || gpe_number == ACPI_UINT32_MAX) {
>
> /* Conversion failed; invalid method, just ignore it */
>
> diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index
> 0876d77b3206..d6ea5712ec57 100644
> --- a/drivers/acpi/sysfs.c
> +++ b/drivers/acpi/sysfs.c
> @@ -616,8 +616,12 @@ static ssize_t counter_set(struct kobject *kobj,
> all_counters[index].count = tmp;
> else
> result = -EINVAL;
> - } else
> - all_counters[index].count = strtoul(buf, NULL, 0);
> + } else {
> + if (!kstrtoul(buf, 0, &tmp))
> + all_counters[index].count = tmp;
> + else
> + result = -EINVAL;
> + }
>
> if (ACPI_FAILURE(result))
> result = -EINVAL;
> diff --git a/include/acpi/platform/aclinux.h
> b/include/acpi/platform/aclinux.h index 74ba46c8157a..9925c1d5d58f 100644
> --- a/include/acpi/platform/aclinux.h
> +++ b/include/acpi/platform/aclinux.h
> @@ -119,7 +119,6 @@
>
> #define ACPI_MACHINE_WIDTH BITS_PER_LONG
> #define ACPI_EXPORT_SYMBOL(symbol) EXPORT_SYMBOL(symbol);
> -#define strtoul simple_strtoul
>
> #define acpi_cache_tstruct kmem_cache
> #define acpi_spinlock spinlock_t *
> --
> 2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] acpi: Use kstrtoul() instead of strtoul()/simple_strtoul()
> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Wednesday, July 29, 2015 11:39 AM > To: Moore, Robert; r...@rjwysocki.net > Cc: l...@kernel.org; Zheng, Lv; linux-a...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@acpica.org > Subject: Re: [PATCH v2] acpi: Use kstrtoul() instead of > strtoul()/simple_strtoul() > > On 07/29/2015 10:51 AM, Moore, Robert wrote: > > > > > >> -Original Message- > >> From: Guenter Roeck [mailto:li...@roeck-us.net] > >> Sent: Monday, July 27, 2015 5:32 PM > >> To: r...@rjwysocki.net > >> Cc: l...@kernel.org; Moore, Robert; Zheng, Lv; > >> linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; > >> de...@acpica.org; Guenter Roeck > >> Subject: [PATCH v2] acpi: Use kstrtoul() instead of > >> strtoul()/simple_strtoul() > >> > >> simple_strtoul() is deprecated; replace with kstrtoul() and > kstrtouint(). > > > > The ACPICA code is os-independent and cannot use these functions (at > least not directly). > > > > > Odd argument, given that kstrtoul() is used already in the acpi code. They are not in the os-independent ACPICA code. The ACPI-related drivers are another story, since they are OS-dendent. > > Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpi/acpica: fix Thunderbolt hotplug
Lv is looking at it. He has already commented that this might not be the best
solution, so he is continuing to investigate.
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Friday, April 15, 2016 12:40 AM
> To: Prarit Bhargava
> Cc: linux-kernel@vger.kernel.org; Moore, Robert; Zheng, Lv; Wysocki,
> Rafael J; Len Brown; linux-a...@vger.kernel.org; de...@acpica.org
> Subject: Re: [PATCH] acpi/acpica: fix Thunderbolt hotplug
>
> Bob, Rafael, any comments about this?
>
> This seems to solve a real issue with Thunderbolt hotplug on Dell XPS
> laptops. I do not know ACPICA that well to tell if this is 100% correct
> fix but many reporters say it fixes the problem they are facing:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=115121
>
> On Tue, Mar 29, 2016 at 06:45:40PM -0400, Prarit Bhargava wrote:
> > The following hung task trace is seen when hotplugging an ethernet
> > dongle in a Thunderbolt port on Linux.
> >
> > INFO: task kworker/0:4:1468 blocked for more than 120 seconds.
> > Tainted: GW 4.6.0-rc1+ #1
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message.
> > kworker/0:4 D 8802a265ba38 13344 1468 2 0x
> > Workqueue: kacpid acpi_os_execute_deferred
> > 8802a265ba38 8802a265ba00 81130200 81e0d580
> > 88029e5eb340 8802a265c000 88029d69d000 88029e5eb340
> > 818c1b8d 8802b64e8758 8802a265ba50 818bdfcc
> > Call Trace:
> > [] ? test_callback+0x10/0x30 []
> > ? __down_timeout+0x5d/0xd0 [] schedule+0x3c/0x90
> > [] schedule_timeout+0x210/0x360
> > [] ? sched_clock+0x9/0x10 [] ?
> > local_clock+0x1c/0x20 [] ?
> > mark_held_locks+0x76/0xa0 [] ?
> > _raw_spin_unlock_irq+0x2c/0x40 [] ?
> > __down_timeout+0x5d/0xd0 [] ?
> > trace_hardirqs_on_caller+0xf5/0x1b0
> > [] ? __down_timeout+0x5d/0xd0 []
> > __down_timeout+0x7c/0xd0 [] ?
> > _raw_spin_lock_irqsave+0x82/0x90 []
> > down_timeout+0x4c/0x60 []
> > acpi_os_wait_semaphore+0xaa/0x16a []
> > acpi_ex_system_wait_mutex+0x81/0xfa
> > [] acpi_ds_begin_method_execution+0x25a/0x373
> > [] acpi_ds_call_control_method+0x107/0x2e0
> > [] acpi_ps_parse_aml+0x177/0x495
> > [] acpi_ps_execute_method+0x1f7/0x2b9
> > [] acpi_ns_evaluate+0x2ee/0x435
> > [] acpi_ev_asynch_execute_gpe_method+0xbd/0x159
> > [] acpi_os_execute_deferred+0x17/0x23
> > [] process_one_work+0x242/0x700
> > [] ? process_one_work+0x1ba/0x700
> > [] worker_thread+0x4e/0x490 [] ?
> > process_one_work+0x700/0x700 [] ?
> > process_one_work+0x700/0x700 [] kthread+0x101/0x120
> > [] ? trace_hardirqs_on_caller+0xf5/0x1b0
> > [] ret_from_fork+0x22/0x50 [] ?
> > kthread_create_on_node+0x250/0x250
> > 2 locks held by kworker/0:4/1468:
> > #0: ("kacpid"){.+.+.+}, at: []
> > process_one_work+0x1ba/0x700
> > #1: ((&dpc->work)){+.+.+.}, at: []
> > process_one_work+0x1ba/0x700
> >
> > The issue appears to be that the kworker thread attempts to acquire
> > the
> > _E42 method's mutex twice when executing acpi_ps_execute_method() and
> > recursing through the entry method.
> >
> > The current code does take the possiblity of this recursion into
> > account, however, it is only for the case where the walk_state has been
> populated.
> >
> > This can be fixed by setting the thread id in the !walk_state case to
> > allow for recursion.
> >
> > Cc: Robert Moore
> > Cc: Lv Zheng
> > Cc: "Rafael J. Wysocki"
> > Cc: Len Brown
> > Cc: linux-a...@vger.kernel.org
> > Cc: de...@acpica.org
> > Signed-off-by: Prarit Bhargava
> > ---
> > drivers/acpi/acpica/dsmethod.c |3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/acpi/acpica/dsmethod.c
> > b/drivers/acpi/acpica/dsmethod.c index 1982310..93799db 100644
> > --- a/drivers/acpi/acpica/dsmethod.c
> > +++ b/drivers/acpi/acpica/dsmethod.c
> > @@ -428,6 +428,9 @@ acpi_ds_begin_method_execution(struct
> acpi_namespace_node *method_node,
> > obj_desc->method.mutex->mutex.
> > original_sync_level =
> > obj_desc->method.mutex->mutex.sync_level;
> > +
> > + obj_desc->method.mutex->mutex.thread_id =
> > + acpi_os_get_thread_id();
> > }
> > }
> >
> > --
> > 1.7.9.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] acpi/acpica: fix Thunderbolt hotplug
Internal discussion. Given the urgency, we've decided to take the patch. Bob > -Original Message- > From: Prarit Bhargava [mailto:pra...@redhat.com] > Sent: Friday, April 15, 2016 10:03 AM > To: Moore, Robert; Mika Westerberg > Cc: linux-kernel@vger.kernel.org; Zheng, Lv; Wysocki, Rafael J; Len Brown; > linux-a...@vger.kernel.org; de...@acpica.org > Subject: Re: [PATCH] acpi/acpica: fix Thunderbolt hotplug > > > > On 04/15/2016 12:21 PM, Moore, Robert wrote: > > Lv is looking at it. He has already commented that this might not be the > best solution, so he is continuing to investigate. > > > > /me scratches head > > Where was that comment made? > > P.
RE: [PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this version of ACPI spec
> -Original Message-
> From: Abdulhamid, Harb [mailto:ha...@codeaurora.org]
> Sent: Saturday, February 20, 2016 1:41 PM
> To: Zheng, Lv; Wysocki, Rafael J; Rafael J. Wysocki; Brown, Len
> Cc: Lv Zheng; linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org;
> Moore, Robert; Al Stone; fu@linaro.org; tbai...@codeaurora.org;
> rruig...@codeaurora.org
> Subject: Re: [PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this
> version of ACPI spec
>
> On 2/19/2016 1:17 AM, Lv Zheng wrote:
> > From: Bob Moore
> >
> > ACPICA commit 5f21bddaa2cec035ca80608803ce2f0858d4f387
> >
> > Small changes:
> > 1) A couple new predefined names
> > 2) New _HID values
> I don't see where you are adding new _HID values in this patch.
>
Not everything in the patch actually makes it into the Linux kernel. The new
_HID values are for the AcpiHelp tables, which in turn are also used by the
disassembler.
> > 3) New subtable for HEST
> >
> > Link: https://github.com/acpica/acpica/commit/5f21bdda
> > Signed-off-by: Bob Moore
> > Signed-off-by: Lv Zheng
> > ---
> > drivers/acpi/acpica/acpredef.h |9 +
> > drivers/acpi/acpica/utdecode.c | 30 +-
> > include/acpi/actbl.h |2 +-
> > include/acpi/actbl1.h | 29 ++---
> > include/acpi/actypes.h |3 ++-
> > 5 files changed, 55 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/acpredef.h
> > b/drivers/acpi/acpica/acpredef.h index 5faeab4..4ca426b 100644
> > --- a/drivers/acpi/acpica/acpredef.h
> > +++ b/drivers/acpi/acpica/acpredef.h
> > @@ -523,6 +523,9 @@ const union acpi_predefined_info
> acpi_gbl_predefined_methods[] = {
> > METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (4 Int) */
> > PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 4, 0, 0, 0),
> >
> > + {{"_FIT", METHOD_0ARGS,
> > + METHOD_RETURNS(ACPI_RTYPE_BUFFER)}}, /* ACPI 6.0 */
> > +
> > {{"_FIX", METHOD_0ARGS,
> > METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Ints)
> */
> > PACKAGE_INFO(ACPI_PTYPE1_VAR, ACPI_RTYPE_INTEGER, 0, 0, 0, 0), @@
> > -1053,6 +1056,12 @@ const union acpi_predefined_info
> acpi_gbl_predefined_methods[] = {
> > METHOD_RETURNS(ACPI_RTYPE_INTEGER | ACPI_RTYPE_STRING |
> > ACPI_RTYPE_BUFFER)}},
> >
> > + {{"_WPC", METHOD_0ARGS,
> > + METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> > +
> > + {{"_WPP", METHOD_0ARGS,
> > + METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> > +
> > PACKAGE_INFO(0, 0, 0, 0, 0, 0) /* Table terminator */
> > };
> > #else
> > diff --git a/drivers/acpi/acpica/utdecode.c
> > b/drivers/acpi/acpica/utdecode.c index 6ba65b0..efd7988 100644
> > --- a/drivers/acpi/acpica/utdecode.c
> > +++ b/drivers/acpi/acpica/utdecode.c
> > @@ -446,7 +446,7 @@ const char *acpi_ut_get_mutex_name(u32 mutex_id)
> >
> > /* Names for Notify() values, used for debug output */
> >
> > -static const char *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
> > +static const char *acpi_gbl_generic_notify[ACPI_GENERIC_NOTIFY_MAX +
> > +1] = {
> > /* 00 */ "Bus Check",
> > /* 01 */ "Device Check",
> > /* 02 */ "Device Wake",
> > @@ -459,49 +459,53 @@ static const char
> *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
> > /* 09 */ "Device PLD Check",
> > /* 0A */ "Reserved",
> > /* 0B */ "System Locality Update",
> > - /* 0C */ "Shutdown Request",
> > + /* 0C */ "Shutdown Request",
> > + /* Reserved in ACPI 6.0 */
> > /* 0D */ "System Resource Affinity Update"
> > };
> >
> > -static const char *acpi_gbl_device_notify[4] = {
> > +static const char *acpi_gbl_device_notify[5] = {
> > /* 80 */ "Status Change",
> > /* 81 */ "Information Change",
> > /* 82 */ "Device-Specific Change",
> > - /* 83 */ "Device-Specific Change"
> > + /* 83 */ "Device-Specific Change",
> > + /* 84 */ "Reserved"
> > };
> >
> > -static const char *acpi_gbl_processor_notify[4] = {
> > +static const char *acpi_gbl_processor_notify[5] = {
> > /* 80 */ "Performance Capability Change",
> > /* 81 */ "C-State Chan
RE: [PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this version of ACPI spec
Yes, looks like we missed the revision update for the generic update.
We will update the actbl1.h file
Thanks,
Bob
> -Original Message-
> From: Abdulhamid, Harb [mailto:ha...@codeaurora.org]
> Sent: Saturday, February 20, 2016 1:41 PM
> To: Zheng, Lv; Wysocki, Rafael J; Rafael J. Wysocki; Brown, Len
> Cc: Lv Zheng; linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org;
> Moore, Robert; Al Stone; fu@linaro.org; tbai...@codeaurora.org;
> rruig...@codeaurora.org
> Subject: Re: [PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this
> version of ACPI spec
>
> On 2/19/2016 1:17 AM, Lv Zheng wrote:
> > From: Bob Moore
> >
> > ACPICA commit 5f21bddaa2cec035ca80608803ce2f0858d4f387
> >
> > Small changes:
> > 1) A couple new predefined names
> > 2) New _HID values
> I don't see where you are adding new _HID values in this patch.
>
> > 3) New subtable for HEST
> >
> > Link: https://github.com/acpica/acpica/commit/5f21bdda
> > Signed-off-by: Bob Moore
> > Signed-off-by: Lv Zheng
> > ---
> > drivers/acpi/acpica/acpredef.h |9 +
> > drivers/acpi/acpica/utdecode.c | 30 +-
> > include/acpi/actbl.h |2 +-
> > include/acpi/actbl1.h | 29 ++---
> > include/acpi/actypes.h |3 ++-
> > 5 files changed, 55 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/acpredef.h
> > b/drivers/acpi/acpica/acpredef.h index 5faeab4..4ca426b 100644
> > --- a/drivers/acpi/acpica/acpredef.h
> > +++ b/drivers/acpi/acpica/acpredef.h
> > @@ -523,6 +523,9 @@ const union acpi_predefined_info
> acpi_gbl_predefined_methods[] = {
> > METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (4 Int) */
> > PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 4, 0, 0, 0),
> >
> > + {{"_FIT", METHOD_0ARGS,
> > + METHOD_RETURNS(ACPI_RTYPE_BUFFER)}}, /* ACPI 6.0 */
> > +
> > {{"_FIX", METHOD_0ARGS,
> > METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Ints)
> */
> > PACKAGE_INFO(ACPI_PTYPE1_VAR, ACPI_RTYPE_INTEGER, 0, 0, 0, 0), @@
> > -1053,6 +1056,12 @@ const union acpi_predefined_info
> acpi_gbl_predefined_methods[] = {
> > METHOD_RETURNS(ACPI_RTYPE_INTEGER | ACPI_RTYPE_STRING |
> > ACPI_RTYPE_BUFFER)}},
> >
> > + {{"_WPC", METHOD_0ARGS,
> > + METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> > +
> > + {{"_WPP", METHOD_0ARGS,
> > + METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> > +
> > PACKAGE_INFO(0, 0, 0, 0, 0, 0) /* Table terminator */
> > };
> > #else
> > diff --git a/drivers/acpi/acpica/utdecode.c
> > b/drivers/acpi/acpica/utdecode.c index 6ba65b0..efd7988 100644
> > --- a/drivers/acpi/acpica/utdecode.c
> > +++ b/drivers/acpi/acpica/utdecode.c
> > @@ -446,7 +446,7 @@ const char *acpi_ut_get_mutex_name(u32 mutex_id)
> >
> > /* Names for Notify() values, used for debug output */
> >
> > -static const char *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
> > +static const char *acpi_gbl_generic_notify[ACPI_GENERIC_NOTIFY_MAX +
> > +1] = {
> > /* 00 */ "Bus Check",
> > /* 01 */ "Device Check",
> > /* 02 */ "Device Wake",
> > @@ -459,49 +459,53 @@ static const char
> *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
> > /* 09 */ "Device PLD Check",
> > /* 0A */ "Reserved",
> > /* 0B */ "System Locality Update",
> > - /* 0C */ "Shutdown Request",
> > + /* 0C */ "Shutdown Request",
> > + /* Reserved in ACPI 6.0 */
> > /* 0D */ "System Resource Affinity Update"
> > };
> >
> > -static const char *acpi_gbl_device_notify[4] = {
> > +static const char *acpi_gbl_device_notify[5] = {
> > /* 80 */ "Status Change",
> > /* 81 */ "Information Change",
> > /* 82 */ "Device-Specific Change",
> > - /* 83 */ "Device-Specific Change"
> > + /* 83 */ "Device-Specific Change",
> > + /* 84 */ "Reserved"
> > };
> >
> > -static const char *acpi_gbl_processor_notify[4] = {
> > +static const char *acpi_gbl_processor_notify[5] = {
> > /* 80 */ "Performance Capability Change",
> > /* 81 */ "C-State Change",
> > /* 82 */ "Throttling Capabil
RE: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
I've got these for the next release of ACPICA
> -Original Message-
> From: Aleksey Makarov [mailto:aleksey.maka...@linaro.org]
> Sent: Wednesday, February 24, 2016 9:10 AM
> To: linux-a...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Aleksey Makarov; Russell King; Greg Kroah-
> Hartman; Rafael J . Wysocki; Leif Lindholm; Graeme Gregory; Al Stone;
> Christopher Covington; Len Brown; Moore, Robert; Zheng, Lv;
> de...@acpica.org
> Subject: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
>
> The recent version of Microsoft Debug Port Table 2 (DBG2) [1] specifies
> additional serial debug port subtypes. These constants are also referred
> by Serial Port Console Redirection Table (SPCR) [2]
>
> Add these constants.
>
> [1] https://msdn.microsoft.com/en-
> us/library/windows/hardware/dn639131(v=vs.85).aspx
> [2] https://msdn.microsoft.com/en-
> us/library/windows/hardware/dn639132(v=vs.85).aspx
>
> Signed-off-by: Aleksey Makarov
> ---
> include/acpi/actbl2.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
> a4ef625..652f747 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -371,6 +371,11 @@ struct acpi_dbg2_device {
>
> #define ACPI_DBG2_16550_COMPATIBLE 0x
> #define ACPI_DBG2_16550_SUBSET 0x0001
> +#define ACPI_DBG2_ARM_PL011 0x0003
> +#define ACPI_DBG2_ARM_SBSA_32BIT0x000D
> +#define ACPI_DBG2_ARM_SBSA_GENERIC 0x000E
> +#define ACPI_DBG2_ARM_DCC 0x000F
> +#define ACPI_DBG2_BCM2835 0x0010
>
> #define ACPI_DBG2_1394_STANDARD 0x
>
> --
> 2.7.1
RE: [PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this version of ACPI spec
> There are few things I see missing in this patch in your updates made to
> actbl1.h, I list them below:
>
> 1) Adding time stamp as you did breaks backwards compatibility (something
> we discovered during our testing). We tried to remedy this by adding a
> new version of the acpi_hest_generic_data structure. Note that we named
> it v3 to reflect this was the updated version number in ACPI 6.1. (see
> https://lkml.org/lkml/2016/2/5/549)
I used V300 in case there is ever some other 3xx version.
Plus, I made a full struct for the V300 case.
>
> 2) Missing definition of generic error data validation bits, needed to
> determine whether or not field being read are valid or not (see
> https://lkml.org/lkml/2016/2/5/549)
Done.
>
> 3) Need to extend acpi_hest_notify_types to add GPIO, SEA, SEI, and GSIV
> (see https://lkml.org/lkml/2016/2/5/545)
Done.
>
> 4) Also for the purpose of backwards compatibility, we needed to add both
> acpi_hest_generic and acpi_hest_generic_v2 to the structure "ghes",
> referencing the v2 pointer when needed.
> (https://lkml.org/lkml/2016/2/5/550)
This doesn't affect the ACPICA code (actbl1.h), I don't think.
>
> Can you please review the above patch series patches for comparison, and
> if in agreement, can you please update this patch to better align with the
> changes we need? We can rework our patch series to depend on your patch
> series (i.e. leaving actbl1.h untouched on our side).
>
> >
> >
> > /*
> > ** @@ -1015,6 +1037,7 @@ struct acpi_nfit_memory_map {
> > #define ACPI_NFIT_MEM_NOT_ARMED (1<<3) /* 03: Memory Device
> is not armed */
> > #define ACPI_NFIT_MEM_HEALTH_OBSERVED (1<<4) /* 04: Memory Device
> observed SMART/health events */
> > #define ACPI_NFIT_MEM_HEALTH_ENABLED(1<<5) /* 05: SMART/health
> events enabled */
> > +#define ACPI_NFIT_MEM_MAP_FAILED(1<<6) /* 06: Mapping to
> SPA failed */
> >
> > /* 2: Interleave Structure */
> >
> > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> > db46546..140886e 100644
> > --- a/include/acpi/actypes.h
> > +++ b/include/acpi/actypes.h
> > @@ -630,7 +630,8 @@ typedef u64 acpi_integer;
> > #define ACPI_NOTIFY_SHUTDOWN_REQUEST(u8) 0x0C
> > #define ACPI_NOTIFY_AFFINITY_UPDATE (u8) 0x0D
> >
> > -#define ACPI_NOTIFY_MAX 0x0D
> > +#define ACPI_GENERIC_NOTIFY_MAX 0x0D
> > +#define ACPI_SPECIFIC_NOTIFY_MAX0x84
> >
> > /*
> > * Types associated with ACPI names and objects. The first group of
> >
>
> Harb
> --
> Qualcomm Technologies, Inc.
> on behalf of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
RE: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and NFIT support
What ACPICA has done here is to define these values consistently with the
ToUUID ASL macro:
Byte encoding of UUID/GUID strings into ACPI Buffer objects (use ToUUID from
ASL):
Input UUID/GUID String format : aabbccdd-eeff-gghh-iijj-kkllmmnnoopp
Expected output ACPI buffer : dd,cc,bb,aa, ff,ee, hh,gg, ii,jj,
kk,ll,mm,nn,oo,pp
> -Original Message-
> From: Toshi Kani [mailto:toshi.k...@hp.com]
> Sent: Thursday, May 21, 2015 10:25 AM
> To: Williams, Dan J
> Cc: Jens Axboe; linux-nvd...@lists.01.org; Neil Brown; Greg KH; Wysocki,
> Rafael J; linux-kernel@vger.kernel.org; Moore, Robert; Linux ACPI; Zheng,
> Lv; Christoph Hellwig; Ingo Molnar
> Subject: Re: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure
> and NFIT support
>
> On Thu, 2015-05-21 at 08:56 -0700, Dan Williams wrote:
> > On Thu, May 21, 2015 at 6:55 AM, Toshi Kani wrote:
> > > On Wed, 2015-05-20 at 16:56 -0400, Dan Williams wrote:
> > > :
> > >> +/* NVDIMM - NFIT table */
> > >> +
> > >> +#define UUID_VOLATILE_MEMORY"4f940573-dafd-e344-b16c-
> 3f22d252e5d0"
> > >> +#define UUID_PERSISTENT_MEMORY "79d3f066-f3b4-7440-ac43-
> 0d3318b78cdb"
> > >> +#define UUID_CONTROL_REGION "f601f792-b413-5d40-910b-
> 299367e8234c"
> > >> +#define UUID_DATA_REGION"3005af91-865d-0e47-a6b0-
> 0a2db9408249"
> > >> +#define UUID_VOLATILE_VIRTUAL_DISK "5a53ab77-fc45-4b62-5560-
> f7b281d1f96e"
> > >> +#define UUID_VOLATILE_VIRTUAL_CD"30bd5a3d-7541-ce87-6d64-
> d2ade523c4bb"
> > >> +#define UUID_PERSISTENT_VIRTUAL_DISK"c902ea5c-074d-69d3-269f-
> 4496fbe096f9"
> > >> +#define UUID_PERSISTENT_VIRTUAL_CD "88810108-cd42-48bb-100f-
> 5387d53ded3d"
> > >
> > > acpi_str_to_uuid() performs little-endian byte-swapping, so the UUID
> > > strings here need to be actual values.
> > >
> > > For instance, UUID_PERSISTENT_MEMORY should be:
> > > #define UUID_PERSISTENT_MEMORY "66f0d379-b4f3-4074-ac43-
> 0d3318b78cdb"
> > >
> >
> > No, the spec defines the GUID for persistent memory as:
> >
> > { 0x66F0D379, 0xB4F3, 0x4074, 0xAC, 0x43, 0x0D, 0x33, 0x18, 0xB7,
> > 0x8C, 0xDB }
> >
> > The byte encoding for that GUID is the following (all fields stored
> > big endian:
> > https://en.wikipedia.org/wiki/Globally_unique_identifier#Binary_encodi
> > ng)
> >
> > { 0x66, 0xF0, 0xD3, 0x79, 0xB4, 0xF3, 0x40,0x74, 0xAC, 0x43, 0x0D,
> > 0x33, 0x18, 0xB7, 0x8C, 0xDB }
> >
> > The reverse ACPI string translation of a UUID buffer according to
> > "ACPI 6 - 19.6.136 ToUUID (Convert String to UUID Macro)"
> >
> > { dd, cc, bb, aa, ff, ee, hh, gg, ii, jj, kk, ll, mm, nn, oo, pp }
> >
> > "aabbccdd-eeff-gghh-iijj-kkllmmnnoopp"
> >
> > "79d3f066-f3b4-7440-ac43-0d3318b78cdb"
> >
> > Indeed, v2 of this patchset got this wrong. Thanks to the sharp eyes
> > of Bob Moore on the ACPICA team, he caught this discrepancy. It seems
> > the ACPI spec uses the terms "GUID" and "UUID" interchangeably.
>
> I agree that this thing is confusing...
>
> The Wiki page you pointed states that:
> ===
> Byte encoding
> :
> This endianness applies only to the way in which a GUID is stored, and not
> to the way in which it is represented in text. GUIDs and RFC 4122 UUIDs
> should be identical when displayed textually.
>
> Text encoding
> :
> For the first three fields, the most significant digit is on the left.
> ===
>
> Wiki page of UUID below also states that:
> http://en.wikipedia.org/wiki/Universally_unique_identifier
> ===
> Definition
> :
> The first 3 sequences are interpreted as complete hexadecimal numbers,
> while the final 2 as a plain sequence of bytes. The byte order is "most
> significant byte first (known as network byte order) ===
>
> So, the text encoding of GUID represents actual value; no endianness
> applies here. So, the following GUID definition:
>
> { 0x66F0D379, 0xB4F3, 0x4074, 0xAC, 0x43, 0x0D, 0x33, 0x18, 0xB7, 0x8C,
> 0xDB }
>
> Should be text encoded as:
>
> "66f0d379-b4f3-4074-ac43-0d3318b78cdb"
>
> Now, byte-encoding is confusing. While the Wiki page you pointed states
> that GUID has big endian per Microsoft definition, EFI spec defines
> differently. Please look at EFI 2.5 "Appendix A GUID and Time Formats".
>
> The EFI spec states that:
> ===
> All EFI GUIDs (Globally Unique Identifiers) have the format described in
> RFC 4122 and comply with the referenced algorithms for generating GUIDs.
> It should be noted that TimeLow, TimeMid, TimeHighAndVersion fields in the
> EFI are encoded as little endian.
> ===
>
> Table 212 defines how text representation of the GUID is stored in Buffer,
> which is little endian format. This table also states that the most
> significant byte is the first in text encoding, which is consistent with
> the Wiki pages.
>
> The ACPI spec, ToUUID, is consistent with EFI spec Table 212 as well.
>
> Thanks,
> -Toshi
RE: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure and NFIT support
It looks to me that you are correct and I screwed up when I made those strings.
The odd thing is that we had discussed this whole issue internally for a few
days -- then I went ahead and messed up the strings. I think my brain was going
around in circles.
Anyway, here is the latest info, please have a look:
Below is the GUID for volatile memory region directly from the ACPI spec:
{ 0x7305944F, 0xFDDA, 0x44E3, 0xB1, 0x6C, 0x3F, 0x22, 0xD2, 0x52, 0xE5, 0xD0 }
Here is an example of ToUUID using a corrected version of the GUID string. Note
that the ordering of the string is identical to the version in the ACPI spec:
11: Name (UUID, ToUUID ("7305944F-FDDA-44E3-B16C-3F22D252E5D0"))
Here is the AML output of the ToUUID macro. Note that the first three fields
are reversed, the rest of the string is left as-is (as per the ToUUID
definition):
0024: 08 55 55 49 44 .".UUID"
0029: 11 13 0A 10 4F 94 05 73 "O..s"
0031: DA FD E3 44 B1 6C 3F 22 "...D.l?""
0039: D2 52 E5 D0 ".R.."
This is the important part:
4F 94 05 73 "O..s"
0031: DA FD E3 44 B1 6C 3F 22 "...D.l?""
0039: D2 52 E5 D0
I believe that this is correct.
Thanks for your help,
Bob
> -Original Message-
> From: Dan Williams [mailto:dan.j.willi...@intel.com]
> Sent: Thursday, May 21, 2015 2:35 PM
> To: Linda Knippers
> Cc: Toshi Kani; Jens Axboe; linux-nvd...@lists.01.org; Neil Brown; Greg
> KH; Wysocki, Rafael J; Moore, Robert; linux-kernel@vger.kernel.org; Linux
> ACPI; Ingo Molnar; Zheng, Lv; Christoph Hellwig
> Subject: Re: [PATCH v3 02/21] libnd, nfit: initial libnd infrastructure
> and NFIT support
>
> On Thu, May 21, 2015 at 1:59 PM, Linda Knippers
> wrote:
> > On 05/21/2015 03:59 PM, Toshi Kani wrote:
> >> On Thu, 2015-05-21 at 13:44 -0600, Toshi Kani wrote:
> >>> On Thu, 2015-05-21 at 12:06 -0700, Dan Williams wrote:
> >>>> On Thu, May 21, 2015 at 11:01 AM, Toshi Kani
> wrote:
> >>>>> On Thu, 2015-05-21 at 17:49 +, Moore, Robert wrote:
> >>>>>> What ACPICA has done here is to define these values consistently
> with the ToUUID ASL macro:
> >>>>>>
> >>>>>>
> >>>>>> Byte encoding of UUID/GUID strings into ACPI Buffer objects (use
> ToUUID from ASL):
> >>>>>>
> >>>>>>Input UUID/GUID String format : aabbccdd-eeff-gghh-iijj-
> kkllmmnnoopp
> >>>>>> Expected output ACPI buffer : dd,cc,bb,aa, ff,ee, hh,gg,
> >>>>>> ii,jj, kk,ll,mm,nn,oo,pp
> >>>>>>
> >>>>>
> >>>>> I do not see any issue in this conversion, which is consistent
> >>>>> with ToUUID defined in ACPI spec.
> >>>>>
> >>>>> My point is that the string format of GUID is endian-neutral.
> >>>>> Wiki pages and EFI spec agree on it. EFI 2.5 spec, Table 225
> >>>>> (sorry not Table 212, which is v2.4), is also clear about how
> >>>>> String and Buffer are related with actual values of GUID.
> >>>>
> >>>> I think the critical point from the UEFI spec is the "It should
> >>>> also be noted that TimeLow, TimeMid, TimeHighAndVersion fields in
> >>>> the EFI are encoded as little endian". That would imply the byte
> >>>> encoding of...
> >>>>
> >>>> { 0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67, 0xE8,
> >>>> 0x23, 0x4C }
> >>>>
> >>>> ...should be:
> >>>>
> >>>> { f6,01,f7,92,b4,13,5d,40,91,0b,29,93,67,e8,23,4c }
> >>>
> >>> The above NFIT GUID as data values means:
> >>>
> >>> EFI_GUID(0x92F701F6, 0x13B4, 0x405D, 0x91, 0x0B, 0x29, 0x93, 0x67,
> >>> 0xE8, 0x23, 0x4C)
> >>>
> >>>> Which implies the text conversion should be:
> >>>>
> >>>> "92f701f6-13b4-405d-910b-299367e8234c"
> >>>
> >>> Nope.
> >>
> >> Oops! Sorry, I misread your email... The above string is correct,
> >> although I do not think you need such conversion.
> >>
> >>> EFI 2.5 spec, Appendix A "GUID and Time Formats" defines that:
> >>> (NOTE, I simplified the table 225 to fit in this email) == This
> >>> specification also defines a standard text representation of the
> >>> GUID. This format is also sometimes called the “registry format”. It
>
