From: Sudeep Holla <sudeep.holla@arm.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Pat Erley <pat-lkml@erley.org>, Al Stone <ahs3@redhat.com>,
linaro-kernel@lists.linaro.org, linux-ia64@vger.kernel.org,
patches@linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org,
linux-acpi@vger.kernel.org, Hanjun Guo <guohanjun@huawei.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks
Date: Tue, 13 Oct 2015 09:43:45 +0100 [thread overview]
Message-ID: <561CC441.6090003@arm.com> (raw)
In-Reply-To: <32835486.gnkKHR2R1U@vostro.rjw.lan>
On 12/10/15 20:25, Rafael J. Wysocki wrote:
> On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:
[...]
>>
>> Instead of just removing the check completely on x86, IMO restrict
>> it to some newer/later version of ACPI so you can still force
>> vendors to fix their ACPI tables at-least in future.
>
> No, we can't force vendors to fix their ACPI tables. This is
> completely unrealistic.
>
No, I was referring to the future platforms *only*
> We simly need to deal with the bugs in the ACPI tables in the
> kernel.
>
Yes sadly true for existing systems, but if we now place a check for
ACPIv6.0 and above, we might avoid seeing such broken tables sometime in
future once the kernel with this check in place is used for validation.
>> It would be good to get such sanity check in the tools used to
>> build those tables, but yes since such static tables can be built
>> in many ways, its difficult to deal it in all those tools.
>
> As I said to Al, we need those checks in firmware test suites.
> Having them in the kernel is OK too, but they should cause warnings
> to be printed to the kernel log instead of causing the kernel to
> panic.
>
Agreed
--
Regards,
Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Pat Erley <pat-lkml@erley.org>, Al Stone <ahs3@redhat.com>,
linaro-kernel@lists.linaro.org, linux-ia64@vger.kernel.org,
patches@linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org,
linux-acpi@vger.kernel.org, Hanjun Guo <guohanjun@huawei.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks
Date: Tue, 13 Oct 2015 08:43:45 +0000 [thread overview]
Message-ID: <561CC441.6090003@arm.com> (raw)
In-Reply-To: <32835486.gnkKHR2R1U@vostro.rjw.lan>
On 12/10/15 20:25, Rafael J. Wysocki wrote:
> On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:
[...]
>>
>> Instead of just removing the check completely on x86, IMO restrict
>> it to some newer/later version of ACPI so you can still force
>> vendors to fix their ACPI tables at-least in future.
>
> No, we can't force vendors to fix their ACPI tables. This is
> completely unrealistic.
>
No, I was referring to the future platforms *only*
> We simly need to deal with the bugs in the ACPI tables in the
> kernel.
>
Yes sadly true for existing systems, but if we now place a check for
ACPIv6.0 and above, we might avoid seeing such broken tables sometime in
future once the kernel with this check in place is used for validation.
>> It would be good to get such sanity check in the tools used to
>> build those tables, but yes since such static tables can be built
>> in many ways, its difficult to deal it in all those tools.
>
> As I said to Al, we need those checks in firmware test suites.
> Having them in the kernel is OK too, but they should cause warnings
> to be printed to the kernel log instead of causing the kernel to
> panic.
>
Agreed
--
Regards,
Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks
Date: Tue, 13 Oct 2015 09:43:45 +0100 [thread overview]
Message-ID: <561CC441.6090003@arm.com> (raw)
In-Reply-To: <32835486.gnkKHR2R1U@vostro.rjw.lan>
On 12/10/15 20:25, Rafael J. Wysocki wrote:
> On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:
[...]
>>
>> Instead of just removing the check completely on x86, IMO restrict
>> it to some newer/later version of ACPI so you can still force
>> vendors to fix their ACPI tables at-least in future.
>
> No, we can't force vendors to fix their ACPI tables. This is
> completely unrealistic.
>
No, I was referring to the future platforms *only*
> We simly need to deal with the bugs in the ACPI tables in the
> kernel.
>
Yes sadly true for existing systems, but if we now place a check for
ACPIv6.0 and above, we might avoid seeing such broken tables sometime in
future once the kernel with this check in place is used for validation.
>> It would be good to get such sanity check in the tools used to
>> build those tables, but yes since such static tables can be built
>> in many ways, its difficult to deal it in all those tools.
>
> As I said to Al, we need those checks in firmware test suites.
> Having them in the kernel is OK too, but they should cause warnings
> to be printed to the kernel log instead of causing the kernel to
> panic.
>
Agreed
--
Regards,
Sudeep
next prev parent reply other threads:[~2015-10-13 8:43 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 23:45 [PATCH v5 0/5] Provide better MADT subtable sanity checks Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` [PATCH v5 1/5] ACPI: add in a bad_madt_entry() function to eventually replace the macro Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` [PATCH v5 2/5] ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` [PATCH v5 3/5] ACPI / IA64: remove usage of BAD_MADT_ENTRY Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` [PATCH v5 4/5] ACPI / X86: " Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` [PATCH v5 5/5] ACPI: remove definition of BAD_MADT_ENTRY macro Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-29 23:45 ` Al Stone
2015-09-30 9:00 ` [PATCH v5 0/5] Provide better MADT subtable sanity checks Hanjun Guo
2015-09-30 9:00 ` Hanjun Guo
2015-09-30 9:00 ` Hanjun Guo
2015-09-30 9:00 ` Hanjun Guo
2015-09-30 16:10 ` Al Stone
2015-09-30 16:10 ` Al Stone
2015-09-30 16:10 ` Al Stone
2015-10-05 13:39 ` Rafael J. Wysocki
2015-10-05 13:39 ` Rafael J. Wysocki
2015-10-05 13:39 ` Rafael J. Wysocki
2015-10-05 17:12 ` Al Stone
2015-10-05 17:12 ` Al Stone
2015-10-05 17:12 ` Al Stone
2015-10-12 3:08 ` Pat Erley
2015-10-12 3:49 ` [Linaro-acpi] " Hanjun Guo
2015-10-12 3:49 ` Hanjun Guo
2015-10-12 3:49 ` Hanjun Guo
2015-10-12 3:58 ` Pat Erley
2015-10-12 3:58 ` Pat Erley
2015-10-12 3:58 ` Pat Erley
2015-10-12 7:04 ` Hanjun Guo
2015-10-12 7:04 ` Hanjun Guo
2015-10-12 7:04 ` Hanjun Guo
2015-10-12 9:44 ` Sudeep Holla
2015-10-12 9:44 ` Sudeep Holla
2015-10-12 9:44 ` Sudeep Holla
2015-10-12 13:04 ` Hanjun Guo
2015-10-12 13:04 ` Hanjun Guo
2015-10-12 13:04 ` Hanjun Guo
2015-10-12 18:56 ` Rafael J. Wysocki
2015-10-12 19:25 ` Rafael J. Wysocki
2015-10-12 19:25 ` Rafael J. Wysocki
2015-10-12 19:07 ` Al Stone
2015-10-12 19:07 ` Al Stone
2015-10-12 19:07 ` Al Stone
2015-10-13 8:43 ` Sudeep Holla [this message]
2015-10-13 8:43 ` Sudeep Holla
2015-10-13 8:43 ` Sudeep Holla
2015-10-12 18:53 ` Rafael J. Wysocki
2015-10-12 19:21 ` Rafael J. Wysocki
2015-10-12 19:21 ` Rafael J. Wysocki
2015-10-13 1:23 ` Hanjun Guo
2015-10-13 1:23 ` Hanjun Guo
2015-10-13 1:23 ` Hanjun Guo
2015-10-12 20:52 ` Al Stone
2015-10-12 20:52 ` Al Stone
2015-10-12 20:52 ` Al Stone
2015-10-13 4:06 ` Pat Erley
2015-10-13 4:06 ` Pat Erley
2015-10-13 4:06 ` Pat Erley
2015-10-14 20:20 ` Al Stone
2015-10-14 20:20 ` Al Stone
2015-10-14 20:20 ` Al Stone
2015-10-14 20:57 ` Rafael J. Wysocki
2015-10-14 21:25 ` Rafael J. Wysocki
2015-10-14 21:25 ` Rafael J. Wysocki
2015-10-14 21:27 ` Al Stone
2015-10-14 21:27 ` Al Stone
2015-10-14 21:27 ` Al Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561CC441.6090003@arm.com \
--to=sudeep.holla@arm.com \
--cc=ahs3@redhat.com \
--cc=guohanjun@huawei.com \
--cc=hanjun.guo@linaro.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pat-lkml@erley.org \
--cc=patches@linaro.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.