[PATCH] Fix _STA checking in acpi_bus_add

[PATCH] Fix _STA checking in acpi_bus_add

[Bjorn Helgaas]

In 2.6.1-rc1, acpi_bus_add() calls acpi_bus_get_status() to evaluate
_STA, but botches checking the return value.  The result is that _STA
is ignored (if it was evaluated correctly), or we check garbage (if
the evaluation failed).  Here's a patch to fix it:

===== drivers/acpi/scan.c 1.19 vs edited =====
--- 1.19/drivers/acpi/scan.c	Sun May 25 18:00:00 2003
+++ edited/drivers/acpi/scan.c	Fri Jan  2 16:14:25 2004
@@ -703,11 +703,11 @@
 	switch (type) {
 	case ACPI_BUS_TYPE_DEVICE:
 		result = acpi_bus_get_status(device);
-		if (!result)
-			break;
-		if (!device->status.present) 
+		if (ACPI_FAILURE(result) || !device->status.present) {
 			result = -ENOENT;
-		goto end;
+			goto end;
+		}
+		break;
 	default:
 		STRUCT_TO_INT(device->status) = 0x0F;
 		break;



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: [PATCH] Fix _STA checking in acpi_bus_add

[Bjorn Helgaas]

I haven't seen any response to this.  Is there at least agreement
that the current code is broken?  Is there somewhere I should be
checking for status besides the mailing list?

On Friday 02 January 2004 4:35 pm, Bjorn Helgaas wrote:
> In 2.6.1-rc1, acpi_bus_add() calls acpi_bus_get_status() to evaluate
> _STA, but botches checking the return value.  The result is that _STA
> is ignored (if it was evaluated correctly), or we check garbage (if
> the evaluation failed).  Here's a patch to fix it:
> 
> ===== drivers/acpi/scan.c 1.19 vs edited =====
> --- 1.19/drivers/acpi/scan.c	Sun May 25 18:00:00 2003
> +++ edited/drivers/acpi/scan.c	Fri Jan  2 16:14:25 2004
> @@ -703,11 +703,11 @@
>  	switch (type) {
>  	case ACPI_BUS_TYPE_DEVICE:
>  		result = acpi_bus_get_status(device);
> -		if (!result)
> -			break;
> -		if (!device->status.present) 
> +		if (ACPI_FAILURE(result) || !device->status.present) {
>  			result = -ENOENT;
> -		goto end;
> +			goto end;
> +		}
> +		break;
>  	default:
>  		STRUCT_TO_INT(device->status) = 0x0F;
>  		break;
> 



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: [PATCH] Fix _STA checking in acpi_bus_add

[Len Brown]

Applied.

thanks Bjorn,
-Len

ps. did you find this because you've got a system where the actual
get_status failed, or the _STA returned !present and that was ignored?

On Fri, 2004-01-02 at 18:35, Bjorn Helgaas wrote:
> In 2.6.1-rc1, acpi_bus_add() calls acpi_bus_get_status() to evaluate
> _STA, but botches checking the return value.  The result is that _STA
> is ignored (if it was evaluated correctly), or we check garbage (if
> the evaluation failed).  Here's a patch to fix it:
> 
> ===== drivers/acpi/scan.c 1.19 vs edited =====
> --- 1.19/drivers/acpi/scan.c	Sun May 25 18:00:00 2003
> +++ edited/drivers/acpi/scan.c	Fri Jan  2 16:14:25 2004
> @@ -703,11 +703,11 @@
>  	switch (type) {
>  	case ACPI_BUS_TYPE_DEVICE:
>  		result = acpi_bus_get_status(device);
> -		if (!result)
> -			break;
> -		if (!device->status.present) 
> +		if (ACPI_FAILURE(result) || !device->status.present) {
>  			result = -ENOENT;
> -		goto end;
> +			goto end;
> +		}
> +		break;
>  	default:
>  		STRUCT_TO_INT(device->status) = 0x0F;
>  		break;
> 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: [PATCH] Fix _STA checking in acpi_bus_add

[Bjorn Helgaas]

On Friday 23 January 2004 9:43 pm, Len Brown wrote:
> Applied.

Thanks!

> ps. did you find this because you've got a system where the actual
> get_status failed, or the _STA returned !present and that was ignored?

Umm...  let's see... the latter, I guess.  I found this because
ia64 linux was complaining about some invalid ranges in _CRS on
the Intel Tiger box.  It turned out that the ranges all had
_LEN==0, and we should have been ignoring them anyway.

But somebody from HP-UX noticed that we were complaining about
ranges on a bridge that should have been !present according to
the _STA.

Now that you've applied this, we have to resolve the next issue
I found while investigating this: the chipset config interface
(CBN/CSFF) is reported as _STA==0x8, i.e., "functioning, but not
present".  We can't find anything in the spec on how to interpret
this.

The problem here is that since CBN/CSFF is !present, we won't
enumerate devices under them.  Therefore, we will no longer find
the AGP bridge on Big Sur.

Bjorn



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: [PATCH] Fix _STA checking in acpi_bus_add

[Brown, Len]

> Now that you've applied this, we have to resolve the next issue
> I found while investigating this: the chipset config interface
> (CBN/CSFF) is reported as _STA==0x8, i.e., "functioning, but not
> present".  We can't find anything in the spec on how to interpret
> this.

Sounds like broken firmware. Not only is it !present, it is !enabled.

The _STA section of the ACPI spec says that if a device isn't
(present && enabled) then it shouldn't even decode its
hardware resources.

> The problem here is that since CBN/CSFF is !present, we won't
> enumerate devices under them.  Therefore, we will no longer find
> the AGP bridge on Big Sur.

Oof!


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn