9:45 a.m.
ACPI Spec. 4.0a, 6.4.3.5 Address Space Range Descriptor, Table 6-40 on
page 260 implies _LEN > 0, _MIF = 1, and _MAF = 1 is the only valid
combination for _CRS. However, I found a _CRS example on page, which
has _LEN = _MIF = _MAF = 0. Can you please clarify? If the table is
correct, iasl should have warned about it. I think iasl currently
treats _PRS and _CRS equally.
Jung-uk Kim
9:50 a.m.
On Friday 22 July 2011 12:45 pm, Jung-uk Kim wrote:
ACPI Spec. 4.0a, 6.4.3.5 Address Space Range Descriptor, Table 6-40
on page 260 implies _LEN > 0, _MIF = 1, and _MAF = 1 is the only
valid combination for _CRS. However, I found a _CRS example on
page, which has _LEN = _MIF = _MAF = 0. Can you please clarify?
^^^^
page 356
I was going to fill in the blank but pressed the send button
prematurely.
Sorry,
Jung-uk Kim
11:43 a.m.
On Friday 22 July 2011 12:45 pm, Jung-uk Kim wrote:
ACPI Spec. 4.0a, 6.4.3.5 Address Space Range Descriptor, Table 6-40
on page 260 implies _LEN > 0, _MIF = 1, and _MAF = 1 is the only
valid combination for _CRS. However, I found a _CRS example on
page, which has _LEN = _MIF = _MAF = 0. Can you please clarify?
If the table is correct, iasl should have warned about it. I think
iasl currently treats _PRS and _CRS equally.
John Baldwin <jhb(a)FreeBSD.org> pointed out iASL's address space range
check introduced in ACPI-CA 20100428 is just bogus. It is often
times dynamically recalculated from a template. Therefore, OS must
do the sanity check at *runtime*, at least for _CRS.
Jung-uk Kim
12:15 p.m.
I think we relaxed the iASL checking a bit because of these issues. If not, we plan to do
so.
This might be an area where we could check the descriptors at runtime, as they are
returned from _CRS, etc.
Bob
-----Original Message-----
From: devel-bounces(a)acpica.org [mailto:[email protected]] On
Behalf Of Jung-uk Kim
Sent: Friday, July 22, 2011 11:44 AM
To: devel(a)acpica.org
Cc: John Baldwin
Subject: Re: [Devel] _CRS/_PRS for address space range
On Friday 22 July 2011 12:45 pm, Jung-uk Kim wrote:
> ACPI Spec. 4.0a, 6.4.3.5 Address Space Range Descriptor, Table 6-40
> on page 260 implies _LEN > 0, _MIF = 1, and _MAF = 1 is the only
> valid combination for _CRS. However, I found a _CRS example on
> page, which has _LEN = _MIF = _MAF = 0. Can you please clarify?
> If the table is correct, iasl should have warned about it. I think
> iasl currently treats _PRS and _CRS equally.
John Baldwin <jhb(a)FreeBSD.org> pointed out iASL's address space range
check introduced in ACPI-CA 20100428 is just bogus. It is often
times dynamically recalculated from a template. Therefore, OS must
do the sanity check at *runtime*, at least for _CRS.
Jung-uk Kim
_______________________________________________
Devel mailing list
Devel(a)acpica.org
http://lists.acpica.org/listinfo/devel
12:48 p.m.
On Friday 22 July 2011 03:15 pm, Moore, Robert wrote:
I think we relaxed the iASL checking a bit because of these issues.
If not, we plan to do so.
ACPICA 20110527 still has this issue.
This might be an area where we could check the descriptors at
runtime, as they are returned from _CRS, etc.
That'll be great.
Thanks!
JK
Bob
> -----Original Message-----
> From: devel-bounces(a)acpica.org [mailto:[email protected]]
> On Behalf Of Jung-uk Kim
> Sent: Friday, July 22, 2011 11:44 AM
> To: devel(a)acpica.org
> Cc: John Baldwin
> Subject: Re: [Devel] _CRS/_PRS for address space range
>
> On Friday 22 July 2011 12:45 pm, Jung-uk Kim wrote:
> > ACPI Spec. 4.0a, 6.4.3.5 Address Space Range Descriptor, Table
> > 6-40 on page 260 implies _LEN > 0, _MIF = 1, and _MAF = 1 is
> > the only valid combination for _CRS. However, I found a _CRS
> > example on page, which has _LEN = _MIF = _MAF = 0. Can you
> > please clarify? If the table is correct, iasl should have
> > warned about it. I think iasl currently treats _PRS and _CRS
> > equally.
>
> John Baldwin <jhb(a)FreeBSD.org> pointed out iASL's address space
> range check introduced in ACPI-CA 20100428 is just bogus. It is
> often times dynamically recalculated from a template. Therefore,
> OS must do the sanity check at *runtime*, at least for _CRS.
>
> Jung-uk Kim
> _______________________________________________
> Devel mailing list
> Devel(a)acpica.org
> http://lists.acpica.org/listinfo/devel
1:01 p.m.
There is, however, an option to iASL to disable this checking:
-cr Disable Resource Descriptor error checking
-----Original Message-----
From: Jung-uk Kim [mailto:[email protected]]
Sent: Friday, July 22, 2011 12:48 PM
To: Moore, Robert
Cc: devel(a)acpica.org; John Baldwin
Subject: Re: [Devel] _CRS/_PRS for address space range
On Friday 22 July 2011 03:15 pm, Moore, Robert wrote:
> I think we relaxed the iASL checking a bit because of these issues.
> If not, we plan to do so.
ACPICA 20110527 still has this issue.
> This might be an area where we could check the descriptors at
> runtime, as they are returned from _CRS, etc.
That'll be great.
Thanks!
JK
> Bob
>
> > -----Original Message-----
> > From: devel-bounces(a)acpica.org [mailto:[email protected]]
> > On Behalf Of Jung-uk Kim
> > Sent: Friday, July 22, 2011 11:44 AM
> > To: devel(a)acpica.org
> > Cc: John Baldwin
> > Subject: Re: [Devel] _CRS/_PRS for address space range
> >
> > On Friday 22 July 2011 12:45 pm, Jung-uk Kim wrote:
> > > ACPI Spec. 4.0a, 6.4.3.5 Address Space Range Descriptor, Table
> > > 6-40 on page 260 implies _LEN > 0, _MIF = 1, and _MAF = 1 is
> > > the only valid combination for _CRS. However, I found a _CRS
> > > example on page, which has _LEN = _MIF = _MAF = 0. Can you
> > > please clarify? If the table is correct, iasl should have
> > > warned about it. I think iasl currently treats _PRS and _CRS
> > > equally.
> >
> > John Baldwin <jhb(a)FreeBSD.org> pointed out iASL's address space
> > range check introduced in ACPI-CA 20100428 is just bogus. It is
> > often times dynamically recalculated from a template. Therefore,
> > OS must do the sanity check at *runtime*, at least for _CRS.
> >
> > Jung-uk Kim
> > _______________________________________________
> > Devel mailing list
> > Devel(a)acpica.org
> > http://lists.acpica.org/listinfo/devel
4039
days inactive
4039
days old
5 comments
2 participants
participants (2)
-
Jung-uk Kim -
Moore, Robert