On 04/21/2016 07:37 AM, Alexey Klimov wrote:
> Hi Al,
>
> I hope you don't mind if I put few minor questions here.
>
> On Mon, Apr 18, 2016 at 8:32 PM, Al Stone <al.st...@linaro.org> wrote:
>> The ACPI 6.1 specification was recently released at the end of January
&g
On 04/21/2016 07:37 AM, Alexey Klimov wrote:
> Hi Al,
>
> I hope you don't mind if I put few minor questions here.
>
> On Mon, Apr 18, 2016 at 8:32 PM, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January
>> 2016, but the
On 04/19/2016 05:15 AM, Lorenzo Pieralisi wrote:
> On Mon, Apr 18, 2016 at 01:32:22PM -0600, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January
>> 2016, but the arm64 kernel documentation for the use of ACPI was written
>> for the 5.
On 04/19/2016 05:15 AM, Lorenzo Pieralisi wrote:
> On Mon, Apr 18, 2016 at 01:32:22PM -0600, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January
>> 2016, but the arm64 kernel documentation for the use of ACPI was written
>> for the 5.
On 04/21/2016 08:53 AM, Alexey Klimov wrote:
>
> On Tue, Apr 19, 2016 at 1:11 AM, Al Stone <a...@redhat.com> 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 04/21/2016 08:53 AM, Alexey Klimov wrote:
>
> On Tue, Apr 19, 2016 at 1:11 AM, 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.
>>
>> Wha
bool
> - depends on !M68K
> depends on ISA || PCI
> default y
>
>
This solves the particular problem I was running into on an arm64 AMD Seattle
system. Thanks!
Tested-by: Al Stone <a...@redhat.com>
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
8K
> depends on ISA || PCI
> default y
>
>
This solves the particular problem I was running into on an arm64 AMD Seattle
system. Thanks!
Tested-by: Al Stone
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
On 04/19/2016 02:12 PM, Ashwin Chaugule wrote:
> + Ryan
>
> Hi Al,
>
> On 18 April 2016 at 20:11, Al Stone <a...@redhat.com> wrote:
>> When CPPC is being used by ACPI on arm64, user space tools such as
>> cpupower report CPU frequency values from sysfs that are
On 04/19/2016 02:12 PM, Ashwin Chaugule wrote:
> + Ryan
>
> Hi Al,
>
> On 18 April 2016 at 20:11, 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.
>
-by: Al Stone <a...@redhat.com>
---
drivers/acpi/cppc_acpi.c| 61 +
drivers/cpufreq/Kconfig.arm | 1 +
2 files changed, 57 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 8adac69..d61ced6
-by: Al Stone
---
drivers/acpi/cppc_acpi.c| 61 +
drivers/cpufreq/Kconfig.arm | 1 +
2 files changed, 57 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 8adac69..d61ced6 100644
--- a/drivers/acpi
On 04/18/2016 04:28 AM, Viresh Kumar wrote:
> Cc'ing Ashwin.
>
Boy, do I feel silly for forgetting that. Thanks, Viresh.
--
ciao,
al
-------
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
On 04/18/2016 04:28 AM, Viresh Kumar wrote:
> Cc'ing Ashwin.
>
Boy, do I feel silly for forgetting that. Thanks, Viresh.
--
ciao,
al
-------
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
mmendation; it described kernel
behavior that does not exist (Al Stone).
Changes for v3:
-- Clarify use of _LPI/_RDI (Vikas Sajjan)
-- Whitespace cleanup as pointed out by checkpatch
Changes for v2:
-- Clean up white space (Harb Abdulhahmid)
-- Clarification on _CCA usage (Harb Abdulhamid)
mmendation; it described kernel
behavior that does not exist (Al Stone).
Changes for v3:
-- Clarify use of _LPI/_RDI (Vikas Sajjan)
-- Whitespace cleanup as pointed out by checkpatch
Changes for v2:
-- Clean up white space (Harb Abdulhahmid)
-- Clarification on _CCA usage (Harb Abdulhamid)
correctly. Hence, other approaches are
also being considered.
This has been tested on three arm64 servers, with and without DMI, with
and without CPPC support.
Signed-off-by: Al Stone <a...@redhat.com>
---
drivers/acpi/cppc_acpi.c| 61 +
drivers/c
correctly. Hence, other approaches are
also being considered.
This has been tested on three arm64 servers, with and without DMI, with
and without CPPC support.
Signed-off-by: Al Stone
---
drivers/acpi/cppc_acpi.c| 61 +
drivers/cpufreq/Kconfig.arm | 1
On 04/15/2016 03:35 PM, Jonathan Corbet wrote:
> On Mon, 28 Mar 2016 18:06:42 -0600
> Al Stone <al.st...@linaro.org> wrote:
>
>> This patch reflects going back through and examining the specs in detail
>> and updating content appropriately. Whilst there, a few odd
On 04/15/2016 03:35 PM, Jonathan Corbet wrote:
> On Mon, 28 Mar 2016 18:06:42 -0600
> Al Stone wrote:
>
>> This patch reflects going back through and examining the specs in detail
>> and updating content appropriately. Whilst there, a few odds and ends of
>>
On 04/15/2016 11:47 AM, Lorenzo Pieralisi wrote:
> On Fri, Apr 15, 2016 at 10:41:02AM -0600, Al Stone wrote:
>> On 04/15/2016 08:37 AM, Lorenzo Pieralisi wrote:
>>> Hi Al,
>>>
>>> On Mon, Mar 28, 2016 at 06:06:42PM -0600, Al Stone wrote:
>>>>
On 04/15/2016 11:47 AM, Lorenzo Pieralisi wrote:
> On Fri, Apr 15, 2016 at 10:41:02AM -0600, Al Stone wrote:
>> On 04/15/2016 08:37 AM, Lorenzo Pieralisi wrote:
>>> Hi Al,
>>>
>>> On Mon, Mar 28, 2016 at 06:06:42PM -0600, Al Stone wrote:
>>>>
On 04/15/2016 08:37 AM, Lorenzo Pieralisi wrote:
> Hi Al,
>
> On Mon, Mar 28, 2016 at 06:06:42PM -0600, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January
>> 2016, but the arm64 kernel documentation for the use of ACPI was written
&
On 04/15/2016 08:37 AM, Lorenzo Pieralisi wrote:
> Hi Al,
>
> On Mon, Mar 28, 2016 at 06:06:42PM -0600, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January
>> 2016, but the arm64 kernel documentation for the use of ACPI was written
&
On 04/08/2016 07:12 AM, Will Deacon wrote:
> On Thu, Apr 07, 2016 at 03:50:55PM -0600, Al Stone wrote:
>> On 03/28/2016 06:06 PM, Al Stone wrote:
>>> The ACPI 6.1 specification was recently released at the end of January
>>> 2016, but the arm64 kernel documentation for
On 04/08/2016 07:12 AM, Will Deacon wrote:
> On Thu, Apr 07, 2016 at 03:50:55PM -0600, Al Stone wrote:
>> On 03/28/2016 06:06 PM, Al Stone wrote:
>>> The ACPI 6.1 specification was recently released at the end of January
>>> 2016, but the arm64 kernel documentation for
On 03/28/2016 06:06 PM, Al Stone wrote:
> The ACPI 6.1 specification was recently released at the end of January
> 2016, but the arm64 kernel documentation for the use of ACPI was written
> for the 5.1 version of the spec. There were significant additions to the
> spec that had
On 03/28/2016 06:06 PM, Al Stone wrote:
> The ACPI 6.1 specification was recently released at the end of January
> 2016, but the arm64 kernel documentation for the use of ACPI was written
> for the 5.1 version of the spec. There were significant additions to the
> spec that had
On 04/07/2016 01:26 AM, Geert Uytterhoeven wrote:
> On Thu, Apr 7, 2016 at 2:18 AM, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
>> On Wed, Apr 06, 2016 at 03:27:20PM -0600, Al Stone wrote:
>>> On arm64 systems, using /dev/port does not really make sense; th
On 04/07/2016 01:26 AM, Geert Uytterhoeven wrote:
> On Thu, Apr 7, 2016 at 2:18 AM, Greg Kroah-Hartman
> wrote:
>> On Wed, Apr 06, 2016 at 03:27:20PM -0600, Al Stone wrote:
>>> On arm64 systems, using /dev/port does not really make sense; this is
>>> historicall
binmode(IOPORTS);
sysseek(IOPORTS, 0x2e, 0);
syswrite(IOPORTS, pack("C", 0x0d), 1);
So, make sure CONFIG_DEVPORT cannot be set on arm64; it cannot really be
used and it allows us to crash a kernel from user space.
Signed-off-by: Al Stone <a...@redhat.com>
Cc:
sysseek(IOPORTS, 0x2e, 0);
syswrite(IOPORTS, pack("C", 0x0d), 1);
So, make sure CONFIG_DEVPORT cannot be set on arm64; it cannot really be
used and it allows us to crash a kernel from user space.
Signed-off-by: Al Stone
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
driv
d while the latest version mentioned above describes a bit of a review
process to handle this case, I don't recall the kernel community at large
agreeing to it, nor to it having been implemented. If I missed that part,
my apologies; please let me know where it was decided. If I haven't, then
perhaps this needs to be the first test case of that process.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
entioned above describes a bit of a review
process to handle this case, I don't recall the kernel community at large
agreeing to it, nor to it having been implemented. If I missed that part,
my apologies; please let me know where it was decided. If I haven't, then
perhaps this needs to be the first test case of that process.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
prior to it being approved by
the forum; there are limits to such disclosures, and a public mailing list may
be well past those limits.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
ed by
the forum; there are limits to such disclosures, and a public mailing list may
be well past those limits.
--
ciao,
al
-------
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
Abdulhahmid)
-- Clarification on _CCA usage (Harb Abdulhamid)
-- IORT moved to required from recommended (Hanjun Guo)
-- Clarify IORT description (Hanjun Guo)
Signed-off-by: Al Stone <al.st...@linaro.org>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea
Abdulhahmid)
-- Clarification on _CCA usage (Harb Abdulhamid)
-- IORT moved to required from recommended (Hanjun Guo)
-- Clarify IORT description (Hanjun Guo)
Signed-off-by: Al Stone
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Jonathan Corbet
---
Documentation/arm64/acpi_object_usage.txt
On 03/15/2016 10:50 PM, Vikas Sajjan wrote:
> Hi Al Stone,
>
> On Wed, Mar 16, 2016 at 1:58 AM, Al Stone <al.st...@linaro.org> wrote:
>> The ACPI 6.1 specification was recently released at the end of January 2016,
>> but the arm64 kernel documentation for
On 03/15/2016 10:50 PM, Vikas Sajjan wrote:
> Hi Al Stone,
>
> On Wed, Mar 16, 2016 at 1:58 AM, Al Stone wrote:
>> The ACPI 6.1 specification was recently released at the end of January 2016,
>> but the arm64 kernel documentation for the use of ACPI was written for the
>&
Abdulhamid)
-- IORT moved to required from recommended (Hanjun Guo)
-- Clarify IORT description (Hanjun Guo)
Signed-off-by: Al Stone <al.st...@linaro.org>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Jonathan Corbet <cor...@lwn.ne
Abdulhamid)
-- IORT moved to required from recommended (Hanjun Guo)
-- Clarify IORT description (Hanjun Guo)
Signed-off-by: Al Stone
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Jonathan Corbet
---
Documentation/arm64/acpi_object_usage.txt | 445 ++
Documentation/arm64
riteria for submission.
>
> The license applies not to this code but to the document describing the
> tables.
Just for the record, the SPCR table struct definition has been part
of the Linux kernel since at least commit b24aad44 on 2009-07-24
(line 1112 of include/acpi/actbl2.h) -- or so git blame tells me.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
riteria for submission.
>
> The license applies not to this code but to the document describing the
> tables.
Just for the record, the SPCR table struct definition has been part
of the Linux kernel since at least commit b24aad44 on 2009-07-24
(line 1112 of include/acpi/actbl2.h) -- or so git blame tells me.
--
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
passing control to the kernel. That's the consensus so far on how this is to
be done.
This also looks to be using _DSD in ACPI, which is another topic that's still
under discussion. What does the ASL look like for these PHYs, as used in this
patch?
--
ciao,
al
passing control to the kernel. That's the consensus so far on how this is to
be done.
This also looks to be using _DSD in ACPI, which is another topic that's still
under discussion. What does the ASL look like for these PHYs, as used in this
patch?
--
ciao,
al
On 11/12/2015 05:25 PM, Guenter Roeck wrote:
> On 11/12/2015 04:06 PM, Al Stone wrote:
>> On 11/05/2015 09:41 AM, Guenter Roeck wrote:
>>> On 11/05/2015 07:00 AM, Fu Wei wrote:
>>>> Hi Timur,
>>>>
>>>> On 5 November 2015 at 22:40, Timur Tabi w
Sorry for the delayed response...I've got some difficult family things to work
on IRL that are taking priority...
On 11/12/2015 05:23 PM, Timur Tabi wrote:
> On 11/12/2015 06:06 PM, Al Stone wrote:
>> If it is a NAK, that's fine, but I also want to be sure I understand what the
>
Sorry for the delayed response...I've got some difficult family things to work
on IRL that are taking priority...
On 11/12/2015 05:23 PM, Timur Tabi wrote:
> On 11/12/2015 06:06 PM, Al Stone wrote:
>> If it is a NAK, that's fine, but I also want to be sure I understand what the
>
On 11/12/2015 05:25 PM, Guenter Roeck wrote:
> On 11/12/2015 04:06 PM, Al Stone wrote:
>> On 11/05/2015 09:41 AM, Guenter Roeck wrote:
>>> On 11/05/2015 07:00 AM, Fu Wei wrote:
>>>> Hi Timur,
>>>>
>>>> On 5 November 2015 at 22:40, Timur
be
accepted so I could never get to my goal of an SBSA-compliant driver. I don't
think that's what was meant, so what did I miss?
Thanks in advance for any clarifications that can be provided.I really do
appreciate it. Email is not always the clearest mechanism for communication
so sometimes I have
nd the changes would not be
accepted so I could never get to my goal of an SBSA-compliant driver. I don't
think that's what was meant, so what did I miss?
Thanks in advance for any clarifications that can be provided.I really do
appreciate it. Email is not always the clearest me
e changed and is now usable for consoles, so it got worked
on and implemented.
> Leif, Al?
>
> [1] https://lkml.org/lkml/2015/9/8/287
>
> Thanks,
> Mark.
>
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
e changed and is now usable for consoles, so it got worked
on and implemented.
> Leif, Al?
>
> [1] https://lkml.org/lkml/2015/9/8/287
>
> Thanks,
> Mark.
>
--
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
On 10/21/2015 04:29 PM, Rafael J. Wysocki wrote:
> On Wed, Oct 21, 2015 at 6:41 PM, Al Stone wrote:
>> On 09/30/2015 04:38 AM, Graeme Gregory wrote:
>>> As discussed when Shannon Zhao sent a patch to add platform_device support
>>> to pl061 driver. Russel and other mai
On 10/21/2015 04:29 PM, Rafael J. Wysocki wrote:
> On Wed, Oct 21, 2015 at 6:41 PM, Al Stone <a...@redhat.com> wrote:
>> On 09/30/2015 04:38 AM, Graeme Gregory wrote:
>>> As discussed when Shannon Zhao sent a patch to add platform_device support
>>> to pl061 dri
--
> 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
>
Any comments on these patches? It's been awful quiet
--
ciao,
al
-
--
> 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
>
Any comments on these patches? It's been awful quiet
--
ciao,
al
-
these MADT checks breaks far too many existing
x86 systems where the firmware does things it should not; re-reading some
of the ia64 kernel code, there's a pathological case there where it could
break (but shouldn't if iasl is being used to compile tables). I'll be
working on the new version today.
em arch-specific; doing these MADT checks breaks far too many existing
x86 systems where the firmware does things it should not; re-reading some
of the ia64 kernel code, there's a pathological case there where it could
break (but shouldn't if iasl is being used to compile tables). I'll be
working on
On 10/14/2015 03:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 14, 2015 02:20:51 PM Al Stone wrote:
>> This is a multi-part message in MIME format.
>> --020400080004050109020606
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encodin
On 10/12/2015 10:06 PM, Pat Erley wrote:
> On 10/12/2015 01:52 PM, Al Stone wrote:
>> On 10/11/2015 09:58 PM, Pat Erley wrote:
>>> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>>>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>>>> On 10/05/2015 10:12 AM,
On 10/12/2015 10:06 PM, Pat Erley wrote:
> On 10/12/2015 01:52 PM, Al Stone wrote:
>> On 10/11/2015 09:58 PM, Pat Erley wrote:
>>> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>>>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>>>> On 10/05/2015 10:12 AM,
On 10/14/2015 03:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 14, 2015 02:20:51 PM Al Stone wrote:
>> This is a multi-part message in MIME format.
>> --020400080004050109020606
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encodin
On 10/11/2015 09:58 PM, Pat Erley wrote:
> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>> On 10/05/2015 10:12 AM, Al Stone wrote:
>>>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
>>>>> On Wednesday,
gt;>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>>>>> On 10/05/2015 10:12 AM, Al Stone wrote:
>>>>>>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
>>>>>>>> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>>>&g
gt;>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>>>>> On 10/05/2015 10:12 AM, Al Stone wrote:
>>>>>>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
>>>>>>>> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>>>&g
On 10/11/2015 09:58 PM, Pat Erley wrote:
> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>> On 10/05/2015 10:12 AM, Al Stone wrote:
>>>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
>>>>> On Wednesday,
On 10/09/2015 03:02 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 05:05:00 PM Al Stone wrote:
>> On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
>>> On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
>>>> On 10/08/2015 02:41 PM, Rafael J. Wy
On 10/09/2015 03:02 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 05:05:00 PM Al Stone wrote:
>> On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
>>> On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
>>>> On 10/08/2015 02:41 PM, Rafael J. Wy
On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
>> On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
>>> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
>>>> On Thursday, October 08, 2
On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
>> On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
>>> On 10/08/2015 05:44 AM, Hanjun Guo wrote:
>>>> On 10/08/2015 11:21 AM, kernel t
nse, the less usable it will
become.
At a minimum, whoever is responsible for this firmware needs to make
sure the spec reflects what they are doing. In the meantime, the
only option is what Hanjun suggests -- make this a warning and not a
failure. I'll prepare a patch and attach it to a rep
nse, the less usable it will
become.
At a minimum, whoever is responsible for this firmware needs to make
sure the spec reflects what they are doing. In the meantime, the
only option is what Hanjun suggests -- make this a warning and not a
failure. I'll prepare a patch and attach it to a rep
On 10/08/2015 04:50 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 02:32:15 PM Al Stone wrote:
>> On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
>>> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
>>>> On Thursday, October 08, 2
On 10/08/2015 02:41 PM, Rafael J. Wysocki wrote:
> On Thursday, October 08, 2015 10:37:55 PM Rafael J. Wysocki wrote:
>> On Thursday, October 08, 2015 10:36:40 AM Al Stone wrote:
>>> On 10/08/2015 05:44 AM, Hanjun Guo wrote:
>>>> On 10/08/2015 11:21 AM, kernel t
On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>>> On 2015/9/30 7:45, Al Stone wrote:
>>>> NB: this patch set is for use against the linux-pm bleeding
On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>>> On 2015/9/30 7:45, Al Stone wrote:
>>>> NB: this patch set is for use against the linux-pm bleeding
On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> On 2015/9/30 7:45, Al Stone wrote:
>> NB: this patch set is for use against the linux-pm bleeding edge branch.
>>
[snip...]
>
> For this patch set,
>
> Reviewed-by: Hanjun Guo
>
> Thanks
> H
On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> On 2015/9/30 7:45, Al Stone wrote:
>> NB: this patch set is for use against the linux-pm bleeding edge branch.
>>
[snip...]
>
> For this patch set,
>
> Reviewed-by: Hanjun Guo <hanjun@linaro.org>
>
> Tha
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone
Cc: Tony Luck
Cc: Fenghua Yu
---
arch/ia64/kernel/acpi.c | 20
Now that we have introduced to bad_madt_entry(), and we have removed
all the usages of the BAD_MADT_ENTRY macro from all of the various
architectures that use it (arm64, ia64, x86), we can remove the macro
definition since it is no longer used.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc
not impact current behavior
(Sudeep Holla)
Changes for v2:
-- Acked-by on 2/5 from Marc Zyngier and Catalin Marinas for ARM
-- Correct faulty end of loop test found by Timur Tabi
Al Stone (5):
ACPI: add in a bad_madt_entry() function to eventually replace the
macro
ACPI / ARM64
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro, or in the case
of arm64, the BAD_MADT_GICC_ENTRY, too.
Signed-off-by: Al Stone
Acked-by: Catalin Marinas
from now on.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
---
drivers/acpi/tables.c | 247 +-
1 file changed, 246 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 6c0f079..a2ed38a 100644
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro, or in the case
of arm64, the BAD_MADT_GICC_ENTRY, too.
Signed-off-by: Al Stone <al.st...@linaro.org>
from now on.
Signed-off-by: Al Stone <al.st...@linaro.org>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <l...@kernel.org>
---
drivers/acpi/tables.c | 247 +-
1 file changed, 246 insertions(+), 1 deletion(-)
diff --
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone <al.st...@linaro.org>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
C
not impact current behavior
(Sudeep Holla)
Changes for v2:
-- Acked-by on 2/5 from Marc Zyngier and Catalin Marinas for ARM
-- Correct faulty end of loop test found by Timur Tabi
Al Stone (5):
ACPI: add in a bad_madt_entry() function to eventually replace the
macro
ACPI / ARM64
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone <al.st...@linaro.org>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Fenghua
Now that we have introduced to bad_madt_entry(), and we have removed
all the usages of the BAD_MADT_ENTRY macro from all of the various
architectures that use it (arm64, ia64, x86), we can remove the macro
definition since it is no longer used.
Signed-off-by: Al Stone <al.st...@linaro.org&
On 09/25/2015 05:29 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 16, 2015 05:26:40 PM Al Stone wrote:
>> Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity
>> check on the various subtables that are defined for the MADT. The check
>> compares the
still aimed at 4.4)?
>>
>> The Al's patches are gone for now, because they introduced a 0-day testing
>> regression.
>>
>> I guess this means I can apply your patches first and ask Al to rebase his
>> next version on them.
>
> OK. I'll rebase them on the current ble
f I wait for his patches.
>
> Regards,
> Sudeep
My apologies. Was participating in family stuff all weekend
and Linaro Connect all last week.
This appears to be an incorrect reading of the 1.0 spec, and not
being able to find the 1.0b version, on my part. Unfortunately,
http://www.a
still aimed at 4.4)?
>>
>> The Al's patches are gone for now, because they introduced a 0-day testing
>> regression.
>>
>> I guess this means I can apply your patches first and ask Al to rebase his
>> next version on them.
>
> OK. I'll rebase them on the current ble
correct?
>>
>
> Correct, I think it's easier if I wait for his patches.
>
> Regards,
> Sudeep
My apologies. Was participating in family stuff all weekend
and Linaro Connect all last week.
This appears to be an incorrect reading of the 1.0 spec, and not
being able to find the 1
On 09/25/2015 05:29 PM, Rafael J. Wysocki wrote:
> On Wednesday, September 16, 2015 05:26:40 PM Al Stone wrote:
>> Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity
>> check on the various subtables that are defined for the MADT. The check
>> compares the
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro.
Signed-off-by: Al Stone
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc
Now that we have introduced the bad_madt_entry() function, and that
function is being invoked in acpi_table_parse_madt() for us, there
is no longer any need to use the BAD_MADT_ENTRY macro, or in the case
of arm64, the BAD_MADT_GICC_ENTRY, too.
Signed-off-by: Al Stone
Acked-by: Catalin Marinas
201 - 300 of 552 matches
Mail list logo
