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
mm->logical_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_a
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
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
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 may
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
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
>>> negative value
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 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
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 wrote:
>>> For ACPI tables that have subtables, acpi_parse_entries_array() gets used
>>> to step through each of the subtables in me
-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 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
>
>
>
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
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 not co
d-off-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/tab
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
icate 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
d
ucted 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(-)
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 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 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
d-off-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/tab
ucted 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(-)
test that had a 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 parsin
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
ase 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
ucted 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(-)
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
is 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()
d-off-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/tab
uld be needed with more cpumasks to show who belongs to what physical package;
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/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 serv
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
attle, APM Mustang and Cavium ThunderX systems.
[0] https://marc.info/?l=linux-pm&m=150584702021552&w=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
) 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
ot;.
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:
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(&ghes_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
---
})
> }
>
> 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
Interrupt(ResourceConsumer,..., "\_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
o know these sorts of things,
so that the 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
---
for bare-metal environments 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
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
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
req:
> 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
---
On 09/13/2016 07:09 PM, Rafael J. Wysocki wrote:
> On Wednesday, July 20, 2016 03:10:04 PM Al Stone wrote:
>> When CPPC is being used by ACPI on arm64, user space tools such as
>> cpupower report CPU frequency values from sysfs that are incorrect.
>>
>> What the driver
On 08/25/2016 04:00 PM, Pandruvada, Srinivas wrote:
> On Tue, 2016-08-23 at 10:14 -0600, Al Stone wrote:
>>>>
>
> [...]
>
>>> In x86 when CPPC is used, the unit is really unit-less in CPPC
>>> tables.
>>> This means that cpu->perf_caps.
On 08/22/2016 10:31 PM, Pandruvada, Srinivas wrote:
> On Mon, 2016-08-22 at 12:12 -0600, Al Stone wrote:
>> On 08/22/2016 11:45 AM, Ashwin Chaugule wrote:
>>>
>>> Hi Al,
>>>
>>> On Mon, Aug 22, 2016 at 10:16 AM, Al Stone wrote:
>>>>
&
On 08/22/2016 11:45 AM, Ashwin Chaugule wrote:
> Hi Al,
>
> On Mon, Aug 22, 2016 at 10:16 AM, Al Stone wrote:
>> Maybe a top-post will get attention
>>
>> Yet another ping; this was first submitted on 20 July, and has received
>> no comments. It has now bee
instructions, please?
Also adding Rafael on the ACPI side, just in case, since he's also reviewing
the Intel patches on the linux-acpi mailing list that are adding CPPC usage.
On 08/11/2016 12:15 PM, Al Stone wrote:
> On 08/01/2016 02:31 PM, Viresh Kumar wrote:
>> [+ Ashwin's new emai
On 08/20/2016 04:55 AM, Pavel Machek wrote:
> On Fri 2016-08-19 17:24:00, Al Stone wrote:
>> Really minor patches: one to cleanup whitespace, the second just makes
>> the code a wee bit more maintainable by correcting some variable names
>> without changing functionality.
.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index fa6fd19..3e167b4 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
could be risky
since we cannot guarantee that no callback will ever have side effects
that another callback depends on to work correctly.
So, the simplest approach is to just remove the part of the error
message that will always be incorrect.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len
,
they were written assuming the acpi_parse_entries_array() function
operated as its comments describe. For example, a callback that
counts the number of subtables of a specific type can now be assured
that as many subtables as possible have been enumerated.
Signed-off-by: Al Stone
Cc: Rafael J
the total skipped, there could be side effects
or dependencies between callbacks that would make the original plan of
iterating over all callbacks risky, for very little value (Rafael)
Al Stone (3):
ACPI: fix incorrect counts returned by acpi_parse_entries_array()
Signed-off-by: Al Stone
---
arch/ia64/sn/kernel/sn2/sn2_smp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/sn/kernel/sn2/sn2_smp.c
b/arch/ia64/sn/kernel/sn2/sn2_smp.c
index c98dc96..8701b2f 100644
--- a/arch/ia64/sn/kernel/sn2/sn2_smp.c
+++ b/arch/ia64
Really trivial changes: one for whitespace, and a second for a compilation
error that can occur due to a use before a definition without a forward
declaration.
Al Stone (2):
ia64: remove extraneous white space
ia64: fix compilation error when using struct before defining it
arch/ia64/sn
In sn2_smp.c, the struct ptc_stats was being used before it was defined.
Move the usage of the struct to after the definition.
Found during cross-compilation using ia64 defconfig.
Signed-off-by: Al Stone
---
arch/ia64/sn/kernel/sn2/sn2_smp.c | 6 +++---
1 file changed, 3 insertions(+), 3
aps that so that the routine acpi_parse_madt_lapic_entries()
will now consistently use x2count to refer to X2APIC info, and count
to refer to LAPIC info.
Signed-off-by: Al Stone
---
arch/x86/kernel/acpi/boot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kerne
Really minor patches: one to cleanup whitespace, the second just makes
the code a wee bit more maintainable by correcting some variable names
without changing functionality.
Al Stone (2):
x86: ACPI: remove extraneous white space after semicolon
x86: ACPI: make variable names clearer in
Signed-off-by: Al Stone
---
arch/x86/kernel/acpi/boot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 90d84c3..5fb8f05 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1513,7
Signed-off-by: Al Stone
---
drivers/acpi/tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 9f0ad6e..fa6fd19 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -416,7 +416,7 @@ int __init
Commit 9b3fedde27d3 ("ACPI / tables: Add acpi_subtable_proc to ACPI
table parsers") added a second identical declaration for the function
acpi_table_parse_entries() to include/linux/acpi.h.
Remove the redundant one.
Signed-off-by: Al Stone
---
include/linux/acpi.h | 4
1 file
The first patch is a trivial whitespace cleanup. The second is also
simple in that it removes a duplicate declaration from a header file.
Al Stone (2):
ACPI: remove extraneous whitespace from a comment
ACPI: remove duplicate declaration for acpi_table_parse_entries()
drivers/acpi/tables.c
On 08/01/2016 02:31 PM, Viresh Kumar wrote:
> [+ Ashwin's new email id..]
>
> On 20-07-16, 15:10, Al Stone wrote:
>> When CPPC is being used by ACPI on arm64, user space tools such as
>> cpupower report CPU frequency values from sysfs that are incorrect.
>>
On 07/20/2016 03:10 PM, Al Stone wrote:
> When CPPC is being used by ACPI on arm64, user space tools such as
> cpupower report CPU frequency values from sysfs that are incorrect.
>
> What the driver was doing was reporting the values given by ACPI tables
> in whatever scale was
thinko: needed to have DEPENDS on DMI in Kconfig.arm,
not SELECT DMI (found by build daemon)
Signed-off-by: Al Stone
Signed-off-by: Prashanth Prakash
---
drivers/cpufreq/cppc_cpufreq.c | 53 ++
1 file changed, 49 insertions(+), 4 deletions(-)
diff
On 07/14/2016 11:39 AM, Prakash, Prashanth wrote:
>
>
> On 7/14/2016 10:15 AM, Al Stone wrote:
>> On 07/14/2016 04:03 AM, Alexey Klimov wrote:
>>> Hi Al,
>>>
>>> On Tue, Jul 12, 2016 at 11:16:11AM -0600, Al Stone wrote:
>>>> When CPPC is
On 07/14/2016 04:03 AM, Alexey Klimov wrote:
> Hi Al,
>
> On Tue, Jul 12, 2016 at 11:16:11AM -0600, Al Stone wrote:
>> When CPPC is being used by ACPI on arm64, user space tools such as
>> cpupower report CPU frequency values from sysfs that are incorrect.
>>
>&
arithmetic occurs,
especially no division by zero (Alexey Klimov)
Changes for v2:
-- Corrected thinko: needed to have DEPENDS on DMI in Kconfig.arm,
not SELECT DMI (found by build daemon)
Signed-off-by: Al Stone
---
drivers/acpi/cppc_acpi.c| 106
On 07/01/2016 04:01 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:55 PM, Al Stone wrote:
>> On 07/01/2016 03:46 PM, Rafael J. Wysocki wrote:
>>> On Fri, Jul 1, 2016 at 11:41 PM, Al Stone wrote:
>>>> On 07/01/2016 03:32 PM, Rafael J. Wysocki wrote:
>>
On 07/01/2016 03:56 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:50 PM, Al Stone wrote:
>> On 07/01/2016 03:44 PM, Rafael J. Wysocki wrote:
>>> On Fri, Jul 1, 2016 at 11:36 PM, Al Stone wrote:
>>>> On 07/01/2016 03:25 PM, Rafael J. Wysocki wrote:
>>
On 07/01/2016 03:54 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:44 PM, Al Stone wrote:
>> On 07/01/2016 03:40 PM, Rafael J. Wysocki wrote:
>>> On Fri, Jul 1, 2016 at 11:21 PM, Al Stone wrote:
>>>> The function acpi_parse_entries_array() has a limiti
On 07/01/2016 03:46 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:41 PM, Al Stone wrote:
>> On 07/01/2016 03:32 PM, Rafael J. Wysocki wrote:
>>> On Fri, Jul 1, 2016 at 11:21 PM, Al Stone wrote:
>>>> Without this patch, the acpi_parse_entries_array() func
On 07/01/2016 03:44 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:36 PM, Al Stone wrote:
>> On 07/01/2016 03:25 PM, Rafael J. Wysocki wrote:
>>> On Fri, Jul 1, 2016 at 11:21 PM, Al Stone wrote:
>>>> The static function acpi_parse_entries_array() is
On 07/01/2016 03:32 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:21 PM, Al Stone wrote:
>> Without this patch, the acpi_parse_entries_array() function will return
>> the very first time there is any error found in either the array of
>> callback functions or if
On 07/01/2016 03:40 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:21 PM, Al Stone wrote:
>> The function acpi_parse_entries_array() has a limiting parameter,
>> max_entries, which tells the function to stop looking at subtables
>> once that limit has been reac
On 07/01/2016 03:25 PM, Rafael J. Wysocki wrote:
> On Fri, Jul 1, 2016 at 11:21 PM, Al Stone wrote:
>> The static function acpi_parse_entries_array() is provided an array of
>> type struct acpi_subtable_proc that has a callback function and a count.
>> The count should refle
ple of days.
Al Stone (3):
ACPI: fix incorrect counts returned by acpi_parse_entries_array()
ACPI: fix acpi_parse_entries_array() so it traverses all subtables
ACPI: fix acpi_parse_entries_array() so it reports overflow correctly
drivers/acpi/tables.c | 25 +++--
1 file c
, regardless of the number of entries in the array, or which callback
has been invoked. The fix is to use the index into the array, instead of
a pointer to the beginning of the array.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 4 ++--
1 file changed
array, or the callbacks may be able to process subsequent
subtables without error. The change here makes the function consistent
with its description so that it will properly return the sum of all
matching entries for all proc handlers, instead of stopping abruptly
as it does today.
Signed-off-by: Al
occupied.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 76c07ed..227312d 100644
--- a/drivers/acpi/tables.c
+++ b/drivers
ackwards approach.
Thank you for remembering to pull this in. Those of us working in the
background on APEI for arm64 appreciate it because now we can take it off our
TODO list :).
--
ciao,
al
-------
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
On 06/14/2016 08:50 AM, Catalin Marinas wrote:
> On Tue, Jun 14, 2016 at 08:46:26AM -0600, Al Stone wrote:
>> On 06/14/2016 03:24 AM, Will Deacon wrote:
>>> On Tue, Jun 14, 2016 at 10:13:31AM +0100, Will Deacon wrote:
>>>> On Mon, Jun 13, 2016 at 03:41:54PM -0600, A
On 06/14/2016 03:24 AM, Will Deacon wrote:
> On Tue, Jun 14, 2016 at 10:13:31AM +0100, Will Deacon wrote:
>> On Mon, Jun 13, 2016 at 03:41:54PM -0600, Al Stone wrote:
>>> This is a resend only: Ping? Last ping was 26 May; there has been zero
>>> response since then.
ACPI 6.1 for arm64.
Changes for v5:
-- Miscellaneous typos and corrections (Lorenzo Pieralisi)
-- Add linux-acpi@ ML to the distribution list (Alexey Klimov)
-- Corrections to CPPC information (Alexey Klimov)
-- ACK from Lorenzo Pieralisi
-- Updated bibliographic info (Al Stone
. Whilst there, a few odds and ends of
typos were caught as well. This brings the documentation up to date with
ACPI 6.1 for arm64.
Signed-off-by: Al Stone
Acked-by: Lorenzo Pieralisi
Reviewed-by: Hanjun Guo
Reviewed-by: Roy Franz
---
Documentation/arm64/acpi_object_usage.txt | 343
On 05/17/2016 10:30 AM, Al Stone wrote:
> On 05/16/2016 05:44 PM, Alexey Klimov wrote:
>> On Mon, May 2, 2016 at 09:19 PM, Al Stone wrote:
>>> On 04/25/2016 03:21 PM, Al Stone wrote:
>>>> The ACPI 6.1 specification was recently released at the end of January
&
1 - 100 of 283 matches
Mail list logo
