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;
> }
> -
> - /*lint -fallt
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,
> parse
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/acpica/exfldio.c index ade35ff1c7ba.
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_REFERENCE
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/acpica/dswexec.c > > b/drivers/acpi/acpica/dswexec.c index 1d4f8c81028c.
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
> +++ b/drivers/acpi/acpica/
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;
case ARGI
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, );
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 working as it 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_EXCEPTION if
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, >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, _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/acpixf.h
@@ -452,7 +452,8 @
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, );
+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->serial, buf + 7, 3);
> > >> > + memcpy(bix->serial
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->serial, buf + 7, 3);
> > >> > + memcpy(bix->serial
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 <linux-a...@vger.kernel.org>
> Cc: Zhang, Rui <rui.zh...@intel.com>; Linux PM p...@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Schmauss, Erik
> <erik.schma...@intel.com>; Moore, Robert <robert.mo...@intel.com>; Wang,
> Wendy <wendy.w...@intel.com>
> Subject: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()
>
> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>
> 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 <rafael.j.wyso...@intel.com>
> ---
> 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 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 <robert.mo...@intel.com>;
> alexander.le...@microsoft.com; linux-kernel@vger.kernel.org;
> sta...@vger.kernel.org
> Cc: Schmauss, Erik <erik.schma...@intel.com>; Wysocki, Rafael J
> <rafael.j.wyso...@intel.com>
> 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 <mario_limoncie...@dell.com>;
> > alexander.le...@microsoft.com; linux-kernel@vger.kernel.org;
> > sta...@vger.kernel.org
> > Cc: Schmauss, Erik <erik.schma...@intel.com>; Wysocki, Rafael J
> > <rafael.j.wyso...@intel.com>
> > 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 <robert.mo...@intel.com>; Schmauss, Erik
> > > <erik.schma...@intel.com>; Wysocki, Rafael J
> > > <rafael.j.wyso...@intel.com>
> > > 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 <mario_limoncie...@dell.com>; Bob Moore
> > > > <robert.mo...@intel.com>; Erik Schmauss <erik.schma...@intel.com>;
> > > Rafael J .
> > > > Wysocki <rafael.j.wyso...@intel.com>; Sasha Levin
> > > > <alexander.le...@microsoft.com>
> > > > Subject: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the
> > > > Windows
> > > > 10 version 1607 and 1703 OSI strings
> > > >
> > > > From: Mario Limonciello <mario.limoncie...@dell.com>
> > > >
> > > > [ 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 <mario.limoncie...@dell.com>
> > > > Signed-off-by: Bob Moore <robert.mo...@intel.com>
> > > > Signed-off-by: Erik Schmauss <erik.schma...@intel.com>
> > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > > > Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
> > > > ---
> > > > 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
&
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 <robert.mo...@intel.com>; Schmauss, Erik
> <erik.schma...@intel.com>; Wysocki, Rafael J
> <rafael.j.wyso...@intel.com>
> 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 <mario_limoncie...@dell.com>; Bob Moore
> > <robert.mo...@intel.com>; Erik Schmauss <erik.schma...@intel.com>;
> Rafael J .
> > Wysocki <rafael.j.wyso...@intel.com>; Sasha Levin
> > <alexander.le...@microsoft.com>
> > Subject: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the Windows
> > 10 version 1607 and 1703 OSI strings
> >
> > From: Mario Limonciello <mario.limoncie...@dell.com>
> >
> > [ 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 <mario.limoncie...@dell.com>
> > Signed-off-by: Bob Moore <robert.mo...@intel.com>
> > Signed-off-by: Erik Schmauss <erik.schma...@intel.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
> > ---
> > drivers/acpi/acpica/utosi.c | 2 ++
> > include/acpi/actypes.h | 2 ++
> > 2 files changed, 4 insertions(+)
> >
> > diff --git a/drivers/acpi/acpica/utosi.c b/drivers/acpi/acpica/utosi.c
> > index 8f3d203aed79..51d9011b5b33 100644
> > --- a/drivers/acpi/acpica/utosi.c
> > +++ b/drivers/acpi/acpica/utosi.c
> > @@ -101,6 +101,8 @@ static struct acpi_interface_info
> > acpi_default_supported_interfaces[] = {
> > {"Windows 2012", NULL, 0, ACPI_OSI_WIN_8}, /* Windows 8 and Server
> > 2012 - Added 08/2012 */
> > {"Windows 2013", NULL, 0, ACPI_OSI_WIN_8}, /* Windows 8.1 and
> Server
> > 2012 R2 - Added 01/2014 */
> > {"Windows 2015", NULL, 0, ACPI_OSI_WIN_10}, /* Windows 10 -
> Added
> > 03/2015 */
> > + {"Windows 2016", NULL, 0, ACPI_OSI_WIN_10_RS1}, /* Windows 10
> > version 1607 - Added 12/2017 */
> > + {"Windows 2017", NULL, 0, ACPI_OSI_WIN_10_RS2}, /* Windows 10
> > version 1703 - Added 12/2017 */
> >
> > /* Feature Group Strings */
> >
> > diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> > f914958c4adb..d27bc051f47f 100644
> > --- a/include/acpi/actypes.h
> > +++ b/include/acpi/actypes.h
> > @@ -1284,6 +1284,8 @@ typedef enum {
> > #define ACPI_OSI_WIN_7 0x0B
> > #define ACPI_OSI_WIN_8 0x0C
> > #define ACPI_OSI_WIN_10 0x0D
> > +#define ACPI_OSI_WIN_10_RS1 0x0E
> > +#define ACPI_OSI_WIN_10_RS2 0x0F
> >
> > /* Definitions of file IO */
> >
> > --
> > 2.14.1
>
> I don't believe that it would be a good idea to bring back this patch to
> kernels older than 4.15. These strings do activate some extra features
> in Windows and some BIOS ASL has been written to only activate them when
> the newer Windows versions are detected. I have no concerns bringing
> them to 4.15 though.
>
> Bringing them back to stable may introduce other problems that requires
> backporting additional driver changes too.
[Moore, Robert]
There should be no problem with this change concerning older machines. The
firmware on these machines will simply never call _OSI with any strings newer
than when the firmware was written -- including this new one.
Bob
RE: [PATCH AUTOSEL for 4.4 093/167] ACPICA: Recognize the Windows 10 version 1607 and 1703 OSI strings
> -Original Message-
> From: mario.limoncie...@dell.com [mailto:mario.limoncie...@dell.com]
> Sent: 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 <erik.schma...@intel.com>; 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 <robert.mo...@intel.com>
> 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 <andy.shevche...@gmail.com>; Kai-Heng Feng
> > <kai.heng.f...@canonical.com>
> > Cc: Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown
> > <l...@kernel.org>; ACPI Devel Maling List
> > <linux-a...@vger.kernel.org>; Linux Kernel Mailing List > ker...@vger.kernel.org>; Limonciello, Mario
> > <mario_limoncie...@dell.com>; Moore, Robert <robert.mo...@intel.com>
> > 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 <kai.heng.f...@canonical.com>
> > > Cc: Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown
> > > <l...@kernel.org>; ACPI Devel Maling List
> > > <linux-a...@vger.kernel.org>; Linux Kernel Mailing List > > ker...@vger.kernel.org>; Mario Limonciello
> > > <mario.limoncie...@dell.com>
> > > 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
> > > <kai.heng.f...@canonical.com> 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: 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 <robert.mo...@intel.com>; Zheng, Lv
> <lv.zh...@intel.com>; Wysocki, Rafael J <rafael.j.wyso...@intel.com>;
> 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 <vadim.lomovt...@cavium.com>
>
> 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 <vadim.lomovt...@cavium.com>
> ---
> 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] 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 <gomonov...@gmail.com>
> Cc: Moore, Robert <robert.mo...@intel.com>; Zheng, Lv
> <lv.zh...@intel.com>; Wysocki, Rafael J <rafael.j.wyso...@intel.com>;
> Len Brown <l...@kernel.org>; ACPI Devel Maling List a...@vger.kernel.org>; de...@acpica.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; Schmauss, Erik <erik.schma...@intel.com>
> Subject: Re: [PATCH] ACPICA: Fix indentation
>
> On Fri, Dec 8, 2017 at 5:29 PM, Vasyl Gomonovych <gomonov...@gmail.com>
> 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 <gomonov...@gmail.com>
>
> 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] 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 <robert.mo...@intel.com>; Zheng, Lv <lv.zh...@intel.com>;
> de...@acpica.org; Jeremy Linton <jeremy.lin...@arm.com>
> 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 <jeremy.lin...@arm.com>
> ---
> 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 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
> <robert.mo...@intel.com>; Zheng, Lv <lv.zh...@intel.com>
> 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 <b...@redhat.com>
> > ---
> > 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: [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 <colin.k...@canonical.com> > Cc: Wysocki, Rafael J <rafael.j.wyso...@intel.com>; Rafael J. Wysocki > <r...@rjwysocki.net>; Linux Kernel Mailing List ker...@vger.kernel.org>; ACPI Devel Maling List a...@vger.kernel.org>; Jérémy Lefaure <jeremy.lefa...@lse.epita.fr>; > 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 > <colin.k...@canonical.com> 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" <r...@rjwysocki.net> 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: [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 <lizhenhuajiy...@163.com>; de...@acpica.org; Zheng, Lv
> <lv.zh...@intel.com>; Wysocki, Rafael J <rafael.j.wyso...@intel.com>;
> 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 <robert.mo...@intel.com>; Zheng,
> > Lv <lv.zh...@intel.com>; Wysocki, Rafael J
> > <rafael.j.wyso...@intel.com>; l...@kernel.org;
> > linux-a...@vger.kernel.org; linux- ker...@vger.kernel.org
> > Cc: Zhenhua <lizhenhuajiy...@163.com>
> > 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 <lizhenhuajiy...@163.com>
> > ---
> > 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: 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 <robert.mo...@intel.com>; Zheng, Lv
> <lv.zh...@intel.com>; Wysocki, Rafael J <rafael.j.wyso...@intel.com>;
> l...@kernel.org; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Zhenhua <lizhenhuajiy...@163.com>
> 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 <lizhenhuajiy...@163.com>
> ---
> 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/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' <lorenzo.pieral...@arm.com>; linux-
> a...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> Zhang, Rui <rui.zh...@intel.com>; Rafael J. Wysocki <r...@rjwysocki.net>;
> Will Deacon <will.dea...@arm.com>; Robin Murphy <robin.mur...@arm.com>;
> Hanjun Guo <hanjun@linaro.org>; Feng Kan <f...@apm.com>; Jon Masters
> <j...@redhat.com>; Nate Watterson <nwatt...@codeaurora.org>
> 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
> > <lorenzo.pieral...@arm.com>; Moore, Robert <robert.mo...@intel.com>;
> Zhang, Rui <rui.zh...@intel.com>; Rafael J.
> > Wysocki <r...@rjwysocki.net>; Will Deacon <will.dea...@arm.com>; Robin
> > Murphy <robin.mur...@arm.com>; Hanjun Guo <hanjun@linaro.org>;
> > Feng Kan <f...@apm.com>; Jon Masters <j...@redhat.com>; Nate Watterson
> > <nwatt...@codeaurora.org>
> > 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 <lorenzo.pieral...@arm.com>
> > Cc: Robert Moore <robert.mo...@intel.com>
> > Cc: Zhang Rui <rui.zh...@intel.com>
> > Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
> > ---
> > 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, );
> 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
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, );
> 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 <lorenzo.pieral...@arm.com>; Moore, Robert
> <robert.mo...@intel.com>; Zhang, Rui <rui.zh...@intel.com>; Rafael J.
> Wysocki <r...@rjwysocki.net>; Will Deacon <will.dea...@arm.com>; Robin
> Murphy <robin.mur...@arm.com>; Hanjun Guo <hanjun@linaro.org>; Feng
> Kan <f...@apm.com>; Jon Masters <j...@redhat.com>; Nate Watterson
> <nwatt...@codeaurora.org>
> 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 <lorenzo.pieral...@arm.com>
> Cc: Robert Moore <robert.mo...@intel.com>
> Cc: Zhang Rui <rui.zh...@intel.com>
> Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
> ---
> 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, );
> 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, );
> 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 <ganapatrao.kulka...@cavium.com>; Zheng, Lv
> <lv.zh...@intel.com>; Moore, Robert <robert.mo...@intel.com>; Rafael J.
> Wysocki <r...@rjwysocki.net>
> 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 <ganapatrao.kulka...@cavium.com>
> > ---
> > 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 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 <lv.zh...@intel.com>; Moore, Robert > <robert.mo...@intel.com>; Wysocki, Rafael J <rafael.j.wyso...@intel.com> > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org; Seunghun Han <kkama...@gmail.com> > 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
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] ? rest_init+0
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 <robert.mo...@intel.com>; Zheng, Lv > <lv.zh...@intel.com>; Wysocki, Rafael J <rafael.j.wyso...@intel.com>; > l...@kernel.org; linux-kernel@vger.kernel.org; Seraphime Kirkovski > <kirkser...@gmail.com> > 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 <kirkser...@gmail.com> > --- > 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: [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 <ross.zwis...@linux.intel.com>; Anaczkowski, Lukasz
> <lukasz.anaczkow...@intel.com>; Box, David E <david.e@intel.com>;
> Kogut, Jaroslaw <jaroslaw.ko...@intel.com>; Lahtinen, Joonas
> <joonas.lahti...@intel.com>; Moore, Robert <robert.mo...@intel.com>;
> Nachimuthu, Murugasamy <murugasamy.nachimu...@intel.com>; Odzioba,
> Lukasz <lukasz.odzi...@intel.com>; Wysocki, Rafael J
> <rafael.j.wyso...@intel.com>; Rafael J. Wysocki <r...@rjwysocki.net>;
> Schmauss, Erik <erik.schma...@intel.com>; Verma, Vishal L
> <vishal.l.ve...@intel.com>; Zheng, Lv <lv.zh...@intel.com>; Williams,
> Dan J <dan.j.willi...@intel.com>; Hansen, Dave <dave.han...@intel.com>;
> Dave Hansen <dave.han...@linux.intel.com>; Greg Kroah-Hartman
> <gre...@linuxfoundation.org>; Len Brown <l...@kernel.org>; Tim Chen
> <tim.c.c...@linux.intel.com>; 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"
> <lv.zh...@intel.com>. 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 <ross.zwis...@linux.intel.com>
> ---
> 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_
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 <robert.mo...@intel.com>; Jan Kiszka > <jan.kis...@siemens.com> > Cc: Mika Westerberg <mika.westerb...@linux.intel.com>; Rafael J. Wysocki > <r...@rjwysocki.net>; Len Brown <l...@kernel.org>; Zheng, Lv > <lv.zh...@intel.com>; linux-a...@vger.kernel.org; Linux Kernel Mailing > List <linux-kernel@vger.kernel.org>; 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 <robert.mo...@intel.com> > wrote: > > > > > >> -Original Message- > >> From: Jan Kiszka [mailto:jan.kis...@siemens.com] > >> Sent: Monday, May 29, 2017 5:53 AM > >> To: Mika Westerberg <mika.westerb...@linux.intel.com> > >> Cc: Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown > >> <l...@kernel.org>; Zheng, Lv <lv.zh...@intel.com>; > >> linux-a...@vger.kernel.org; Linux Kernel Mailing List > >> <linux-kernel@vger.kernel.org>; de...@acpica.org; Moore, Robert > >> <robert.mo...@intel.com> > >> 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 <jan.kis...@siemens.com> > >> >> --- > >> >> > >> >> 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 0x004A1B18 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: 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 0x004A1B18 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 <mika.westerb...@linux.intel.com> > Cc: Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown <l...@kernel.org>; > Zheng, Lv <lv.zh...@intel.com>; linux-a...@vger.kernel.org; Linux Kernel > Mailing List <linux-kernel@vger.kernel.org>; de...@acpica.org; Moore, > Robert <robert.mo...@intel.com> > 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 <jan.kis...@siemens.com> > >> --- > >> > >> 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: 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 <robert.mo...@intel.com>
> Cc: Zheng, Lv <lv.zh...@intel.com>; Wysocki, Rafael J
> <rafael.j.wyso...@intel.com>; l...@kernel.org; linux-
> a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org;
> Karim Eshapa <karim.esh...@gmail.com>
> 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 <karim.esh...@gmail.com>
> ---
> 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: 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 <r...@rjwysocki.net>; Len Brown <l...@kernel.org>;
> Moore, Robert <robert.mo...@intel.com>; Zheng, Lv <lv.zh...@intel.com>
> 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 <jon.ma...@broadcom.com>
> ---
> 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: 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] 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 <li...@roeck-us.net>
> Cc: Zheng, Lv <lv.zh...@intel.com>; Rafael J. Wysocki
> <raf...@kernel.org>; Moore, Robert <robert.mo...@intel.com>; Wysocki,
> Rafael J <rafael.j.wyso...@intel.com>; Len Brown <l...@kernel.org>;
> linux-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
>
> 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: 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 <robert.mo...@intel.com> > Cc: Zheng, Lv <lv.zh...@intel.com>; Wysocki, Rafael J > <rafael.j.wyso...@intel.com>; 'Len Brown' <l...@kernel.org>; 'linux- > a...@vger.kernel.org' <linux-a...@vger.kernel.org>; 'de...@acpica.org' > <de...@acpica.org>; 'linux-kernel@vger.kernel.org' ker...@vger.kernel.org>; Box, David E <david.e@intel.com> > Subject: Re: [PATCH] ACPICA: Export mutex functions > > On Mon, Apr 17, 2017 at 07:27:37PM +0000, Moore, Robert wrote: > > > > > -Original Message- > > > From: Moore, Robert > > > Sent: Monday, April 17, 2017 10:13 AM > > > To: Guenter Roeck <li...@roeck-us.net>; Zheng, Lv > > > <lv.zh...@intel.com> > > > Cc: Wysocki, Rafael J <rafael.j.wyso...@intel.com>; Len Brown > > > <l...@kernel.org>; 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: 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' <li...@roeck-us.net>; Zheng, Lv <lv.zh...@intel.com> > Cc: Wysocki, Rafael J <rafael.j.wyso...@intel.com>; 'Len Brown' > <l...@kernel.org>; 'linux-a...@vger.kernel.org' a...@vger.kernel.org>; 'de...@acpica.org' <de...@acpica.org>; 'linux- > ker...@vger.kernel.org' <linux-kernel@vger.kernel.org>; Box, David E > (david.e@intel.com) <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 <li...@roeck-us.net>; Zheng, Lv <lv.zh...@intel.com> > > Cc: Wysocki, Rafael J <rafael.j.wyso...@intel.com>; Len Brown > > <l...@kernel.org>; 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 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 <li...@roeck-us.net>; Zheng, Lv <lv.zh...@intel.com> > Cc: Wysocki, Rafael J <rafael.j.wyso...@intel.com>; Len Brown > <l...@kernel.org>; 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
> -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
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 <robert.mo...@intel.com> > > > Cc: Zheng, Lv <lv.zh...@intel.com>; Wysocki, Rafael J > > > <rafael.j.wyso...@intel.com>; Len Brown <l...@kernel.org>; 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: 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 <robert.mo...@intel.com>
> Cc: Zheng, Lv <lv.zh...@intel.com>; Wysocki, Rafael J
> <rafael.j.wyso...@intel.com>; Len Brown <l...@kernel.org>; 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 <robert.mo...@intel.com>; Zheng, Lv
> > > <lv.zh...@intel.com>; Wysocki, Rafael J
> > > <rafael.j.wyso...@intel.com>; Len Brown <l...@kernel.org>
> > > Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
> > > ker...@vger.kernel.org; Guenter Roeck <li...@roeck-us.net>
> > > Subject: [PATCH] ACPICA: Export mutex functions
> > >
> > > Mutex functions may be needed by drivers. Examples are accesses to
> > > Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO
> > > environmental monitor registers, both which may also be accessed
> > > through DSDT.
> > >
> > > Signed-off-by: Guenter Roeck <li...@roeck-us.net>
> > > ---
> > > drivers/acpi/acpica/utxfmutex.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/acpi/acpica/utxfmutex.c
> > > b/drivers/acpi/acpica/utxfmutex.c index c016211c35ae..5d20581f4b2f
> > > 100644
> > > --- a/drivers/acpi/acpica/utxfmutex.c
> > > +++ b/drivers/acpi/acpica/utxfmutex.c
> > > @@ -150,6 +150,7 @@ acpi_acquire_mutex(acpi_handle handle,
> > > acpi_string pathname, u16 timeout)
> > > status = acpi_os_acquire_mutex(mutex_obj->mutex.os_mutex, timeout);
> > > return (status);
> > > }
> > > +ACPI_EXPORT_SYMBOL(acpi_acquire_mutex)
> > >
> > >
> > > /***
> > >
> > >
> > > *
> > > @@ -185,3 +186,4 @@ acpi_status acpi_release_mutex(acpi_handle
> > > handle, acpi_string pathname)
> > > acpi_os_release_mutex(mutex_obj->mutex.os_mutex);
> > > return (AE_OK);
> > > }
> > > +ACPI_EXPORT_SYMBOL(acpi_release_mutex)
> > > --
> > > 2.7.4
> >
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 <robert.mo...@intel.com> > Cc: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com>; Maciej S. > Szmigiero <m...@maciej.szmigiero.name>; linux-kernel@vger.kernel.org; > Arthur Heymans <art...@aheymans.xyz>; tpmdd-de...@lists.sourceforge.net; > gnu...@no-log.org; Zheng, Lv <lv.zh...@intel.com>; Wysocki, Rafael J > <rafael.j.wyso...@intel.com>; 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?
