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: [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: [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] 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] 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
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] ACPICA: fix -Wfallthrough
-Original Message- From: Nick Desaulniers Sent: Friday, November 13, 2020 2:09 PM To: Moore, Robert Cc: Kaneda, Erik ; Wysocki, Rafael J ; Gustavo A . R . Silva ; clang-built-li...@googlegroups.com; Len Brown ; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] ACPICA: fix -Wfallthrough On Fri, Nov 13, 2020 at 1:45 PM Moore, Robert wrote: > > BTW, if you can make a pull request for the patch up on github, that would > help. https://github.com/acpica/acpica/pull/650 Great, thanks. I'll look at/merge the request next week. Bob -- Thanks, ~Nick Desaulniers
RE: [PATCH] ACPICA: fix -Wfallthrough
BTW, if you can make a pull request for the patch up on github, that would help.
-Original Message-
From: Moore, Robert
Sent: Friday, November 13, 2020 1:44 PM
To: Nick Desaulniers
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Gustavo A . R . Silva ;
clang-built-li...@googlegroups.com; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message-
From: Moore, Robert
Sent: Friday, November 13, 2020 1:42 PM
To: Nick Desaulniers
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Gustavo A . R . Silva ;
clang-built-li...@googlegroups.com; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message-
From: Nick Desaulniers
Sent: Friday, November 13, 2020 1:33 PM
To: Moore, Robert
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Gustavo A . R . Silva ;
clang-built-li...@googlegroups.com; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPICA: fix -Wfallthrough
On Fri, Nov 13, 2020 at 1:27 PM Moore, Robert wrote:
>
>
>
> -Original Message-
> From: ndesaulniers via sendgmr
> On Behalf Of Nick
> Desaulniers
> Sent: Tuesday, November 10, 2020 6:12 PM
> To: Moore, Robert ; Kaneda, Erik
> ; Wysocki, Rafael J
> ; Gustavo A . R . Silva
>
> Cc: clang-built-li...@googlegroups.com; Nick Desaulniers
> ; Len Brown ;
> linux-a...@vger.kernel.org; de...@acpica.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH] ACPICA: fix -Wfallthrough
>
> The "fallthrough" pseudo-keyword was added as a portable way to denote
> intentional fallthrough. This code seemed to be using a mix of fallthrough
> comments that GCC recognizes, and some kind of lint marker.
> I'm guessing that linter hasn't been run in a while from the mixed use of the
> marker vs comments.
>
> /*lint -fallthrough */
>
> This is the lint marker
Yes; but from my patch, the hunk modifying
acpi_ex_store_object_to_node() and vsnprintf() seem to indicate that maybe the
linter hasn't been run in a while.
Which linter is that? I'm curious whether I should leave those be, and whether
we're going to have an issue between compilers and linters as to which
line/order these would need to appear on.
It's an old version of PC-Lint, which we don't use anymore.
So, you can get rid of the lint markers.
>
> BTW, what version of gcc added -Wfallthrough?
GCC 7.1 added -Wimplicit-fallthrough.
>
>
> Signed-off-by: Nick Desaulniers
> ---
> drivers/acpi/acpica/dscontrol.c | 3 +--
> drivers/acpi/acpica/dswexec.c | 4 +---
> drivers/acpi/acpica/dswload.c | 3 +--
> drivers/acpi/acpica/dswload2.c | 3 +--
> drivers/acpi/acpica/exfldio.c | 3 +--
> drivers/acpi/acpica/exresop.c | 5 ++---
> drivers/acpi/acpica/exstore.c | 6 ++
> drivers/acpi/acpica/hwgpe.c | 3 +--
> drivers/acpi/acpica/utdelete.c | 3 +--
> drivers/acpi/acpica/utprint.c | 2 +-
> 10 files changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dscontrol.c
> b/drivers/acpi/acpica/dscontrol.c index 4b5b6e859f62..1e75e5fbfd19
> 100644
> --- a/drivers/acpi/acpica/dscontrol.c
> +++ b/drivers/acpi/acpica/dscontrol.c
> @@ -61,8 +61,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state
> *walk_state,
> break;
> }
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_IF_OP:
> /*
> diff --git a/drivers/acpi/acpica/dswexec.c
> b/drivers/acpi/acpica/dswexec.c index 1d4f8c81028c..e8c32d4fe55f
> 100644
> --- a/drivers/acpi/acpica/dswexec.c
> +++ b/drivers/acpi/acpica/dswexec.c
> @@ -597,9 +597,7 @@ acpi_status acpi_ds_exec_end_op(struct acpi_walk_state
> *walk_state)
> if (ACPI_FAILURE(status)) {
> break;
> }
> -
> - /* Fall through */
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_INT_EVAL_SUBTREE_OP:
>
> diff --git a/drivers/acpi/acpica/dswload.c
> b/drivers/acpi/acpica/dswload.c index 27069325b6de..afc663c3742d
> 100644
> --- a/drivers/acpi/acpica/dswload.c
> +++ b/drivers/acpi/acpica/dswload.c
> @@ -223,8 +223,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state *walk_state,
> parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
> break;
> }
> -
> -
RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message-
From: Moore, Robert
Sent: Friday, November 13, 2020 1:42 PM
To: Nick Desaulniers
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Gustavo A . R . Silva ;
clang-built-li...@googlegroups.com; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message-
From: Nick Desaulniers
Sent: Friday, November 13, 2020 1:33 PM
To: Moore, Robert
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Gustavo A . R . Silva ;
clang-built-li...@googlegroups.com; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPICA: fix -Wfallthrough
On Fri, Nov 13, 2020 at 1:27 PM Moore, Robert wrote:
>
>
>
> -Original Message-
> From: ndesaulniers via sendgmr
> On Behalf Of Nick
> Desaulniers
> Sent: Tuesday, November 10, 2020 6:12 PM
> To: Moore, Robert ; Kaneda, Erik
> ; Wysocki, Rafael J
> ; Gustavo A . R . Silva
>
> Cc: clang-built-li...@googlegroups.com; Nick Desaulniers
> ; Len Brown ;
> linux-a...@vger.kernel.org; de...@acpica.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH] ACPICA: fix -Wfallthrough
>
> The "fallthrough" pseudo-keyword was added as a portable way to denote
> intentional fallthrough. This code seemed to be using a mix of fallthrough
> comments that GCC recognizes, and some kind of lint marker.
> I'm guessing that linter hasn't been run in a while from the mixed use of the
> marker vs comments.
>
> /*lint -fallthrough */
>
> This is the lint marker
Yes; but from my patch, the hunk modifying
acpi_ex_store_object_to_node() and vsnprintf() seem to indicate that maybe the
linter hasn't been run in a while.
Which linter is that? I'm curious whether I should leave those be, and whether
we're going to have an issue between compilers and linters as to which
line/order these would need to appear on.
It's an old version of PC-Lint, which we don't use anymore.
So, you can get rid of the lint markers.
>
> BTW, what version of gcc added -Wfallthrough?
GCC 7.1 added -Wimplicit-fallthrough.
>
>
> Signed-off-by: Nick Desaulniers
> ---
> drivers/acpi/acpica/dscontrol.c | 3 +--
> drivers/acpi/acpica/dswexec.c | 4 +---
> drivers/acpi/acpica/dswload.c | 3 +--
> drivers/acpi/acpica/dswload2.c | 3 +--
> drivers/acpi/acpica/exfldio.c | 3 +--
> drivers/acpi/acpica/exresop.c | 5 ++---
> drivers/acpi/acpica/exstore.c | 6 ++
> drivers/acpi/acpica/hwgpe.c | 3 +--
> drivers/acpi/acpica/utdelete.c | 3 +--
> drivers/acpi/acpica/utprint.c | 2 +-
> 10 files changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dscontrol.c
> b/drivers/acpi/acpica/dscontrol.c index 4b5b6e859f62..1e75e5fbfd19
> 100644
> --- a/drivers/acpi/acpica/dscontrol.c
> +++ b/drivers/acpi/acpica/dscontrol.c
> @@ -61,8 +61,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state
> *walk_state,
> break;
> }
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_IF_OP:
> /*
> diff --git a/drivers/acpi/acpica/dswexec.c
> b/drivers/acpi/acpica/dswexec.c index 1d4f8c81028c..e8c32d4fe55f
> 100644
> --- a/drivers/acpi/acpica/dswexec.c
> +++ b/drivers/acpi/acpica/dswexec.c
> @@ -597,9 +597,7 @@ acpi_status acpi_ds_exec_end_op(struct acpi_walk_state
> *walk_state)
> if (ACPI_FAILURE(status)) {
> break;
> }
> -
> - /* Fall through */
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_INT_EVAL_SUBTREE_OP:
>
> diff --git a/drivers/acpi/acpica/dswload.c
> b/drivers/acpi/acpica/dswload.c index 27069325b6de..afc663c3742d
> 100644
> --- a/drivers/acpi/acpica/dswload.c
> +++ b/drivers/acpi/acpica/dswload.c
> @@ -223,8 +223,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state *walk_state,
> parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
> break;
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> default:
>
> diff --git a/drivers/acpi/acpica/dswload2.c
> b/drivers/acpi/acpica/dswload2.c index edadbe146506..1b794b6ba072
> 100644
> --- a/drivers/acpi/acpica/dswload2.c
> +++ b/drivers/acpi/acpica/dswload2.c
> @@ -213,8 +213,7 @@ acpi_ds_load2_begin_op(struct acpi_walk_state *walk_state,
>
RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message-
From: Nick Desaulniers
Sent: Friday, November 13, 2020 1:33 PM
To: Moore, Robert
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Gustavo A . R . Silva ;
clang-built-li...@googlegroups.com; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPICA: fix -Wfallthrough
On Fri, Nov 13, 2020 at 1:27 PM Moore, Robert wrote:
>
>
>
> -Original Message-
> From: ndesaulniers via sendgmr
> On Behalf Of Nick
> Desaulniers
> Sent: Tuesday, November 10, 2020 6:12 PM
> To: Moore, Robert ; Kaneda, Erik
> ; Wysocki, Rafael J
> ; Gustavo A . R . Silva
>
> Cc: clang-built-li...@googlegroups.com; Nick Desaulniers
> ; Len Brown ;
> linux-a...@vger.kernel.org; de...@acpica.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH] ACPICA: fix -Wfallthrough
>
> The "fallthrough" pseudo-keyword was added as a portable way to denote
> intentional fallthrough. This code seemed to be using a mix of fallthrough
> comments that GCC recognizes, and some kind of lint marker.
> I'm guessing that linter hasn't been run in a while from the mixed use of the
> marker vs comments.
>
> /*lint -fallthrough */
>
> This is the lint marker
Yes; but from my patch, the hunk modifying
acpi_ex_store_object_to_node() and vsnprintf() seem to indicate that maybe the
linter hasn't been run in a while.
Which linter is that? I'm curious whether I should leave those be, and whether
we're going to have an issue between compilers and linters as to which
line/order these would need to appear on.
It's an old version of PC-Lint, which we don't use anymore.
>
> BTW, what version of gcc added -Wfallthrough?
GCC 7.1 added -Wimplicit-fallthrough.
>
>
> Signed-off-by: Nick Desaulniers
> ---
> drivers/acpi/acpica/dscontrol.c | 3 +--
> drivers/acpi/acpica/dswexec.c | 4 +---
> drivers/acpi/acpica/dswload.c | 3 +--
> drivers/acpi/acpica/dswload2.c | 3 +--
> drivers/acpi/acpica/exfldio.c | 3 +--
> drivers/acpi/acpica/exresop.c | 5 ++---
> drivers/acpi/acpica/exstore.c | 6 ++
> drivers/acpi/acpica/hwgpe.c | 3 +--
> drivers/acpi/acpica/utdelete.c | 3 +--
> drivers/acpi/acpica/utprint.c | 2 +-
> 10 files changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dscontrol.c
> b/drivers/acpi/acpica/dscontrol.c index 4b5b6e859f62..1e75e5fbfd19
> 100644
> --- a/drivers/acpi/acpica/dscontrol.c
> +++ b/drivers/acpi/acpica/dscontrol.c
> @@ -61,8 +61,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state
> *walk_state,
> break;
> }
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_IF_OP:
> /*
> diff --git a/drivers/acpi/acpica/dswexec.c
> b/drivers/acpi/acpica/dswexec.c index 1d4f8c81028c..e8c32d4fe55f
> 100644
> --- a/drivers/acpi/acpica/dswexec.c
> +++ b/drivers/acpi/acpica/dswexec.c
> @@ -597,9 +597,7 @@ acpi_status acpi_ds_exec_end_op(struct acpi_walk_state
> *walk_state)
> if (ACPI_FAILURE(status)) {
> break;
> }
> -
> - /* Fall through */
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_INT_EVAL_SUBTREE_OP:
>
> diff --git a/drivers/acpi/acpica/dswload.c
> b/drivers/acpi/acpica/dswload.c index 27069325b6de..afc663c3742d
> 100644
> --- a/drivers/acpi/acpica/dswload.c
> +++ b/drivers/acpi/acpica/dswload.c
> @@ -223,8 +223,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state *walk_state,
> parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
> break;
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> default:
>
> diff --git a/drivers/acpi/acpica/dswload2.c
> b/drivers/acpi/acpica/dswload2.c index edadbe146506..1b794b6ba072
> 100644
> --- a/drivers/acpi/acpica/dswload2.c
> +++ b/drivers/acpi/acpica/dswload2.c
> @@ -213,8 +213,7 @@ acpi_ds_load2_begin_op(struct acpi_walk_state *walk_state,
> parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
> break;
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> default:
>
> diff --git a/drivers/acpi/acpica/exfldio.c
> b/drivers/acpi/a
RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message-
From: ndesaulniers via sendgmr
On Behalf Of Nick Desaulniers
Sent: Tuesday, November 10, 2020 6:12 PM
To: Moore, Robert ; Kaneda, Erik
; Wysocki, Rafael J ;
Gustavo A . R . Silva
Cc: clang-built-li...@googlegroups.com; Nick Desaulniers
; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: [PATCH] ACPICA: fix -Wfallthrough
The "fallthrough" pseudo-keyword was added as a portable way to denote
intentional fallthrough. This code seemed to be using a mix of fallthrough
comments that GCC recognizes, and some kind of lint marker.
I'm guessing that linter hasn't been run in a while from the mixed use of the
marker vs comments.
/*lint -fallthrough */
This is the lint marker
BTW, what version of gcc added -Wfallthrough?
Signed-off-by: Nick Desaulniers
---
drivers/acpi/acpica/dscontrol.c | 3 +--
drivers/acpi/acpica/dswexec.c | 4 +---
drivers/acpi/acpica/dswload.c | 3 +--
drivers/acpi/acpica/dswload2.c | 3 +--
drivers/acpi/acpica/exfldio.c | 3 +--
drivers/acpi/acpica/exresop.c | 5 ++---
drivers/acpi/acpica/exstore.c | 6 ++
drivers/acpi/acpica/hwgpe.c | 3 +--
drivers/acpi/acpica/utdelete.c | 3 +--
drivers/acpi/acpica/utprint.c | 2 +-
10 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/acpi/acpica/dscontrol.c b/drivers/acpi/acpica/dscontrol.c
index 4b5b6e859f62..1e75e5fbfd19 100644
--- a/drivers/acpi/acpica/dscontrol.c
+++ b/drivers/acpi/acpica/dscontrol.c
@@ -61,8 +61,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state
*walk_state,
break;
}
}
-
- /*lint -fallthrough */
+ fallthrough;
case AML_IF_OP:
/*
diff --git a/drivers/acpi/acpica/dswexec.c b/drivers/acpi/acpica/dswexec.c
index 1d4f8c81028c..e8c32d4fe55f 100644
--- a/drivers/acpi/acpica/dswexec.c
+++ b/drivers/acpi/acpica/dswexec.c
@@ -597,9 +597,7 @@ acpi_status acpi_ds_exec_end_op(struct acpi_walk_state
*walk_state)
if (ACPI_FAILURE(status)) {
break;
}
-
- /* Fall through */
- /*lint -fallthrough */
+ fallthrough;
case AML_INT_EVAL_SUBTREE_OP:
diff --git a/drivers/acpi/acpica/dswload.c b/drivers/acpi/acpica/dswload.c
index 27069325b6de..afc663c3742d 100644
--- a/drivers/acpi/acpica/dswload.c
+++ b/drivers/acpi/acpica/dswload.c
@@ -223,8 +223,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state *walk_state,
parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
break;
}
-
- /*lint -fallthrough */
+ fallthrough;
default:
diff --git a/drivers/acpi/acpica/dswload2.c b/drivers/acpi/acpica/dswload2.c
index edadbe146506..1b794b6ba072 100644
--- a/drivers/acpi/acpica/dswload2.c
+++ b/drivers/acpi/acpica/dswload2.c
@@ -213,8 +213,7 @@ acpi_ds_load2_begin_op(struct acpi_walk_state *walk_state,
parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
break;
}
-
- /*lint -fallthrough */
+ fallthrough;
default:
diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index ade35ff1c7ba..9d1cabe0fed9 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -433,8 +433,7 @@ acpi_ex_field_datum_io(union acpi_operand_object *obj_desc,
* Now that the Bank has been selected, fall through to the
* region_field case and write the datum to the Operation Region
*/
-
- /*lint -fallthrough */
+ fallthrough;
case ACPI_TYPE_LOCAL_REGION_FIELD:
/*
diff --git a/drivers/acpi/acpica/exresop.c b/drivers/acpi/acpica/exresop.c
index 4d1b22971d58..df48faa9a551 100644
--- a/drivers/acpi/acpica/exresop.c
+++ b/drivers/acpi/acpica/exresop.c
@@ -197,8 +197,7 @@ acpi_ex_resolve_operands(u16 opcode,
case ACPI_REFCLASS_DEBUG:
target_op = AML_DEBUG_OP;
-
- /*lint -fallthrough */
+ fallthrough;
case ACPI_REFCLASS_ARG:
case ACPI_REFCLASS_LOCAL:
@@ -264,7 +263,7 @@ acpi_ex_resolve_operands(u16 opcode,
* Else not a string - fall through to the normal
Reference
* case below
*/
- /*lint -fallthrough */
+ fallthrough;
case ARGI
RE: [PATCH] ACPICA: fix -Wfallthrough
I can do it this way: In the global header actypes.h: #ifndef ACPI_FALLTHROUGH #define ACPI_FALLTHROUGH #endif In the gcc-specific header (acgcc.h): #define ACPI_FALLTHROUGH__attribute__((__fallthrough__)) This would not be #defined in the MSVC-specific header (acmsvc.h) -- thus using the default (null) in actypes.h (The per-environment headers are always included first). (We do all macros in upper case, prefixed with "ACPI_") If you can update your patch to use ACPI_FALLTHROUGH, I can do the rest (above). Thanks, Bob -Original Message- From: Joe Perches Sent: Friday, November 13, 2020 8:30 AM To: Miguel Ojeda ; Nick Desaulniers Cc: Moore, Robert ; Kaneda, Erik ; Wysocki, Rafael J ; Gustavo A . R . Silva ; clang-built-li...@googlegroups.com; Len Brown ; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] ACPICA: fix -Wfallthrough On Fri, 2020-11-13 at 09:14 +0100, Miguel Ojeda wrote: > On Fri, Nov 13, 2020 at 1:09 AM Nick Desaulniers > wrote: > > > > Thank you for the explicit diagnostics observed. Something fishy is > > going on though, https://godbolt.org/z/Gbxbxa is how I expect MSVC > > to handle include/linux/compiler_attributes.h. > > > > The C preprocessor should make it such that MSVC never sees > > `__attribute__` or `__fallthrough__`; that it does begs the question. > > That would seem to imply that `#if __has_attribute(__fallthrough__)` > > somehow evaluates to true on MSVC, but my godbolt link shows it does > > not. > > > > Could the upstream ACPICA project be #define'ing something that > > could be altering this? (Or not #define'ing something?) > > > > Worst case, we could do as Joe Perches suggested and disable > > -Wfallthrough for drivers/acpi/acpica/. > > I agree, something is fishy. MSVC has several flags for conformance > and extensions support, including two full C preprocessors in newer > versions; which means we might be missing something, but I don't see > how the code in compiler_attributes.h could be confusing MSVC even in > older non-conforming versions. I believe this has nothing to do with linux and only to do with compiling acpica for other environments like Windows. From: https://acpica.org/ The ACPI Component Architecture (ACPICA) project provides an operating system (OS)-independent reference implementation of the Advanced Configuration and Power Interface Specification (ACPI). It can be easily adapted to execute under any host OS.
RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message- From: Nick Desaulniers Sent: Thursday, November 12, 2020 11:31 AM To: Moore, Robert Cc: Kaneda, Erik ; Wysocki, Rafael J ; Gustavo A . R . Silva ; clang-built-li...@googlegroups.com; Len Brown ; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] ACPICA: fix -Wfallthrough On Thu, Nov 12, 2020 at 7:13 AM Moore, Robert wrote: > > > > -Original Message- > From: Nick Desaulniers > Sent: Wednesday, November 11, 2020 10:48 AM > To: Moore, Robert > Cc: Kaneda, Erik ; Wysocki, Rafael J > ; Gustavo A . R . Silva > ; clang-built-li...@googlegroups.com; Len Brown > ; linux-a...@vger.kernel.org; de...@acpica.org; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH] ACPICA: fix -Wfallthrough > > On Wed, Nov 11, 2020 at 7:15 AM Moore, Robert wrote: > > > > Yes, but: isn't the "fallthrough" keyword compiler-specific? That is the > > problem for us. > > It's not a keyword. > > It's a preprocessor macro that expands to > __attribute__((__fallthrough__)) for compilers that support it. For > compilers that do not, it expands to nothing. Both GCC 7+ and Clang support > this attribute. Which other compilers that support -Wimplicit-fallthrough do > you care to support? > > We need to support MSVC 2017 -- which apparently does not support this. In which case, the macro is not expanded to a compiler attribute the compiler doesn't support. Please see also its definition in include/linux/compiler_attributes.h. From what I can tell, MSVC does not warn on implicit fallthrough, so there's no corresponding attribute (or comment) to disable the warning in MSVC. That doesn't mean this code is not portable to MSVC; a macro that expands to nothing should not be a problem. Based on https://docs.microsoft.com/en-us/cpp/code-quality/c26819?view=msvc-160 https://developercommunity.visualstudio.com/idea/423975/issue-compiler-warning-when-using-implicit-fallthr.html it sounds like MSVC 2019 will be able to warn, for C++ mode, which will rely on the C++ style attribute to annotate intentional fallthrough. Can you confirm how this does not work for MSVC 2017? 1>c:\acpica\source\components\utilities\utdelete.c(270): warning C4013: '__attribute__' undefined; assuming extern returning int 1>c:\acpica\source\components\utilities\utdelete.c(270): error C2065: '__fallthrough__': undeclared identifier 1>c:\acpica\source\components\utilities\utdelete.c(272): error C2143: syntax error: missing ';' before 'case' > > Bob > > > > > > -Original Message- > > From: ndesaulniers via sendgmr > > On Behalf Of Nick > > Desaulniers > > Sent: Tuesday, November 10, 2020 6:12 PM > > To: Moore, Robert ; Kaneda, Erik > > ; Wysocki, Rafael J > > ; Gustavo A . R . Silva > > > > Cc: clang-built-li...@googlegroups.com; Nick Desaulniers > > ; Len Brown ; > > linux-a...@vger.kernel.org; de...@acpica.org; > > linux-kernel@vger.kernel.org > > Subject: [PATCH] ACPICA: fix -Wfallthrough > > > > The "fallthrough" pseudo-keyword was added as a portable way to denote > > intentional fallthrough. This code seemed to be using a mix of fallthrough > > comments that GCC recognizes, and some kind of lint marker. > > I'm guessing that linter hasn't been run in a while from the mixed use of > > the marker vs comments. > > > > Signed-off-by: Nick Desaulniers > > --- > > drivers/acpi/acpica/dscontrol.c | 3 +-- > > drivers/acpi/acpica/dswexec.c | 4 +--- > > drivers/acpi/acpica/dswload.c | 3 +-- > > drivers/acpi/acpica/dswload2.c | 3 +-- > > drivers/acpi/acpica/exfldio.c | 3 +-- > > drivers/acpi/acpica/exresop.c | 5 ++--- > > drivers/acpi/acpica/exstore.c | 6 ++ > > drivers/acpi/acpica/hwgpe.c | 3 +-- > > drivers/acpi/acpica/utdelete.c | 3 +-- > > drivers/acpi/acpica/utprint.c | 2 +- > > 10 files changed, 12 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/acpi/acpica/dscontrol.c > > b/drivers/acpi/acpica/dscontrol.c index 4b5b6e859f62..1e75e5fbfd19 > > 100644 > > --- a/drivers/acpi/acpica/dscontrol.c > > +++ b/drivers/acpi/acpica/dscontrol.c > > @@ -61,8 +61,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state > > *walk_state, > > break; > > } > > } > > - > > - /*lint -fallthrough */ > > + fallthrough; > > > > case AML_IF_OP: > > /* > > diff --git a/drivers/acpi
RE: [PATCH] ACPICA: fix -Wfallthrough
-Original Message-
From: Nick Desaulniers
Sent: Wednesday, November 11, 2020 10:48 AM
To: Moore, Robert
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Gustavo A . R . Silva ;
clang-built-li...@googlegroups.com; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPICA: fix -Wfallthrough
On Wed, Nov 11, 2020 at 7:15 AM Moore, Robert wrote:
>
> Yes, but: isn't the "fallthrough" keyword compiler-specific? That is the
> problem for us.
It's not a keyword.
It's a preprocessor macro that expands to
__attribute__((__fallthrough__)) for compilers that support it. For compilers
that do not, it expands to nothing. Both GCC 7+ and Clang support this
attribute. Which other compilers that support -Wimplicit-fallthrough do you
care to support?
We need to support MSVC 2017 -- which apparently does not support this.
> Bob
>
>
> -Original Message-
> From: ndesaulniers via sendgmr
> On Behalf Of Nick
> Desaulniers
> Sent: Tuesday, November 10, 2020 6:12 PM
> To: Moore, Robert ; Kaneda, Erik
> ; Wysocki, Rafael J
> ; Gustavo A . R . Silva
>
> Cc: clang-built-li...@googlegroups.com; Nick Desaulniers
> ; Len Brown ;
> linux-a...@vger.kernel.org; de...@acpica.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH] ACPICA: fix -Wfallthrough
>
> The "fallthrough" pseudo-keyword was added as a portable way to denote
> intentional fallthrough. This code seemed to be using a mix of fallthrough
> comments that GCC recognizes, and some kind of lint marker.
> I'm guessing that linter hasn't been run in a while from the mixed use of the
> marker vs comments.
>
> Signed-off-by: Nick Desaulniers
> ---
> drivers/acpi/acpica/dscontrol.c | 3 +--
> drivers/acpi/acpica/dswexec.c | 4 +---
> drivers/acpi/acpica/dswload.c | 3 +--
> drivers/acpi/acpica/dswload2.c | 3 +--
> drivers/acpi/acpica/exfldio.c | 3 +--
> drivers/acpi/acpica/exresop.c | 5 ++---
> drivers/acpi/acpica/exstore.c | 6 ++
> drivers/acpi/acpica/hwgpe.c | 3 +--
> drivers/acpi/acpica/utdelete.c | 3 +--
> drivers/acpi/acpica/utprint.c | 2 +-
> 10 files changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dscontrol.c
> b/drivers/acpi/acpica/dscontrol.c index 4b5b6e859f62..1e75e5fbfd19
> 100644
> --- a/drivers/acpi/acpica/dscontrol.c
> +++ b/drivers/acpi/acpica/dscontrol.c
> @@ -61,8 +61,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state
> *walk_state,
> break;
> }
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_IF_OP:
> /*
> diff --git a/drivers/acpi/acpica/dswexec.c
> b/drivers/acpi/acpica/dswexec.c index 1d4f8c81028c..e8c32d4fe55f
> 100644
> --- a/drivers/acpi/acpica/dswexec.c
> +++ b/drivers/acpi/acpica/dswexec.c
> @@ -597,9 +597,7 @@ acpi_status acpi_ds_exec_end_op(struct acpi_walk_state
> *walk_state)
> if (ACPI_FAILURE(status)) {
> break;
> }
> -
> - /* Fall through */
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_INT_EVAL_SUBTREE_OP:
>
> diff --git a/drivers/acpi/acpica/dswload.c
> b/drivers/acpi/acpica/dswload.c index 27069325b6de..afc663c3742d
> 100644
> --- a/drivers/acpi/acpica/dswload.c
> +++ b/drivers/acpi/acpica/dswload.c
> @@ -223,8 +223,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state *walk_state,
> parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
> break;
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> default:
>
> diff --git a/drivers/acpi/acpica/dswload2.c
> b/drivers/acpi/acpica/dswload2.c index edadbe146506..1b794b6ba072
> 100644
> --- a/drivers/acpi/acpica/dswload2.c
> +++ b/drivers/acpi/acpica/dswload2.c
> @@ -213,8 +213,7 @@ acpi_ds_load2_begin_op(struct acpi_walk_state *walk_state,
> parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
> break;
> }
> -
> - /*lint -fallthrough */
> + fallthrough;
>
> default:
>
> diff --git a/drivers/acpi/acpica/exfldio.c
> b/drivers/acpi/acpica/exfldio.c index ade35ff1c7ba..9d1cabe0fed9
> 100644
> --- a/drivers/acpi/acpica/exfldio.c
> +
RE: [PATCH] ACPICA: fix -Wfallthrough
Yes, but: isn't the "fallthrough" keyword compiler-specific? That is the
problem for us.
Bob
-Original Message-
From: ndesaulniers via sendgmr
On Behalf Of Nick Desaulniers
Sent: Tuesday, November 10, 2020 6:12 PM
To: Moore, Robert ; Kaneda, Erik
; Wysocki, Rafael J ;
Gustavo A . R . Silva
Cc: clang-built-li...@googlegroups.com; Nick Desaulniers
; Len Brown ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
Subject: [PATCH] ACPICA: fix -Wfallthrough
The "fallthrough" pseudo-keyword was added as a portable way to denote
intentional fallthrough. This code seemed to be using a mix of fallthrough
comments that GCC recognizes, and some kind of lint marker.
I'm guessing that linter hasn't been run in a while from the mixed use of the
marker vs comments.
Signed-off-by: Nick Desaulniers
---
drivers/acpi/acpica/dscontrol.c | 3 +--
drivers/acpi/acpica/dswexec.c | 4 +---
drivers/acpi/acpica/dswload.c | 3 +--
drivers/acpi/acpica/dswload2.c | 3 +--
drivers/acpi/acpica/exfldio.c | 3 +--
drivers/acpi/acpica/exresop.c | 5 ++---
drivers/acpi/acpica/exstore.c | 6 ++
drivers/acpi/acpica/hwgpe.c | 3 +--
drivers/acpi/acpica/utdelete.c | 3 +--
drivers/acpi/acpica/utprint.c | 2 +-
10 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/acpi/acpica/dscontrol.c b/drivers/acpi/acpica/dscontrol.c
index 4b5b6e859f62..1e75e5fbfd19 100644
--- a/drivers/acpi/acpica/dscontrol.c
+++ b/drivers/acpi/acpica/dscontrol.c
@@ -61,8 +61,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state
*walk_state,
break;
}
}
-
- /*lint -fallthrough */
+ fallthrough;
case AML_IF_OP:
/*
diff --git a/drivers/acpi/acpica/dswexec.c b/drivers/acpi/acpica/dswexec.c
index 1d4f8c81028c..e8c32d4fe55f 100644
--- a/drivers/acpi/acpica/dswexec.c
+++ b/drivers/acpi/acpica/dswexec.c
@@ -597,9 +597,7 @@ acpi_status acpi_ds_exec_end_op(struct acpi_walk_state
*walk_state)
if (ACPI_FAILURE(status)) {
break;
}
-
- /* Fall through */
- /*lint -fallthrough */
+ fallthrough;
case AML_INT_EVAL_SUBTREE_OP:
diff --git a/drivers/acpi/acpica/dswload.c b/drivers/acpi/acpica/dswload.c
index 27069325b6de..afc663c3742d 100644
--- a/drivers/acpi/acpica/dswload.c
+++ b/drivers/acpi/acpica/dswload.c
@@ -223,8 +223,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state *walk_state,
parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
break;
}
-
- /*lint -fallthrough */
+ fallthrough;
default:
diff --git a/drivers/acpi/acpica/dswload2.c b/drivers/acpi/acpica/dswload2.c
index edadbe146506..1b794b6ba072 100644
--- a/drivers/acpi/acpica/dswload2.c
+++ b/drivers/acpi/acpica/dswload2.c
@@ -213,8 +213,7 @@ acpi_ds_load2_begin_op(struct acpi_walk_state *walk_state,
parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
break;
}
-
- /*lint -fallthrough */
+ fallthrough;
default:
diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index ade35ff1c7ba..9d1cabe0fed9 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -433,8 +433,7 @@ acpi_ex_field_datum_io(union acpi_operand_object *obj_desc,
* Now that the Bank has been selected, fall through to the
* region_field case and write the datum to the Operation Region
*/
-
- /*lint -fallthrough */
+ fallthrough;
case ACPI_TYPE_LOCAL_REGION_FIELD:
/*
diff --git a/drivers/acpi/acpica/exresop.c b/drivers/acpi/acpica/exresop.c
index 4d1b22971d58..df48faa9a551 100644
--- a/drivers/acpi/acpica/exresop.c
+++ b/drivers/acpi/acpica/exresop.c
@@ -197,8 +197,7 @@ acpi_ex_resolve_operands(u16 opcode,
case ACPI_REFCLASS_DEBUG:
target_op = AML_DEBUG_OP;
-
- /*lint -fallthrough */
+ fallthrough;
case ACPI_REFCLASS_ARG:
case ACPI_REFCLASS_LOCAL:
@@ -264,7 +263,7 @@ acpi_ex_resolve_operands(u16 opcode,
* Else not a string - fall through to the normal
Reference
* case below
*/
- /*lint -fallthrough */
+ fallthrough;
RE: [PATCH][next] ACPICA: Use fallthrough pseudo-keyword
I'm afraid that the macro does not compile under MSVC:
warning C4067: unexpected tokens following preprocessor directive - expected a
newline (compiling source file ..\..\source\tools\acpiexec\aetests.c)
It looks like "__has_attribute" is not supported.
-Original Message-
From: Joe Perches
Sent: Monday, July 27, 2020 7:22 PM
To: Gustavo A. R. Silva ; Moore, Robert
; Rafael J. Wysocki ; Gustavo A. R.
Silva
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Len Brown ; ACPI Devel Maling
List ; open list:ACPI COMPONENT ARCHITECTURE
(ACPICA) ; Linux Kernel Mailing List
Subject: Re: [PATCH][next] ACPICA: Use fallthrough pseudo-keyword
On Mon, 2020-07-27 at 17:23 -0500, Gustavo A. R. Silva wrote:
> Hi,
>
>
> This is a macro pseudo-keyword, which expands to /* fallthrough */ for
> compilers that don't support the attribute __fallthrough__. See:
Not really.
It expands to
do {} while (0)
for compilers that do not support the __fallthrough__ attribute.
The /* fallthrough */ after that is for the human reader and is stripped before
compilation.
> include/linux/compiler_attributes.h:213:
> 213 #if __has_attribute(__fallthrough__)
> 214 # define fallthrough__attribute__((__fallthrough__))
> 215 #else
> 216 # define fallthroughdo {} while (0) /* fallthrough */
> 217 #endif
>
> So, any compiler (older or new) will be fine with it.
But old compilers should not emit warnings for these uses.
RE: [PATCH -next] ACPICA: Remove unneeded semicolon
Got it, thanks. Bob -Original Message- From: Zou Wei Sent: Tuesday, September 22, 2020 12:49 AM To: Moore, Robert ; Kaneda, Erik ; Wysocki, Rafael J ; l...@kernel.org Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Zou Wei Subject: [PATCH -next] ACPICA: Remove unneeded semicolon Fixes coccicheck warning: ./drivers/acpi/acpica/nsalloc.c:297:2-3: Unneeded semicolon Signed-off-by: Zou Wei --- drivers/acpi/acpica/nsalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/nsalloc.c b/drivers/acpi/acpica/nsalloc.c index fe9b363..83d26ab 100644 --- a/drivers/acpi/acpica/nsalloc.c +++ b/drivers/acpi/acpica/nsalloc.c @@ -294,7 +294,7 @@ void acpi_ns_delete_children(struct acpi_namespace_node *parent_node) node_to_delete = next_node; next_node = next_node->peer; acpi_ns_delete_node(node_to_delete); - }; + } /* Clear the parent's child pointer */ -- 2.6.2
RE: [PATCH][next] ACPICA: Use fallthrough pseudo-keyword
Yes, but:
include/linux/compiler_attributes.h
This file is linux-specific and cannot be used with ACPICA.
Bob
-Original Message-
From: Joe Perches
Sent: Monday, July 27, 2020 7:22 PM
To: Gustavo A. R. Silva ; Moore, Robert
; Rafael J. Wysocki ; Gustavo A. R.
Silva
Cc: Kaneda, Erik ; Wysocki, Rafael J
; Len Brown ; ACPI Devel Maling
List ; open list:ACPI COMPONENT ARCHITECTURE
(ACPICA) ; Linux Kernel Mailing List
Subject: Re: [PATCH][next] ACPICA: Use fallthrough pseudo-keyword
On Mon, 2020-07-27 at 17:23 -0500, Gustavo A. R. Silva wrote:
> Hi,
>
>
> This is a macro pseudo-keyword, which expands to /* fallthrough */ for
> compilers that don't support the attribute __fallthrough__. See:
Not really.
It expands to
do {} while (0)
for compilers that do not support the __fallthrough__ attribute.
The /* fallthrough */ after that is for the human reader and is stripped before
compilation.
> include/linux/compiler_attributes.h:213:
> 213 #if __has_attribute(__fallthrough__)
> 214 # define fallthrough__attribute__((__fallthrough__))
> 215 #else
> 216 # define fallthroughdo {} while (0) /* fallthrough */
> 217 #endif
>
> So, any compiler (older or new) will be fine with it.
But old compilers should not emit warnings for these uses.
RE: [PATCH] service_layers: osunixmap: Remove unnecessary brackets in acpi_os_map_memory()
- return (NULL);
+ return NULL;
This is the ACPICA coding standard, and it does not affect anything.
Bob
-Original Message-
From: Xu Wang
Sent: Thursday, July 09, 2020 1:08 AM
To: Moore, Robert ; Kaneda, Erik
; Wysocki, Rafael J ;
l...@kernel.org; vu...@iscas.ac.cn; linux-a...@vger.kernel.org; de...@acpica.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] service_layers: osunixmap: Remove unnecessary brackets in
acpi_os_map_memory()
Remove extra brackets.
Signed-off-by: Xu Wang
---
tools/power/acpi/os_specific/service_layers/osunixmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/power/acpi/os_specific/service_layers/osunixmap.c
b/tools/power/acpi/os_specific/service_layers/osunixmap.c
index c565546e85bc..52f3e70b5c81 100644
--- a/tools/power/acpi/os_specific/service_layers/osunixmap.c
+++ b/tools/power/acpi/os_specific/service_layers/osunixmap.c
@@ -70,7 +70,7 @@ void *acpi_os_map_memory(acpi_physical_address where,
acpi_size length)
fd = open(SYSTEM_MEMORY, O_RDONLY | O_BINARY);
if (fd < 0) {
fprintf(stderr, "Cannot open %s\n", SYSTEM_MEMORY);
- return (NULL);
+ return NULL;
}
/* Align the offset to use mmap */
@@ -85,7 +85,7 @@ void *acpi_os_map_memory(acpi_physical_address where,
acpi_size length)
if (mapped_memory == MAP_FAILED) {
fprintf(stderr, "Cannot map %s\n", SYSTEM_MEMORY);
close(fd);
- return (NULL);
+ return NULL;
}
close(fd);
--
2.17.1
RE: [PATCH][next] ACPICA: Use fallthrough pseudo-keyword
It looks like this attribute is not supported by msvc 2017 (and perhaps other
compilers) -- it is apparently a GCC extension -- meaning that it cannot be
used in the ACPICA compiler-independent code.
Bob
-Original Message-
From: Rafael J. Wysocki
Sent: Wednesday, July 08, 2020 3:59 AM
To: Gustavo A. R. Silva
Cc: Moore, Robert ; Kaneda, Erik
; Wysocki, Rafael J ; Len
Brown ; ACPI Devel Maling List ;
open list:ACPI COMPONENT ARCHITECTURE (ACPICA) ; Linux Kernel
Mailing List
Subject: Re: [PATCH][next] ACPICA: Use fallthrough pseudo-keyword
On Tue, Jul 7, 2020 at 10:01 PM Gustavo A. R. Silva
wrote:
>
> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
> fall-through markings when it is the case.
>
> [1]
> https://www.kernel.org/doc/html/latest/process/deprecated.html?highlig
> ht=fallthrough#implicit-switch-case-fall-through
>
> Signed-off-by: Gustavo A. R. Silva
I need to talk to Erik and Bob about this one.
> ---
> drivers/acpi/acpica/dscontrol.c |2 +-
> drivers/acpi/acpica/dswexec.c |3 +--
> drivers/acpi/acpica/dswload.c |2 +-
> drivers/acpi/acpica/dswload2.c |4 +---
> drivers/acpi/acpica/exfldio.c |2 +-
> drivers/acpi/acpica/exresop.c |4 ++--
> drivers/acpi/acpica/exstore.c |4 ++--
> drivers/acpi/acpica/hwgpe.c |3 +--
> drivers/acpi/acpica/utdelete.c |3 +--
> drivers/acpi/acpica/utprint.c |2 +-
> 10 files changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dscontrol.c
> b/drivers/acpi/acpica/dscontrol.c index 4b5b6e859f62..134d53380663
> 100644
> --- a/drivers/acpi/acpica/dscontrol.c
> +++ b/drivers/acpi/acpica/dscontrol.c
> @@ -62,7 +62,7 @@ acpi_ds_exec_begin_control_op(struct acpi_walk_state
> *walk_state,
> }
> }
>
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_IF_OP:
> /*
> diff --git a/drivers/acpi/acpica/dswexec.c
> b/drivers/acpi/acpica/dswexec.c index 1d4f8c81028c..41f6cb61778a
> 100644
> --- a/drivers/acpi/acpica/dswexec.c
> +++ b/drivers/acpi/acpica/dswexec.c
> @@ -598,8 +598,7 @@ acpi_status acpi_ds_exec_end_op(struct acpi_walk_state
> *walk_state)
> break;
> }
>
> - /* Fall through */
> - /*lint -fallthrough */
> + fallthrough;
>
> case AML_INT_EVAL_SUBTREE_OP:
>
> diff --git a/drivers/acpi/acpica/dswload.c
> b/drivers/acpi/acpica/dswload.c index 27069325b6de..1d8789869dda
> 100644
> --- a/drivers/acpi/acpica/dswload.c
> +++ b/drivers/acpi/acpica/dswload.c
> @@ -224,7 +224,7 @@ acpi_ds_load1_begin_op(struct acpi_walk_state *walk_state,
> break;
> }
>
> - /*lint -fallthrough */
> + fallthrough;
>
> default:
>
> diff --git a/drivers/acpi/acpica/dswload2.c
> b/drivers/acpi/acpica/dswload2.c index edadbe146506..de367e8e4cf4
> 100644
> --- a/drivers/acpi/acpica/dswload2.c
> +++ b/drivers/acpi/acpica/dswload2.c
> @@ -213,9 +213,7 @@ acpi_ds_load2_begin_op(struct acpi_walk_state *walk_state,
> parse_flags & ACPI_PARSE_MODULE_LEVEL)) {
> break;
> }
> -
> - /*lint -fallthrough */
> -
> + fallthrough;
> default:
>
> /* All other types are an error */ diff --git
> a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c index
> ade35ff1c7ba..677ba3ab1482 100644
> --- a/drivers/acpi/acpica/exfldio.c
> +++ b/drivers/acpi/acpica/exfldio.c
> @@ -434,7 +434,7 @@ acpi_ex_field_datum_io(union acpi_operand_object
> *obj_desc,
> * region_field case and write the datum to the Operation
> Region
> */
>
> - /*lint -fallthrough */
> + fallthrough;
>
> case ACPI_TYPE_LOCAL_REGION_FIELD:
> /*
> diff --git a/drivers/acpi/acpica/exresop.c
> b/drivers/acpi/acpica/exresop.c index 4d1b22971d58..7c8676adcf43
> 100644
> --- a/drivers/acpi/acpica/exresop.c
> +++ b/drivers/acpi/acpica/exresop.c
> @@ -198,7 +198,7 @@ acpi_ex_resolve_operands(u16 opcode,
>
> target_op = AML_DEBUG_OP;
>
> - /*lint -fallthrough */
> +
RE: [RFC PATCH 1/3] ACPICA: ACPI 6.3: PPTT add additional fields in Processor Structure Flags
John,
These #defines are all already in actbl2.h. Perhaps they didn't make it into
Linux.
Bob
-Original Message-
From: John Garry
Sent: Thursday, October 10, 2019 6:30 AM
To: catalin.mari...@arm.com; w...@kernel.org; r...@rjwysocki.net;
l...@kernel.org; Moore, Robert ; Schmauss, Erik
; sudeep.ho...@arm.com; rrich...@marvell.com;
jeremy.lin...@arm.com
Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
linux-a...@vger.kernel.org; linux...@huawei.com; gre...@linuxfoundation.org;
guohan...@huawei.com; wanghuiqi...@huawei.com; Wysocki, Rafael J
; John Garry
Subject: [RFC PATCH 1/3] ACPICA: ACPI 6.3: PPTT add additional fields in
Processor Structure Flags
From: Erik Schmauss
Commit b5eab512e7cffb2bb37c4b342b5594e9e75fd486 upstream.
ACPICA commit c736ea34add19a3a07e0e398711847cd6b95affd
Link: https://github.com/acpica/acpica/commit/c736ea34
Signed-off-by: Erik Schmauss
Signed-off-by: Bob Moore
Signed-off-by: Rafael J. Wysocki
Signed-off-by: John Garry
---
include/acpi/actbl2.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
c50ef7e6b942..1d4ef0621174 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -1472,8 +1472,11 @@ struct acpi_pptt_processor {
/* Flags */
-#define ACPI_PPTT_PHYSICAL_PACKAGE (1)/* Physical package */
-#define ACPI_PPTT_ACPI_PROCESSOR_ID_VALID (2)/* ACPI Processor ID
valid */
+#define ACPI_PPTT_PHYSICAL_PACKAGE (1)
+#define ACPI_PPTT_ACPI_PROCESSOR_ID_VALID (1<<1)
+#define ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD (1<<2) /* ACPI 6.3 */
+#define ACPI_PPTT_ACPI_LEAF_NODE(1<<3) /* ACPI 6.3 */
+#define ACPI_PPTT_ACPI_IDENTICAL(1<<4) /* ACPI 6.3 */
/* 1: Cache Type Structure */
--
2.17.1
RE: [PATCH] ACPICA: make acpi_load_table() return table index
How about this:
Go back to using acpi_tb_install_and_load_table(), but then call
acpi_ns_initialize_objects afterwards This is what acpi_load_table does.
ACPI_INFO (("Host-directed Dynamic ACPI Table Load:"));
Status = AcpiTbInstallAndLoadTable (ACPI_PTR_TO_PHYSADDR (Table),
ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE, &TableIndex);
if (ACPI_SUCCESS (Status))
{
/* Complete the initialization/resolution of new objects */
AcpiNsInitializeObjects ();
}
-Original Message-
From: Nikolaus Voss
Sent: Monday, September 23, 2019 2:05 AM
To: Moore, Robert
Cc: Ferry Toth ; Shevchenko, Andriy
; Schmauss, Erik ; Rafael
J. Wysocki ; Len Brown ; Jacek Anaszewski
; Pavel Machek ; Dan Murphy
; linux-a...@vger.kernel.org; de...@acpica.org;
linux-kernel@vger.kernel.org; Jan Kiszka
Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index
On Thu, 19 Sep 2019, Moore, Robert wrote:
>
>
> -Original Message-
> From: Nikolaus Voss [mailto:n...@vosn.de]
> Sent: Wednesday, September 18, 2019 7:32 AM
> To: Moore, Robert
> Cc: Ferry Toth ; Shevchenko, Andriy
> ; Schmauss, Erik
> ; Rafael J. Wysocki ; Len
> Brown ; Jacek Anaszewski
> ; Pavel Machek ; Dan Murphy
> ; linux-a...@vger.kernel.org; de...@acpica.org;
> linux-kernel@vger.kernel.org; Jan Kiszka
> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index
>
> On Wed, 18 Sep 2019, Moore, Robert wrote:
>>
>>
>> -Original Message-
>> From: Nikolaus Voss [mailto:n...@vosn.de]
>> Sent: Monday, September 16, 2019 2:47 AM
>> To: Moore, Robert
>> Cc: Ferry Toth ; Shevchenko, Andriy
>> ; Schmauss, Erik
>> ; Rafael J. Wysocki ; Len
>> Brown ; Jacek Anaszewski
>> ; Pavel Machek ; Dan Murphy
>> ; linux-a...@vger.kernel.org; de...@acpica.org;
>> linux-kernel@vger.kernel.org; Jan Kiszka
>> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table
>> index
>>
>> On Fri, 13 Sep 2019, Moore, Robert wrote:
>>>
>>>
>>> -Original Message-
>>> From: Ferry Toth [mailto:fnt...@gmail.com]
>>> Sent: Friday, September 13, 2019 9:48 AM
>>> To: Shevchenko, Andriy ; Moore, Robert
>>>
>>> Cc: Nikolaus Voss ; Schmauss, Erik
>>> ; Rafael J. Wysocki ;
>>> Len Brown ; Jacek Anaszewski
>>> ; Pavel Machek ; Dan
>>> Murphy ; linux-a...@vger.kernel.org;
>>> de...@acpica.org; linux-kernel@vger.kernel.org;
>>> nikolaus.v...@loewensteinmedical.de;
>>> Jan Kiszka
>>> Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table
>>> index
>>>
>>> Hello all,
>>>
>>> Sorry to have sent our message with cancelled e-mail address. I have
>>> correct this now.
>>>
>>> Op 13-09-19 om 17:12 schreef Shevchenko, Andriy:
>>>> On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote:
>>>>> -Original Message-
>>>>> From: Nikolaus Voss [mailto:n...@vosn.de]
>>>>> Sent: Friday, September 13, 2019 12:44 AM
>>>>> To: Moore, Robert
>>>>> Cc: Shevchenko, Andriy ; Schmauss,
>>>>> Erik ; Rafael J. Wysocki
>>>>> ; Len Brown ; Jacek Anaszewski
>>>>> ; Pavel Machek ; Dan
>>>>> Murphy ; linux-a...@vger.kernel.org;
>>>>> de...@acpica.org; linux-kernel@vger.kernel.org; Ferry Toth
>>>>> ; nikolaus.v...@loewensteinmedical.de
>>>>> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table
>>>>> index
>>>>>
>>>>> Bob,
>>>>>
>>>>> On Thu, 12 Sep 2019, Moore, Robert wrote:
>>>>>> The ability to unload an ACPI table (especially AML tables such
>>>>>> as
>>>>>> SSDTs) is in the process of being deprecated in ACPICA -- since
>>>>>> it is also deprecated in the current ACPI specification. This is
>>>>>> being done because of the difficulty of deleting the namespace
>>>>>> entries for the table. FYI, Windows does not properly support this
>>>>>> function either.
>>>>>
>>>>> ok, I see it can be a problem to unload an AML table with all it's
>>>>> consequences e.g. with respect to driver unregistering in setups
>>>>> with complex dependencies. It will only work properly under
>>>>> certain conditions
>>>>> - nevertheless acpi_tb_unload_table() is still exported in ACPICA and we
>>>>> should get this wor
RE: [PATCH] ACPICA: make acpi_load_table() return table index
-Original Message- From: Nikolaus Voss [mailto:n...@vosn.de] Sent: Wednesday, September 18, 2019 7:32 AM To: Moore, Robert Cc: Ferry Toth ; Shevchenko, Andriy ; Schmauss, Erik ; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Jan Kiszka Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index On Wed, 18 Sep 2019, Moore, Robert wrote: > > > -Original Message- > From: Nikolaus Voss [mailto:n...@vosn.de] > Sent: Monday, September 16, 2019 2:47 AM > To: Moore, Robert > Cc: Ferry Toth ; Shevchenko, Andriy > ; Schmauss, Erik > ; Rafael J. Wysocki ; Len > Brown ; Jacek Anaszewski > ; Pavel Machek ; Dan Murphy > ; linux-a...@vger.kernel.org; de...@acpica.org; > linux-kernel@vger.kernel.org; Jan Kiszka > Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index > > On Fri, 13 Sep 2019, Moore, Robert wrote: >> >> >> -Original Message- >> From: Ferry Toth [mailto:fnt...@gmail.com] >> Sent: Friday, September 13, 2019 9:48 AM >> To: Shevchenko, Andriy ; Moore, Robert >> >> Cc: Nikolaus Voss ; Schmauss, Erik >> ; Rafael J. Wysocki ; Len >> Brown ; Jacek Anaszewski >> ; Pavel Machek ; Dan Murphy >> ; linux-a...@vger.kernel.org; de...@acpica.org; >> linux-kernel@vger.kernel.org; nikolaus.v...@loewensteinmedical.de; >> Jan Kiszka >> Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table >> index >> >> Hello all, >> >> Sorry to have sent our message with cancelled e-mail address. I have correct >> this now. >> >> Op 13-09-19 om 17:12 schreef Shevchenko, Andriy: >>> On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote: >>>> -Original Message- >>>> From: Nikolaus Voss [mailto:n...@vosn.de] >>>> Sent: Friday, September 13, 2019 12:44 AM >>>> To: Moore, Robert >>>> Cc: Shevchenko, Andriy ; Schmauss, >>>> Erik ; Rafael J. Wysocki >>>> ; Len Brown ; Jacek Anaszewski >>>> ; Pavel Machek ; Dan >>>> Murphy ; linux-a...@vger.kernel.org; >>>> de...@acpica.org; linux-kernel@vger.kernel.org; Ferry Toth >>>> ; nikolaus.v...@loewensteinmedical.de >>>> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table >>>> index >>>> >>>> Bob, >>>> >>>> On Thu, 12 Sep 2019, Moore, Robert wrote: >>>>> The ability to unload an ACPI table (especially AML tables such as >>>>> SSDTs) is in the process of being deprecated in ACPICA -- since it >>>>> is also deprecated in the current ACPI specification. This is >>>>> being done because of the difficulty of deleting the namespace >>>>> entries for the table. FYI, Windows does not properly support this >>>>> function either. >>>> >>>> ok, I see it can be a problem to unload an AML table with all it's >>>> consequences e.g. with respect to driver unregistering in setups >>>> with complex dependencies. It will only work properly under certain >>>> conditions >>>> - nevertheless acpi_tb_unload_table() is still exported in ACPICA and we >>>> should get this working as it worked before. >>>> >>>> AcpiTbUnloadTable is not exported, it is an internal interface only >>>> -- as recognized by the "AcpiTb". >>> >>> In Linux it became a part of ABI when the >>> >>> commit 772bf1e2878ecfca0d1f332071c83e021dd9cf01 >>> Author: Jan Kiszka >>> Date: Fri Jun 9 20:36:31 2017 +0200 >>> >>> ACPI: configfs: Unload SSDT on configfs entry removal >>> >>> appeared in the kernel. >> >> And the commit message explains quite well why it is an important feature: >> >> "This allows to change SSDTs without rebooting the system. >> It also allows to destroy devices again that a dynamically loaded SSDT >> created. >> >> The biggest problem AFAIK is that under linux, many drivers cannot be >> unloaded. Also, there are many race conditions as the namespace entries >> "owned" by an SSDT being unloaded are deleted (out from underneath a driver). >> >> This is widely similar to the DT overlay behavior." >> >>>> I'm not sure that I want to change the interface to AcpiLoadTable >>>> just for something that is being deprecated. Already, we throw an >>>> ACPI_EXC
RE: [PATCH] ACPICA: make acpi_load_table() return table index
-Original Message- From: Nikolaus Voss [mailto:n...@vosn.de] Sent: Monday, September 16, 2019 2:47 AM To: Moore, Robert Cc: Ferry Toth ; Shevchenko, Andriy ; Schmauss, Erik ; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Jan Kiszka Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index On Fri, 13 Sep 2019, Moore, Robert wrote: > > > -Original Message- > From: Ferry Toth [mailto:fnt...@gmail.com] > Sent: Friday, September 13, 2019 9:48 AM > To: Shevchenko, Andriy ; Moore, Robert > > Cc: Nikolaus Voss ; Schmauss, Erik > ; Rafael J. Wysocki ; Len > Brown ; Jacek Anaszewski > ; Pavel Machek ; Dan Murphy > ; linux-a...@vger.kernel.org; de...@acpica.org; > linux-kernel@vger.kernel.org; nikolaus.v...@loewensteinmedical.de; Jan > Kiszka > Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table index > > Hello all, > > Sorry to have sent our message with cancelled e-mail address. I have correct > this now. > > Op 13-09-19 om 17:12 schreef Shevchenko, Andriy: >> On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote: >>> -Original Message- >>> From: Nikolaus Voss [mailto:n...@vosn.de] >>> Sent: Friday, September 13, 2019 12:44 AM >>> To: Moore, Robert >>> Cc: Shevchenko, Andriy ; Schmauss, Erik >>> ; Rafael J. Wysocki ; >>> Len Brown ; Jacek Anaszewski >>> ; Pavel Machek ; Dan >>> Murphy ; linux-a...@vger.kernel.org; >>> de...@acpica.org; linux-kernel@vger.kernel.org; Ferry Toth >>> ; nikolaus.v...@loewensteinmedical.de >>> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table >>> index >>> >>> Bob, >>> >>> On Thu, 12 Sep 2019, Moore, Robert wrote: >>>> The ability to unload an ACPI table (especially AML tables such as >>>> SSDTs) is in the process of being deprecated in ACPICA -- since it >>>> is also deprecated in the current ACPI specification. This is being >>>> done because of the difficulty of deleting the namespace entries >>>> for the table. FYI, Windows does not properly support this function >>>> either. >>> >>> ok, I see it can be a problem to unload an AML table with all it's >>> consequences e.g. with respect to driver unregistering in setups >>> with complex dependencies. It will only work properly under certain >>> conditions >>> - nevertheless acpi_tb_unload_table() is still exported in ACPICA and we >>> should get this working as it worked before. >>> >>> AcpiTbUnloadTable is not exported, it is an internal interface only >>> -- as recognized by the "AcpiTb". >> >> In Linux it became a part of ABI when the >> >> commit 772bf1e2878ecfca0d1f332071c83e021dd9cf01 >> Author: Jan Kiszka >> Date: Fri Jun 9 20:36:31 2017 +0200 >> >> ACPI: configfs: Unload SSDT on configfs entry removal >> >> appeared in the kernel. > > And the commit message explains quite well why it is an important feature: > > "This allows to change SSDTs without rebooting the system. > It also allows to destroy devices again that a dynamically loaded SSDT > created. > > The biggest problem AFAIK is that under linux, many drivers cannot be > unloaded. Also, there are many race conditions as the namespace entries > "owned" by an SSDT being unloaded are deleted (out from underneath a driver). > > This is widely similar to the DT overlay behavior." > >>> I'm not sure that I want to change the interface to AcpiLoadTable >>> just for something that is being deprecated. Already, we throw an >>> ACPI_EXCEPTION if the Unload operator is encountered in the AML byte >>> stream. The same thing with AcpiUnloadParentTable - it is being deprecated. >>> >>> ACPI_EXCEPTION ((AE_INFO, AE_NOT_IMPLEMENTED, >>> "AML Unload operator is not supported")); Bob, what is your suggestion to fix the regression then? We could revert acpi_configfs.c to use acpi_tb_install_and_load_table() instead of acpi_load_table(), leaving loaded APCI objects uninitalized, but at least, unloading will work again. I guess my next question is: why do you want to unload a table in the first place? Do we have any other options? Niko
RE: [PATCH] ACPICA: make acpi_load_table() return table index
-Original Message- From: Ferry Toth [mailto:fnt...@gmail.com] Sent: Friday, September 13, 2019 9:48 AM To: Shevchenko, Andriy ; Moore, Robert Cc: Nikolaus Voss ; Schmauss, Erik ; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; nikolaus.v...@loewensteinmedical.de; Jan Kiszka Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table index Hello all, Sorry to have sent our message with cancelled e-mail address. I have correct this now. Op 13-09-19 om 17:12 schreef Shevchenko, Andriy: > On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote: >> -Original Message- >> From: Nikolaus Voss [mailto:n...@vosn.de] >> Sent: Friday, September 13, 2019 12:44 AM >> To: Moore, Robert >> Cc: Shevchenko, Andriy ; Schmauss, Erik >> ; Rafael J. Wysocki ; Len >> Brown ; Jacek Anaszewski >> ; Pavel Machek ; Dan Murphy >> ; linux-a...@vger.kernel.org; de...@acpica.org; >> linux-kernel@vger.kernel.org; Ferry Toth ; >> nikolaus.v...@loewensteinmedical.de >> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table >> index >> >> Bob, >> >> On Thu, 12 Sep 2019, Moore, Robert wrote: >>> The ability to unload an ACPI table (especially AML tables such as >>> SSDTs) is in the process of being deprecated in ACPICA -- since it >>> is also deprecated in the current ACPI specification. This is being >>> done because of the difficulty of deleting the namespace entries for >>> the table. FYI, Windows does not properly support this function either. >> >> ok, I see it can be a problem to unload an AML table with all it's >> consequences e.g. with respect to driver unregistering in setups with >> complex dependencies. It will only work properly under certain >> conditions >> - nevertheless acpi_tb_unload_table() is still exported in ACPICA and we >> should get this working as it worked before. >> >> AcpiTbUnloadTable is not exported, it is an internal interface only >> -- as recognized by the "AcpiTb". > > In Linux it became a part of ABI when the > > commit 772bf1e2878ecfca0d1f332071c83e021dd9cf01 > Author: Jan Kiszka > Date: Fri Jun 9 20:36:31 2017 +0200 > > ACPI: configfs: Unload SSDT on configfs entry removal > > appeared in the kernel. And the commit message explains quite well why it is an important feature: "This allows to change SSDTs without rebooting the system. It also allows to destroy devices again that a dynamically loaded SSDT created. The biggest problem AFAIK is that under linux, many drivers cannot be unloaded. Also, there are many race conditions as the namespace entries "owned" by an SSDT being unloaded are deleted (out from underneath a driver). This is widely similar to the DT overlay behavior." >> I'm not sure that I want to change the interface to AcpiLoadTable >> just for something that is being deprecated. Already, we throw an >> ACPI_EXCEPTION if the Unload operator is encountered in the AML byte >> stream. The same thing with AcpiUnloadParentTable - it is being deprecated. >> >> ACPI_EXCEPTION ((AE_INFO, AE_NOT_IMPLEMENTED, >> "AML Unload operator is not supported")); >
RE: [PATCH] ACPICA: make acpi_load_table() return table index
-Original Message- From: Nikolaus Voss [mailto:n...@vosn.de] Sent: Friday, September 13, 2019 12:44 AM To: Moore, Robert Cc: Shevchenko, Andriy ; Schmauss, Erik ; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Ferry Toth ; nikolaus.v...@loewensteinmedical.de Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index Bob, On Thu, 12 Sep 2019, Moore, Robert wrote: > The ability to unload an ACPI table (especially AML tables such as > SSDTs) is in the process of being deprecated in ACPICA -- since it is > also deprecated in the current ACPI specification. This is being done > because of the difficulty of deleting the namespace entries for the > table. FYI, Windows does not properly support this function either. ok, I see it can be a problem to unload an AML table with all it's consequences e.g. with respect to driver unregistering in setups with complex dependencies. It will only work properly under certain conditions - nevertheless acpi_tb_unload_table() is still exported in ACPICA and we should get this working as it worked before. AcpiTbUnloadTable is not exported, it is an internal interface only -- as recognized by the "AcpiTb". I'm not sure that I want to change the interface to AcpiLoadTable just for something that is being deprecated. Already, we throw an ACPI_EXCEPTION if the Unload operator is encountered in the AML byte stream. The same thing with AcpiUnloadParentTable - it is being deprecated. ACPI_EXCEPTION ((AE_INFO, AE_NOT_IMPLEMENTED, "AML Unload operator is not supported")); The API change I request is not directly related to table unloading, it's just that the index of the loaded table is returned for future reference: [...] >> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index >> 3845c8fcc94e5..c90bbdc4146a6 100644 >> --- a/include/acpi/acpixf.h >> +++ b/include/acpi/acpixf.h >> @@ -452,7 +452,8 @@ ACPI_EXTERNAL_RETURN_STATUS(acpi_status >> ACPI_INIT_FUNCTION >> u8 physical)) >> >> ACPI_EXTERNAL_RETURN_STATUS(acpi_status >> -acpi_load_table(struct acpi_table_header *table)) >> +acpi_load_table(struct acpi_table_header *table, >> +u32 *table_idx)) >> >> ACPI_EXTERNAL_RETURN_STATUS(acpi_status >> acpi_unload_parent_table(acpi_handle object)) >> -- >> 2.17.1 >> This allows for a simple fix of the regression and doesn't imply future support for table unloading. Would this be acceptable? Niko
RE: [PATCH] ACPICA: make acpi_load_table() return table index
Nikolaus,
The ability to unload an ACPI table (especially AML tables such as SSDTs) is in
the process of being deprecated in ACPICA -- since it is also deprecated in the
current ACPI specification. This is being done because of the difficulty of
deleting the namespace entries for the table. FYI, Windows does not properly
support this function either.
Bob
-Original Message-
From: Nikolaus Voss [mailto:nikolaus.v...@loewensteinmedical.de]
Sent: Thursday, September 12, 2019 1:08 AM
To: Shevchenko, Andriy ; Schmauss, Erik
; Rafael J. Wysocki ; Moore,
Robert
Cc: Len Brown ; Jacek Anaszewski ;
Pavel Machek ; Dan Murphy ;
linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org;
n...@vosn.de; Nikolaus Voss
Subject: [PATCH] ACPICA: make acpi_load_table() return table index
For unloading an ACPI table, it is necessary to provide the index of the table.
The method intended for dynamically loading or hotplug addition of tables,
acpi_load_table(), should provide this information via an optional pointer to
the loaded table index.
This patch fixes the table unload function of acpi_configfs.
Reported-by: Andy Shevchenko
Fixes: d06c47e3dd07f ("ACPI: configfs: Resolve objects on host-directed table
loads")
Signed-off-by: Nikolaus Voss
---
drivers/acpi/acpi_configfs.c | 2 +-
drivers/acpi/acpica/dbfileio.c | 2 +-
drivers/acpi/acpica/tbxfload.c | 8 ++--
drivers/firmware/efi/efi.c | 2 +-
include/acpi/acpixf.h | 3 ++-
5 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c index
57d9d574d4dde..77f81242a28e6 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -53,7 +53,7 @@ static ssize_t acpi_table_aml_write(struct config_item *cfg,
if (!table->header)
return -ENOMEM;
- ret = acpi_load_table(table->header);
+ ret = acpi_load_table(table->header, &table->index);
if (ret) {
kfree(table->header);
table->header = NULL;
diff --git a/drivers/acpi/acpica/dbfileio.c b/drivers/acpi/acpica/dbfileio.c
index c6e25734dc5cd..e1b6e54a96ac1 100644
--- a/drivers/acpi/acpica/dbfileio.c
+++ b/drivers/acpi/acpica/dbfileio.c
@@ -93,7 +93,7 @@ acpi_status acpi_db_load_tables(struct acpi_new_table_desc
*list_head)
while (table_list_head) {
table = table_list_head->table;
- status = acpi_load_table(table);
+ status = acpi_load_table(table, NULL);
if (ACPI_FAILURE(status)) {
if (status == AE_ALREADY_EXISTS) {
acpi_os_printf
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 86f1693f6d29a..d08cd8ffcbdb6 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -268,7 +268,8 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_install_table)
*
* PARAMETERS: table - Pointer to a buffer containing the ACPI
*table to be loaded.
- *
+ * table_idx - Pointer to a u32 for storing the table
+ *index, might be NULL
* RETURN: Status
*
* DESCRIPTION: Dynamically load an ACPI table from the caller's buffer. Must
@@ -278,7 +279,7 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_install_table)
* to ensure that the table is not deleted or unmapped.
*
**/
-acpi_status acpi_load_table(struct acpi_table_header *table)
+acpi_status acpi_load_table(struct acpi_table_header *table, u32
+*table_idx)
{
acpi_status status;
u32 table_index;
@@ -297,6 +298,9 @@ acpi_status acpi_load_table(struct acpi_table_header *table)
status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
FALSE, &table_index);
+ if (table_idx)
+ *table_idx = table_index;
+
if (ACPI_SUCCESS(status)) {
/* Complete the initialization/resolution of new objects */
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index
ad3b1f4866b35..9773e4212baef 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -308,7 +308,7 @@ static __init int efivar_ssdt_load(void)
goto free_data;
}
- ret = acpi_load_table(data);
+ ret = acpi_load_table(data, NULL);
if (ret) {
pr_err("failed to load table: %d\n", ret);
goto free_data;
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index
3845c8fcc94e5..c90bbdc4146a6 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/ac
RE: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings
-Original Message- From: Schmauss, Erik Sent: Thursday, August 01, 2019 1:18 PM To: Qian Cai ; Moore, Robert ; Wysocki, Rafael J Cc: j...@freebsd.org; l...@kernel.org; ndesaulni...@google.com; linux-a...@vger.kernel.org; de...@acpica.org; clang-built-li...@googlegroups.com; linux-kernel@vger.kernel.org Subject: RE: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings > -Original Message- > From: Qian Cai [mailto:c...@lca.pw] > Sent: Thursday, August 1, 2019 12:16 PM > To: Moore, Robert ; Wysocki, Rafael J > > Cc: Schmauss, Erik ; j...@freebsd.org; > l...@kernel.org; ndesaulni...@google.com; linux-a...@vger.kernel.org; > de...@acpica.org; clang-built-li...@googlegroups.com; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings > > On Fri, 2019-07-26 at 19:35 +, Moore, Robert wrote: > > We've taken the change to ACPI_TO_POINTER. > > I am a bit confused here. I saw the commit in the acpia repo. > > https://github.com/acpica/acpica/commit/02bbca5070e42d298c9b824300aa0 > eb8a082d797 > > but how does that change will go into the linux kernel? Suppose Rafael > will need to pick it up manually? >I do that after every ACPICA release Which happens about once per month. >Erik > > > > > > > -Original Message- > > From: Qian Cai [mailto:c...@lca.pw] > > Sent: Thursday, July 18, 2019 12:49 PM > > To: Wysocki, Rafael J > > Cc: Moore, Robert ; Schmauss, Erik > > ; j...@freebsd.org; l...@kernel.org; > > ndesaulni...@google.com; linux-acpi @vger.kernel.org; > > de...@acpica.org; clang-built-li...@googlegroups.com; linux- > > ker...@vger.kernel.org; Qian Cai > > Subject: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings > > > > Clang generate quite a few of those warnings. > > > > drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer > > treated as a cast from integer to pointer is a GNU extension > > [-Wnull-pointer- > arithmetic] > > status = acpi_get_handle(ACPI_ROOT_OBJECT, > > obj->string.pointer, > > ^~~~ > > ./include/acpi/actypes.h:458:56: note: expanded from macro > 'ACPI_ROOT_OBJECT' > > #define ACPI_ROOT_OBJECT((acpi_handle) > > ACPI_TO_POINTER > > (ACPI_MAX_PTR)) > > ^~~ > > ./include/acpi/actypes.h:509:41: note: expanded from macro > 'ACPI_TO_POINTER' > > #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void > > *) 0, > > (acpi_size) (i)) > > > > ^~~ > > ./include/acpi/actypes.h:503:84: note: expanded from macro 'ACPI_ADD_PTR' > > #define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, > > (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b))) > > ^ > > ./include/acpi/actypes.h:501:66: note: expanded from macro > 'ACPI_CAST_PTR' > > #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) > > (p)) > > ^ > > This is because pointer arithmetic on a pointer not pointing to an > > array is an undefined behavior (C11 6.5.6, constraint 8). Fix it by > > just casting the corresponding pointers using ACPI_CAST_PTR() and > > skip the arithmetic. Also, fix a checkpatch warning together. > > > > ERROR: Macros with complex values should be enclosed in parentheses > > #45: FILE: include/acpi/actypes.h:509: > > +#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, i) > > > > Signed-off-by: Qian Cai > > --- > > > > v2: Use ACPI_CAST_PTR() in ACPI_TO_POINTER() directly without > > arithmetic. > > > > include/acpi/actypes.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index > > ad6892a24015..163181e2d884 100644 > > --- a/include/acpi/actypes.h > > +++ b/include/acpi/actypes.h > > @@ -506,7 +506,7 @@ typedef u64 acpi_integer; > > > > /* Pointer/Integer type conversions */ > > > > -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void > > *) 0, > > (acpi_size) (i)) > > +#define ACPI_TO_POINTER(i) (ACPI_CAST_PTR (void, i)) > > #define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) > > 0) > > #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) > > 0)->f), (void > > *) 0) > > #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i) > > -- > > 2.20.1 (Apple Git-117) > >
RE: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings
We've taken the change to ACPI_TO_POINTER. Thanks, Bob -Original Message- From: Qian Cai [mailto:c...@lca.pw] Sent: Thursday, July 18, 2019 12:49 PM To: Wysocki, Rafael J Cc: Moore, Robert ; Schmauss, Erik ; j...@freebsd.org; l...@kernel.org; ndesaulni...@google.com; linux-a...@vger.kernel.org; de...@acpica.org; clang-built-li...@googlegroups.com; linux-kernel@vger.kernel.org; Qian Cai Subject: [PATCH v2] acpica: fix -Wnull-pointer-arithmetic warnings Clang generate quite a few of those warnings. drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer treated as a cast from integer to pointer is a GNU extension [-Wnull-pointer-arithmetic] status = acpi_get_handle(ACPI_ROOT_OBJECT, obj->string.pointer, ^~~~ ./include/acpi/actypes.h:458:56: note: expanded from macro 'ACPI_ROOT_OBJECT' #define ACPI_ROOT_OBJECT((acpi_handle) ACPI_TO_POINTER (ACPI_MAX_PTR)) ^~~ ./include/acpi/actypes.h:509:41: note: expanded from macro 'ACPI_TO_POINTER' #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, (acpi_size) (i)) ^~~ ./include/acpi/actypes.h:503:84: note: expanded from macro 'ACPI_ADD_PTR' #define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b))) ^ ./include/acpi/actypes.h:501:66: note: expanded from macro 'ACPI_CAST_PTR' #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) ^ This is because pointer arithmetic on a pointer not pointing to an array is an undefined behavior (C11 6.5.6, constraint 8). Fix it by just casting the corresponding pointers using ACPI_CAST_PTR() and skip the arithmetic. Also, fix a checkpatch warning together. ERROR: Macros with complex values should be enclosed in parentheses #45: FILE: include/acpi/actypes.h:509: +#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, i) Signed-off-by: Qian Cai --- v2: Use ACPI_CAST_PTR() in ACPI_TO_POINTER() directly without arithmetic. include/acpi/actypes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index ad6892a24015..163181e2d884 100644 --- a/include/acpi/actypes.h +++ b/include/acpi/actypes.h @@ -506,7 +506,7 @@ typedef u64 acpi_integer; /* Pointer/Integer type conversions */ -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, (acpi_size) (i)) +#define ACPI_TO_POINTER(i) (ACPI_CAST_PTR (void, i)) #define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0) #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0) #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i) -- 2.20.1 (Apple Git-117)
RE: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings
-Original Message- From: Qian Cai [mailto:c...@lca.pw] Sent: Wednesday, July 24, 2019 6:40 AM To: Moore, Robert ; Nick Desaulniers Cc: Wysocki, Rafael J ; Schmauss, Erik ; j...@freebsd.org; Len Brown ; linux-a...@vger.kernel.org; de...@acpica.org; clang-built-linux ; LKML Subject: Re: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings On Tue, 2019-07-23 at 20:49 +, Moore, Robert wrote: > > > Signed-off-by: Qian Cai > > > --- > > > include/acpi/actypes.h | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index > > > ad6892a24015..25b4a32da177 100644 > > > --- a/include/acpi/actypes.h > > > +++ b/include/acpi/actypes.h > > > @@ -500,13 +500,13 @@ typedef u64 acpi_integer; > > > > > > #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) > > > (p)) #define ACPI_CAST_INDIRECT_PTR(t, p)((t **) > > > (acpi_uintptr_t) (p)) -#define ACPI_ADD_PTR(t, a, b) > > > ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b))) > > > +#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (a) + > > > (acpi_size)(b)) > > We have some questions concerning this change. If (a) is not cast to a > u8, the addition will be in whatever units are appropriate for (a) > i.e., the type of (a). However, we want ACPI_ADD_PTR (And > ACPI_SUB_PTR) to simply perform a byte addition or subtraction - thus > the cast to u8. I believe that is the original thinking behind the macros. I posted a v2 a while ago, and should clear this concern. OK then this change only affects ACPI_TO_POINTER? +#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, i) > > > > #define ACPI_SUB_PTR(t, a, b) ACPI_CAST_PTR (t, > > > (ACPI_CAST_PTR (u8, (a)) - (acpi_size)(b))) #define > > > ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, > > > (a)) - ACPI_CAST_PTR (u8, (b > > > > > > /* Pointer/Integer type conversions */ > > > > > > -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void > > > *) 0, > > > (acpi_size) (i)) > > > +#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, 0, > > > (acpi_size) (i)) > > > > IIUC, these are adding `i` to NULL (or (void*)0)? X + 0 == X ? > > -- > > Thanks, > > ~Nick Desaulniers > >
RE: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings
-Original Message- From: Qian Cai [mailto:c...@lca.pw] Sent: Wednesday, July 17, 2019 5:50 PM To: Nick Desaulniers Cc: Wysocki, Rafael J ; Moore, Robert ; Schmauss, Erik ; j...@freebsd.org; Len Brown ; linux-a...@vger.kernel.org; de...@acpica.org; clang-built-linux ; LKML Subject: Re: [PATCH] acpica: fix -Wnull-pointer-arithmetic warnings > On Jul 17, 2019, at 6:01 PM, Nick Desaulniers wrote: > > On Tue, Jul 16, 2019 at 8:38 PM Qian Cai wrote: >> >> Clang generate quite a few of those warnings. >> >> drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer >> treated as a cast from integer to pointer is a GNU extension >> [-Wnull-pointer-arithmetic] >>status = acpi_get_handle(ACPI_ROOT_OBJECT, >> obj->string.pointer, >> ^~~~ >> ./include/acpi/actypes.h:458:56: note: expanded from macro >> 'ACPI_ROOT_OBJECT' >> #define ACPI_ROOT_OBJECT((acpi_handle) ACPI_TO_POINTER >> (ACPI_MAX_PTR)) >> >> ^~~ >> ./include/acpi/actypes.h:509:41: note: expanded from macro >> 'ACPI_TO_POINTER' >> #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, >> (acpi_size) (i)) >> >> ^~~ >> ./include/acpi/actypes.h:503:84: note: expanded from macro >> 'ACPI_ADD_PTR' >> #define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, >> (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b))) >> ^ >> ./include/acpi/actypes.h:501:66: note: expanded from macro >> 'ACPI_CAST_PTR' >> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >> ^ >> This is because pointer arithmetic on a pointer not pointing to an >> array is an undefined behavior. Fix it by doing an integer arithmetic >> instead. > > Hi Qian, thanks for the patch. How do I reproduce this issue, > precisely? I just tried: > $ make CC=clang -j71 drivers/acpi/scan.o on linux-next today and don't > observe the warning. My clang is ToT built sometime this week. It > looks like drivers/acpi/scan.o when CONFIG_ACPI=y, which is set in the > defconfig. Is there another set of configs to enable to observe the > warning? # make W=1 -j 256 With the config, https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config > > Also, the fix is curious. Arithmetic on pointers to different > "objects" (with one element passed the end) may lead to provence > issues due to undefined behavior, but I would have expected some cases > to uintptr_t, then arithmetic on that type, as the solution (which is > what I suspect ACPI_CAST_PTR is doing). > > Further, you seem to have modified ACPI_ADD_PTR but not ACPI_SUB_PTR; > I would have expected both to be afflicted together or not at all > based on their existing implementations. Yes, I thought about that, but ACPI_SUB_PTR does not seem used anywhere, so I thought maybe just start a new discussion to remove it all together later. ACPI_SUB_PTR is used in the iasl data table compiler. > >> >> Signed-off-by: Qian Cai >> --- >> include/acpi/actypes.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index >> ad6892a24015..25b4a32da177 100644 >> --- a/include/acpi/actypes.h >> +++ b/include/acpi/actypes.h >> @@ -500,13 +500,13 @@ typedef u64 acpi_integer; >> >> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >> #define ACPI_CAST_INDIRECT_PTR(t, p)((t **) (acpi_uintptr_t) (p)) >> -#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR >> (u8, (a)) + (acpi_size)(b))) >> +#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (a) + >> (acpi_size)(b)) We have some questions concerning this change. If (a) is not cast to a u8, the addition will be in whatever units are appropriate for (a) i.e., the type of (a). However, we want ACPI_ADD_PTR (And ACPI_SUB_PTR) to simply perform a byte addition or subtraction - thus the cast to u8. I believe that is the original thinking behind the macros. >> #define ACPI_SUB_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR >> (u8, (a)) - (acpi_size)(b))) >> #define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, >> (a)) - ACPI_CAST_PTR (u8, (b >> >> /* Pointer/Integer type conversions */ >> >> -#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) 0, >> (acpi_size) (i)) >> +#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, 0, (acpi_size) >> (i)) > > IIUC, these are adding `i` to NULL (or (void*)0)? X + 0 == X ? > -- > Thanks, > ~Nick Desaulniers
RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads
> -Original Message-
> From: Nikolaus Voss [mailto:n...@vosn.de]
> Sent: Wednesday, June 19, 2019 2:31 AM
> To: Moore, Robert
> Cc: Rafael J. Wysocki ; Rafael J. Wysocki
> ; Len Brown ; Schmauss, Erik
> ; Jacek Anaszewski
> ; Pavel Machek ; Dan Murphy
> ; Thierry Reding ; ACPI Devel
> Maling List ; open list:ACPI COMPONENT
> ARCHITECTURE (ACPICA) ; linux-l...@vger.kernel.org;
> Linux PWM List ; Linux Kernel Mailing List
> ; nikolaus.v...@loewensteinmedical.de
> Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table
> loads
>
> Hi Bob,
>
> On Tue, 18 Jun 2019, Moore, Robert wrote:
> >
> >
> >> -Original Message-
> >> From: Moore, Robert
> >> Sent: Tuesday, June 18, 2019 1:25 PM
> >> To: 'Nikolaus Voss'
> >> Cc: 'Rafael J. Wysocki' ; 'Rafael J. Wysocki'
> >> ; 'Len Brown' ; Schmauss, Erik
> >> ; 'Jacek Anaszewski'
> >> ; 'Pavel Machek' ; 'Dan
> >> Murphy' ; 'Thierry Reding'
> >> ; 'ACPI Devel Maling List'
> >> ; 'open list:ACPI COMPONENT ARCHITECTURE
> >> (ACPICA)' ; 'linux- l...@vger.kernel.org' l...@vger.kernel.org>; 'Linux PWM List'
> >> ; 'Linux Kernel Mailing List' >> ker...@vger.kernel.org>
> >> Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed
> >> table loads
> >>
> >> If it is in fact the AcpiLoadTable interface that is incorrect, that
> >> of course is different. I'll check that out next.
> >>
> > [Moore, Robert]
> >
> > Yes, this is the issue, not specifically the Load() operator, but the
> > AcpiLoadTable interface only.
>
> thanks for checking this out. So what is the conclusion? Is my fix of
> AcpiLoadTable() sufficient or do we need a different solution?
>
> Niko
>
Your change is in the correct area. We want to do something like this, however:
diff --git a/source/components/executer/exconfig.c
b/source/components/executer/exconfig.c
index 84a058ada..eba1a6d28 100644
--- a/source/components/executer/exconfig.c
+++ b/source/components/executer/exconfig.c
@@ -342,10 +342,9 @@ AcpiExLoadTableOp (
return_ACPI_STATUS (Status);
}
-/* Complete the initialization/resolution of package objects */
+/* Complete the initialization/resolution of new objects */
-Status = AcpiNsWalkNamespace (ACPI_TYPE_PACKAGE, ACPI_ROOT_OBJECT,
-ACPI_UINT32_MAX, 0, AcpiNsInitOnePackage, NULL, NULL, NULL);
+AcpiNsInitializeObjects ();
/* Parameter Data (optional) */
@@ -620,10 +619,11 @@ AcpiExLoadOp (
return_ACPI_STATUS (Status);
}
-/* Complete the initialization/resolution of package objects */
+/* Complete the initialization/resolution of new objects */
-Status = AcpiNsWalkNamespace (ACPI_TYPE_PACKAGE, ACPI_ROOT_OBJECT,
-ACPI_UINT32_MAX, 0, AcpiNsInitOnePackage, NULL, NULL, NULL);
+AcpiExExitInterpreter ();
+AcpiNsInitializeObjects ();
+AcpiExEnterInterpreter ();
/* Store the DdbHandle into the Target operand */
diff --git a/source/components/tables/tbxfload.c
b/source/components/tables/tbxfload.c
index 217d54bf0..1e17db6c8 100644
--- a/source/components/tables/tbxfload.c
+++ b/source/components/tables/tbxfload.c
@@ -479,6 +479,13 @@ AcpiLoadTable (
ACPI_INFO (("Host-directed Dynamic ACPI Table Load:"));
Status = AcpiTbInstallAndLoadTable (ACPI_PTR_TO_PHYSADDR (Table),
ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE, &TableIndex);
+if (ACPI_SUCCESS (Status))
+{
+/* Complete the initialization/resolution of new objects */
+
+AcpiNsInitializeObjects ();
+}
+
return_ACPI_STATUS (Status);
}
> [...]
RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads
> -Original Message-
> From: Moore, Robert
> Sent: Tuesday, June 18, 2019 1:25 PM
> To: 'Nikolaus Voss'
> Cc: 'Rafael J. Wysocki' ; 'Rafael J. Wysocki'
> ; 'Len Brown' ; Schmauss, Erik
> ; 'Jacek Anaszewski'
> ; 'Pavel Machek' ; 'Dan
> Murphy' ; 'Thierry Reding' ;
> 'ACPI Devel Maling List' ; 'open list:ACPI
> COMPONENT ARCHITECTURE (ACPICA)' ; 'linux-
> l...@vger.kernel.org' ; 'Linux PWM List'
> ; 'Linux Kernel Mailing List' ker...@vger.kernel.org>
> Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table
> loads
>
> If it is in fact the AcpiLoadTable interface that is incorrect, that of
> course is different. I'll check that out next.
>
[Moore, Robert]
Yes, this is the issue, not specifically the Load() operator, but the
AcpiLoadTable interface only.
>
> > -Original Message-
> > From: Moore, Robert
> > Sent: Tuesday, June 18, 2019 1:23 PM
> > To: 'Nikolaus Voss'
> > Cc: 'Rafael J. Wysocki' ; 'Rafael J. Wysocki'
> > ; 'Len Brown' ; Schmauss, Erik
> > ; 'Jacek Anaszewski'
> > ; 'Pavel Machek' ; 'Dan
> > Murphy' ; 'Thierry Reding' ;
> > 'ACPI Devel Maling List' ; 'open list:ACPI
> > COMPONENT ARCHITECTURE (ACPICA)' ; 'linux-
> > l...@vger.kernel.org' ; 'Linux PWM List'
> > ; 'Linux Kernel Mailing List' > ker...@vger.kernel.org>
> > Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed
> > table loads
> >
> > It looks to me that the package objects are being initialized properly
> > already, unless I'm missing something. Please check the examples below
> > and in the attached files.
> >
> > Attached is a small test case that dynamically loads an SSDT which
> > contains a package object which in turn contains references to other
> > objects.
> >
> >
> > Main DSDT:
> > Method (LD1)
> > {
> > Load (BUF1, HNDL) // SSDT is in BUF1
> > Store (HNDL, Debug)
> > Return
> > }
> >
> > Loaded table:
> > External (DEV1, DeviceObj)
> > Name (PKG1, Package() {
> > 1,2, DEV2, DEV1, 4})
> > Device (DEV2) {}
> >
> >
> > AcpiExec Output:
> > - ev ld1
> > Evaluating \LD1
> > ACPI: Dynamic OEM Table Load:
> > ACPI: SSDT 0x006DEEB8 51 (v02 Intel Load 0001
> INTL
> > 20190509)
> > ACPI Exec: Table Event INSTALL, [SSDT] 006DEEB8
> > Table [SSDT: Load] (id 06) -5 Objects with 1 Devices, 0
> > Regions,1 Methods
> > ACPI Exec: Table Event LOAD, [SSDT] 006DEEB8 ACPI Debug: Reference
> > [DdbHandle] Table Index 0x3
> > 0x7 Outstanding allocations after evaluation of \LD1 Evaluation of
> > \LD1 returned object 006D2FE8, external buffer length 18
> > [Integer] =
> >
> > - ev pkg1
> > Evaluating \PKG1
> > Evaluation of \PKG1 returned object 006D2FE8, external buffer length
> 90
> > [Package] Contains 5 Elements:
> > [Integer] = 0001
> > [Integer] = 0002
> > [Object Reference] = 006DDF88 Name DEV2 Device
> > [Object Reference] = 006DD608 Name DEV1 Device
> > [Integer] = 0004
RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads
If it is in fact the AcpiLoadTable interface that is incorrect, that of course
is different. I'll check that out next.
> -Original Message-
> From: Moore, Robert
> Sent: Tuesday, June 18, 2019 1:23 PM
> To: 'Nikolaus Voss'
> Cc: 'Rafael J. Wysocki' ; 'Rafael J. Wysocki'
> ; 'Len Brown' ; Schmauss, Erik
> ; 'Jacek Anaszewski'
> ; 'Pavel Machek' ; 'Dan
> Murphy' ; 'Thierry Reding' ;
> 'ACPI Devel Maling List' ; 'open list:ACPI
> COMPONENT ARCHITECTURE (ACPICA)' ; 'linux-
> l...@vger.kernel.org' ; 'Linux PWM List'
> ; 'Linux Kernel Mailing List' ker...@vger.kernel.org>
> Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table
> loads
>
> It looks to me that the package objects are being initialized properly
> already, unless I'm missing something. Please check the examples below
> and in the attached files.
>
> Attached is a small test case that dynamically loads an SSDT which
> contains a package object which in turn contains references to other
> objects.
>
>
> Main DSDT:
> Method (LD1)
> {
> Load (BUF1, HNDL) // SSDT is in BUF1
> Store (HNDL, Debug)
> Return
> }
>
> Loaded table:
> External (DEV1, DeviceObj)
> Name (PKG1, Package() {
> 1,2, DEV2, DEV1, 4})
> Device (DEV2) {}
>
>
> AcpiExec Output:
> - ev ld1
> Evaluating \LD1
> ACPI: Dynamic OEM Table Load:
> ACPI: SSDT 0x006DEEB8 51 (v02 Intel Load 0001 INTL
> 20190509)
> ACPI Exec: Table Event INSTALL, [SSDT] 006DEEB8
> Table [SSDT: Load] (id 06) -5 Objects with 1 Devices, 0
> Regions,1 Methods
> ACPI Exec: Table Event LOAD, [SSDT] 006DEEB8 ACPI Debug: Reference
> [DdbHandle] Table Index 0x3
> 0x7 Outstanding allocations after evaluation of \LD1 Evaluation of \LD1
> returned object 006D2FE8, external buffer length 18
> [Integer] =
>
> - ev pkg1
> Evaluating \PKG1
> Evaluation of \PKG1 returned object 006D2FE8, external buffer length 90
> [Package] Contains 5 Elements:
> [Integer] = 0001
> [Integer] = 0002
> [Object Reference] = 006DDF88 Name DEV2 Device
> [Object Reference] = 006DD608 Name DEV1 Device
> [Integer] = 0004
RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads
It looks to me that the package objects are being initialized properly already,
unless I'm missing something. Please check the examples below and in the
attached files.
Attached is a small test case that dynamically loads an SSDT which contains a
package object which in turn contains references to other objects.
Main DSDT:
Method (LD1)
{
Load (BUF1, HNDL) // SSDT is in BUF1
Store (HNDL, Debug)
Return
}
Loaded table:
External (DEV1, DeviceObj)
Name (PKG1, Package() {
1,2, DEV2, DEV1, 4})
Device (DEV2) {}
AcpiExec Output:
- ev ld1
Evaluating \LD1
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0x006DEEB8 51 (v02 Intel Load 0001 INTL
20190509)
ACPI Exec: Table Event INSTALL, [SSDT] 006DEEB8
Table [SSDT: Load] (id 06) -5 Objects with 1 Devices, 0 Regions,
1 Methods
ACPI Exec: Table Event LOAD, [SSDT] 006DEEB8
ACPI Debug: Reference [DdbHandle] Table Index 0x3
0x7 Outstanding allocations after evaluation of \LD1
Evaluation of \LD1 returned object 006D2FE8, external buffer length 18
[Integer] =
- ev pkg1
Evaluating \PKG1
Evaluation of \PKG1 returned object 006D2FE8, external buffer length 90
[Package] Contains 5 Elements:
[Integer] = 0001
[Integer] = 0002
[Object Reference] = 006DDF88 Name DEV2 Device
[Object Reference] = 006DD608 Name DEV1 Device
[Integer] = 0004
loadedtable.asl
Description: loadedtable.asl
tableinit.asl
Description: tableinit.asl
loadedtable.hex
Description: loadedtable.hex
RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads
I'm looking at this. We've changed the initialization of objects in the namespace recently, so I'm checking this out. > -Original Message- > From: Nikolaus Voss [mailto:n...@vosn.de] > Sent: Tuesday, June 18, 2019 2:22 AM > To: Moore, Robert > Cc: Rafael J. Wysocki ; Rafael J. Wysocki > ; Len Brown ; Schmauss, Erik > ; Jacek Anaszewski > ; Pavel Machek ; Dan Murphy > ; Thierry Reding ; ACPI Devel > Maling List ; open list:ACPI COMPONENT > ARCHITECTURE (ACPICA) ; linux-l...@vger.kernel.org; > Linux PWM List ; Linux Kernel Mailing List > > Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table > loads > > On Mon, 17 Jun 2019, Moore, Robert wrote: > >> -Original Message- > >> From: Nikolaus Voss [mailto:n...@vosn.de] > >> Sent: Sunday, June 16, 2019 11:24 PM > >> To: Moore, Robert > >> Cc: Rafael J. Wysocki ; Rafael J. Wysocki > >> ; Len Brown ; Schmauss, Erik > >> ; Jacek Anaszewski > >> ; Pavel Machek ; Dan Murphy > >> ; Thierry Reding ; ACPI > >> Devel Maling List ; open list:ACPI > >> COMPONENT ARCHITECTURE (ACPICA) ; > >> linux-l...@vger.kernel.org; Linux PWM List > >> ; Linux Kernel Mailing List > >> ; nikolaus.v...@loewensteinmedical.de > >> Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed > >> table loads > >> > >> Bob, > >> > >> On Fri, 14 Jun 2019, Moore, Robert wrote: > >>> > >>> > >>> -Original Message- > >>> From: Nikolaus Voss [mailto:n...@vosn.de] > >>> Sent: Friday, June 14, 2019 2:26 AM > >>> To: Rafael J. Wysocki > >>> Cc: Rafael J. Wysocki ; Len Brown > >>> ; Moore, Robert ; Schmauss, > >>> Erik ; Jacek Anaszewski > >>> ; Pavel Machek ; Dan > >>> Murphy ; Thierry Reding ; > >>> ACPI Devel Maling List ; open list:ACPI > >>> COMPONENT ARCHITECTURE (ACPICA) ; > >>> linux-l...@vger.kernel.org; Linux PWM List > >>> ; Linux Kernel Mailing List > >>> > >>> Subject: Re: [PATCH v2 1/3] ACPI: Resolve objects on host-directed > >>> table loads > >>> > >>> Hi Rafael, > >>> > >>> On Fri, 14 Jun 2019, Rafael J. Wysocki wrote: > >>>> On Wed, Jun 12, 2019 at 10:36 AM Nikolaus Voss > >>>> wrote: > >>>>> > >>>>> If an ACPI SSDT overlay is loaded after built-in tables have been > >>>>> loaded e.g. via configfs or efivar_ssdt_load() it is necessary to > >>>>> rewalk the namespace to resolve references. Without this, relative > >>>>> and absolute paths like ^PCI0.SBUS or \_SB.PCI0.SBUS are not > >>>>> resolved correctly. > >>>>> > >>>>> Make configfs load use the same method as efivar_ssdt_load(). > >>>>> > >>>>> Signed-off-by: Nikolaus Voss > >>>> > >>>> This is fine by me, so > >>>> > >>>> Acked-by: Rafael J. Wysocki > >>>> > >>>> Or if you want me to take this patch (without the other two in the > >>>> series), please let me know. > >>> > >>> thanks. I think it would be the best if you take up this patch as it > >>> is an independent topic. In retrospect it wasn't a good idea to put > >>> it into this series. > >>> > >>> Kind regards, > >>> Niko > >>> > >>> I would have to ask, why is additional code needed for package > >>> initialization/resolution? It already happens elsewhere in acpica. > >>> Bob > >> > >> for built-in tables loaded via acpi_ex_load_table_op() everything is > >> fine, because after acpi_tb_load_table() acpi_ns_walk_namespace() is > >> called to resolve references. > >> > >> My fix only affects tables loaded dynamically via either > >> acpi_configfs driver (for debugging purposes) or efivar_ssdt_load() > >> (to specify a table on the kernel's command line). They use > >> acpi_load_table() to load the table from a caller-owned buffer. To > >> resolve the references, it is again necessary to rewalk the > >> namespace, which was simply missing in acpi_load_table(). > >> > > [Moore, Robert] > > > > Perhaps you should call AcpiInitializeObjects after the call to > > AcpiLoadTable, but I will check. > > My usage of acpi_load_table() is to load a SSDT which is the intended > use of this method according to its description. And my expectation is > that the package objects of the loaded table are initialized when this > function successfully returns so it aligns with the behavior of > acpi_ex_load_table_op() for built-in SSDTs. Otherwise there would be no > point in having this function at all, because > acpi_tb_install_and_load_table() could be called directly without any > difference. > > Niko
RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads
> -Original Message- > From: Nikolaus Voss [mailto:n...@vosn.de] > Sent: Sunday, June 16, 2019 11:24 PM > To: Moore, Robert > Cc: Rafael J. Wysocki ; Rafael J. Wysocki > ; Len Brown ; Schmauss, Erik > ; Jacek Anaszewski > ; Pavel Machek ; Dan Murphy > ; Thierry Reding ; ACPI Devel > Maling List ; open list:ACPI COMPONENT > ARCHITECTURE (ACPICA) ; linux-l...@vger.kernel.org; > Linux PWM List ; Linux Kernel Mailing List > ; nikolaus.v...@loewensteinmedical.de > Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table > loads > > Bob, > > On Fri, 14 Jun 2019, Moore, Robert wrote: > > > > > > -Original Message- > > From: Nikolaus Voss [mailto:n...@vosn.de] > > Sent: Friday, June 14, 2019 2:26 AM > > To: Rafael J. Wysocki > > Cc: Rafael J. Wysocki ; Len Brown > > ; Moore, Robert ; Schmauss, > > Erik ; Jacek Anaszewski > > ; Pavel Machek ; Dan Murphy > > ; Thierry Reding ; ACPI > > Devel Maling List ; open list:ACPI > > COMPONENT ARCHITECTURE (ACPICA) ; > > linux-l...@vger.kernel.org; Linux PWM List > > ; Linux Kernel Mailing List > > > > Subject: Re: [PATCH v2 1/3] ACPI: Resolve objects on host-directed > > table loads > > > > Hi Rafael, > > > > On Fri, 14 Jun 2019, Rafael J. Wysocki wrote: > >> On Wed, Jun 12, 2019 at 10:36 AM Nikolaus Voss > >> wrote: > >>> > >>> If an ACPI SSDT overlay is loaded after built-in tables have been > >>> loaded e.g. via configfs or efivar_ssdt_load() it is necessary to > >>> rewalk the namespace to resolve references. Without this, relative > >>> and absolute paths like ^PCI0.SBUS or \_SB.PCI0.SBUS are not > >>> resolved correctly. > >>> > >>> Make configfs load use the same method as efivar_ssdt_load(). > >>> > >>> Signed-off-by: Nikolaus Voss > >> > >> This is fine by me, so > >> > >> Acked-by: Rafael J. Wysocki > >> > >> Or if you want me to take this patch (without the other two in the > >> series), please let me know. > > > > thanks. I think it would be the best if you take up this patch as it > > is an independent topic. In retrospect it wasn't a good idea to put it > > into this series. > > > > Kind regards, > > Niko > > > > I would have to ask, why is additional code needed for package > > initialization/resolution? It already happens elsewhere in acpica. Bob > > for built-in tables loaded via acpi_ex_load_table_op() everything is > fine, because after acpi_tb_load_table() acpi_ns_walk_namespace() is > called to resolve references. > > My fix only affects tables loaded dynamically via either acpi_configfs > driver (for debugging purposes) or efivar_ssdt_load() (to specify a > table on the kernel's command line). They use acpi_load_table() to load > the table from a caller-owned buffer. To resolve the references, it is > again necessary to rewalk the namespace, which was simply missing in > acpi_load_table(). > [Moore, Robert] Perhaps you should call AcpiInitializeObjects after the call to AcpiLoadTable, but I will check. > Niko
RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads
-Original Message- From: Nikolaus Voss [mailto:n...@vosn.de] Sent: Friday, June 14, 2019 2:26 AM To: Rafael J. Wysocki Cc: Rafael J. Wysocki ; Len Brown ; Moore, Robert ; Schmauss, Erik ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; Thierry Reding ; ACPI Devel Maling List ; open list:ACPI COMPONENT ARCHITECTURE (ACPICA) ; linux-l...@vger.kernel.org; Linux PWM List ; Linux Kernel Mailing List Subject: Re: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads Hi Rafael, On Fri, 14 Jun 2019, Rafael J. Wysocki wrote: > On Wed, Jun 12, 2019 at 10:36 AM Nikolaus Voss > wrote: >> >> If an ACPI SSDT overlay is loaded after built-in tables have been >> loaded e.g. via configfs or efivar_ssdt_load() it is necessary to >> rewalk the namespace to resolve references. Without this, relative >> and absolute paths like ^PCI0.SBUS or \_SB.PCI0.SBUS are not resolved >> correctly. >> >> Make configfs load use the same method as efivar_ssdt_load(). >> >> Signed-off-by: Nikolaus Voss > > This is fine by me, so > > Acked-by: Rafael J. Wysocki > > Or if you want me to take this patch (without the other two in the > series), please let me know. thanks. I think it would be the best if you take up this patch as it is an independent topic. In retrospect it wasn't a good idea to put it into this series. Kind regards, Niko I would have to ask, why is additional code needed for package initialization/resolution? It already happens elsewhere in acpica. Bob [...]
RE: [PATCH v2] ACPI / device_sysfs: change _ADR representation to 64 bits
> -Original Message-
> From: Pierre-Louis Bossart [mailto:pierre-louis.boss...@linux.intel.com]
> Sent: Wednesday, May 1, 2019 5:53 AM
> To: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org; ti...@suse.de; broo...@kernel.org;
> vk...@kernel.org; gre...@linuxfoundation.org;
> liam.r.girdw...@linux.intel.com; j...@cadence.com; j...@perches.com;
> srinivas.kandaga...@linaro.org; Pierre-Louis Bossart louis.boss...@linux.intel.com>; Rafael J. Wysocki ;
> Len Brown ; Moore, Robert ;
> Schmauss, Erik ; open list:ACPI a...@vger.kernel.org>; open list:ACPI COMPONENT ARCHITECTURE (ACPICA)
>
> Subject: [PATCH v2] ACPI / device_sysfs: change _ADR representation to
> 64 bits
>
> Standards such as the MIPI DisCo for SoundWire 1.0 specification assume
> the _ADR field is 64 bits.
>
> _ADR is defined as an "Integer" represented as 64 bits since ACPI 2.0
> released in 2002. The low levels already use _ADR as 64 bits, e.g. in
> struct acpi_device_info.
>
[Moore, Robert]
Just to be precise: since acpi 2.0 the integer width is either 32 bits or 64
bits, depending on the version number of the DSDT (1-->32, 2 or greater --> 64).
> This patch bumps the representation used for sysfs to 64 bits. To avoid
> any compatibility/ABI issues, the printf format is only extended to 16
> characters when the actual _ADR value exceeds the 32 bit maximum.
>
> Example with a SoundWire device, the results show the complete vendorID
> and linkID which were omitted before:
>
> Before:
> $ more /sys/bus/acpi/devices/device\:38/adr
> 0x5d07
> After:
> $ more /sys/bus/acpi/devices/device\:38/adr
> 0x10025d07
>
> Signed-off-by: Pierre-Louis Bossart louis.boss...@linux.intel.com>
> ---
> v2: only use 64 bits when required to avoid compatibility issues
> (feedback from Vinod and Rafael)
>
> drivers/acpi/device_sysfs.c | 6 --
> include/acpi/acpi_bus.h | 2 +-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
> index 8940054d6250..7dda0ee05cd1 100644
> --- a/drivers/acpi/device_sysfs.c
> +++ b/drivers/acpi/device_sysfs.c
> @@ -428,8 +428,10 @@ static ssize_t acpi_device_adr_show(struct device
> *dev, {
> struct acpi_device *acpi_dev = to_acpi_device(dev);
>
> - return sprintf(buf, "0x%08x\n",
> -(unsigned int)(acpi_dev->pnp.bus_address));
> + if (acpi_dev->pnp.bus_address > 0x)
> + return sprintf(buf, "0x%016llx\n", acpi_dev-
> >pnp.bus_address);
> + else
> + return sprintf(buf, "0x%08llx\n", acpi_dev->pnp.bus_address);
> }
> static DEVICE_ATTR(adr, 0444, acpi_device_adr_show, NULL);
>
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index
> f7981751ac77..9075e28ea60a 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -230,7 +230,7 @@ struct acpi_device_dir {
> /* Plug and Play */
>
> typedef char acpi_bus_id[8];
> -typedef unsigned long acpi_bus_address;
> +typedef u64 acpi_bus_address;
> typedef char acpi_device_name[40];
> typedef char acpi_device_class[20];
>
> --
> 2.17.1
RE: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng implementation
> -Original Message-
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Sent: Friday, August 31, 2018 7:55 AM
> To: Andy Shevchenko
> Cc: Hans de Goede ; Bastien Nocera
> ; stephenj...@gmail.com; Sebastian Reichel
> ; Wysocki, Rafael J ;
> l...@kernel.org; Moore, Robert ;
> lv.zh...@intel.com; mika.westerb...@linux.intel.com; linux-
> a...@vger.kernel.org; de...@acpica.org; linux...@vger.kernel.org; lkml
>
> Subject: Re: [PATCH v2] ACPI: surface3_power: MSHW0011 rev-eng
> implementation
>
> Hi Andy,
>
> I am resurrecting this thread now that ACPICA seemed to finally have
> fixed the bug that prevent the driver to work.
> The patch I submitted was reverted shortly after, which lead me to
> ignore this review until ACPICA was fixed. It took a lot of effort from
> Hans to have a fix accepted, so now we can hope to upstream this driver.
>
[Moore, Robert]
The worst part of all this is that the ACPI specification is so ambiguous in
this area, that we were forced to *guess* at certain elements of the
implementation.
So, if anyone knows of any ASL/machines that use the serial bus stuff, please
forward the code to me.
This includes:
GenericSerialBus
SMBus
IPMI
And maybe:
GeneralPurposeIo
For completeness.
> On Fri, Jun 30, 2017 at 6:37 PM Andy Shevchenko
> wrote:
> >
> > On Fri, Jun 30, 2017 at 6:57 PM, Benjamin Tissoires
> > wrote:
> > > On Jun 29 2017 or thereabouts, Andy Shevchenko wrote:
> > >> On Thu, Jun 29, 2017 at 3:10 PM, Benjamin Tissoires
> > >> wrote:
> >
> > >> What devices (laptops, tablets) have it?
> > >> Surface 3. What else?
> > >
> > > So far, Surface 3 only. It's a Microsoft PNPId, so I guess they
> > > control which device has it. Maybe the model after the Surface 3
> > > (reduced
> > > platform) will have such chip, but for now, it's unknown.
> >
> > Please, extend introduction in commit message to state above.
>
> OK. On this note, I have been mentioned that the Surface Pro 2017 uses a
> similar mechanism as in it's also using an operation region handler, but
> this time over UART, not I2C :)
>
> >
> > >> > I couldn't manage to get the IRQ correctly triggered, so I am
> > >> > using a good old polling thread to check for changes.
> > >>
> > >> It might be
> >
> > It seems I didn't finished the sentence here.
> >
> > I though it might be actually ACPI event, GPE or direct IRQ (when GPIO
> > chip should not disable it, though if it's the case it likely a BIOS
> > bug for this hardware).
>
> If you don't mind, I'd rather have the polling version that seems to be
> working first. I haven't touched the logs I had from Windows since last
> year, so I am a little bit rusty on debugging this.
> FWIW, /proc/interrupts doesn't change a bit when I unplug/replug the
> power cable.
>
> My guess is that the Windows driver initializes the chip in a different
> way and this enables the cable detection.
>
> >
> > >> > + help
> > >> > + Select this option to enable support for ACPI operation
> > >> > + region of the Surface 3 battery platform driver.
> > >>
> > >> > +/*
> > >> > + * Supports for the power IC on the Surface 3 tablet.
> > >>
> > >> Shouldn't it go to drivers/acpi/pmic folder ?
> > >
> > > Already answered later in the thread, so yes, I'll move it there.
> >
> > Actually Hans did a good point, so, feel free to use
> drivers/platform/x86.
>
> Roger that!
>
> >
> > >> And did you check if it have actual chip IP vendor name and model?
> > >> Most likely it's a TI (based?) solution.
> > >
> > > As mentioned, I have strictly no idea. I can not crack open the
> > > Surface
> > > 3 without breaking the warranty (I already had to return it once
> > > because the disk crashed).
> >
> > We have one indeed cracked (screen is broken for good :-) ), so, I
> > would check what I can find there.
> >
> > > And I do not find anything brand-related under Windows either:
> > > - it's called "Surface Platform Power Driver"
> > > - and the driver is provided by Microsoft
> >
> > Fair enough.
> >
> > >> > +static int mshw0011_bix(struct mshw0011_data *cdata, struct bix
> > >> > +*bix) {
> > >>
> > >> > + memcpy(bix->seri
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 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 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] 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] acpi: acpica: add acpi status check prior walking through namespace
Another way to look at this is that the kernel should not be calling ACPI
interfaces if ACPI is disabled.
> -Original Message-
> From: Vadim Lomovtsev [mailto:vadim.lomovt...@caviumnetworks.com]
> Sent: Tuesday, December 12, 2017 7:59 AM
> To: Moore, Robert ; Zheng, Lv
> ; Wysocki, Rafael J ;
> l...@kernel.org; linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org
> Cc: vadim.lomovt...@cavium.com
> Subject: [PATCH] acpi: acpica: add acpi status check prior walking
> through namespace
>
> From: Vadim Lomovtsev
>
> While having kernel built with ACPI support enabled and booted over FDT,
> the ltp_acpi test from LTP suite causes kernel crash while calling
> acpi_ns_walk_namespace(). The acpi_get_devices is high level wrapper for
> it, so we need to protect kernel from crashes by adding acpi status
> check before walking through namespace which is not loaded because of
> acpi is disabled.
>
> Signed-off-by: Vadim Lomovtsev
> ---
> drivers/acpi/acpica/nsxfeval.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/acpi/acpica/nsxfeval.c
> b/drivers/acpi/acpica/nsxfeval.c index 783f4c8..e0eb9ae 100644
> --- a/drivers/acpi/acpica/nsxfeval.c
> +++ b/drivers/acpi/acpica/nsxfeval.c
> @@ -52,6 +52,8 @@
> #define _COMPONENT ACPI_NAMESPACE
> ACPI_MODULE_NAME("nsxfeval")
>
> +extern int acpi_disabled;
> +
> /* Local prototypes */
> static void acpi_ns_resolve_references(struct acpi_evaluate_info
> *info);
>
> @@ -812,6 +814,11 @@ static void acpi_ns_resolve_references(struct
> acpi_evaluate_info *info)
>
> ACPI_FUNCTION_TRACE(acpi_get_devices);
>
> + /* check if ACPI disabled to prevent kernel crash later */
> + if (acpi_disabled) {
> + return_ACPI_STATUS(AE_NOT_CONFIGURED);
> + }
> +
> /* Parameter validation */
>
> if (!user_function) {
> --
> 1.8.3.1
RE: [PATCH] ACPICA: Fix indentation
This type of thing more often than not is caused by running the code through
indent (lindent).
Original ACPICA code:
ACPI_FUNCTION_NAME (ExDumpOperand)
/* Check if debug output enabled */
if (!ACPI_IS_DEBUG_ENABLED (ACPI_LV_EXEC, _COMPONENT))
{
return;
}
Raw "linuxized" code:
ACPI_FUNCTION_NAME (ex_dump_operand)
/* Check if debug output enabled */
if (!ACPI_IS_DEBUG_ENABLED (ACPI_LV_EXEC, _COMPONENT)) {
return;
}
> -Original Message-
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of
> Rafael J. Wysocki
> Sent: Friday, December 8, 2017 9:06 AM
> To: Vasyl Gomonovych
> Cc: Moore, Robert ; Zheng, Lv
> ; Wysocki, Rafael J ;
> Len Brown ; ACPI Devel Maling List a...@vger.kernel.org>; de...@acpica.org; Linux Kernel Mailing List
> ; Schmauss, Erik
> Subject: Re: [PATCH] ACPICA: Fix indentation
>
> On Fri, Dec 8, 2017 at 5:29 PM, Vasyl Gomonovych
> wrote:
> > This patch avoids that smatch reports the following:
> > drivers/acpi/acpica/exdump.c:623 acpi_ex_dump_operand() warn:
> > inconsistent indenting
> >
> > Signed-off-by: Vasyl Gomonovych
>
> This is ACPICA code, so changes like this should go in via the upstream.
>
> Erik may want to pick this up, however.
>
> > ---
> > drivers/acpi/acpica/exdump.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/exdump.c
> > b/drivers/acpi/acpica/exdump.c index 83398dc..f43d3d7 100644
> > --- a/drivers/acpi/acpica/exdump.c
> > +++ b/drivers/acpi/acpica/exdump.c
> > @@ -619,8 +619,8 @@ void acpi_ex_dump_operand(union
> > acpi_operand_object *obj_desc, u32 depth)
> >
> > ACPI_FUNCTION_NAME(ex_dump_operand)
> >
> > - /* Check if debug output enabled */
> > - if (!ACPI_IS_DEBUG_ENABLED(ACPI_LV_EXEC, _COMPONENT)) {
> > + /* Check if debug output enabled */
> > + if (!ACPI_IS_DEBUG_ENABLED(ACPI_LV_EXEC, _COMPONENT)) {
> > return;
> > }
> >
> > --
RE: [PATCH v4 1/9] ACPICA: Add additional PPTT flags for cache properties
Included in ACPICA version 20171110
> -Original Message-
> From: Jeremy Linton [mailto:jeremy.lin...@arm.com]
> Sent: Thursday, November 9, 2017 1:03 PM
> To: linux-a...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; sudeep.ho...@arm.com;
> hanjun@linaro.org; lorenzo.pieral...@arm.com; r...@rjwysocki.net;
> will.dea...@arm.com; catalin.mari...@arm.com;
> gre...@linuxfoundation.org; viresh.ku...@linaro.org;
> mark.rutl...@arm.com; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org; jh...@codeaurora.org; wangxiongfe...@huawei.com;
> jonathan.zh...@cavium.com; a...@redhat.com;
> jayachandran.n...@cavium.com; austi...@codeaurora.org; l...@kernel.org;
> Moore, Robert ; Zheng, Lv ;
> de...@acpica.org; Jeremy Linton
> Subject: [PATCH v4 1/9] ACPICA: Add additional PPTT flags for cache
> properties
>
> The PPTT table has a number of flags that can be set to describe whether
> the cache is I/D/U and the allocation and write policies. Add these
> flags.
>
> Signed-off-by: Jeremy Linton
> ---
> include/acpi/actbl1.h | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index
> 6b8714a428b6..71f874e2790d 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -1346,6 +1346,20 @@ struct acpi_pptt_cache {
> #define ACPI_PPTT_MASK_CACHE_TYPE (0x0C) /* Cache type */
> #define ACPI_PPTT_MASK_WRITE_POLICY (0x10) /* Write policy */
>
> +/* Attributes describing cache */
> +#define ACPI_PPTT_CACHE_READ_ALLOCATE(0x0) /* Cache line is
> allocated on read */
> +#define ACPI_PPTT_CACHE_WRITE_ALLOCATE (0x01) /* Cache line is
> allocated on write */
> +#define ACPI_PPTT_CACHE_RW_ALLOCATE (0x02) /* Cache line is
> allocated on read and write */
> +#define ACPI_PPTT_CACHE_RW_ALLOCATE_ALT (0x03) /* Alternate
> representation of above */
> +
> +#define ACPI_PPTT_CACHE_TYPE_DATA(0x0) /* Data cache */
> +#define ACPI_PPTT_CACHE_TYPE_INSTR (1<<2) /* Instruction cache */
> +#define ACPI_PPTT_CACHE_TYPE_UNIFIED (2<<2) /* Unified I & D cache
> */
> +#define ACPI_PPTT_CACHE_TYPE_UNIFIED_ALT(3<<2) /* Alternate
> representation of above */
> +
> +#define ACPI_PPTT_CACHE_POLICY_WB(0x0) /* Cache is write back
> */
> +#define ACPI_PPTT_CACHE_POLICY_WT(1<<4) /* Cache is write
> through */
> +
> /* 2: ID Structure */
>
> struct acpi_pptt_id {
> --
> 2.13.5
RE: [PATCH] ACPICA: Clean up whitespace of indentation
Anything like this probably happens during the conversion of ACPICA code to
Linux-style code. This conversion happens after every release (monthly) of
ACPICA.
Specifically indent/lindent seems to do things like this, if I remember
correctly.
> -Original Message-
> From: Baoquan He [mailto:b...@redhat.com]
> Sent: Tuesday, November 7, 2017 2:43 AM
> To: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org
> Cc: r...@rjwysocki.net; l...@kernel.org; Moore, Robert
> ; Zheng, Lv
> Subject: Re: [PATCH] ACPICA: Clean up whitespace of indentation
>
> PING!
>
> On 10/28/17 at 09:34am, Baoquan He wrote:
> > Use tabs (not spaces) for indentation.
> >
> > Signed-off-by: Baoquan He
> > ---
> > include/acpi/actbl1.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index
> > 6b8714a428b6..d8a4fc066abe 100644
> > --- a/include/acpi/actbl1.h
> > +++ b/include/acpi/actbl1.h
> > @@ -1438,9 +1438,9 @@ struct acpi_srat_mem_affinity {
> > u16 reserved; /* Reserved, must be zero */
> > u64 base_address;
> > u64 length;
> > - u32 reserved1;
> > + u32 reserved1;
> > u32 flags;
> > - u64 reserved2; /* Reserved, must be zero */
> > + u64 reserved2; /* Reserved, must be zero */
> > };
> >
> > /* Flags */
> > --
> > 2.5.5
> >
RE: [Devel] [PATCH 15/18] acpi: use ARRAY_SIZE
> -Original Message- > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Rafael J. > Wysocki > Sent: Tuesday, October 3, 2017 9:05 AM > To: Colin Ian King > Cc: Wysocki, Rafael J ; Rafael J. Wysocki > ; Linux Kernel Mailing List ker...@vger.kernel.org>; ACPI Devel Maling List a...@vger.kernel.org>; Jérémy Lefaure ; > de...@acpica.org > Subject: Re: [Devel] [PATCH 15/18] acpi: use ARRAY_SIZE > > On Tue, Oct 3, 2017 at 2:34 PM, Colin Ian King > wrote: > > On 03/10/17 12:39, Rafael J. Wysocki wrote: > >> On Tuesday, October 3, 2017 3:16:22 AM CEST Jérémy Lefaure wrote: > >>> On Mon, 02 Oct 2017 14:27:52 +0200 > >>> "Rafael J. Wysocki" wrote: > >>> > >>>> ACPICA is soewhat special code, though and I'm not taking or ACKing > >>>> patches for it directly as a rule. > >>>> > >>>> For one, I'm not sure if ACPICA can use ARRAY_SIZE at all. > >>> Why is it special code that can't use ARRAY_SIZE ? Is it because > >>> this macro is defined in linux/kernel.h ? > > > > However, ACPICA does have ACPI_ARRAY_LENGTH(x), see > > source/include/actypes.h > > Fair enough, but that cleanup should go in via ACPICA upstream anyway. [Moore, Robert] This would be acceptable, as long as it will work properly in the cases that were presented earlier (using ARRAY_SIZE). > > Thanks, > Rafael > ___ > Devel mailing list > de...@acpica.org > https://lists.acpica.org/mailman/listinfo/devel
RE: [PATCH 1/1] ACPI: NULL pointer checking
> -Original Message-
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
> Sent: Wednesday, September 6, 2017 9:43 AM
> To: Zhenhua ; de...@acpica.org; Zheng, Lv
> ; Wysocki, Rafael J ;
> l...@kernel.org; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [Devel] [PATCH 1/1] ACPI: NULL pointer checking
>
>
>
> > -Original Message-
> > From: Zhenhua [mailto:lizhenhuajiy...@163.com]
> > Sent: Wednesday, September 6, 2017 6:35 AM
> > To: de...@acpica.org; Moore, Robert ; Zheng,
> > Lv ; Wysocki, Rafael J
> > ; l...@kernel.org;
> > linux-a...@vger.kernel.org; linux- ker...@vger.kernel.org
> > Cc: Zhenhua
> > Subject: [PATCH 1/1] ACPI: NULL pointer checking
> >
> > These two pointers should be checked, for some broken devices they may
> > cause system crash.
> >
> > Signed-off-by: Zhenhua
> > ---
> > drivers/acpi/acpica/nsaccess.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/nsaccess.c
> > b/drivers/acpi/acpica/nsaccess.c index f2733f51ca8d..151abb0ef4d5
> > 100644
> > --- a/drivers/acpi/acpica/nsaccess.c
> > +++ b/drivers/acpi/acpica/nsaccess.c
> > @@ -338,7 +338,7 @@ acpi_ns_lookup(union acpi_generic_state
> *scope_info,
> > return_ACPI_STATUS(AE_AML_INTERNAL);
> > }
> >
> > - if (!(flags & ACPI_NS_PREFIX_IS_SCOPE)) {
> > + if ((!prefix_node) && (!(flags & ACPI_NS_PREFIX_IS_SCOPE))) {
> [Moore, Robert]
>
> Is there an actual case where the original code failed?
>
>
[Moore, Robert]
Prefix_node is guaranteed to be valid at this point in the code.
>
> > /*
> > * This node might not be a actual "scope" node (such as
> a
> > * Device/Method, etc.) It could be a Package or other
> object @@
> > -369,7 +369,7 @@ acpi_ns_lookup(union acpi_generic_state *scope_info,
> > ACPI_DEBUG_PRINT((ACPI_DB_NAMES,
> > "Null Pathname (Zero segments), Flags=%X\n",
> > flags));
> > - } else {
> > + } else if (path) {
[Moore, Robert]
Likewise, "path" is guaranteed to be valid at this point.
> > /*
> > * Name pointer is valid (and must be in internal name
> > format)
> > *
> > --
> > 2.14.1
> >
>
> ___
> Devel mailing list
> de...@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel
RE: [PATCH 1/1] ACPI: NULL pointer checking
> -Original Message-
> From: Zhenhua [mailto:lizhenhuajiy...@163.com]
> Sent: Wednesday, September 6, 2017 6:35 AM
> To: de...@acpica.org; Moore, Robert ; Zheng, Lv
> ; Wysocki, Rafael J ;
> l...@kernel.org; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Zhenhua
> Subject: [PATCH 1/1] ACPI: NULL pointer checking
>
> These two pointers should be checked, for some broken devices they may
> cause system crash.
>
> Signed-off-by: Zhenhua
> ---
> drivers/acpi/acpica/nsaccess.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpica/nsaccess.c
> b/drivers/acpi/acpica/nsaccess.c index f2733f51ca8d..151abb0ef4d5 100644
> --- a/drivers/acpi/acpica/nsaccess.c
> +++ b/drivers/acpi/acpica/nsaccess.c
> @@ -338,7 +338,7 @@ acpi_ns_lookup(union acpi_generic_state *scope_info,
> return_ACPI_STATUS(AE_AML_INTERNAL);
> }
>
> - if (!(flags & ACPI_NS_PREFIX_IS_SCOPE)) {
> + if ((!prefix_node) && (!(flags & ACPI_NS_PREFIX_IS_SCOPE))) {
[Moore, Robert]
Is there an actual case where the original code failed?
> /*
>* This node might not be a actual "scope" node (such as
> a
>* Device/Method, etc.) It could be a Package or other
> object @@ -369,7 +369,7 @@ acpi_ns_lookup(union acpi_generic_state
> *scope_info,
> ACPI_DEBUG_PRINT((ACPI_DB_NAMES,
> "Null Pathname (Zero segments), Flags=%X\n",
> flags));
> - } else {
> + } else if (path) {
> /*
>* Name pointer is valid (and must be in internal name
> format)
>*
> --
> 2.14.1
>
RE: [PATCH 1/4] ACPI: Allow _DMA method in walk resources
Could you post this as a pull request on our github?
https://github.com/acpica/acpica
> -Original Message-
> From: Moore, Robert
> Sent: Thursday, July 20, 2017 8:49 AM
> To: 'Lorenzo Pieralisi' ; linux-
> a...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> Zhang, Rui ; Rafael J. Wysocki ;
> Will Deacon ; Robin Murphy ;
> Hanjun Guo ; Feng Kan ; Jon Masters
> ; Nate Watterson
> Subject: RE: [PATCH 1/4] ACPI: Allow _DMA method in walk resources
>
> I think we can take this as-is into ACPICA.
> Bob
>
>
> > -Original Message-
> > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > Sent: Thursday, July 20, 2017 7:45 AM
> > To: linux-a...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org;
> > linux-kernel@vger.kernel.org; Lorenzo Pieralisi
> > ; Moore, Robert ;
> Zhang, Rui ; Rafael J.
> > Wysocki ; Will Deacon ; Robin
> > Murphy ; Hanjun Guo ;
> > Feng Kan ; Jon Masters ; Nate Watterson
> >
> > Subject: [PATCH 1/4] ACPI: Allow _DMA method in walk resources
> >
> > The _DMA object contains a resource template, this change adds support
> > for the walk resources function so that ACPI devices containing a _DMA
> > object can actually parse it to detect DMA ranges for the respective
> > bus.
> >
> > Signed-off-by: Lorenzo Pieralisi
> > Cc: Robert Moore
> > Cc: Zhang Rui
> > Cc: "Rafael J. Wysocki"
> > ---
> > drivers/acpi/acpica/rsxface.c | 7 ---
> > include/acpi/acnames.h| 1 +
> > 2 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/rsxface.c
> > b/drivers/acpi/acpica/rsxface.c index 59a4f9e..be65e65 100644
> > --- a/drivers/acpi/acpica/rsxface.c
> > +++ b/drivers/acpi/acpica/rsxface.c
> > @@ -615,7 +615,7 @@ ACPI_EXPORT_SYMBOL(acpi_walk_resource_buffer)
> > *device we are querying
> > * name- Method name of the resources we
> want.
> > *(METHOD_NAME__CRS,
> METHOD_NAME__PRS,
> > or
> > - *METHOD_NAME__AEI)
> > + *METHOD_NAME__AEI or
> METHOD_NAME__DMA)
> > * user_function - Called for each resource
> > * context - Passed to user_function
> > *
> > @@ -641,11 +641,12 @@ acpi_walk_resources(acpi_handle device_handle,
> > if (!device_handle || !user_function || !name ||
> > (!ACPI_COMPARE_NAME(name, METHOD_NAME__CRS) &&
> > !ACPI_COMPARE_NAME(name, METHOD_NAME__PRS) &&
> > -!ACPI_COMPARE_NAME(name, METHOD_NAME__AEI))) {
> > +!ACPI_COMPARE_NAME(name, METHOD_NAME__AEI) &&
> > +!ACPI_COMPARE_NAME(name, METHOD_NAME__DMA))) {
> > return_ACPI_STATUS(AE_BAD_PARAMETER);
> > }
> >
> > - /* Get the _CRS/_PRS/_AEI resource list */
> > + /* Get the _CRS/_PRS/_AEI/_DMA resource list */
> >
> > buffer.length = ACPI_ALLOCATE_LOCAL_BUFFER;
> > status = acpi_rs_get_method_data(device_handle, name, &buffer);
> diff
> > --git a/include/acpi/acnames.h b/include/acpi/acnames.h index
> > b421584..d8dd3bf 100644
> > --- a/include/acpi/acnames.h
> > +++ b/include/acpi/acnames.h
> > @@ -54,6 +54,7 @@
> > #define METHOD_NAME__CLS"_CLS"
> > #define METHOD_NAME__CRS"_CRS"
> > #define METHOD_NAME__DDN"_DDN"
> > +#define METHOD_NAME__DMA"_DMA"
> > #define METHOD_NAME__HID"_HID"
> > #define METHOD_NAME__INI"_INI"
> > #define METHOD_NAME__PLD"_PLD"
> > --
> > 2.10.0
RE: [PATCH 1/4] ACPI: Allow _DMA method in walk resources
I think we can take this as-is into ACPICA.
Bob
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: Thursday, July 20, 2017 7:45 AM
> To: linux-a...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> Lorenzo Pieralisi ; Moore, Robert
> ; Zhang, Rui ; Rafael J.
> Wysocki ; Will Deacon ; Robin
> Murphy ; Hanjun Guo ; Feng
> Kan ; Jon Masters ; Nate Watterson
>
> Subject: [PATCH 1/4] ACPI: Allow _DMA method in walk resources
>
> The _DMA object contains a resource template, this change adds support
> for the walk resources function so that ACPI devices containing a _DMA
> object can actually parse it to detect DMA ranges for the respective
> bus.
>
> Signed-off-by: Lorenzo Pieralisi
> Cc: Robert Moore
> Cc: Zhang Rui
> Cc: "Rafael J. Wysocki"
> ---
> drivers/acpi/acpica/rsxface.c | 7 ---
> include/acpi/acnames.h| 1 +
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/acpica/rsxface.c
> b/drivers/acpi/acpica/rsxface.c index 59a4f9e..be65e65 100644
> --- a/drivers/acpi/acpica/rsxface.c
> +++ b/drivers/acpi/acpica/rsxface.c
> @@ -615,7 +615,7 @@ ACPI_EXPORT_SYMBOL(acpi_walk_resource_buffer)
> *device we are querying
> * name- Method name of the resources we want.
> *(METHOD_NAME__CRS, METHOD_NAME__PRS,
> or
> - *METHOD_NAME__AEI)
> + *METHOD_NAME__AEI or METHOD_NAME__DMA)
> * user_function - Called for each resource
> * context - Passed to user_function
> *
> @@ -641,11 +641,12 @@ acpi_walk_resources(acpi_handle device_handle,
> if (!device_handle || !user_function || !name ||
> (!ACPI_COMPARE_NAME(name, METHOD_NAME__CRS) &&
>!ACPI_COMPARE_NAME(name, METHOD_NAME__PRS) &&
> - !ACPI_COMPARE_NAME(name, METHOD_NAME__AEI))) {
> + !ACPI_COMPARE_NAME(name, METHOD_NAME__AEI) &&
> + !ACPI_COMPARE_NAME(name, METHOD_NAME__DMA))) {
> return_ACPI_STATUS(AE_BAD_PARAMETER);
> }
>
> - /* Get the _CRS/_PRS/_AEI resource list */
> + /* Get the _CRS/_PRS/_AEI/_DMA resource list */
>
> buffer.length = ACPI_ALLOCATE_LOCAL_BUFFER;
> status = acpi_rs_get_method_data(device_handle, name, &buffer);
> diff --git a/include/acpi/acnames.h b/include/acpi/acnames.h index
> b421584..d8dd3bf 100644
> --- a/include/acpi/acnames.h
> +++ b/include/acpi/acnames.h
> @@ -54,6 +54,7 @@
> #define METHOD_NAME__CLS"_CLS"
> #define METHOD_NAME__CRS"_CRS"
> #define METHOD_NAME__DDN"_DDN"
> +#define METHOD_NAME__DMA"_DMA"
> #define METHOD_NAME__HID"_HID"
> #define METHOD_NAME__INI"_INI"
> #define METHOD_NAME__PLD"_PLD"
> --
> 2.10.0
RE: [PATCH v4 1/2] ACPICA: ACPI 6.2: Add support for new SRAT subtable
This support is already in the ACPICA code base, but I can't speak to when it
will be upstreamed to Linux. Lv would know this.
Bob
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: Thursday, June 22, 2017 6:43 AM
> To: Ganapatrao Kulkarni ; Zheng, Lv
> ; Moore, Robert ; Rafael J.
> Wysocki
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> marc.zyng...@arm.com; catalin.mari...@arm.com; will.dea...@arm.com;
> hanjun@linaro.org; t...@linutronix.de; ja...@lakedaemon.net;
> jn...@caviumnetworks.com; gpkulka...@gmail.com
> Subject: Re: [PATCH v4 1/2] ACPICA: ACPI 6.2: Add support for new SRAT
> subtable
>
> Hi Rafael, Lv, Robert,
>
> On Thu, Jun 22, 2017 at 11:40:11AM +0530, Ganapatrao Kulkarni wrote:
> > Add GIC ITS Affinity (ACPI 6.2) subtable to SRAT table.
> >
> > ACPICA commit 5bc67f63918da249bfe279ee461d152bb3e6f55b
> > Link: https://github.com/acpica/acpica/commit/5bc67f6
> >
> > Signed-off-by: Ganapatrao Kulkarni
> > ---
> > include/acpi/actbl1.h | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
>
> This patch is fine to me but it is up to you or who sends the ACPICA
> pull request to send it upstream or give us an ACK so that it can go via
> irqchip.
>
> We need to know how this commit (and other ACPICA changes) will be sent
> upstream to handle trees dependencies, please advise it is a bit urgent,
> thank you.
>
> Lorenzo
>
> > diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index
> > b4ce55c..253c9db 100644
> > --- a/include/acpi/actbl1.h
> > +++ b/include/acpi/actbl1.h
> > @@ -1192,7 +1192,8 @@ enum acpi_srat_type {
> > ACPI_SRAT_TYPE_MEMORY_AFFINITY = 1,
> > ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY = 2,
> > ACPI_SRAT_TYPE_GICC_AFFINITY = 3,
> > - ACPI_SRAT_TYPE_RESERVED = 4 /* 4 and greater are reserved */
> > + ACPI_SRAT_TYPE_GIC_ITS_AFFINITY = 4,/* ACPI 6.2 */
> > + ACPI_SRAT_TYPE_RESERVED = 5 /* 5 and greater are reserved */
> > };
> >
> > /*
> > @@ -1260,6 +1261,15 @@ struct acpi_srat_gicc_affinity {
> > u32 clock_domain;
> > };
> >
> > +/* 4: GIC ITS Affinity (ACPI 6.2) */
> > +
> > +struct acpi_srat_its_affinity {
> > + struct acpi_subtable_header header;
> > + u32 proximity_domain;
> > + u16 reserved;
> > + u32 its_id;
> > +};
> > +
> > /* Flags for struct acpi_srat_gicc_affinity */
> >
> > #define ACPI_SRAT_GICC_ENABLED (1) /* 00: Use affinity structure
> */
> > --
> > 1.8.1.4
> >
RE: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks
This might be a dumb question, but isn't the system basically hosed once the ACPI subsystem is shutdown? > -Original Message- > From: Seunghun Han [mailto:kkama...@gmail.com] > Sent: Wednesday, June 14, 2017 4:08 AM > To: Zheng, Lv ; Moore, Robert > ; Wysocki, Rafael J > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org; Seunghun Han > Subject: [PATCH] acpi: acpica: fix acpi parse and parseext cache leaks > > I'm Seunghun Han, and I work for National Security Research Institute of > South Korea. > > I have been doing a research on ACPI and found an ACPI cache leak in > ACPI early abort cases. > > Boot log of ACPI cache leak is as follows: > [0.352414] ACPI: Added _OSI(Module Device) > [0.353182] ACPI: Added _OSI(Processor Device) > [0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) > [0.353182] ACPI: Added _OSI(Processor Aggregator Device) > [0.356028] ACPI: Unable to start the ACPI Interpreter > [0.356799] ACPI Error: Could not remove SCI handler > (20170303/evmisc-281) > [0.360215] kmem_cache_destroy Acpi-State: Slab cache still has > objects > [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 4.12.0-rc4-next-20170608+ #10 > [0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [0.361873] Call Trace: > [0.362243] ? dump_stack+0x5c/0x81 > [0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 > [0.362944] ? acpi_sleep_proc_init+0x27/0x27 > [0.363296] ? acpi_os_delete_cache+0xa/0x10 > [0.363646] ? acpi_ut_delete_caches+0x6d/0x7b > [0.364000] ? acpi_terminate+0xa/0x14 > [0.364000] ? acpi_init+0x2af/0x34f > [0.364000] ? __class_create+0x4c/0x80 > [0.364000] ? video_setup+0x7f/0x7f > [0.364000] ? acpi_sleep_proc_init+0x27/0x27 > [0.364000] ? do_one_initcall+0x4e/0x1a0 > [0.364000] ? kernel_init_freeable+0x189/0x20a > [0.364000] ? rest_init+0xc0/0xc0 > [0.364000] ? kernel_init+0xa/0x100 > [0.364000] ? ret_from_fork+0x25/0x30 > > I analyzed this memory leak detailed. I found that “Acpi-State” cache > and “Acpi-Parse” cache were merged because the size of cache objects was > same slab cache size. > > I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked > using SLAB_NEVER_MERGE flag in kmem_cache_create() function. > > Real ACPI cache leak point is as follows: > [0.360101] ACPI: Added _OSI(Module Device) > [0.360101] ACPI: Added _OSI(Processor Device) > [0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) > [0.361043] ACPI: Added _OSI(Processor Aggregator Device) > [0.364016] ACPI: Unable to start the ACPI Interpreter > [0.365061] ACPI Error: Could not remove SCI handler > (20170303/evmisc-281) > [0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has > objects > [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW > 4.12.0-rc4-next-20170608+ #8 > [0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [0.372000] Call Trace: > [0.372000] ? dump_stack+0x5c/0x81 > [0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 > [0.372000] ? acpi_sleep_proc_init+0x27/0x27 > [0.372000] ? acpi_os_delete_cache+0xa/0x10 > [0.372000] ? acpi_ut_delete_caches+0x56/0x7b > [0.372000] ? acpi_terminate+0xa/0x14 > [0.372000] ? acpi_init+0x2af/0x34f > [0.372000] ? __class_create+0x4c/0x80 > [0.372000] ? video_setup+0x7f/0x7f > [0.372000] ? acpi_sleep_proc_init+0x27/0x27 > [0.372000] ? do_one_initcall+0x4e/0x1a0 > [0.372000] ? kernel_init_freeable+0x189/0x20a > [0.372000] ? rest_init+0xc0/0xc0 > [0.372000] ? kernel_init+0xa/0x100 > [0.372000] ? ret_from_fork+0x25/0x30 > [0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has > objects > [0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW > 4.12.0-rc4-next-20170608+ #8 > [0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS > VirtualBox 12/01/2006 > [0.392000] Call Trace: > [0.392000] ? dump_stack+0x5c/0x81 > [0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 > [0.392000] ? acpi_sleep_proc_init+0x27/0x27 > [0.392000] ? acpi_os_delete_cache+0xa/0x10 > [0.392000] ? acpi_ut_delete_caches+0x6d/0x7b > [0.392000] ? acpi_terminate+0xa/0x14 > [0.392000] ? acpi_init+0x2af/0x34f > [0.392000] ? __class_create+0x4c/0x80 > [0.392000] ? video_setup+0x7f/0x7f > [0.392000] ? acpi_sleep_proc_init+0x27/0x27 > [0.392000] ? do_one_initcall+0x4e/0x1a0 > [0.392000] ? kernel_init_freeable+0x189/0x20a > [0.392000] ? r
RE: [PATCH] acpi: acpica: dsutils: fix an off-by-one index
I believe that the rationale for this is that at that point in the code, it is *guaranteed* that there is at least one operand; therefore the -1 would always be valid. In the end, we just deleted that call to acpi_db_display_argument_object. I don't know if this change has made it into Linux yet. Bob > -Original Message- > From: Seraphime Kirkovski [mailto:kirkser...@gmail.com] > Sent: Tuesday, June 6, 2017 3:00 PM > To: de...@acpica.org; linux-a...@vger.kernel.org > Cc: Moore, Robert ; Zheng, Lv > ; Wysocki, Rafael J ; > l...@kernel.org; linux-kernel@vger.kernel.org; Seraphime Kirkovski > > Subject: [PATCH] acpi: acpica: dsutils: fix an off-by-one index > > This was detected by UBSAN. > Fix it by checking whether there are any arguments prior to indexing the > array. > > [0.222775] UBSAN: Undefined behaviour in > drivers/acpi/acpica/dsutils.c:640:16 > [0.222778] index -1 is out of range for type > 'acpi_operand_object*[9]' > [0.222781] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc4- > dirty #32 > [0.222782] Hardware name: Hewlett-Packard HP EliteBook 2560p/162B, > BIOS 68SSU Ver. F.02 07/26/2011 > [0.222783] Call Trace: > [0.222790] dump_stack+0x4e/0x78 > [0.222792] ubsan_epilogue+0xd/0x40 > [0.222794] __ubsan_handle_out_of_bounds+0x68/0x80 > [0.222795] ? perf_trace_sys_exit+0x12d/0x170 > [0.222797] ? kmem_cache_alloc+0x1e6/0x2e0 > [0.222800] acpi_ds_create_operand+0x20b/0x2a6 > [0.222801] acpi_ds_eval_data_object_operands+0x58/0x16c > [0.222803] acpi_ds_exec_end_op+0x424/0x582 > [0.222805] acpi_ps_parse_loop+0x730/0x792 > [0.222807] acpi_ps_parse_aml+0xac/0x2eb > [0.222809] acpi_ds_execute_arguments+0x129/0x14d > [0.222810] acpi_ds_get_buffer_arguments+0x62/0x65 > [0.222812] acpi_ns_init_one_object+0xe0/0x13b > [0.222814] acpi_ns_walk_namespace+0x121/0x1ef > [0.222815] ? acpi_ns_exec_module_code_list+0x1b7/0x1b7 > [0.222817] ? acpi_ns_exec_module_code_list+0x1b7/0x1b7 > [0.222818] acpi_walk_namespace+0xa0/0xd5 > [0.222820] acpi_ns_initialize_objects+0x37/0x5a > [0.222823] acpi_initialize_objects+0x34/0x54 > [0.222824] ? acpi_sleep_proc_init+0x2d/0x2d > [0.222826] acpi_init+0xcb/0x34d > [0.222828] ? __class_create+0x54/0x80 > [0.222830] ? fbmem_init+0x7f/0xd4 > [0.222831] ? acpi_sleep_proc_init+0x2d/0x2d > [0.222832] do_one_initcall+0x52/0x1d0 > [0.222835] kernel_init_freeable+0x314/0x3a6 > [0.222837] ? rest_init+0x80/0x80 > [0.222838] kernel_init+0xf/0x120 > [0.222839] ? rest_init+0x80/0x80 > [0.222841] ret_from_fork+0x22/0x30 > > Signed-off-by: Seraphime Kirkovski > --- > drivers/acpi/acpica/dsutils.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/acpi/acpica/dsutils.c > b/drivers/acpi/acpica/dsutils.c index 406edec20de7..b66eddd3df6e 100644 > --- a/drivers/acpi/acpica/dsutils.c > +++ b/drivers/acpi/acpica/dsutils.c > @@ -636,11 +636,10 @@ acpi_ds_create_operand(struct acpi_walk_state > *walk_state, > ACPI_DEBUG_PRINT((ACPI_DB_DISPATCH, > "Argument previously created, already > stacked\n")); > > - acpi_db_display_argument_object(walk_state-> > - operands[walk_state-> > - num_operands - > - 1], > - walk_state); > + if (walk_state->num_operands) > + acpi_db_display_argument_object(walk_state-> > + operands[walk_state->num_operands - 1], > + walk_state); > > /* >* Use value that was already previously returned > -- > 2.11.0
RE: [RFC 1/6] ACPICA: add HMAT table definitions
Full support for HMAT was just released in ACPICA version 20170531.
> -Original Message-
> From: Ross Zwisler [mailto:ross.zwis...@linux.intel.com]
> Sent: Friday, June 2, 2017 2:00 PM
> To: linux-kernel@vger.kernel.org
> Cc: Ross Zwisler ; Anaczkowski, Lukasz
> ; Box, David E ;
> Kogut, Jaroslaw ; Lahtinen, Joonas
> ; Moore, Robert ;
> Nachimuthu, Murugasamy ; Odzioba,
> Lukasz ; Wysocki, Rafael J
> ; Rafael J. Wysocki ;
> Schmauss, Erik ; Verma, Vishal L
> ; Zheng, Lv ; Williams,
> Dan J ; Hansen, Dave ;
> Dave Hansen ; Greg Kroah-Hartman
> ; Len Brown ; Tim Chen
> ; de...@acpica.org; linux-
> a...@vger.kernel.org; linux-nvd...@lists.01.org
> Subject: [RFC 1/6] ACPICA: add HMAT table definitions
>
> Import HMAT table definitions from the ACPICA codebase.
>
> This kernel patch was generated using an ACPICA patch from "Zheng, Lv"
> . The actual upstream patch that adds these table
> definitions will come from the Intel ACPICA team as part of their
> greater ACPI 6.2 update.
>
> Signed-off-by: Ross Zwisler
> ---
> include/acpi/actbl1.h | 119
> ++
> 1 file changed, 119 insertions(+)
>
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index
> b4ce55c..a5df3f3 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -65,6 +65,7 @@
> #define ACPI_SIG_ECDT "ECDT" /* Embedded Controller Boot
> Resources Table */
> #define ACPI_SIG_EINJ "EINJ" /* Error Injection table */
> #define ACPI_SIG_ERST "ERST" /* Error Record Serialization
> Table */
> +#define ACPI_SIG_HMAT "HMAT" /* Heterogeneous Memory
> Attributes Table */
> #define ACPI_SIG_HEST "HEST" /* Hardware Error Source
> Table */
> #define ACPI_SIG_MADT "APIC" /* Multiple APIC Description
> Table */
> #define ACPI_SIG_MSCT "MSCT" /* Maximum System
> Characteristics Table */
> @@ -688,6 +689,124 @@ struct acpi_hest_generic_data_v300 {
>
>
> /***
>
> *
> + * HMAT - Heterogeneous Memory Attributes Table (ACPI 6.2)
> + *Version 1
> + *
> + **
> + /
> +
> +struct acpi_table_hmat {
> + struct acpi_table_header header; /* Common ACPI table header */
> + u32 reserved;
> +};
> +
> +
> +/* Values for HMAT structure types */
> +
> +enum acpi_hmat_type {
> + ACPI_HMAT_TYPE_ADDRESS_RANGE = 0, /* Memory subystem address range
> */
> + ACPI_HMAT_TYPE_LOCALITY = 1, /* System locality latency and
> bandwidth information */
> + ACPI_HMAT_TYPE_CACHE = 2, /* Memory side cache information
> */
> + ACPI_HMAT_TYPE_RESERVED = 3 /* 3 and greater are reserved */
> +};
> +
> +struct acpi_hmat_structure {
> + u16 type;
> + u16 reserved;
> + u32 length;
> +};
> +
> +/*
> + * HMAT Structures, correspond to Type in struct acpi_hmat_structure
> +*/
> +
> +/* 0: Memory subystem address range */
> +
> +struct acpi_hmat_address_range {
> + struct acpi_hmat_structure header;
> + u16 flags;
> + u16 reserved1;
> + u32 processor_PD; /* Processor proximity domain */
> + u32 memory_PD; /* Memory proximity domain */
> + u32 reserved2;
> + u64 physical_address_base; /* Physical address range base */
> + u64 physical_address_length; /* Physical address range length */ };
> +
> +/* Masks for Flags field above */
> +
> +#define ACPI_HMAT_PROCESSOR_PD_VALID (1)/* 1: processor_PD field is
> valid */
> +#define ACPI_HMAT_MEMORY_PD_VALID(1<<1) /* 1: memory_PD field is
> valid */
> +#define ACPI_HMAT_RESERVATION_HINT (1<<2) /* 1: Reservation hint */
> +
> +/* 1: System locality latency and bandwidth information */
> +
> +struct acpi_hmat_locality {
> + struct acpi_hmat_structure header;
> + u8 flags;
> + u8 data_type;
> + u16 reserved1;
> + u32 number_of_initiator_Pds;
> + u32 number_of_target_Pds;
> + u32 reserved2;
> + u64 entry_base_unit;
> + u32 data[1]; /* initiator/target lists followed by entry matrix */
> };
> +
> +/* Masks for Flags field above */
> +
> +#define ACPI_HMAT_MEMORY_HIERARCHY (0x0F)
> +
> +/* Values for Memory Hierarchy flag */
> +
> +#define ACPI_HMAT_MEMORY0
> +#define ACPI_HMAT_LAST_LEVEL_CACHE 1
> +#define ACPI_HMAT_1ST_LEVEL_CACHE 2
> +#define ACPI_HMAT_2N
RE: [PATCH] acpi: configfs: Unload SSDT on configfs entry removal
> -Original Message- > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Tuesday, May 30, 2017 2:42 PM > To: Moore, Robert ; Jan Kiszka > > Cc: Mika Westerberg ; Rafael J. Wysocki > ; Len Brown ; Zheng, Lv > ; linux-a...@vger.kernel.org; Linux Kernel Mailing > List ; de...@acpica.org > Subject: Re: [PATCH] acpi: configfs: Unload SSDT on configfs entry > removal > > On Tue, May 30, 2017 at 11:16 PM, Moore, Robert > wrote: > > > > > >> -Original Message- > >> From: Jan Kiszka [mailto:jan.kis...@siemens.com] > >> Sent: Monday, May 29, 2017 5:53 AM > >> To: Mika Westerberg > >> Cc: Rafael J. Wysocki ; Len Brown > >> ; Zheng, Lv ; > >> linux-a...@vger.kernel.org; Linux Kernel Mailing List > >> ; de...@acpica.org; Moore, Robert > >> > >> Subject: Re: [PATCH] acpi: configfs: Unload SSDT on configfs entry > >> removal > >> > >> On 2017-05-29 14:47, Mika Westerberg wrote: > >> > On Mon, May 29, 2017 at 01:33:29PM +0200, Jan Kiszka wrote: > >> >> Enhance acpi_load_table to also return the table index. Use that > >> >> index to unload the table again when the corresponding directory > >> >> in configfs gets removed. This allows to change SSDTs without > >> >> rebooting > >> the system. > >> >> It also allows to destroy devices again that a dynamically loaded > >> >> SSDT created. > >> >> > >> >> This is widely similar to the DT overlay behavior. > >> >> > >> >> Signed-off-by: Jan Kiszka > >> >> --- > >> >> > >> >> Can someone explain to me why an unloaded table still sticks > >> >> around in sysfs and why we cannot release its ID and rather have > >> >> to use a new one when loading a modified version? > >> > > >> > IIRC ACPICA relies the fact that SSDTs are never unloaded. Bob > >> > (CC'd) can correct me if I got it wrong. > >> > > > > > > [Moore, Robert] > > > > I'm not entirely sure what the table manager code looks like at this > time, but ACPICA does in fact support table unloading. > > > > It is a rather dangerous thing to do, however -- unless you are > careful about it. Basically, all handles that reference the table to be > unloaded will go bad. > > Right. > > Linux should handle that in theory, but the code in there is mostly very > lightly tested AFAICS. > [Moore, Robert] The load/unload functionality works with the current table interfaces. For example, the AML debugger supports both Load and Unload commands: LoadLoad ACPI table from a file UnloadUnload an ACPI table via namespace object - load ssdt.aml Input file ssdt.aml, Length 0x3A (58) bytes ACPI: Host-directed Dynamic ACPI Table Load: ACPI: SSDT 0x0000004A1B18 3A (v02 Intel _SSDT_01 0001 INTL 20170303) ACPI Exec: Table Event INSTALL, [SSDT] 004A1B18 ACPI Exec: Table Event LOAD, [SSDT] 004A1B18 - unload _T32 ACPI Exec: Table Event UNLOAD, [SSDT] 004A1B18 Parent of [_T32] (004A1028) unloaded and uninstalled > >> OK... Is that standard-driven or just a limitation of this > >> implementation? > >> > >> Is there an upper limit of tables? I'm thinking of lengthy > >> development sessions that play with tables, loading and unloading > modified versions. > >> > > > > [Moore, Robert] > > > > I think that the maximum number of loaded ACPI tables is 255 at any > given time. However, things are cleaned up after an unload such that > repeated load/unload cycles should not consume resources. > > I'm not sure if this is going to work seamlessly right away, but it > certainly can be made work. > > That said, the change as proposed would be an API modification forcing > all of the OSes using ACPICA to change (or to carry out-of-the-tree > patches), so not nice. > > What about adding a separate version of acpi_load_table() returning an > index (or an error on failures) instead of the status and leaving the > existing acpi_load_table() as is? > > Thanks, > Rafael
RE: [PATCH] acpi: configfs: Unload SSDT on configfs entry removal
> -Original Message- > From: Jan Kiszka [mailto:jan.kis...@siemens.com] > Sent: Monday, May 29, 2017 5:53 AM > To: Mika Westerberg > Cc: Rafael J. Wysocki ; Len Brown ; > Zheng, Lv ; linux-a...@vger.kernel.org; Linux Kernel > Mailing List ; de...@acpica.org; Moore, > Robert > Subject: Re: [PATCH] acpi: configfs: Unload SSDT on configfs entry > removal > > On 2017-05-29 14:47, Mika Westerberg wrote: > > On Mon, May 29, 2017 at 01:33:29PM +0200, Jan Kiszka wrote: > >> Enhance acpi_load_table to also return the table index. Use that > >> index to unload the table again when the corresponding directory in > >> configfs gets removed. This allows to change SSDTs without rebooting > the system. > >> It also allows to destroy devices again that a dynamically loaded > >> SSDT created. > >> > >> This is widely similar to the DT overlay behavior. > >> > >> Signed-off-by: Jan Kiszka > >> --- > >> > >> Can someone explain to me why an unloaded table still sticks around > >> in sysfs and why we cannot release its ID and rather have to use a > >> new one when loading a modified version? > > > > IIRC ACPICA relies the fact that SSDTs are never unloaded. Bob (CC'd) > > can correct me if I got it wrong. > [Moore, Robert] I'm not entirely sure what the table manager code looks like at this time, but ACPICA does in fact support table unloading. It is a rather dangerous thing to do, however -- unless you are careful about it. Basically, all handles that reference the table to be unloaded will go bad. > OK... Is that standard-driven or just a limitation of this > implementation? > > Is there an upper limit of tables? I'm thinking of lengthy development > sessions that play with tables, loading and unloading modified versions. > [Moore, Robert] I think that the maximum number of loaded ACPI tables is 255 at any given time. However, things are cleaned up after an unload such that repeated load/unload cycles should not consume resources. > Jan > > -- > Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence > Center Embedded Linux
RE: [PATCH] acpi: acpica: dbfileio: Use strlcpy to Copy a C-string into a sized buffer
I'm not sure that strlcpy is portable.
Bob
> -Original Message-
> From: Karim Eshapa [mailto:karim.esh...@gmail.com]
> Sent: Tuesday, May 23, 2017 4:26 PM
> To: Moore, Robert
> Cc: Zheng, Lv ; Wysocki, Rafael J
> ; l...@kernel.org; linux-
> a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org;
> Karim Eshapa
> Subject: [PATCH] acpi: acpica: dbfileio: Use strlcpy to Copy a C-string
> into a sized buffer
>
> Use strlcpy with sized buffer instead of strncpy to avoid non NUL-
> terminated source strings problems.
>
> Signed-off-by: Karim Eshapa
> ---
> drivers/acpi/acpica/dbfileio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/dbfileio.c
> b/drivers/acpi/acpica/dbfileio.c index 4d81ea2..f0f22f1 100644
> --- a/drivers/acpi/acpica/dbfileio.c
> +++ b/drivers/acpi/acpica/dbfileio.c
> @@ -99,7 +99,7 @@ void acpi_db_open_debug_file(char *name)
> }
>
> acpi_os_printf("Debug output file %s opened\n", name);
> - strncpy(acpi_gbl_db_debug_filename, name,
> + strlcpy(acpi_gbl_db_debug_filename, name,
> sizeof(acpi_gbl_db_debug_filename));
> acpi_gbl_db_output_to_file = TRUE;
> }
> --
> 2.7.4
RE: [PATCH] ACPI: SPCR: Use access width to determine mmio usage
Jon,
You might want to take a look at using the acpi_read and acpi_write ACPICA
interfaces that accept a GAS structure and handle the access width (etc.)
automatically.
Bob
> -Original Message-
> From: Jon Mason [mailto:jon.ma...@broadcom.com]
> Sent: Thursday, May 4, 2017 8:06 AM
> To: Rafael Wysocki ; Len Brown ;
> Moore, Robert ; Zheng, Lv
> Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
> de...@acpica.org; bcm-kernel-feedback-l...@broadcom.com
> Subject: [PATCH] ACPI: SPCR: Use access width to determine mmio usage
>
> The current SPCR code does not check the access width of the mmio, and
> uses a default of 8bit register accesses. This prevents devices that
> only do 16 or 32bit register accesses from working. By simply checking
> this field and setting the mmio string appropriately, this issue can be
> corrected. To prevent any legacy issues, the code will default to 8bit
> accesses if the value is anything but 16 or 32.
>
> Signed-off-by: Jon Mason
> ---
> drivers/acpi/spcr.c | 18 --
> include/acpi/acrestyp.h | 7 +++
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index
> 01c9466..11233f6 100644
> --- a/drivers/acpi/spcr.c
> +++ b/drivers/acpi/spcr.c
> @@ -74,8 +74,22 @@ int __init parse_spcr(bool earlycon)
> goto done;
> }
>
> - iotype = table->serial_port.space_id ==
> ACPI_ADR_SPACE_SYSTEM_MEMORY ?
> - "mmio" : "io";
> + if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> + switch (table->serial_port.access_width) {
> + default:
> + pr_err("Unexpected SPCR Access Width. Defaulting to
> byte size\n");
> + case ACPI_ACCESS_SIZE_BYTE:
> + iotype = "mmio";
> + break;
> + case ACPI_ACCESS_SIZE_WORD:
> + iotype = "mmio16";
> + break;
> + case ACPI_ACCESS_SIZE_DWORD:
> + iotype = "mmio32";
> + break;
> + }
> + } else
> + iotype = "io";
>
> switch (table->interface_type) {
> case ACPI_DBG2_ARM_SBSA_32BIT:
> diff --git a/include/acpi/acrestyp.h b/include/acpi/acrestyp.h index
> f0f7403..781cb55 100644
> --- a/include/acpi/acrestyp.h
> +++ b/include/acpi/acrestyp.h
> @@ -372,6 +372,13 @@ struct acpi_resource_generic_register {
> u64 address;
> };
>
> +/* Generic Address Space Access Sizes */
> +#define ACPI_ACCESS_SIZE_UNDEFINED 0
> +#define ACPI_ACCESS_SIZE_BYTE1
> +#define ACPI_ACCESS_SIZE_WORD2
> +#define ACPI_ACCESS_SIZE_DWORD 3
> +#define ACPI_ACCESS_SIZE_QWORD 4
> +
> struct acpi_resource_gpio {
> u8 revision_id;
> u8 connection_type;
> --
> 2.7.4
RE: [PATCH] acpi: fix typo
Ok, we've got the changes to actypes.h in ACPICA. Thanks, Bob
RE: [PATCH] ACPICA: Export mutex functions
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, April 18, 2017 7:15 AM
> To: Guenter Roeck
> Cc: Zheng, Lv ; Rafael J. Wysocki
> ; Moore, Robert ; Wysocki,
> Rafael J ; Len Brown ;
> linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org; Box, David E
> Subject: Re: [PATCH] ACPICA: Export mutex functions
>
> On Tuesday, April 18, 2017 06:50:26 AM Guenter Roeck wrote:
> > On 04/18/2017 12:14 AM, Zheng, Lv wrote:
> > > Hi,
>
> [cut]
>
> > >
> > > Maybe I should provide more detailed examples for this solution.
> > >
> > > For example:
> > > OperationRegion (SIOT, SuperIOAddressSpace, Zero, 100) Field (SIOT,
> > > ByteAcc, Lock, Preserve) {
> > > FNC1, 8,
> > > FNC2, 8,
> > > ...
> > > }
> > >
> > > Acquire (MUX0)
> > > Store (0, FNC1)
> > > Release (MUX0)
> > >
> > > Then you can call (let me use casual pseudo code)
> > > acpi_install_operation_region(SuperIOAddressSpace,
> superio_opregion_handler) from OS side.
> > > In its callback superio_opregion_handler(), you can:
> > >
> > > superio_enter();
> > > If (address == 0) {
> > >/* mean FNC1 */
> > >Perform the locked superior accesses } else if (address == 1) {
> > >/* mean FNC2 */
> > >Perform the locked superior accesses } superio_exit();
> > >
> > > Are there similar approach in your DSDT?
> > >
> >
> > Some snippets from the DSDT:
> >
> > Device (SIO1)
> > {
> > Name (_HID, EisaId ("PNP0C02") /* PNP Motherboard
> Resources */) // _HID: Hardware ID
> > Name (_UID, Zero) // _UID: Unique ID
> > ...
> > Mutex (MUT0, 0x00)
> > Method (ENFG, 1, NotSerialized)
> > {
> > Acquire (MUT0, 0x0FFF)
> > INDX = 0x87
> > INDX = One
> > INDX = 0x55
> > If ((SP1O == 0x2E))
> > {
> > INDX = 0x55
> > }
> > Else
> > {
> > INDX = 0xAA
> > }
> >
> > LDN = Arg0
> > }
> >
> > Method (EXFG, 0, NotSerialized)
> > {
> > INDX = 0x02
> > DATA = 0x02
> > Release (MUT0)
> > }
> >
> > OperationRegion (IOID, SystemIO, SP1O, 0x02)/* SP1O
> is 0x2e */
> > Field (IOID, ByteAcc, NoLock, Preserve)
> > {
> > INDX, 8,
> > DATA, 8
> > }
> > ...
> >
> > Example for use:
> > Method (DCNT, 2, NotSerialized)
> > {
> > ENFG (CGLD (Arg0))
> > If (((DMCH < 0x04) && ((Local1 = (DMCH &
> 0x03)) != Zero)))
> > {
> > RDMA (Arg0, Arg1, Local1++)
> > }
> >
> > ACTR = Arg1
> > Local1 = (IOAH << 0x08)
> > Local1 |= IOAL
> > RRIO (Arg0, Arg1, Local1, 0x08)
> > EXFG ()
> > }
> >
> > Can there be more than one address space handler for a given region ?
> > Each driver accessing the resource would need that handler.
>
> Rather, every driver accessing the resource would need to be aware of
> the existence of the operation region handler and would need to use the
> mutual exclusion mechanism used by that handler, if my understanding
> here is correct.
>
> The existence of an operation region for a specific section of address
> space is a declaration that AML is going to access locations in that
> section. It allows the OS to install a handler for that region to
> intercept AML accesses and do what it likes with them.
>
> Thanks,
> Rafael
Yes, agreed.
Bob
RE: [PATCH] ACPICA: Export mutex functions
> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Monday, April 17, 2017 12:45 PM > To: Moore, Robert > Cc: Zheng, Lv ; Wysocki, Rafael J > ; 'Len Brown' ; 'linux- > a...@vger.kernel.org' ; 'de...@acpica.org' > ; 'linux-kernel@vger.kernel.org' ker...@vger.kernel.org>; Box, David E > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Mon, Apr 17, 2017 at 07:27:37PM +, Moore, Robert wrote: > > > > > -Original Message- > > > From: Moore, Robert > > > Sent: Monday, April 17, 2017 10:13 AM > > > To: Guenter Roeck ; Zheng, Lv > > > > > > Cc: Wysocki, Rafael J ; Len Brown > > > ; linux-a...@vger.kernel.org; de...@acpica.org; > > > linux- ker...@vger.kernel.org > > > Subject: RE: [PATCH] ACPICA: Export mutex functions > > > > > > There is a model for the drivers to directly acquire an AML mutex > > > object. That is why the acquire/release public interfaces were added > > > to ACPICA. > > > > > > I forget all of the details, but the model was developed with MS and > > > others during the ACPI 6.0 timeframe. > > > > > > > > [Moore, Robert] > > > > > > Here is the case where the OS may need to directly acquire an AML > mutex: > > > > From the ACPI spec: > > > > 19.6.2 Acquire (Acquire a Mutex) > > > > Note: For Mutex objects referenced by a _DLM object, the host OS may > also contend for ownership. > > > From the context in the dsdt, and from description of expected use cases > for _DLM objects I can find, this is what the mutex is used for (to > serialize access to a resource on a low pin count serial interconnect, > aka LPC). > > What does that mean in practice ? That I am not supposed to use it > because it doesn't follow standard ACPI mutex declaration rules ? > > Thanks, > Guenter > > > [Moore, Robert] I'm not an expert on the _DLM method, but I would point you to the description section in the ACPI spec, 5.7.5 _DLM (DeviceLock Mutex). > > > > > > Other than this case, the OS/drivers should never need to directly > acquire an AML mutex. > > Bob > >
RE: [PATCH] ACPICA: Export mutex functions
> -Original Message- > From: Moore, Robert > Sent: Monday, April 17, 2017 12:28 PM > To: 'Guenter Roeck' ; Zheng, Lv > Cc: Wysocki, Rafael J ; 'Len Brown' > ; 'linux-a...@vger.kernel.org' a...@vger.kernel.org>; 'de...@acpica.org' ; 'linux- > ker...@vger.kernel.org' ; Box, David E > (david.e@intel.com) > Subject: RE: [PATCH] ACPICA: Export mutex functions > > > > -Original Message- > > From: Moore, Robert > > Sent: Monday, April 17, 2017 10:13 AM > > To: Guenter Roeck ; Zheng, Lv > > Cc: Wysocki, Rafael J ; Len Brown > > ; linux-a...@vger.kernel.org; de...@acpica.org; > > linux- ker...@vger.kernel.org > > Subject: RE: [PATCH] ACPICA: Export mutex functions > > > > There is a model for the drivers to directly acquire an AML mutex > > object. That is why the acquire/release public interfaces were added > > to ACPICA. > > > > I forget all of the details, but the model was developed with MS and > > others during the ACPI 6.0 timeframe. > > > > > [Moore, Robert] > > > Here is the case where the OS may need to directly acquire an AML mutex: > > From the ACPI spec: > > 19.6.2 Acquire (Acquire a Mutex) > > Note: For Mutex objects referenced by a _DLM object, the host OS may > also contend for ownership. > > Other than this case, the OS/drivers should never need to directly > acquire an AML mutex. > Bob [Moore, Robert] Here is more information, from the ACPICA reference: 8.3.15 AcpiAcquireMutex This function is intended to be used in conjunction with the _DLM (Device Lock Method) predefined name to directly acquire a mutex object that is defined in the ACPI namespace. The purpose of this is to provide a mutual exclusion mechanism between the AML interpreter and an ACPI-related device driver, in order to support multiple-operation transactions. >From the ACPI Specification: "The _DLM object appears in a device scope when >AML access to the device must be synchronized with the OS environment. It is >used in conjunction with a standard Mutex object. With _DLM, the standard >Mutex provides synchronization within the AML environment as usual, but also >synchronizes with the OS environment." The AML mutex node is pointed to by Parent:Pathname. Either the Parent or the Pathname can be NULL, but not both. If the operation fails an appropriate status will be returned.
RE: [PATCH] ACPICA: Export mutex functions
> -Original Message- > From: Moore, Robert > Sent: Monday, April 17, 2017 10:13 AM > To: Guenter Roeck ; Zheng, Lv > Cc: Wysocki, Rafael J ; Len Brown > ; linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org > Subject: RE: [PATCH] ACPICA: Export mutex functions > > There is a model for the drivers to directly acquire an AML mutex > object. That is why the acquire/release public interfaces were added to > ACPICA. > > I forget all of the details, but the model was developed with MS and > others during the ACPI 6.0 timeframe. > > [Moore, Robert] Here is the case where the OS may need to directly acquire an AML mutex: >From the ACPI spec: 19.6.2 Acquire (Acquire a Mutex) Note: For Mutex objects referenced by a _DLM object, the host OS may also contend for ownership. Other than this case, the OS/drivers should never need to directly acquire an AML mutex. Bob
RE: [PATCH] ACPICA: Export mutex functions
There is a model for the drivers to directly acquire an AML mutex object. That
is why the acquire/release public interfaces were added to ACPICA.
I forget all of the details, but the model was developed with MS and others
during the ACPI 6.0 timeframe.
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: Monday, April 17, 2017 8:57 AM
> To: Zheng, Lv
> Cc: Moore, Robert; Wysocki, Rafael J; Len Brown; linux-
> a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ACPICA: Export mutex functions
>
> Hi,
>
> On Mon, Apr 17, 2017 at 09:39:35AM +, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > Subject: Re: [PATCH] ACPICA: Export mutex functions
> > >
> > > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote:
> > > > The ACPICA mutex functions are based on the host OS functions, so
> they don't really buy you anything.
> > > You should just use the native Linux functions.
> > > >
> > >
> > > You mean they don't really acquire the requested ACPI mutex, and the
> > > underlying DSDT which declares and uses the mutex just ignores if
> > > the mutex was acquired by acpi_acquire_mutex() ?
> > >
> > > To clarify: You are saying that code such as
> > >
> > > acpi_status status;
> > >
> > > status = acpi_acquire_mutex(NULL, "\\_SB.PCI0.SBRG.SIO1.MUT0",
> 0x10);
> > > if (ACPI_FAILURE(status)) {
> > > pr_err("Failed to acquire ACPI mutex\n");
> > > return -EBUSY;
> > > }
> >
> > Why do you need to access \_SB.PCI0.SBRG.SIO1.MUT0?
> > OSPM should only invoke entry methods predefined by ACPI spec or
> whatever specs.
> > There shouldn't be any needs that a driver acquires an arbitrary AML
> mutex.
> > You do not seem to have justified the usage model, IMO.
> >
>
> I am sorry, I have no idea how to do that. I can see that the resource in
> question (IO address 0x2e/0x2f) is accessed from the DSDT, that the
> resource is mutex protected, and that accesses to the same IO address from
> the Linux kernel are unreliable unless I acquire the mutex in question. At
> the same time, I can see that request_muxed_region() succeeds, so
> presumably ACPI does not reserve the region for its exclusive use.
>
> It may well be that the "official" response to this problem is "you must
> not instantiate a watchdog, environmental monitor, or gpio driver (or
> anything else provided by the Super-IO chip that requires access to those
> ports) on this platform in Linux". Is that what you are suggesting ?
>
> Thanks,
> Guenter
RE: [PATCH] ACPICA: Export mutex functions
> -Original Message- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, April 14, 2017 3:30 PM > To: Moore, Robert > Cc: Guenter Roeck; Zheng, Lv; Wysocki, Rafael J; Len Brown; linux- > a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Wednesday, April 12, 2017 09:56:37 PM Moore, Robert wrote: > > > > > -Original Message- > > > From: Guenter Roeck [mailto:li...@roeck-us.net] > > > Sent: Wednesday, April 12, 2017 2:23 PM > > > To: Moore, Robert > > > Cc: Zheng, Lv ; Wysocki, Rafael J > > > ; Len Brown ; linux- > > > a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org > > > Subject: Re: [PATCH] ACPICA: Export mutex functions > > > > > > On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote: > > > > The ACPICA mutex functions are based on the host OS functions, so > > > > they > > > don't really buy you anything. You should just use the native Linux > > > functions. > > > > > > > > > > You mean they don't really acquire the requested ACPI mutex, and the > > > underlying DSDT which declares and uses the mutex just ignores if > > > the mutex was acquired by acpi_acquire_mutex() ? > > > > > [Moore, Robert] > > > > OK, I understand now. Yes, these mutex interfaces are in fact intended > for the purpose you mention: > > > > * FUNCTION:AcpiAcquireMutex > > * > > * PARAMETERS: Handle - Mutex or prefix handle (optional) > > * Pathname- Mutex pathname (optional) > > * Timeout - Max time to wait for the lock > (millisec) > > * > > * RETURN: Status > > * > > * DESCRIPTION: Acquire an AML mutex. This is a device driver interface > to > > * AML mutex objects, and allows for transaction locking > between > > * drivers and AML code. The mutex node is pointed to by > > * Handle:Pathname. Either Handle or Pathname can be NULL, > but > > * not both. > > > > > > And yes, both the acquire and release interfaces should be exported. > > OK, so I'm assuming this will go in through the upstream ACPICA. > Yes, done for next release. Bob > Thanks, > Rafael
RE: [PATCH] ACPICA: Export mutex functions
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: Wednesday, April 12, 2017 2:23 PM
> To: Moore, Robert
> Cc: Zheng, Lv ; Wysocki, Rafael J
> ; Len Brown ; linux-
> a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ACPICA: Export mutex functions
>
> On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote:
> > The ACPICA mutex functions are based on the host OS functions, so they
> don't really buy you anything. You should just use the native Linux
> functions.
> >
>
> You mean they don't really acquire the requested ACPI mutex, and the
> underlying DSDT which declares and uses the mutex just ignores if the
> mutex was acquired by acpi_acquire_mutex() ?
>
[Moore, Robert]
OK, I understand now. Yes, these mutex interfaces are in fact intended for the
purpose you mention:
* FUNCTION:AcpiAcquireMutex
*
* PARAMETERS: Handle - Mutex or prefix handle (optional)
* Pathname- Mutex pathname (optional)
* Timeout - Max time to wait for the lock (millisec)
*
* RETURN: Status
*
* DESCRIPTION: Acquire an AML mutex. This is a device driver interface to
* AML mutex objects, and allows for transaction locking between
* drivers and AML code. The mutex node is pointed to by
* Handle:Pathname. Either Handle or Pathname can be NULL, but
* not both.
And yes, both the acquire and release interfaces should be exported.
> To clarify: You are saying that code such as
>
> acpi_status status;
>
> status = acpi_acquire_mutex(NULL, "\\_SB.PCI0.SBRG.SIO1.MUT0",
> 0x10);
> if (ACPI_FAILURE(status)) {
> pr_err("Failed to acquire ACPI mutex\n");
> return -EBUSY;
> }
> ...
>
> when used in conjunction with
>
> ...
> Mutex (MUT0, 0x00)
> Method (ENFG, 1, NotSerialized)
> {
> Acquire (MUT0, 0x0FFF)
> ...
> }
>
> doesn't really provide exclusive access to the resource(s) protected by
> MUT0, even if acpi_acquire_mutex() returns ACPI_SUCCESS ?
>
> Outch. Really ?
>
> Thanks,
> Guenter
>
> >
> > > -Original Message-
> > > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > > Sent: Wednesday, April 12, 2017 8:13 AM
> > > To: Moore, Robert ; Zheng, Lv
> > > ; Wysocki, Rafael J
> > > ; Len Brown
> > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > ker...@vger.kernel.org; Guenter Roeck
> > > Subject: [PATCH] ACPICA: Export mutex functions
> > >
> > > Mutex functions may be needed by drivers. Examples are accesses to
> > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > environmental monitor registers, both which may also be accessed
> > > through DSDT.
> > >
> > > Signed-off-by: Guenter Roeck
> > > ---
> > > drivers/acpi/acpica/utxfmutex.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > 100644
> > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle,
> > > acpi_string pathname, u16 timeout)
> > > status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > > return (status);
> > > }
> > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > >
> > >
> > > /***
> > >
> > >
> > > *
> > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle
> > > handle, acpi_string pathname)
> > > acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > > return (AE_OK);
> > > }
> > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > --
> > > 2.7.4
> >
RE: [Regression Linux 4.11] TPM module not loaded anymore
> -Original Message- > From: Paul Menzel [mailto:pmen...@molgen.mpg.de] > Sent: Wednesday, April 12, 2017 2:27 PM > To: Moore, Robert > Cc: Jarkko Sakkinen ; Maciej S. > Szmigiero ; linux-kernel@vger.kernel.org; > Arthur Heymans ; tpmdd-de...@lists.sourceforge.net; > gnu...@no-log.org; Zheng, Lv ; Wysocki, Rafael J > ; linux-a...@vger.linux.org > Subject: RE: [Regression Linux 4.11] TPM module not loaded anymore > > Dear Robert, > > > Thank you for looking into this. > > > On 2017-04-12 17:54, Moore, Robert wrote: > > And probably the dmesg if error messages appear in there. > > Linux doesn’t log any messages, as the `tpm` module doesn’t load. Please > find the output of `sudo acpidump` attached. > > […] > [Moore, Robert] Do you have any idea what control method(s) are executing? The DSDT and SSDT in the acpidump load fine here, and all predefined control methods in these tables execute OK. We need to root-cause this problem, as a simple revert will break the customers that the fix was intended for in the first place. Bob > > Kind regards, > > Paul > > > PS: Doesn’t your mail client support to easily reply in interleaved > style?
RE: [Regression Linux 4.11] TPM module not loaded anymore (was: Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)
And probably the dmesg if error messages appear in there. > -Original Message- > From: Moore, Robert > Sent: Wednesday, April 12, 2017 8:53 AM > To: 'Jarkko Sakkinen' ; Paul Menzel > > Cc: Maciej S. Szmigiero ; linux- > ker...@vger.kernel.org; Arthur Heymans ; tpmdd- > de...@lists.sourceforge.net; gnu...@no-log.org; Zheng, Lv > ; Wysocki, Rafael J > Subject: RE: [Regression Linux 4.11] TPM module not loaded anymore (was: > Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot) > > Please post the acpidump for this machine so we can analyze the actual > AML byte code. > Thanks. > > > > -Original Message- > > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > > Sent: Tuesday, April 11, 2017 3:58 PM > > To: Paul Menzel > > Cc: Moore, Robert ; Maciej S. Szmigiero > > ; linux-kernel@vger.kernel.org; Arthur > > Heymans ; tpmdd-de...@lists.sourceforge.net; > > gnu...@no-log.org; Zheng, Lv ; Wysocki, Rafael J > > > > Subject: Re: [Regression Linux 4.11] TPM module not loaded anymore > (was: > > Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot) > > > > On Sun, Apr 09, 2017 at 07:34:43PM +0200, Paul Menzel wrote: > > > Dear Linux folks, > > > > > > > > > It turns out that stricter checks in the ACPI subsystem, introduced > > > in commit 57707a9a77 (ACPICA: Resources: Not a valid resource if > > > buffer length too long) [1], cause the TPM module not to be loaded > > > anymore on the Lenovo X60 with coreboot [2]. > > > > > > Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel: > > > > On 2017-04-07 22:13, Jarkko Sakkinen wrote: > > > > > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote: > > > > >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote: > > > > >> > >We added direct ACPI binding to the driver in addition to > > > > >> > >PNP, so if you have an ACPI table it goes down that path and > > > > >> > >does some additional validation of what is in the TPM. The > > > > >> > >BIOS must provide a acpi_dev_resource_memory and a > > > > >> > >ACPI_SIG_TPM2 for the ACPI entry at a minimum. > > > > >> > > > > > >> > Is it correct, that this is added in/for 4.11, so just > > > > >> > recently? Testing with Linux 4.10.8, everything is detected > > just fine. > > > > >> > > > > >> No, it is quite a bit older.. And it should only go for TPM2, > > > > >> which I don't think you have?? > > > > >> > > > > >> Maybe Jarkko has a guess, but sure sounds like something is > > > > >> recently broken in 4.11 > > > > > > > > > > I'll come back to this. I have to re-read the whole mail thread > > > > > to get back into the context. Lots of multitasking because of > > > > > release and so forth. Sorry for the latency! > > > > > > > > I started bisecting this issue. This is the current state. > > > > > > […] > > > > > > Here are the results. > > > > > > ``` > > > git bisect log > > > # bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag > > > 'dm-4.11-changes' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm > > > # good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10 git > > > bisect start 'HEAD' 'v4.10' > > > # good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag > > > 'regmap-v4.11' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap > > > git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d > > > # bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix > > > build paravirt build on arm and arm64 git bisect bad > > > fd4a61e08aa79f2b7835b25c6f94f27bd2d65990 > > > # good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag > > > 'leds_for_4.11' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-led > > > s git bisect good 7aa7d608112baf63a0b1278955f9619427373807 > > > # good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag > > > 'pm-4.11-rc1' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > > > git bisect good 02c3de1105228e367320e7fdeffbf5119
RE: [Regression Linux 4.11] TPM module not loaded anymore (was: Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)
Please post the acpidump for this machine so we can analyze the actual AML byte code. Thanks. > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, April 11, 2017 3:58 PM > To: Paul Menzel > Cc: Moore, Robert ; Maciej S. Szmigiero > ; linux-kernel@vger.kernel.org; Arthur > Heymans ; tpmdd-de...@lists.sourceforge.net; > gnu...@no-log.org; Zheng, Lv ; Wysocki, Rafael J > > Subject: Re: [Regression Linux 4.11] TPM module not loaded anymore (was: > Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot) > > On Sun, Apr 09, 2017 at 07:34:43PM +0200, Paul Menzel wrote: > > Dear Linux folks, > > > > > > It turns out that stricter checks in the ACPI subsystem, introduced in > > commit 57707a9a77 (ACPICA: Resources: Not a valid resource if buffer > > length too long) [1], cause the TPM module not to be loaded anymore on > > the Lenovo X60 with coreboot [2]. > > > > Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel: > > > On 2017-04-07 22:13, Jarkko Sakkinen wrote: > > > > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote: > > > >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote: > > > >> > >We added direct ACPI binding to the driver in addition to PNP, > > > >> > >so if you have an ACPI table it goes down that path and does > > > >> > >some additional validation of what is in the TPM. The BIOS > > > >> > >must provide a acpi_dev_resource_memory and a ACPI_SIG_TPM2 > > > >> > >for the ACPI entry at a minimum. > > > >> > > > > >> > Is it correct, that this is added in/for 4.11, so just > > > >> > recently? Testing with Linux 4.10.8, everything is detected > just fine. > > > >> > > > >> No, it is quite a bit older.. And it should only go for TPM2, > > > >> which I don't think you have?? > > > >> > > > >> Maybe Jarkko has a guess, but sure sounds like something is > > > >> recently broken in 4.11 > > > > > > > > I'll come back to this. I have to re-read the whole mail thread to > > > > get back into the context. Lots of multitasking because of release > > > > and so forth. Sorry for the latency! > > > > > > I started bisecting this issue. This is the current state. > > > > […] > > > > Here are the results. > > > > ``` > > git bisect log > > # bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag > > 'dm-4.11-changes' of > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm > > # good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10 git > > bisect start 'HEAD' 'v4.10' > > # good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag > > 'regmap-v4.11' of > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap > > git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d > > # bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix > > build paravirt build on arm and arm64 git bisect bad > > fd4a61e08aa79f2b7835b25c6f94f27bd2d65990 > > # good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag > > 'leds_for_4.11' of > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds > > git bisect good 7aa7d608112baf63a0b1278955f9619427373807 > > # good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag > > 'pm-4.11-rc1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > > git bisect good 02c3de1105228e367320e7fdeffbf511904f398c > > # bad: [6c24337f22115d669e24ce990842dab667371b4d] Merge tag > > 'fscrypt-for-linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt > > git bisect bad 6c24337f22115d669e24ce990842dab667371b4d > > # bad: [a74d1cafc22e100a9b59c50943ca09c37e03dce8] Merge branches > 'acpi-bus', 'acpi-sleep' and 'acpi-processor' > > git bisect bad a74d1cafc22e100a9b59c50943ca09c37e03dce8 > > # bad: [ce87e09dd88c61f9088768a7708828423549725c] ACPICA: Parser: > > Allow method invocations as target operands git bisect bad > > ce87e09dd88c61f9088768a7708828423549725c > > # good: [0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076] ACPICA: Hardware: > > Add sleep register hooks git bisect good > > 0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076 > > # good: [a654b8ca6d28736995de767ba62e801fd806a3b2] ACPICA: > > Disassembler: Add Switch/Case
RE: [Regression Linux 4.11] TPM module not loaded anymore (was: Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)
I'll try to look at it today Bob > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, April 11, 2017 3:58 PM > To: Paul Menzel > Cc: Moore, Robert ; Maciej S. Szmigiero > ; linux-kernel@vger.kernel.org; Arthur > Heymans ; tpmdd-de...@lists.sourceforge.net; > gnu...@no-log.org; Zheng, Lv ; Wysocki, Rafael J > > Subject: Re: [Regression Linux 4.11] TPM module not loaded anymore (was: > Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot) > > On Sun, Apr 09, 2017 at 07:34:43PM +0200, Paul Menzel wrote: > > Dear Linux folks, > > > > > > It turns out that stricter checks in the ACPI subsystem, introduced in > > commit 57707a9a77 (ACPICA: Resources: Not a valid resource if buffer > > length too long) [1], cause the TPM module not to be loaded anymore on > > the Lenovo X60 with coreboot [2]. > > > > Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel: > > > On 2017-04-07 22:13, Jarkko Sakkinen wrote: > > > > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote: > > > >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote: > > > >> > >We added direct ACPI binding to the driver in addition to PNP, > > > >> > >so if you have an ACPI table it goes down that path and does > > > >> > >some additional validation of what is in the TPM. The BIOS > > > >> > >must provide a acpi_dev_resource_memory and a ACPI_SIG_TPM2 > > > >> > >for the ACPI entry at a minimum. > > > >> > > > > >> > Is it correct, that this is added in/for 4.11, so just > > > >> > recently? Testing with Linux 4.10.8, everything is detected > just fine. > > > >> > > > >> No, it is quite a bit older.. And it should only go for TPM2, > > > >> which I don't think you have?? > > > >> > > > >> Maybe Jarkko has a guess, but sure sounds like something is > > > >> recently broken in 4.11 > > > > > > > > I'll come back to this. I have to re-read the whole mail thread to > > > > get back into the context. Lots of multitasking because of release > > > > and so forth. Sorry for the latency! > > > > > > I started bisecting this issue. This is the current state. > > > > […] > > > > Here are the results. > > > > ``` > > git bisect log > > # bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag > > 'dm-4.11-changes' of > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm > > # good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10 git > > bisect start 'HEAD' 'v4.10' > > # good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag > > 'regmap-v4.11' of > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap > > git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d > > # bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix > > build paravirt build on arm and arm64 git bisect bad > > fd4a61e08aa79f2b7835b25c6f94f27bd2d65990 > > # good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag > > 'leds_for_4.11' of > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds > > git bisect good 7aa7d608112baf63a0b1278955f9619427373807 > > # good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag > > 'pm-4.11-rc1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > > git bisect good 02c3de1105228e367320e7fdeffbf511904f398c > > # bad: [6c24337f22115d669e24ce990842dab667371b4d] Merge tag > > 'fscrypt-for-linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt > > git bisect bad 6c24337f22115d669e24ce990842dab667371b4d > > # bad: [a74d1cafc22e100a9b59c50943ca09c37e03dce8] Merge branches > 'acpi-bus', 'acpi-sleep' and 'acpi-processor' > > git bisect bad a74d1cafc22e100a9b59c50943ca09c37e03dce8 > > # bad: [ce87e09dd88c61f9088768a7708828423549725c] ACPICA: Parser: > > Allow method invocations as target operands git bisect bad > > ce87e09dd88c61f9088768a7708828423549725c > > # good: [0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076] ACPICA: Hardware: > > Add sleep register hooks git bisect good > > 0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076 > > # good: [a654b8ca6d28736995de767ba62e801fd806a3b2] ACPICA: > > Disassembler: Add Switch/Case disassembly support git bisect good > > a
RE: [PATCH] ACPICA: Export mutex functions
The ACPICA mutex functions are based on the host OS functions, so they don't really buy you anything. You should just use the native Linux functions. > -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Wednesday, April 12, 2017 8:13 AM > To: Moore, Robert ; Zheng, Lv > ; Wysocki, Rafael J ; > Len Brown > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org; Guenter Roeck > Subject: [PATCH] ACPICA: Export mutex functions > > Mutex functions may be needed by drivers. Examples are accesses to > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO > environmental monitor registers, both which may also be accessed through > DSDT. > > Signed-off-by: Guenter Roeck > --- > drivers/acpi/acpica/utxfmutex.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/acpi/acpica/utxfmutex.c > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f > 100644 > --- a/drivers/acpi/acpica/utxfmutex.c > +++ b/drivers/acpi/acpica/utxfmutex.c > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle, acpi_string > pathname, u16 timeout) > status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout); > return (status); > } > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex) > > > /*** > > * > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle handle, > acpi_string pathname) > acpi_os_release_mutex(mutex_obj->mutex.os_mutex); > return (AE_OK); > } > +ACPI_EXPORT_SYMBOL(acpi_release_mutex) > -- > 2.7.4
RE: [PATCH] ACPICA: use designated initializers
> -Original Message- > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees > Cook > Sent: Monday, April 3, 2017 10:29 AM > To: Moore, Robert > Cc: Zheng, Lv ; linux-kernel@vger.kernel.org; > Wysocki, Rafael J ; Len Brown > ; linux-a...@vger.kernel.org; de...@acpica.org > Subject: Re: [PATCH] ACPICA: use designated initializers > > On Fri, Mar 31, 2017 at 5:45 PM, Moore, Robert > wrote: > > Acpica is built with many compilers, even very old ones. It runs on at > least 12 known operating systems, and very probably more. > > > > I'm sorry, but no, we are not going to start adding compiler-specific > ifdefs/code in the base ACPICA code. > > > > I don't care what you do in the Linux-specific or gcc-specific > headers, however. If this breaks a customer build, we (you) will hear > about it rather quickly. > > Since the change is specific to the one place ACPICA uses an all- > function-pointer structure, I made the change local: > > https://github.com/acpica/acpica/pull/248 > > would you rather this is in the .h files instead? > > -Kees > > -- > Kees Cook > Pixel Security [Moore, Robert] I have some questions about this entire issue: + * Some compilers can handle designated initializers, which is needed + * under Linux kernel builds for structures that are entirely function * pointers. I don't understand why this is coming up now, since ACPICA has been integrated with Linux for something like the last 15 years. It's the "which is needed under Linux kernel builds" wording that concerns me the most. Are you saying that the ACPICA build for Linux is broken and does not work? Further, there are quite a few similar dispatch tables in ACPICA, why are these not a problem? Bob
RE: [PATCH] ACPICA: use designated initializers
Acpica is built with many compilers, even very old ones. It runs on at least 12 known operating systems, and very probably more. I'm sorry, but no, we are not going to start adding compiler-specific ifdefs/code in the base ACPICA code. I don't care what you do in the Linux-specific or gcc-specific headers, however. If this breaks a customer build, we (you) will hear about it rather quickly. Bob
RE: [PATCH] ACPICA: use designated initializers
Yes, ACPICA must support many compilers, so we keep the code as simple as
possible.
Many of the corporate OS vendors use their own compilers.
> -Original Message-
> From: Zheng, Lv
> Sent: Wednesday, March 29, 2017 7:12 PM
> To: Kees Cook
> Cc: linux-kernel@vger.kernel.org; Moore, Robert
> ; Wysocki, Rafael J
> ; Len Brown ; linux-
> a...@vger.kernel.org; de...@acpica.org
> Subject: RE: [PATCH] ACPICA: use designated initializers
>
> Hi,
>
> > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of
> > Kees Cook
> > Subject: Re: [PATCH] ACPICA: use designated initializers
> >
> > On Sun, Dec 18, 2016 at 10:06 PM, Zheng, Lv
> wrote:
> > > Hi,
> > >
> > >> From: Kees Cook [mailto:keesc...@chromium.org]
> > >> Subject: [PATCH] ACPICA: use designated initializers
> > >>
> > >> Prepare to mark sensitive kernel structures for randomization by
> > >> making sure they're using designated initializers. These were
> > >> identified during allyesconfig builds of x86, arm, and arm64, with
> > >> most initializer fixes extracted from grsecurity.
> > >
> > > This commit is not suitable for ACPICA upstream.
> > > It's not portable. Please drop.
> >
> > What compilers are building this that do not support designated
> > initializers? Also, couldn't this be made into a macro so it could be
> > supported in either case?
>
> It's MSVC.
> In ACPICA upstream, it supports Intel compiler, GCC and MSVC.
>
> >
> > #ifdef __GNUC__
> > # define ACPI_SLEEP_FUNCTIONS(legacy, extended) { \
> > .legacy_function = legacy, \
> > .extended_function = extended, \
> > }
> > #else
> > # define ACPI_SLEEP_FUNCTIONS(legacy, extended) { legacy, extended }
> > #endif
> >
> > ...
> >
> > static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> > ACPI_SLEEP_FUNCTIONS(
> >ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> >acpi_hw_extended_sleep), ...
>
> There are many such cases in ACPICA, and I couldn't see the benefit to
> introduce such mechanism to such a software whose purposes contain
> portability.
> Unless you can invent a mechanism that can be utilized by all such
> cases.
> Then you should put it into acgcc.h and implement a replaceable in
> acmsvc.h.
> After that, you surely need to do a cleanup in the entire ACPICA code
> base using this new mechanism.
>
> Thanks
> Lv
>
> >
> >
> > -Kees
> >
> > >
> > > Thanks
> > > Lv
> > >
> > >>
> > >> Signed-off-by: Kees Cook
> > >> ---
> > >> drivers/acpi/acpica/hwxfsleep.c | 11 ++-
> > >> 1 file changed, 6 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/drivers/acpi/acpica/hwxfsleep.c
> > >> b/drivers/acpi/acpica/hwxfsleep.c index f76e0eab32b8..25cd5c66e102
> > >> 100644
> > >> --- a/drivers/acpi/acpica/hwxfsleep.c
> > >> +++ b/drivers/acpi/acpica/hwxfsleep.c
> > >> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8
> > >> sleep_state, u32 function_id);
> > >> /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE
> > >> */
> > >>
> > >> static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> > >> - {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> > >> - acpi_hw_extended_sleep},
> > >> - {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> > >> - acpi_hw_extended_wake_prep},
> > >> - {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
> acpi_hw_extended_wake}
> > >> + { .legacy_function =
> ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> > >> + .extended_function = acpi_hw_extended_sleep },
> > >> + { .legacy_function =
> ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> > >> + .extended_function = acpi_hw_extended_wake_prep },
> > >> + { .legacy_function =
> ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
> > >> + .extended_function = acpi_hw_extended_wake }
> > >> };
> > >>
> > >> /*
> > >> --
> > >> 2.7.4
> > >>
> > >>
> > >> --
> > >> Kees Cook
> > >> Nexus Security
> >
> >
> >
> > --
> > Kees Cook
> > Pixel Security
RE: [PATCH] acpi: acpica: fix acpi operand cache leak
I'm sure we would like to backport the memory leak into ACPICA code.
Not sure about the warnings.
> -Original Message-
> From: lkp
> Sent: Saturday, February 11, 2017 7:56 PM
> To: Seunghun Han
> Cc: kbuild-...@01.org; Zheng, Lv ; Moore, Robert
> ; Wysocki, Rafael J
> ; linux-kernel@vger.kernel.org; Seunghun Han
>
> Subject: Re: [PATCH] acpi: acpica: fix acpi operand cache leak
>
> Hi Seunghun,
>
> [auto build test WARNING on pm/linux-next] [also build test WARNING on
> v4.10-rc7 next-20170210] [if your patch is applied to the wrong git
> tree, please drop us a note to help improve the system]
>
> url:https://github.com/0day-ci/linux/commits/Seunghun-Han/acpi-
> acpica-fix-acpi-operand-cache-leak/20170212-105735
> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-
> pm.git linux-next
> config: i386-randconfig-x003-201707 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All warnings (new ones prefixed by >>):
>
>drivers/acpi/acpica/nsutils.c: In function 'acpi_ns_terminate':
> >> drivers/acpi/acpica/nsutils.c:600:2: warning: ISO C90 forbids mixed
> >> declarations and code [-Wdeclaration-after-statement]
> union acpi_operand_object *prev;
> ^
>
> vim +600 drivers/acpi/acpica/nsutils.c
>
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 584
> * FUNCTION:acpi_ns_terminate
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 585
> *
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 586
> * PARAMETERS: none
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 587
> *
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 588
> * RETURN: none
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 589
> *
> 44f6c012 drivers/acpi/namespace/nsutils.c Robert Moore 2005-04-18 590
> * DESCRIPTION: free memory allocated for namespace and ACPI table
> storage.
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 591
> *
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 592
>
> **/
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 593
> 4be44fcd drivers/acpi/namespace/nsutils.c Len Brown 2005-08-05 594
> void acpi_ns_terminate(void)
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 595
> {
> 3f69fe15 drivers/acpi/acpica/nsutils.cBob Moore 2013-11-21 596
> acpi_status status;
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 597
> b229cf92 drivers/acpi/namespace/nsutils.c Bob Moore 2006-04-21 598
> ACPI_FUNCTION_TRACE(ns_terminate);
> ^1da177e drivers/acpi/namespace/nsutils.c Linus Torvalds 2005-04-16 599
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 @600
> union acpi_operand_object *prev;
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 601
> union acpi_operand_object *next;
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 602
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 603
> /* Delete any module-level code blocks */
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 604
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 605
> next = acpi_gbl_module_code_list;
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 606
> while (next) {
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 607
> prev = next;
> 25823e78 drivers/acpi/acpica/nsutils.cBob Moore 2015-08-25 608
> next = next->method.mutex;
>
> :: The code at line 600 was first introduced by commit
> :: 25823e784aac78964ada0e49efe2766d2aeb9fa4 ACPICA: Add additional
> debug info/statements
>
> :: TO: Bob Moore
> :: CC: Rafael J. Wysocki
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all Intel
> Corporation
RE: [PATCH] acpica: Fix double-free in acpi_ns_repair_CID()
Here's the sequence of events as I see it: Repair_HID is a standalone function that removes one reference on the incoming object. For simple _HID objects, this in fact deletes the object. For _CID, all elements of the package are examined. If a repair was made on a _HID within the _CID function, one reference on the original object was removed by Repair_HID. However, since the object is part of a package, it has an extra reference to reflect this fact. Thus, in the case in question, the elements of the package all have at least two references. Repair_HID removes one reference, thus the extra RemoveReference is needed in Repair_CID to bring the reference count down to zero actually delete the object (in the typical case where the object had two references). Bob > -Original Message- > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com] > Sent: Friday, February 03, 2017 12:57 PM > To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown; Lin Ming > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org; Daniel Drake; li...@endlessm.com; João Paulo Rechi > Vita > Subject: [PATCH] acpica: Fix double-free in acpi_ns_repair_CID() > > When acpi_ns_repair_CID() is called for a _CID which returns a package of > strings, it calls acpi_ns_repair_HID() for each of the package elements. > acpi_ns_repair_HID() calls acpi_ut_remove_reference() on the original > object, but acpi_ns_repair_CID() calls it again on return, leading to a > double free. > > This problem was seen on a Acer TravelMate P449-G2-MG. > > Thanks to Daniel Drake for helping investigating this problem. > > Signed-off-by: João Paulo Rechi Vita > --- > drivers/acpi/acpica/nsrepair2.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/acpi/acpica/nsrepair2.c > b/drivers/acpi/acpica/nsrepair2.c index d5336122486b..c429c8eca476 100644 > --- a/drivers/acpi/acpica/nsrepair2.c > +++ b/drivers/acpi/acpica/nsrepair2.c > @@ -411,8 +411,6 @@ acpi_ns_repair_CID(struct acpi_evaluate_info *info, > > (*element_ptr)->common.reference_count = > original_ref_count; > - > - acpi_ut_remove_reference(original_element); > } > > element_ptr++; > -- > 2.11.0
RE: [PATCH] acpi: Fix format string type mistakes
These formatting changes will not compile under:
Gcc 4.4.5
Gcc 5.4.0
The printf formatting stuff is very delicate, as ACPICA has to be compiled
under many different compilers.
Bob
> -Original Message-
> From: Zheng, Lv
> Sent: Wednesday, December 21, 2016 12:07 AM
> To: Kees Cook ; Moore, Robert
>
> Cc: Wysocki, Rafael J ; linux-
> ker...@vger.kernel.org; linux-a...@vger.kernel.org; Emese Revfy
> ; de...@acpica.org
> Subject: RE: [PATCH] acpi: Fix format string type mistakes
>
> Hi, Kees and Emese
>
> The pull request is under rebasing.
> So if you cannot reach the URL, find the commit here:
> https://github.com/acpica/acpica/pull/196
>
> Thanks and best regards
> Lv
>
> > From: Zheng, Lv
> > Subject: RE: [PATCH] acpi: Fix format string type mistakes
> >
> > Hi, Kees and Emese
> >
> > I just helped to back port the commit here:
> > https://github.com/acpica/acpica/pull/196/commits/5e64857f
> > If you can see something wrong in it, please let me know.
> >
> > Thanks and best regards
> > Lv
> >
> > > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Zheng, Lv
> > > Subject: Re: [Devel] [PATCH] acpi: Fix format string type mistakes
> > >
> > > Hi,
> > >
> > > > From: Kees Cook [mailto:keesc...@chromium.org]
> > > > Subject: [PATCH] acpi: Fix format string type mistakes
> > > >
> > > > From: Emese Revfy
> > > >
> > > > This adds the missing __printf attribute which allows compile time
> > > > format string checking (and will be used by the coming initify gcc
> > > > plugin). Additionally, this fixes the warnings exposed by the
> attribute.
> > > >
> > > > Signed-off-by: Emese Revfy
> > > > [kees: split scsi/acpi, merged attr and fix, new commit messages]
> > > > Signed-off-by: Kees Cook
> > > > ---
> > > > drivers/acpi/acpica/dbhistry.c | 2 +-
> > > > drivers/acpi/acpica/dbinput.c | 10 ++---
> > > > drivers/acpi/acpica/dbstats.c | 88
> > > > +-
> > > > drivers/acpi/acpica/utdebug.c | 2 +-
> > > > include/acpi/acpiosxf.h| 3 +-
> > > > 5 files changed, 53 insertions(+), 52 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/acpica/dbhistry.c
> > > > b/drivers/acpi/acpica/dbhistry.c index 46bd65d38df9..ec9da4830f6a
> > > > 100644
> > > > --- a/drivers/acpi/acpica/dbhistry.c
> > > > +++ b/drivers/acpi/acpica/dbhistry.c
> > > > @@ -155,7 +155,7 @@ void acpi_db_display_history(void)
> > > >
> > > > for (i = 0; i < acpi_gbl_num_history; i++) {
> > > > if (acpi_gbl_history_buffer[history_index].command) {
> > > > - acpi_os_printf("%3ld %s\n",
> > > > + acpi_os_printf("%3u %s\n",
> > > >
> acpi_gbl_history_buffer[history_index].
> > > >cmd_num,
> > > >
> acpi_gbl_history_buffer[history_index].
> > > > diff --git a/drivers/acpi/acpica/dbinput.c
> > > > b/drivers/acpi/acpica/dbinput.c index 068214f9cc9d..43be06bdb790
> > > > 100644
> > > > --- a/drivers/acpi/acpica/dbinput.c
> > > > +++ b/drivers/acpi/acpica/dbinput.c
> > > > @@ -608,7 +608,7 @@ static u32 acpi_db_get_line(char
> *input_buffer)
> > > > (acpi_gbl_db_parsed_buf, sizeof(acpi_gbl_db_parsed_buf),
> > > > input_buffer)) {
> > > > acpi_os_printf
> > > > - ("Buffer overflow while parsing input line (max %u
> characters)\n",
> > > > + ("Buffer overflow while parsing input line (max %lu
> > > > +characters)\n",
> > > > sizeof(acpi_gbl_db_parsed_buf));
> > > > return (0);
> > > > }
> > > > @@ -864,24 +864,24 @@ acpi_db_command_dispatch(char *input_buffer,
> > > >
> > > > if (param_count == 0) {
> > > > acpi_os_printf
> > > > - ("Current debug level for file output is:
> %8.8lX\n",
> > > > + ("Current debug level for file output is:
> %8.8X\n",
> > > > acpi_gbl_db_debug_level);
> > > >
RE: [PATCH] acpi: Fix format string type mistakes
> -Original Message- > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees > Cook > Sent: Friday, December 16, 2016 3:04 PM > To: Rafael J. Wysocki > Cc: Moore, Robert ; Linux Kernel Mailing List > ; Zheng, Lv ; Wysocki, > Rafael J ; Len Brown ; ACPI > Devel Maling List ; Emese Revfy > ; de...@acpica.org > Subject: Re: [PATCH] acpi: Fix format string type mistakes > > On Fri, Dec 16, 2016 at 2:36 PM, Rafael J. Wysocki > wrote: > > On Fri, Dec 16, 2016 at 10:51 PM, Kees Cook > wrote: > >> From: Emese Revfy > >> > >> This adds the missing __printf attribute which allows compile time > >> format string checking (and will be used by the coming initify gcc > >> plugin). Additionally, this fixes the warnings exposed by the > attribute. > >> > >> Signed-off-by: Emese Revfy > >> [kees: split scsi/acpi, merged attr and fix, new commit messages] > >> Signed-off-by: Kees Cook > > > > This modifies code that we get from an external projiect (ACPICA) and > > the bugs should be fixed in there in the first place. > > Who should get CCed? > > > Moreover, I'm not sure if adding __printf in acpiosxf.h is a good > idea. > > Why not? This is going to be needed by the initify plugin to do correct > detection of what's being passed around to functions... > [Moore, Robert] It's compiler-dependent. > -Kees > > -- > Kees Cook > Nexus Security
RE: [PATCH] ACPI: allow compilation with bare metal compilers
The design for all of this is as follows: 1) OS-dependent includes 2) Compiler-specific includes 3) acenv.h is the master file that pulls in the correct headers (one compiler, and one OS) So, I think I see a couple of possible solutions for you: 1) If you are using GCC, the __GNUC__ symbol should already be defined. 2) If "aclinux.h" works for you, we can either add a conditional case that would apply to your environment, or: 2a) You could define _LINUX in your gcc invocations. Because ACPICA supports many different environments, we don't want to have a "default" case which in a sense would only be an attempt to guess what the user intended. We want to have a clear error that tells the user that something important needs to be done before the code can be compiled. Bob > -Original Message- > From: Al Stone [mailto:a...@redhat.com] > Sent: Monday, November 14, 2016 3:09 PM > To: linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org > Cc: Al Stone ; Rafael J . Wysocki ; > Len Brown ; Moore, Robert ; > Zheng, Lv > Subject: [PATCH] ACPI: allow compilation with bare metal compilers > > The ACPICA subsystem of the ACPI driver sets up a compilation > environment for itself, adding in multiple typedefs unique to ACPICA > that depend on where ACPICA will be used. > > The vast majority of such environments (Linux, QNX, ...) have an > environment defined by the acenv.h header file. When using a Linaro > compiler [1] specifically built to be used in an embedded environment > with perhaps a kernel and an init process as the only things running, > there is no environment defined for ACPICA so the typedefs it needs are > not set up, causing compilation to fail badly unless ACPI is completely > disabled. > Since ACPI is enabled in the default config for the kernel, the > compilation failure is fairly obvious. > > This may not be the optimal solution, but add in to the ACPI header file > include/acpi/platform/acenv.h a default so that if GCC is being used, > and all else fails, assume that we are going to be in a Linux-like > environment and re-use the environment definition for Linux. This > allows us to build a kernel using this compiler [1] with or without > ACPI. > > [1] > https://releases.linaro.org/components/toolchain/binaries/latest/aarch64 > -elff/gcc-linaro-6.1.1-2016-08-x86_64_aarch64-elf.tar.xz > > Signed-off-by: Al Stone > Cc: Rafael J. Wysocki > Cc: Len Brown > Cc: Robert Moore > Cc: Lv Zheng > --- > include/acpi/platform/acenv.h | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/include/acpi/platform/acenv.h > b/include/acpi/platform/acenv.h index 34cce72..cdd1cd6 100644 > --- a/include/acpi/platform/acenv.h > +++ b/include/acpi/platform/acenv.h > @@ -234,6 +234,21 @@ > #elif defined(_AED_EFI) || defined(_GNU_EFI) || defined(_EDK2_EFI) > #include "acefi.h" > > +/* > + * Up to this point, we've been looking for specific environments. In > + * some cases, there is no environment, and we're just working on bare > + * metal. However, since we're compiling the Linux kernel, let's just > + * pretend we're in a Linux environment. > + */ > +#elif defined(__GNUC__) && !defined(__INTEL_COMPILER) #if > +!defined(_LINUX) #define _LINUX #endif #if !defined(__linux__) #define > +__linux__ #endif #include > + > #else > > /* Unknown environment */ > -- > 2.10.2
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 / Interpreter: Remove redundant newline
> Please do not top-post. You're not going to get a lot of help by scolding me. Bob > -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Friday, September 9, 2016 11:41 AM > To: Moore, Robert > Cc: LKML ; Zheng, Lv ; > Wysocki, Rafael J ; Len Brown > ; linux-a...@vger.kernel.org; de...@acpica.org > Subject: Re: [PATCH] ACPICA / Interpreter: Remove redundant newline > > On Fri, Sep 09, 2016 at 06:26:17PM +, Moore, Robert wrote: > > Is this a big deal? > > > > We do this on purpose for AcpiExec, to make the screen output more > readable. > > Please do not top-post. > > What do you mean "big deal"? All other ACPI_INFO calls don't have a "\n" > at the end except this one. How does one "\n" make some output more > readable? > > (Btw, I have no idea what AcpiExec is. Grepping the kernel tree doesn't > give any results). > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply.
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
+
+
UnlockAndExit:
(void) AcpiUtReleaseMutex (ACPI_MTX_TABLES);
return_ACPI_STATUS (Status);
RE: [PATCH] ACPICA / Interpreter: Remove redundant newline
Is this a big deal?
We do this on purpose for AcpiExec, to make the screen output more readable.
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Friday, September 9, 2016 9:13 AM
> To: LKML
> Cc: Moore, Robert ; Zheng, Lv
> ; Wysocki, Rafael J ;
> Len Brown ; linux-a...@vger.kernel.org;
> de...@acpica.org
> Subject: [PATCH] ACPICA / Interpreter: Remove redundant newline
>
> From: Borislav Petkov
>
> acpi_info() already issues a '\n' so remove it in the call.
>
> Signed-off-by: Borislav Petkov
> Cc: Robert Moore
> Cc: Lv Zheng
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> Cc: de...@acpica.org
> ---
> 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 ac71abcd32bb..e7119b7ccd79 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.10.0
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: cleanup method properly on error
/* Put the new state at the head of the walk list */
if (Thread)
{
AcpiDsPushWalkState (WalkState, Thread);
}
Is there any chance that Thread could be zero?
> -Original Message-
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
> Sent: Tuesday, July 26, 2016 7:40 AM
> To: Vegard Nossum ; Zheng, Lv
> ; Wysocki, Rafael J
> Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org; de...@acpica.org
> Subject: Re: [Devel] [PATCH] ACPICA: cleanup method properly on error
>
> We'll look at this.
> Thanks.
>
>
> > -Original Message-
> > From: Vegard Nossum [mailto:vegard.nos...@oracle.com]
> > Sent: Friday, July 22, 2016 8:35 AM
> > To: Moore, Robert ; Zheng, Lv
> > ; Wysocki, Rafael J
> > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > ker...@vger.kernel.org; Vegard Nossum ;
> > sta...@vger.kernel.org
> > Subject: [PATCH] ACPICA: cleanup method properly on error
> >
> > If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
> > walk state push done by acpi_ds_create_walk_state(). Otherwise, the
> > new walk state (which has just been freed) will remain on the thread's
> > walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
> > to get the new state.
> >
> > You can observe this when reading e.g.
> >
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Vegard Nossum
> > ---
> > drivers/acpi/acpica/dsmethod.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/acpi/acpica/dsmethod.c
> > b/drivers/acpi/acpica/dsmethod.c index 47c7b52..44b50a6 100644
> > --- a/drivers/acpi/acpica/dsmethod.c
> > +++ b/drivers/acpi/acpica/dsmethod.c
> > @@ -596,6 +596,8 @@ cleanup:
> > /* On error, we must terminate the method properly */
> >
> > acpi_ds_terminate_control_method(obj_desc, next_walk_state);
> > + if (thread)
> > + acpi_ds_pop_walk_state(thread);
> > acpi_ds_delete_walk_state(next_walk_state);
> >
> > return_ACPI_STATUS(status);
> > --
> > 1.9.1
>
> ___
> Devel mailing list
> de...@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel
RE: [PATCH] ACPICA: cleanup method properly on error
We'll look at this. Thanks. > -Original Message- > From: Vegard Nossum [mailto:vegard.nos...@oracle.com] > Sent: Friday, July 22, 2016 8:35 AM > To: Moore, Robert ; Zheng, Lv > ; Wysocki, Rafael J > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org; Vegard Nossum ; > sta...@vger.kernel.org > Subject: [PATCH] ACPICA: cleanup method properly on error > > If the call to acpi_ds_init_aml_walk() fails, then we have to undo the > walk state push done by acpi_ds_create_walk_state(). Otherwise, the new > walk state (which has just been freed) will remain on the thread's > walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try > to get the new state. > > You can observe this when reading e.g. > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status > > Cc: sta...@vger.kernel.org > Signed-off-by: Vegard Nossum > --- > drivers/acpi/acpica/dsmethod.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/acpi/acpica/dsmethod.c > b/drivers/acpi/acpica/dsmethod.c index 47c7b52..44b50a6 100644 > --- a/drivers/acpi/acpica/dsmethod.c > +++ b/drivers/acpi/acpica/dsmethod.c > @@ -596,6 +596,8 @@ cleanup: > /* On error, we must terminate the method properly */ > > acpi_ds_terminate_control_method(obj_desc, next_walk_state); > + if (thread) > + acpi_ds_pop_walk_state(thread); > acpi_ds_delete_walk_state(next_walk_state); > > return_ACPI_STATUS(status); > -- > 1.9.1
RE: [PATCH 3/6] ACPICA: make use of new strtolower() function
> -Original Message-
> From: Markus Mayer [mailto:markus.ma...@broadcom.com]
> Sent: Thursday, June 30, 2016 9:13 PM
> To: Moore, Robert
> Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown; linux-a...@vger.kernel.org;
> de...@acpica.org; linux-kernel@vger.kernel.org; Box, David E
> Subject: Re: [PATCH 3/6] ACPICA: make use of new strtolower() function
>
> On 30 June 2016 at 19:59, Moore, Robert wrote:
> > This is linux-specific code, ACPICA is os-independent. So we cannot
> > accept such patch.
>
> Understood. I wasn't aware that this was shared code.
Ok. Glad to take fixes and optimizations, however.
Bob
>
> > From: Markus Mayer [mailto:markus.ma...@broadcom.com]
> > Sent: Thursday, June 30, 2016 7:50 PM
> > To: Moore, Robert
> > Cc: Zheng, Lv; Wysocki, Rafael J; Len Brown;
> > linux-a...@vger.kernel.org; de...@acpica.org;
> > linux-kernel@vger.kernel.org; Box, David E
> > Subject: Re: [PATCH 3/6] ACPICA: make use of new strtolower() function
> >
> > On Thursday, 30 June 2016, Moore, Robert wrote:
> >
> > Where is "strtolower" implemented?
> >
> > First patch of the series:
> >
> > https://lkml.org/lkml/2016/6/30/733
> >
> >> -Original Message-
> >> From: Markus Mayer [mailto:mma...@broadcom.com]
> >> Sent: Thursday, June 30, 2016 4:50 PM
> >> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown
> >> Cc: Markus Mayer; linux-a...@vger.kernel.org; de...@acpica.org;
> >> linux- ker...@vger.kernel.org
> >> Subject: [PATCH 3/6] ACPICA: make use of new strtolower() function
> >>
> >> Call strtolower() rather than walking the string explicitly to
> >> convert it to lowercase.
> >>
> >> Signed-off-by: Markus Mayer
> >> ---
> >>
> >> *** Please note that there don't seem to be any callers of
> >> acpi_ut_strlwr().
> >> *** It may be possible to remove the function altogether.
> >>
> >> drivers/acpi/acpica/utnonansi.c | 13 +
> >> 1 file changed, 1 insertion(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/acpi/acpica/utnonansi.c
> >> b/drivers/acpi/acpica/utnonansi.c index 3465fe2..b6e11dc 100644
> >> --- a/drivers/acpi/acpica/utnonansi.c
> >> +++ b/drivers/acpi/acpica/utnonansi.c
> >> @@ -64,19 +64,8 @@ ACPI_MODULE_NAME("utnonansi")
> >>
> >> *
> >> *
> >> /
> >> void acpi_ut_strlwr(char *src_string) {
> >> - char *string;
> >> -
> >> ACPI_FUNCTION_ENTRY();
> >> -
> >> - if (!src_string) {
> >> - return;
> >> - }
> >> -
> >> - /* Walk entire string, lowercasing the letters */
> >> -
> >> - for (string = src_string; *string; string++) {
> >> - *string = (char)tolower((int)*string);
> >> - }
> >> + strtolower(src_string);
> >> }
> >>
> >>
> >> /
> >> *
> >> **
> >> --
> >> 2.7.4
RE: [PATCH 3/6] ACPICA: make use of new strtolower() function
Where is "strtolower" implemented?
> -Original Message-
> From: Markus Mayer [mailto:mma...@broadcom.com]
> Sent: Thursday, June 30, 2016 4:50 PM
> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown
> Cc: Markus Mayer; linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH 3/6] ACPICA: make use of new strtolower() function
>
> Call strtolower() rather than walking the string explicitly to convert it
> to lowercase.
>
> Signed-off-by: Markus Mayer
> ---
>
> *** Please note that there don't seem to be any callers of
> acpi_ut_strlwr().
> *** It may be possible to remove the function altogether.
>
> drivers/acpi/acpica/utnonansi.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/acpi/acpica/utnonansi.c
> b/drivers/acpi/acpica/utnonansi.c index 3465fe2..b6e11dc 100644
> --- a/drivers/acpi/acpica/utnonansi.c
> +++ b/drivers/acpi/acpica/utnonansi.c
> @@ -64,19 +64,8 @@ ACPI_MODULE_NAME("utnonansi")
>
> **
> /
> void acpi_ut_strlwr(char *src_string)
> {
> - char *string;
> -
> ACPI_FUNCTION_ENTRY();
> -
> - if (!src_string) {
> - return;
> - }
> -
> - /* Walk entire string, lowercasing the letters */
> -
> - for (string = src_string; *string; string++) {
> - *string = (char)tolower((int)*string);
> - }
> + strtolower(src_string);
> }
>
>
> /*
> **
> --
> 2.7.4
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] 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] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2
Please send me the patch to actbl3.h > -Original Message- > From: Sudeep Holla [mailto:sudeep.ho...@arm.com] > Sent: Friday, April 08, 2016 5:58 AM > To: hotran > Cc: Jassi Brar; Rafael J. Wysocki; Len Brown; Moore, Robert; Zheng, Lv; > linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; > de...@acpica.org; Sudeep Holla; l...@apm.com; dhd...@apm.com > Subject: Re: [PATCH] mailbox: pcc: Support HW-Reduced Communication > Subspace Type 2 > > Hi, > > On 05/04/16 23:14, hotran wrote: > > ACPI 6.1 has a HW-Reduced Communication Subspace Type 2 intended for > > use on HW-Reduce ACPI Platform, which requires read-modify-write > > sequence to acknowledge doorbell interrupt. This patch provides the > > implementation for the Communication Subspace Type 2. > > > > Signed-off-by: Hoan Tran > > --- > > drivers/mailbox/pcc.c | 384 > > +- > > > include/acpi/actbl3.h | 8 +- > > This(2nd) file is generally imported from ACPICA directly. > > So you need to work with acpica-devel list(you can cc Robert Moore) to get > that alone integrated in acpica projected so that iasl tool and other > related components also gain support for this first. > > If the ACPI tables are generated by UEFI, it would be good to add the > support in tianocore project. IIRC tianocore has some PCC reference in > Acpi60.h header. > > It would help if the above two are done before we start looking into Linux > changes(pcc.c). To summarize this patch needs to be split. > > -- > Regards, > Sudeep
RE: [PATCH] ACPICA: Remove unnecessary "\n" from an ACPI_INFO boot message
Actually, I did in fact put that there to break up the output after the tables
are loaded. Is this a problem?
> -Original Message-
> From: Daniel Bristot de Oliveira [mailto:bris...@redhat.com]
> Sent: Monday, March 28, 2016 10:59 AM
> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] ACPICA: Remove unnecessary "\n" from an ACPI_INFO boot
> message
>
> A "\n" at the end of bellow ACPI_INFO message is causing a blank line in
> the kernel log:
>
> ACPI_INFO(("%u ACPI AML tables successfully acquired and loaded\n",
> tables_loaded));
>
> This patch removes the "\n".
>
> Kernel log before this patch:
> ACPI: Core revision 20160108
> ACPI: 2 ACPI AML tables successfully acquired and loaded
>
> Security Framework initialized
>
> Kernel log after this patch:
> ACPI: Core revision 20160108
> ACPI: 2 ACPI AML tables successfully acquired and loaded
> Security Framework initialized
>
> Signed-off-by: Daniel Bristot de Oliveira
>
> diff --git a/drivers/acpi/acpica/tbxfload.c
> b/drivers/acpi/acpica/tbxfload.c index 3151968..e435b84 100644
> --- a/drivers/acpi/acpica/tbxfload.c
> +++ b/drivers/acpi/acpica/tbxfload.c
> @@ -240,7 +240,8 @@ 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.5.0
RE: [RFC PATCH] acpi: Use a more normal logging style for ACPI_ calls
> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Tuesday, March 29, 2016 9:57 AM > To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown > Cc: linux-a...@vger.kernel.org; linux-kernel; de...@acpica.org > Subject: Re: [RFC PATCH] acpi: Use a more normal logging style for > ACPI_ calls > > On Tue, 2016-03-29 at 15:34 +, Moore, Robert wrote: > > On the other hand, we removed AE_INFO from ACPI_INFO a while back, and > > this may remove the necessity for the double parens. > > Hmm, maybe not. It may be that MSVC's support for __VA_ARGS__ is a bit > unusual. What's the minimum ACPICA msvc version required? 6 I think. The AE_INFO automatically injects the module name, line number, etc. Compatibility across compilers is a major requirement for us.
RE: [RFC PATCH] acpi: Use a more normal logging style for ACPI_ calls
Probably not, because ACPI_INFO is a public (and documented) macro, and ACPICA
is used in many operating systems.
The double parens are there to allow for variable-length arguments, I believe.
Bob
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Monday, March 28, 2016 8:30 PM
> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown
> Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel
> Subject: [RFC PATCH] acpi: Use a more normal logging style for
> ACPI_ calls
>
> This is just an example of a conversion of ACPI_INFO to a more typical
> kernel use style. All of the other ACPI_ calls would also need
> conversion.
>
> Almost all logging functions and macros in the kernel are lower case and
> nearly all use formats with terminating newlines.
>
> ACPI uses upper case macros and no terminating newline in the format.
>
> Some of the uses though _do_ have newlines. This can cause undesired
> newlines in dmesg output.
>
> Also, the ACPI_ macros use a somewhat odd and unpleasant style with
> double parentheses.
>
> Convert this to a lower case macro, add terminating newlines to formats
> and remove the unnecessary extra parentheses.
>
> Rename the logging function to _acpi_info and have the acpi_info macros
> call this _acpi_info function.
>
> Remove the newline from the _acpi_info call.
>
> This means that all calls to acpi_info are complete and it is not possible
> for any other message to be interleaved into this message.
>
> Miscellanea:
>
> o Coalesce formats
> o Realign arguments
> o Coalesce arguments even if > 80 columns
> ---
> drivers/acpi/acpica/dbcmds.c| 4 ++--
> drivers/acpi/acpica/dsmethod.c | 6 ++
> drivers/acpi/acpica/dsobject.c | 5 ++---
> drivers/acpi/acpica/evgpeblk.c | 8
> drivers/acpi/acpica/evgpeinit.c | 2 +-
> drivers/acpi/acpica/exconfig.c | 4 ++--
> drivers/acpi/acpica/nseval.c| 4 ++--
> drivers/acpi/acpica/tbinstal.c | 15 +++
> drivers/acpi/acpica/tbprint.c | 36
> drivers/acpi/acpica/tbutils.c | 3 ++-
> drivers/acpi/acpica/tbxfload.c | 5 +++--
> drivers/acpi/acpica/uttrack.c | 2 +-
> drivers/acpi/acpica/utxferror.c | 7 +++
> include/acpi/acoutput.h | 6 +++---
> include/acpi/acpixf.h | 2 +-
> 15 files changed, 51 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dbcmds.c b/drivers/acpi/acpica/dbcmds.c
> index 772178c..1ef21be 100644
> --- a/drivers/acpi/acpica/dbcmds.c
> +++ b/drivers/acpi/acpica/dbcmds.c
> @@ -348,8 +348,8 @@ void acpi_db_display_table_info(char *table_arg)
> } else {
> /* If the pointer is null, the table has been unloaded
> */
>
> - ACPI_INFO(("%4.4s - Table has been unloaded",
> - table_desc->signature.ascii));
> + acpi_info("%4.4s - Table has been unloaded\n",
> + table_desc->signature.ascii);
> }
> }
> }
> diff --git a/drivers/acpi/acpica/dsmethod.c
> b/drivers/acpi/acpica/dsmethod.c index 1982310..4730b0a 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -809,10 +809,8 @@ acpi_ds_terminate_control_method(union
> acpi_operand_object *method_desc,
> if (method_desc->method.
> info_flags & ACPI_METHOD_SERIALIZED_PENDING) {
> if (walk_state) {
> - ACPI_INFO(("Marking method %4.4s as Serialized "
> - "because of AE_ALREADY_EXISTS error",
> - walk_state->method_node->name.
> - ascii));
> + acpi_info("Marking method %4.4s as Serialized
> because of AE_ALREADY_EXISTS error\n",
> + walk_state->method_node->name.ascii);
> }
>
> /*
> diff --git a/drivers/acpi/acpica/dsobject.c
> b/drivers/acpi/acpica/dsobject.c index a91de2b..6787274 100644
> --- a/drivers/acpi/acpica/dsobject.c
> +++ b/drivers/acpi/acpica/dsobject.c
> @@ -524,9 +524,8 @@ acpi_ds_build_internal_package_obj(struct
> acpi_walk_state *walk_state,
> arg = arg->common.next;
> }
>
> - ACPI_INFO(("Actual Package length (%u) is larger than "
> - "NumElements field (%u), truncated",
> - i, element_
RE: [RFC PATCH] acpi: Use a more normal logging style for ACPI_ calls
On the other hand, we removed AE_INFO from ACPI_INFO a while back, and this may
remove the necessity for the double parens.
> -Original Message-
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
> Sent: Tuesday, March 29, 2016 8:27 AM
> To: Joe Perches; Zheng, Lv; Wysocki, Rafael J; Len Brown
> Cc: linux-a...@vger.kernel.org; linux-kernel; de...@acpica.org
> Subject: Re: [Devel] [RFC PATCH] acpi: Use a more normal logging style for
> ACPI_ calls
>
> Probably not, because ACPI_INFO is a public (and documented) macro, and
> ACPICA is used in many operating systems.
>
> The double parens are there to allow for variable-length arguments, I
> believe.
>
> Bob
>
>
> > -Original Message-
> > From: Joe Perches [mailto:j...@perches.com]
> > Sent: Monday, March 28, 2016 8:30 PM
> > To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len Brown
> > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel
> > Subject: [RFC PATCH] acpi: Use a more normal logging style for
> > ACPI_ calls
> >
> > This is just an example of a conversion of ACPI_INFO to a more typical
> > kernel use style. All of the other ACPI_ calls would also need
> > conversion.
> >
> > Almost all logging functions and macros in the kernel are lower case
> > and nearly all use formats with terminating newlines.
> >
> > ACPI uses upper case macros and no terminating newline in the format.
> >
> > Some of the uses though _do_ have newlines. This can cause undesired
> > newlines in dmesg output.
> >
> > Also, the ACPI_ macros use a somewhat odd and unpleasant style
> > with double parentheses.
> >
> > Convert this to a lower case macro, add terminating newlines to
> > formats and remove the unnecessary extra parentheses.
> >
> > Rename the logging function to _acpi_info and have the acpi_info
> > macros call this _acpi_info function.
> >
> > Remove the newline from the _acpi_info call.
> >
> > This means that all calls to acpi_info are complete and it is not
> > possible for any other message to be interleaved into this message.
> >
> > Miscellanea:
> >
> > o Coalesce formats
> > o Realign arguments
> > o Coalesce arguments even if > 80 columns
> > ---
> > drivers/acpi/acpica/dbcmds.c| 4 ++--
> > drivers/acpi/acpica/dsmethod.c | 6 ++
> > drivers/acpi/acpica/dsobject.c | 5 ++---
> > drivers/acpi/acpica/evgpeblk.c | 8
> > drivers/acpi/acpica/evgpeinit.c | 2 +-
> > drivers/acpi/acpica/exconfig.c | 4 ++--
> > drivers/acpi/acpica/nseval.c| 4 ++--
> > drivers/acpi/acpica/tbinstal.c | 15 +++
> > drivers/acpi/acpica/tbprint.c | 36
> >
> > drivers/acpi/acpica/tbutils.c | 3 ++-
> > drivers/acpi/acpica/tbxfload.c | 5 +++--
> > drivers/acpi/acpica/uttrack.c | 2 +-
> > drivers/acpi/acpica/utxferror.c | 7 +++
> > include/acpi/acoutput.h | 6 +++---
> > include/acpi/acpixf.h | 2 +-
> > 15 files changed, 51 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/dbcmds.c
> > b/drivers/acpi/acpica/dbcmds.c index 772178c..1ef21be 100644
> > --- a/drivers/acpi/acpica/dbcmds.c
> > +++ b/drivers/acpi/acpica/dbcmds.c
> > @@ -348,8 +348,8 @@ void acpi_db_display_table_info(char *table_arg)
> > } else {
> > /* If the pointer is null, the table has been unloaded
> */
> >
> > - ACPI_INFO(("%4.4s - Table has been unloaded",
> > - table_desc->signature.ascii));
> > + acpi_info("%4.4s - Table has been unloaded\n",
> > + table_desc->signature.ascii);
> > }
> > }
> > }
> > diff --git a/drivers/acpi/acpica/dsmethod.c
> > b/drivers/acpi/acpica/dsmethod.c index 1982310..4730b0a 100644
> > --- a/drivers/acpi/acpica/dsmethod.c
> > +++ b/drivers/acpi/acpica/dsmethod.c
> > @@ -809,10 +809,8 @@ acpi_ds_terminate_control_method(union
> > acpi_operand_object *method_desc,
> > if (method_desc->method.
> > info_flags & ACPI_METHOD_SERIALIZED_PENDING) {
> > if (walk_state) {
> > - ACPI_INFO(("Marking method %4.4s as Serialized "
> > - "because of AE_ALREADY_EXISTS error",
> > - walk_state->
RE: [PATCH v6 2/5] ACPI: add definitions of DBG2 subtypes
We implemented all of these in ACPICA version 20160318.
> -Original Message-
> From: Aleksey Makarov [mailto:aleksey.maka...@linaro.org]
> Sent: Thursday, March 24, 2016 5:52 AM
> To: Greg Kroah-Hartman; Rafael J . Wysocki; Len Brown
> Cc: linux-ser...@vger.kernel.org; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Aleksey
> Makarov; Russell King; Leif Lindholm; Graeme Gregory; Al Stone;
> Christopher Covington; Yury Norov; Peter Hurley; Zheng, Lv; Moore, Robert;
> Wysocki, Rafael J; de...@acpica.org
> Subject: [PATCH v6 2/5] 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.4
RE: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure to comply ACPI 6.1
> > Another issue is that it is not clear who needs to perform the byte- > > swapping among ACPICA and drivers. If ACPICA, drivers must agree that ACPICA does not ever do anything with the "data tables" like NFIT, other than handing off the table when requested by a driver. > -Original Message- > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert > Sent: Tuesday, March 01, 2016 9:37 AM > To: Toshi Kani; r...@rjwysocki.net; Williams, Dan J > Cc: linux-nvd...@lists.01.org; linux-kernel@vger.kernel.org; linux- > a...@vger.kernel.org; elli...@hpe.com; de...@acpica.org > Subject: Re: [Devel] [PATCH v2 1/3] ACPI/NFIT: Update Control Region > Structure to comply ACPI 6.1 > > > > > -Original Message- > > From: Toshi Kani [mailto:toshi.k...@hpe.com] > > Sent: Tuesday, March 01, 2016 9:37 AM > > To: Moore, Robert; r...@rjwysocki.net; Williams, Dan J > > Cc: Zheng, Lv; elli...@hpe.com; linux-nvd...@lists.01.org; linux- > > a...@vger.kernel.org; linux-kernel@vger.kernel.org; de...@acpica.org > > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region Structure > > to comply ACPI 6.1 > > > > On Tue, 2016-03-01 at 16:03 +, Moore, Robert wrote: > > > We have a bunch of macros in include/acmacros.h -- like this: > > > > > > ACPI_MOVE_16_TO_16(d, s) > > > > There is a problem in using the ACPICA byte-swap macros. ACPI is > > little- endian arch, so the macros are set to perform byte-swappings > > when the CPU arch is big-endian. This case, however, is the other way > > around. The fields in question are defined & stored as arrays of bytes. > > That's not what I see in the ACPI spec. The fields are defined like any > other ACPI table. > > Vendor ID 2 6 > Identifier indicating the vendor of the NVDIMM. > This field shall be set to the value of the NVDIMM SPD Module Manufacturer > ID Code field a with byte 0 set to DDR4 SPD byte > 320 and byte 1 set to DDR4 SPD byte 321. > > Device ID 2 8 > Identifier for the NVDIMM, assigned by the module vendor. > This field shall be set to the value of the NVDIMM SPD Module Product > Identifier field b with byte 0 set to SPD byte 192 and byte 1 set to SPD > byte 193. > > Revision ID 2 10 > Revision of the NVDIMM, assigned by the module vendor. > Byte 1 of this field is reserved. > Byte 0 of this field shall be set to the value of the NVDIMM SPD Module > Revision Code field a (i.e., SPD byte 349). > > > Etc. > > > If you treat > > them as multi-bytes numeric values, then you need to byte-swap them when > > the CPU arch is little-endian because arrays of bytes have the same > > addressing as big-endian. > > > > Another issue is that it is not clear who needs to perform the byte- > > swapping among ACPICA and drivers. If ACPICA, drivers must agree that > > these fields are always treated as multi-bytes numeric values despite of > > the spec. If drivers, we need to make sure that only a single driver > > performs this byte-swapping one time as ACPI tables are global > structures. > > > > I think it is much clearer to define the structure according to the ACPI > > spec. > > > > Thanks, > > -Toshi > > > > > > -Original Message- > > > > From: Toshi Kani [mailto:toshi.k...@hpe.com] > > > > Sent: Tuesday, March 01, 2016 8:38 AM > > > > To: Moore, Robert; r...@rjwysocki.net; Williams, Dan J > > > > Cc: Zheng, Lv; elli...@hpe.com; linux-nvd...@lists.01.org; linux- > > > > a...@vger.kernel.org; linux-kernel@vger.kernel.org; de...@acpica.org > > > > Subject: Re: [PATCH v2 1/3] ACPI/NFIT: Update Control Region > > > > Structure to comply ACPI 6.1 > > > > > > > > On Tue, 2016-03-01 at 15:13 +, Moore, Robert wrote: > > > > > > > > > > > -Original Message- > > > > > > From: Toshi Kani [mailto:toshi.k...@hpe.com] > > > > > > Sent: Monday, February 22, 2016 1:55 PM > > > > > > To: r...@rjwysocki.net; Williams, Dan J > > > > > > Cc: Moore, Robert; Zheng, Lv; elli...@hpe.com; > > > > > > linux-nvd...@lists.01.or g; linux-a...@vger.kernel.org; > > > > > > linux-kernel@vger.kernel.org; de...@acpica.org; Toshi Kani > > > > > > Subject: [PATCH v2 1/3] ACPI/NFIT: Update Control Region > > > > > > Structure to comply ACPI 6.1 > > > > > > > > > > > > ACPI 6.1, Table 5-133, updates NVDIMM Control Region Structure > > > > > >
