On 30 Jun 2020 17:52, Rafael J. Wysocki wrote:
> On Tue, Jun 30, 2020 at 5:31 PM Al Stone wrote:
> >
> > On 30 Jun 2020 13:44, Rafael J. Wysocki wrote:
> > > On Mon, Jun 29, 2020 at 10:57 PM Al Stone wrote:
> > > >
> > > > On 29 Jun 2020 18:33, Ra
On 30 Jun 2020 13:44, Rafael J. Wysocki wrote:
> On Mon, Jun 29, 2020 at 10:57 PM Al Stone wrote:
> >
> > On 29 Jun 2020 18:33, Rafael J. Wysocki wrote:
> > > From: "Rafael J. Wysocki"
> > >
> > > The ACPICA's strategy with respect to the hand
ical_address +
> + ((u64) address - (u64) mm->physical_address);
>
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "System-Memory (width %u) R/W %u
> Address=%8.8X%8.8X\n",
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
> index aa236b9e6f24..d005e35ab399 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -1201,12 +1201,18 @@ struct acpi_pci_id {
> u16 function;
> };
>
> +struct acpi_mem_mapping {
> + acpi_physical_address physical_address;
> + u8 *logical_address;
> + acpi_size length;
> + struct acpi_mem_mapping *next_mm;
> +};
> +
> struct acpi_mem_space_context {
> u32 length;
> acpi_physical_address address;
> - acpi_physical_address mapped_physical_address;
> - u8 *mapped_logical_address;
> - acpi_size mapped_length;
> + struct acpi_mem_mapping *cur_mm;
> + struct acpi_mem_mapping *first_mm;
> };
>
> /*
> --
> 2.26.2
>
>
>
>
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
Rafael's suggestion
Signed-off-by: Al Stone
---
drivers/acpi/cppc_acpi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 15f103d7532b..3b2525908dd8 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
On 8/26/19 5:02 PM, Rafael J. Wysocki wrote:
> On Tue, Aug 27, 2019 at 12:30 AM Al Stone wrote:
>>
>> According to the ACPI 6.3 specification, the _PSD method is optional
>> when using CPPC. The underlying assumption is that each CPU can change
>> frequency indepe
not be executed properly. This allows _PSD to be optional as it should
be.
v2:
-- verified simple check for AE_NOT_FOUND was sufficient
-- simplified return status check per Rafael's suggestion
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/cppc_acpi.c | 10
On 8/13/19 3:59 PM, Rafael J. Wysocki wrote:
> On Monday, August 5, 2019 7:03:38 PM CEST Al Stone wrote:
>> According to the ACPI 6.3 specification, the _PSD method is optional
>> when using CPPC. The underlying assumption appears to be that each CPU
>> can change frequency i
On 8/13/19 3:57 PM, Rafael J. Wysocki wrote:
> On Tuesday, August 13, 2019 4:00:56 PM CEST Al Stone wrote:
>> On 8/5/19 11:03 AM, Al Stone wrote:
>>> According to the ACPI 6.3 specification, the _PSD method is optional
>>> when using CPPC. The underlying assumption
On 8/5/19 11:03 AM, Al Stone wrote:
> According to the ACPI 6.3 specification, the _PSD method is optional
> when using CPPC. The underlying assumption appears to be that each CPU
> can change frequency independently from all other CPUs; _PSD is provided
> to tell the OS that some pr
On 8/7/19 5:41 AM, Sudeep Holla wrote:
> On Mon, Aug 05, 2019 at 11:03:38AM -0600, Al Stone wrote:
>> According to the ACPI 6.3 specification, the _PSD method is optional
>> when using CPPC. The underlying assumption appears to be that each CPU
>> can change frequency indepen
the method can
not be executed properly. This allows _PSD to be optional as it should
be.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/cppc_acpi.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers
On 6/11/19 10:11 AM, Sudeep Holla wrote:
> On Tue, Jun 11, 2019 at 10:03:15AM -0600, Al Stone wrote:
>> On 6/11/19 6:53 AM, Sudeep Holla wrote:
>>> On Mon, Jun 10, 2019 at 02:07:34PM -0600, Al Stone wrote:
>>>> In the ACPI specification, section 6.1.12, a _UID
On 6/11/19 6:53 AM, Sudeep Holla wrote:
> On Mon, Jun 10, 2019 at 02:07:34PM -0600, Al Stone wrote:
>> In the ACPI specification, section 6.1.12, a _UID may be either an
>> integer or a string object. Up until now, when defining processor
>> Device()s in ACPI (_HID ACPI0007
to this patch.
4) Testing: I only have one very fragile machine to test this on (the
firmware is really, really unstable right now); more testing would
be greatly appreciated.
Signed-off-by: Al Stone
---
drivers/acpi/acpi_processor.c | 57 ++-
incl
2.642015] Could not allocate space for PCC mbox channels
>
> Fixes: 8f8027c5f935 ("mailbox: PCC: erroneous error message when parsing ACPI
> PCCT")
>
> Signed-off-by: David Arcari
> Cc: Al Stone
> Cc: Jassi Brar
> ---
> drivers/mailbox/pcc.c | 7
2.642015] Could not allocate space for PCC mbox channels
>
> Fixes: 8f8027c5f935 ("mailbox: PCC: erroneous error message when parsing ACPI
> PCCT")
>
> Signed-off-by: David Arcari
> Cc: Al Stone
> Cc: Jassi Brar
> ---
> drivers/mailbox/pcc.c | 7
On 05/30/2018 12:24 PM, Colin Ian King wrote:
> On 30/05/18 18:59, Al Stone wrote:
>> On 05/30/2018 11:14 AM, Colin King wrote:
>>> From: Colin Ian King
>>>
>>> The function acpi_table_parse_enties_array can potentially return a
>>> negativ
On 05/30/2018 12:24 PM, Colin Ian King wrote:
> On 30/05/18 18:59, Al Stone wrote:
>> On 05/30/2018 11:14 AM, Colin King wrote:
>>> From: Colin Ian King
>>>
>>> The function acpi_table_parse_enties_array can potentially return a
>>> negativ
ES) {
> pr_warn("Invalid PCCT: %d PCC subspaces\n", count);
> return -EINVAL;
> }
>
Yup, nice catch. A little paranoid, but we like that in a kernel :). Thanks.
Reviewed-by: Al Stone
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
ES) {
> pr_warn("Invalid PCCT: %d PCC subspaces\n", count);
> return -EINVAL;
> }
>
Yup, nice catch. A little paranoid, but we like that in a kernel :). Thanks.
Reviewed-by: Al Stone
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
On 05/15/2018 02:00 AM, Rafael J. Wysocki wrote:
> On Tue, May 15, 2018 at 12:49 AM, Al Stone <a...@redhat.com> wrote:
>> On 05/14/2018 03:04 PM, Prakash, Prashanth wrote:
>>>
>>>
>>> On 4/30/2018 6:39 PM, Al Stone wrote:
>>>> There hav
On 05/15/2018 02:00 AM, Rafael J. Wysocki wrote:
> On Tue, May 15, 2018 at 12:49 AM, Al Stone wrote:
>> On 05/14/2018 03:04 PM, Prakash, Prashanth wrote:
>>>
>>>
>>> On 4/30/2018 6:39 PM, Al Stone wrote:
>>>> There have been multiple reports of the
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Jassi Brar <jassisinghb...@gmail.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/mailbox/pcc.c | 81 ++
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone
Cc: Jassi Brar
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/mailbox/pcc.c | 81 ---
1 file changed, 38 insertions(+), 43 deletions(-)
diff --git a/drive
On 05/15/2018 03:53 PM, Al Stone wrote:
> On 05/15/2018 11:19 AM, Rafael J. Wysocki wrote:
>> On Tue, May 1, 2018 at 2:39 AM, Al Stone <a...@redhat.com> wrote:
>>> For ACPI tables that have subtables, acpi_parse_entries_array() gets used
>>> to step throug
On 05/15/2018 03:53 PM, Al Stone wrote:
> On 05/15/2018 11:19 AM, Rafael J. Wysocki wrote:
>> On Tue, May 1, 2018 at 2:39 AM, Al Stone wrote:
>>> For ACPI tables that have subtables, acpi_parse_entries_array() gets used
>>> to step through each of the subtables i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/15/2018 04:25 PM, valdis.kletni...@vt.edu wrote:
> On Tue, 15 May 2018 15:49:15 -0600, Al Stone said:
>
>> Not off-hand. Could you please send me a copy of
>> /sys/firmware/acpi/tables/APIC
>
> cat /sys/firmware/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/15/2018 04:25 PM, valdis.kletni...@vt.edu wrote:
> On Tue, 15 May 2018 15:49:15 -0600, Al Stone said:
>
>> Not off-hand. Could you please send me a copy of
>> /sys/firmware/acpi/tables/APIC
>
> cat /sys/firmware/
On 05/15/2018 11:19 AM, Rafael J. Wysocki wrote:
> On Tue, May 1, 2018 at 2:39 AM, Al Stone <a...@redhat.com> wrote:
>> For ACPI tables that have subtables, acpi_parse_entries_array() gets used
>> to step through each of the subtables in memory. The primary loop for
On 05/15/2018 11:19 AM, Rafael J. Wysocki wrote:
> On Tue, May 1, 2018 at 2:39 AM, Al Stone wrote:
>> For ACPI tables that have subtables, acpi_parse_entries_array() gets used
>> to step through each of the subtables in memory. The primary loop for this
>> was checki
d the
problem. Did this work before 20180415? I assume it did.
What puzzles me is that this message:
ACPI: [APIC:0x05] Invalid zero length
should only have shown up if the MADT has a broken subtable, and I think that
bit of code has been that way for quite some time (git blame says somewhere
around 2012 when the test for this condition was put in).
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
>
Not off-hand. Could you please send me a copy of /sys/firmware/acpi/tables/APIC
on this machine? The commit cd8c65a6442b that I wrote looks like it got pulled
in on 20180430, which if I'm understanding correctly, seems to have fixed the
problem. Did this work before 20180415? I assume it
On 05/14/2018 03:04 PM, Prakash, Prashanth wrote:
>
>
> On 4/30/2018 6:39 PM, Al Stone wrote:
>> There have been multiple reports of the following error message:
>>
>> [0.068293] Error parsing PCC subspaces from PCCT
>>
>> This error message is n
On 05/14/2018 03:04 PM, Prakash, Prashanth wrote:
>
>
> On 4/30/2018 6:39 PM, Al Stone wrote:
>> There have been multiple reports of the following error message:
>>
>> [0.068293] Error parsing PCC subspaces from PCCT
>>
>> This error message is n
-by: Al Stone <a...@redhat.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/acpi/tables.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 849c4fb19b03..4
-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 849c4fb19b03..4a3410aa6540 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Jassi Brar <jassisinghb...@gmail.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/mailbox/pcc.c | 96 +++
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone
Cc: Jassi Brar
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/mailbox/pcc.c | 96 +--
1 file changed, 63 insertions(+), 33 deletions(-)
diff
ld pointed out would
always be zero
Al Stone (3):
ACPI: improve function documentation for acpi_parse_entries_array()
ACPI: ensure acpi_parse_entries_array() does not access non-existent
table data
mailbox: ACPI: erroneous error message when parsing the ACPI PCCT
drivers/acpi/tab
ACPI tables.
Found by inspection. There is no functional change to existing code
that is known to work when calling acpi_parse_entries_array().
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers
ld pointed out would
always be zero
Al Stone (3):
ACPI: improve function documentation for acpi_parse_entries_array()
ACPI: ensure acpi_parse_entries_array() does not access non-existent
table data
mailbox: ACPI: erroneous error message when parsing the ACPI PCCT
drivers/acpi/tab
ACPI tables.
Found by inspection. There is no functional change to existing code
that is known to work when calling acpi_parse_entries_array().
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
On 04/27/2018 05:16 AM, Rafael J. Wysocki wrote:
> On Tue, Apr 24, 2018 at 9:35 PM, Al Stone <a...@redhat.com> wrote:
>> There have been multiple reports of the following error message:
>>
>> [0.068293] Error parsing PCC subspaces from PCCT
>>
>
> [cut
On 04/27/2018 05:16 AM, Rafael J. Wysocki wrote:
> On Tue, Apr 24, 2018 at 9:35 PM, Al Stone wrote:
>> There have been multiple reports of the following error message:
>>
>> [0.068293] Error parsing PCC subspaces from PCCT
>>
>
> [cut]
>
>>
&g
On 04/27/2018 05:05 AM, Rafael J. Wysocki wrote:
> On Tue, Apr 24, 2018 at 9:35 PM, Al Stone <a...@redhat.com> wrote:
>> For ACPI tables that have subtables, acpi_parse_entries_array() gets used
>> to step through each of the subtables in memory. The primary loop for
On 04/27/2018 05:05 AM, Rafael J. Wysocki wrote:
> On Tue, Apr 24, 2018 at 9:35 PM, Al Stone wrote:
>> For ACPI tables that have subtables, acpi_parse_entries_array() gets used
>> to step through each of the subtables in memory. The primary loop for this
>> was checki
On 04/27/2018 05:04 AM, Rafael J. Wysocki wrote:
> On Tue, Apr 24, 2018 at 9:35 PM, Al Stone <a...@redhat.com> wrote:
>> I found the description of the table_size argument to the function
>> acpi_parse_entries_array() unclear and ambiguous. This is a minor
>> docu
On 04/27/2018 05:04 AM, Rafael J. Wysocki wrote:
> On Tue, Apr 24, 2018 at 9:35 PM, Al Stone wrote:
>> I found the description of the table_size argument to the function
>> acpi_parse_entries_array() unclear and ambiguous. This is a minor
>> documentation change to improve
-by: Al Stone <a...@redhat.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/acpi/tables.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 849c4fb19b03..2
-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 849c4fb19b03..21535762b890 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
ACPI tables.
Found by inspection. There is no functional change to existing code
that is known to work when calling acpi_parse_entries_array().
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers
ACPI tables.
Found by inspection. There is no functional change to existing code
that is known to work when calling acpi_parse_entries_array().
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
predicate that kbuild pointed out would
always be zero
Al Stone (3):
ACPI: improve function documentation for acpi_parse_entries_array()
ACPI: ensure acpi_parse_entries_array() does not access non-existent
table data
mailbox: ACPI: erroneous error message when parsing the ACPI PCCT
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Jassi Brar <jassisinghb...@gmail.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/mailbox/pcc.c | 99 +++
predicate that kbuild pointed out would
always be zero
Al Stone (3):
ACPI: improve function documentation for acpi_parse_entries_array()
ACPI: ensure acpi_parse_entries_array() does not access non-existent
table data
mailbox: ACPI: erroneous error message when parsing the ACPI PCCT
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone
Cc: Jassi Brar
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/mailbox/pcc.c | 99 +--
1 file changed, 73 insertions(+), 26 deletions(-)
diff
please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Al-Stone/ACPI-improve-function-documentation-for-acpi_parse_entries_array/20180404-151910
> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> lin
please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Al-Stone/ACPI-improve-function-documentation-for-acpi_parse_entries_array/20180404-151910
> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> lin
ACPI tables.
Found by inspection. There is no functional change to existing code
that is known to work when calling acpi_parse_entries_array().
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers
ACPI tables.
Found by inspection. There is no functional change to existing code
that is known to work when calling acpi_parse_entries_array().
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Jassi Brar <jassisinghb...@gmail.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/mailbox/pcc.c | 99 +++
sly; the
error message no longer appears and the laptop appears to operate
normally.
Signed-off-by: Al Stone
Cc: Jassi Brar
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/mailbox/pcc.c | 99 +--
1 file changed, 73 insertions(+), 26 deletions(-)
diff
-by: Al Stone <a...@redhat.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/acpi/tables.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 6c5ee7e66842..b
described in more detail
in patch 3/3.
Since these patches primarily involve ACPI usages, it may make
sense for all of them to go through the linux-acpi tree; clearly,
this is up to the maintainers, though.
Al Stone (3):
ACPI: improve function documentation for acpi_parse_entries_array()
AC
described in more detail
in patch 3/3.
Since these patches primarily involve ACPI usages, it may make
sense for all of them to go through the linux-acpi tree; clearly,
this is up to the maintainers, though.
Al Stone (3):
ACPI: improve function documentation for acpi_parse_entries_array()
AC
-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 6c5ee7e66842..b6ac8162a2c0 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
ge;
that might be okay but seems unnecessarily complicated to me.
You can also tell me that I have completely missed the point of the discussion
so far :-). But if you do, you have to tell me what I missed.
Hope this helps clarify...
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
ge;
that might be okay but seems unnecessarily complicated to me.
You can also tell me that I have completely missed the point of the discussion
so far :-). But if you do, you have to tell me what I missed.
Hope this helps clarify...
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
On 10/20/2017 10:10 AM, Mark Rutland wrote:
> Hi Al,
>
> On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:
>> On 10/13/2017 08:27 AM, Mark Rutland wrote:
>>> I certainly agree that exposing the information that we have is useful,
>>> as I have stated sever
On 10/20/2017 10:10 AM, Mark Rutland wrote:
> Hi Al,
>
> On Mon, Oct 16, 2017 at 05:43:19PM -0600, Al Stone wrote:
>> On 10/13/2017 08:27 AM, Mark Rutland wrote:
>>> I certainly agree that exposing the information that we have is useful,
>>> as I have stated sever
On 10/13/2017 08:27 AM, Mark Rutland wrote:
> Hi Timur,
>
> On Fri, Oct 13, 2017 at 08:39:09AM -0500, Timur Tabi wrote:
>> On Wed, Sep 27, 2017 at 5:34 AM, Mark Rutland <mark.rutl...@arm.com> wrote:
>>> On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:
>
On 10/13/2017 08:27 AM, Mark Rutland wrote:
> Hi Timur,
>
> On Fri, Oct 13, 2017 at 08:39:09AM -0500, Timur Tabi wrote:
>> On Wed, Sep 27, 2017 at 5:34 AM, Mark Rutland wrote:
>>> On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:
>>>> As ARMv8
On 09/27/2017 04:34 AM, Mark Rutland wrote:
> On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:
>> As ARMv8 servers get deployed, I keep getting the same set of questions
>> from end-users of those systems: what do all the hex numbers mean in
>> /proc/cpuinfo and cou
On 09/27/2017 04:34 AM, Mark Rutland wrote:
> On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote:
>> As ARMv8 servers get deployed, I keep getting the same set of questions
>> from end-users of those systems: what do all the hex numbers mean in
>> /proc/cpuinfo and cou
, APM Mustang and Cavium ThunderX systems.
[0] https://marc.info/?l=linux-pm=150584702021552=2
Al Stone (3):
arm64: cpuinfo: add MPIDR value to /proc/cpuinfo
arm64: cpuinfo: add human readable CPU names to /proc/cpuinfo
arm64: cpuinfo: display product info in /proc/cpuinfo
arch/arm64
, APM Mustang and Cavium ThunderX systems.
[0] https://marc.info/?l=linux-pm=150584702021552=2
Al Stone (3):
arm64: cpuinfo: add MPIDR value to /proc/cpuinfo
arm64: cpuinfo: add human readable CPU names to /proc/cpuinfo
arm64: cpuinfo: display product info in /proc/cpuinfo
arch/arm64
) and display it in /proc/cpuinfo. To look more
like other server platforms, include the CPU type and frequency when
displaying the product info, too.
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc
) and display it in /proc/cpuinfo. To look more
like other server platforms, include the CPU type and frequency when
displaying the product info, too.
Signed-off-by: Al Stone
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Suzuki K Poulose
Cc: Mark Rutland
---
arch/arm64/kernel/cpuinfo.c | 135
hunderX".
Note that this is not meant to be an exhaustive list of all possible
implementers or CPUs (I'm not even sure that is knowable); this patch
is intentionally limited to only those willing to provide info in
arch/arm64/include/asm/cputype.h
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Cat
hunderX".
Note that this is not meant to be an exhaustive list of all possible
implementers or CPUs (I'm not even sure that is knowable); this patch
is intentionally limited to only those willing to provide info in
arch/arm64/include/asm/cputype.h
Signed-off-by: Al Stone
Cc: Catalin Marinas
Cc: Will
When displaying cpuinfo on an arm64 system, include the MPIDR register
value which can be used to understand the CPU topology on a platform.
This can serve as a cross-check to the information provided in sysfs,
and has been useful in understanding CPU and NUMA allocation issues.
Signed-off-by: Al
When displaying cpuinfo on an arm64 system, include the MPIDR register
value which can be used to understand the CPU topology on a platform.
This can serve as a cross-check to the information provided in sysfs,
and has been useful in understanding CPU and NUMA allocation issues.
Signed-off-by: Al
mutex_unlock(_list_mutex);
> + ghes_proc(ghes);
> break;
> case ACPI_HEST_NOTIFY_NMI:
> ghes_nmi_add(ghes);
>
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
ghes_proc(ghes);
> break;
> case ACPI_HEST_NOTIFY_NMI:
> ghes_nmi_add(ghes);
>
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
gt; }
>
> So for the devices connected to the mbigen, as we clearly say that
> it refers to a specific interrupt controller (mbigen), we can get
> the virq from mbigen's irqdomain once it's created successfully.
>
> Signed-off-by: Hanjun Guo <hanjun@linaro.org>
> S
gt; }
>
> So for the devices connected to the mbigen, as we clearly say that
> it refers to a specific interrupt controller (mbigen), we can get
> the virq from mbigen's irqdomain once it's created successfully.
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: MaJun
rceConsumer,..., "\_SB.MBI0") {12}
>> })
>> }
>>
>>
>> Marc, Lorenzo if you are ok with the above we will submit v10 based on
>> this...
>
> I am ok with it. I am not 100% up-to-date on what's the status on _DSD
> bindings/review/guidelines but it would be certainly a good idea to
> kickstart the process for MBIgen which basically means following this
> as far as I know (and post to the relevant mailing list):
>
> https://github.com/ahs3/dsd/blob/master/documentation/process_rules.txt
So, let's correct this bit: consider that URL deprecated, please, and refer
instead to the text that was agreed upon and in the kernel tree:
Documentation/acpi/DSD-properties-rules.txt
> Al and Darren may add to that as they have more insights.
Since this use of _DSD is very specific to this device, and this device
only, I don't have any real objections. I will say that "num-pins" is
not terribly descriptive so it would be really good to either use a much
more descriptive name or add plenty of commentary in the code -- and
preferably both. I would recommend including the ASL in the code comments,
with a description of how the property is to be used and what it means.
> I would like to send IORT patches to Catalin as soon as possible so
> as Marc pointed out the sooner we sort this out the better.
>
> Thanks,
> Lorenzo
>
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
SB.MBI0") {12}
>> })
>> }
>>
>>
>> Marc, Lorenzo if you are ok with the above we will submit v10 based on
>> this...
>
> I am ok with it. I am not 100% up-to-date on what's the status on _DSD
> bindings/review/guidelines but it would be certainly a good idea to
> kickstart the process for MBIgen which basically means following this
> as far as I know (and post to the relevant mailing list):
>
> https://github.com/ahs3/dsd/blob/master/documentation/process_rules.txt
So, let's correct this bit: consider that URL deprecated, please, and refer
instead to the text that was agreed upon and in the kernel tree:
Documentation/acpi/DSD-properties-rules.txt
> Al and Darren may add to that as they have more insights.
Since this use of _DSD is very specific to this device, and this device
only, I don't have any real objections. I will say that "num-pins" is
not terribly descriptive so it would be really good to either use a much
more descriptive name or add plenty of commentary in the code -- and
preferably both. I would recommend including the ASL in the code comments,
with a description of how the property is to be used and what it means.
> I would like to send IORT patches to Catalin as soon as possible so
> as Marc pointed out the sooner we sort this out the better.
>
> Thanks,
> Lorenzo
>
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
On 01/25/2017 04:27 PM, Dmitry Torokhov wrote:
> On Wed, Jan 25, 2017 at 02:44:10PM -0700, Al Stone wrote:
>>
>> But, to the point of some of the other discussion on the thread, this ACPI
>> sort
>> of power management is a very, very different model than DT so that
On 01/25/2017 04:27 PM, Dmitry Torokhov wrote:
> On Wed, Jan 25, 2017 at 02:44:10PM -0700, Al Stone wrote:
>>
>> But, to the point of some of the other discussion on the thread, this ACPI
>> sort
>> of power management is a very, very different model than DT so that
e hardware and firmware underneath the OS can change over time
without having to change the OS -- the OS just needs to know how to talk to
ACPI.
But, to the point of some of the other discussion on the thread, this ACPI sort
of power management is a very, very different model than DT so that intertwining
the two models is highly unlikely to work, IMHO.
[0] http://www.uefi.org/specifications -- version 6.1, specifically.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
e hardware and firmware underneath the OS can change over time
without having to change the OS -- the OS just needs to know how to talk to
ACPI.
But, to the point of some of the other discussion on the thread, this ACPI sort
of power management is a very, very different model than DT so that intertwining
the two models is highly unlikely to work, IMHO.
[0] http://www.uefi.org/specifications -- version 6.1, specifically.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
ts using GCC. Perhaps
this is just a Linux-only modification...
> Bob
>
>
>> -Original Message-
>> From: Al Stone [mailto:a...@redhat.com]
>> Sent: Monday, November 14, 2016 3:09 PM
>> To: linux-a...@vger.kernel.org; de...@acpica.org; linux-
>> ker.
ts using GCC. Perhaps
this is just a Linux-only modification...
> Bob
>
>
>> -Original Message-
>> From: Al Stone [mailto:a...@redhat.com]
>> Sent: Monday, November 14, 2016 3:09 PM
>> To: linux-a...@vger.kernel.org; de...@acpica.org; linux-
>> ker...@
My bad.
Adding Will Deacon who originally reported the error.
On 11/14/2016 04:08 PM, Al Stone wrote:
> The ACPICA subsystem of the ACPI driver sets up a compilation environment
> for itself, adding in multiple typedefs unique to ACPICA that depend on
> where ACPICA will be used.
>
My bad.
Adding Will Deacon who originally reported the error.
On 11/14/2016 04:08 PM, Al Stone wrote:
> The ACPICA subsystem of the ACPI driver sets up a compilation environment
> for itself, adding in multiple typedefs unique to ACPICA that depend on
> where ACPICA will be used.
>
Signed-off-by: Al Stone <a...@redhat.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
Cc: Robert Moore <robert.mo...@intel.com>
Cc: Lv Zheng <lv.zh...@intel.com>
---
include/acpi/platform/acenv.h | 15 +++
1 file changed, 15 inser
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Robert Moore
Cc: Lv Zheng
---
include/acpi/platform/acenv.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index 34cce72..cdd1cd6 100644
--- a/include
38677df44b67e0f5b6c4d31e9c2734abde8ed9 (cpufreq:
> CPPC: Force reporting values in KHz to fix user space interface)
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cpufreq/cppc_cpufreq.c?id=ad38677df44b67e0f5b6c4d31e9c2734abde8ed9
>
> Thanks
> Hoan
>
>>
>> Thanks,
>> Rafael
>>
Nice catch, Hoan. Thanks!
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
CPPC: Force reporting values in KHz to fix user space interface)
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cpufreq/cppc_cpufreq.c?id=ad38677df44b67e0f5b6c4d31e9c2734abde8ed9
>
> Thanks
> Hoan
>
>>
>> Thanks,
>> Rafael
>>
Nice catch, Hoan. Thanks!
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
1 - 100 of 552 matches
Mail list logo
