Re: [Devel] [PATCH] ACPICA: Fix compilation with bare-metal toolchian
by Rafael J. Wysocki
On Saturday, June 22, 2019 11:03:54 PM CEST Laster K. wrote:
> An ifdef expects to be compiled with full-fledged Linux toolchain,
> but it's common to compile kernel with just bare-metal toolchain
> which doesn't define __linux__. So, also add __KERNEL__ check.
>
> Signed-off-by: Laster K. (lazerl0rd) <officiallazerl0rd(a)gmail.com>
> ---
> Apologies for the multiple/spammed e-mails, I was having mail client issues.
>
> include/acpi/platform/acenv.h | 2 +-
> include/acpi/platform/acenvex.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
> index 35ab3f87cc29..b69319198cb8 100644
> --- a/include/acpi/platform/acenv.h
> +++ b/include/acpi/platform/acenv.h
> @@ -148,7 +148,7 @@
>
> #endif
>
> -#if defined(_LINUX) || defined(__linux__)
> +#if defined(_LINUX) || defined(__KERNEL__) || defined(__linux__)
> #include <acpi/platform/aclinux.h>
>
> #elif defined(_APPLE) || defined(__APPLE__)
> diff --git a/include/acpi/platform/acenvex.h b/include/acpi/platform/acenvex.h
> index 2e36c8344897..c7697a47e33f 100644
> --- a/include/acpi/platform/acenvex.h
> +++ b/include/acpi/platform/acenvex.h
> @@ -19,7 +19,7 @@
> *
> *****************************************************************************/
>
> -#if defined(_LINUX) || defined(__linux__)
> +#if defined(_LINUX) || defined(__KERNEL__) || defined(__linux__)
> #include <acpi/platform/aclinuxex.h>
>
> #elif defined(__DragonFly__)
>
Erik, Bob, any input here?
2 years, 9 months
Re: [PATCH] ACPICA: Use ARRAY_SIZE for 'fadt_info_table','fadt_pm_info_table'
by Moore, Robert
Where does "ARRAY_SIZE" come from? It's not a part of ACPICA.
Bob
-----Original Message-----
From: zhengbin <zhengbin13(a)huawei.com>
Sent: Friday, November 22, 2019 1:33 AM
To: Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik <erik.schmauss(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>; lenb(a)kernel.org; linux-acpi(a)vger.kernel.org; devel(a)acpica.org
Cc: zhengbin13(a)huawei.com
Subject: [PATCH] ACPICA: Use ARRAY_SIZE for 'fadt_info_table','fadt_pm_info_table'
Fixes coccicheck warning:
drivers/acpi/acpica/tbfadt.c:107:27-28: WARNING: Use ARRAY_SIZE
drivers/acpi/acpica/tbfadt.c:137:30-31: WARNING: Use ARRAY_SIZE
Reported-by: Hulk Robot <hulkci(a)huawei.com>
Signed-off-by: zhengbin <zhengbin13(a)huawei.com>
---
drivers/acpi/acpica/tbfadt.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c index 0041bfb..324a804 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -103,8 +103,7 @@ static struct acpi_fadt_info fadt_info_table[] = {
ACPI_FADT_SEPARATE_LENGTH | ACPI_FADT_GPE_REGISTER} };
-#define ACPI_FADT_INFO_ENTRIES \
- (sizeof (fadt_info_table) / sizeof (struct acpi_fadt_info))
+#define ACPI_FADT_INFO_ENTRIES (ARRAY_SIZE(fadt_info_table))
/* Table used to split Event Blocks into separate status/enable registers */
@@ -133,8 +132,7 @@ static struct acpi_fadt_pm_info fadt_pm_info_table[] = {
1}
};
-#define ACPI_FADT_PM_INFO_ENTRIES \
- (sizeof (fadt_pm_info_table) / sizeof (struct acpi_fadt_pm_info))
+#define ACPI_FADT_PM_INFO_ENTRIES (ARRAY_SIZE(fadt_pm_info_table))
/*******************************************************************************
*
--
2.7.4
2 years, 10 months
Re: PROBLEM: Calling ObjectType on buffer field reports type integer
by Schmauss, Erik
>
> This looks like a separate problem to me. On the SB2 there is this piece of code,
> simplified:
>
> Name(RQBF, Buffer (0xFF) {})
> CreateByteField (RQBF, 0x03, ALEN)
>
> // ...
> // GenericSerialBus/AttribRawProcessBytes access to fill RQBF
> // ...
>
> If (/* success and everything is valid */)
> {
> Local3 = (ALEN * 0x08)
> CreateField (RQBF, 0x20, Local3, ARB)
> Local4 = ARB /* \_SB_._SAN.RQSX.ARB_ */
> }
> Else
> {
> Local4 = 0x01 // or some other error code as integer
> }
>
> // ...
> // some more stuff
> // ...
>
> If ((ObjectType (Local4) == One /* Integer */))
> {
> // notify that an error has occurred
> }
> Else
> {
> // success and actually use data from Local4
> }
>
> The code in question basically unpacks a payload from some other
> management stuff sent over the OperationRegion.
>
> Here, ALEN is the length of a dynamically sized payload in bytes, which is
> obtained from the data returned by the OperationRegion access. This can for
> example be 4, making the field length 32 bit. So this is not an issue of the field
> length being larger than intmax bits, it actually is sometimes only 32 bits, or 8
> bits, depending on the response of the driver connected to the
> OperationRegion. Also the DSDT depends on that, see the example below.
>
> Just to reiterate, the code works fine for payloads with ALEN > 8 (so more than
> 8 bytes), but fails for anything less.
Forget what I said in the previous email. You are correct.
They treat bufferfields that are small enough to fit inside of an integer as a buffer or bufferfield.
I did a bunch of testing on windows and determined that, objects created by Create(Bit|Byte|Word|DWord|Qword)Field
work the same way on both interpreters. They get converted to Integers as outlined in the spec.
We simply need to stop perform the BufferField->Integer conversion for buffer fields created by the ASL CreateField() operators.
I'll get a solution hopefully sometime next week..
Thanks,
Erik
>
> Also note that this is not something that can be fixed by just telling the
> GenericSerialBus/OperationRegion driver to just return 9 bytes
> instead: There are length-checks on Local4 further down the line to validate it
> actually contains what was requested.
>
> An example of how this piece of code is actually used, if that helps (again
> simplified):
>
> Method (RQST, 1)
> {
> // pretty much the code above
> Return (Local4) // either payload or integer error code
> }
>
> Scope (_SB.BAT1)
> {
> Method (_STA, 0)
> {
> Local0 = RQST(0x01) // request battery status
>
> If ((ObjectType (Local0) == 0x03)) // is buffer type
> {
> If ((SizeOf (Local0) == 0x04)) // has length 4
> {
> CreateDWordField (Local0, 0, BAST)
> Return (BAST)
> }
> }
>
> Return (0x00) // return default value
> }
> }
>
>
> Regards,
> Maximilian
2 years, 10 months
Re: PROBLEM: Calling ObjectType on buffer field reports type integer
by Moore, Robert
We will probably make this change, depending on what Windows does.
Bob
-----Original Message-----
From: Maximilian Luz <luzmaximilian(a)gmail.com>
Sent: Sunday, November 10, 2019 1:30 PM
To: Schmauss, Erik <erik.schmauss(a)intel.com>; Moore, Robert <robert.moore(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>
Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
Subject: Re: PROBLEM: Calling ObjectType on buffer field reports type integer
On 7/23/19 1:01 AM, Schmauss, Erik wrote:
> Sorry about the late response. This slipped through the cracks.
> I've sent them an email just now and I'll keep you informed
Hi again,
is there any update on this?
Regards,
Maximilian
2 years, 10 months