Bug 3358

Matthieu,
Could you please attach your DSDT?

look at
                                    If (DEN)
                                    {
                                        Return (0x0F)
                                    }
                                    Else
                                    {
                                        Return (0x0D)
                                    }
you could see that when DEM = zero (device disable), the device is functional
but not present

So the right way is to suppress (device->status.functional &&
!device->status.present) case...

Created attachment 3742 [details]
dsdt

I'm a little confused. 0xD (1101b) means present, disabled, functional.

oupps it is me :
I write the wrong test.
When the device is disable via the bios or LPT is enable, for the ECP device
LAnd (LEqual (Local0, 0x80), LEqual (L1EN, 0x01)) will be false, so it will
return 0x8 (1000b) (functional=1, present=enable=0)

The DEN is used when disable via _DIS.

If (LAnd (LEqual (Local0, 0x80), LEqual (L1EN, 0x01)))                  
                            {   
                                If (DEN)
                                {
                                    Return (0x0F)
                                }
                                Else
                                {
                                    Return (0x0D)
                                }
                            }
                            Else
                            {
                                Return (0x08)
                            }
}

Bjorn made the workaround for HP systems. Will send an email to him.

the acpi spec say :
_STA may return bit 0 clear (not present) with bit 3 set (device is functional).
This case is used to indicate
a valid device for which no device driver should be loaded (for example, a
bridge device.) Children of this
device may be present and valid. OSPM should continue enumeration below a device
whose _STA returns
this bit combination.


So it seem clear that if this device should not added in the acpi layer in order
to respect the spec...
The same fix is to be done in pnpacpi...

Here's history for bjorn's workaround:
https://sourceforge.net/mailarchive/message.php?msg_id=6923358

The following is the conclusion till now.
<--quote

On Wednesday 12 May 2004 3:49 pm, Len Brown wrote:
> The ACPI spec gurus say that as of 2.0c,
> _STA.functional is meaningless unless _STA.present.
> 
> However, they also say that the (_STA.functional && !_STA.present)
> implementation was intentional -- apparently to trick some OSPM into
> using a resource for initialization only, but to not load
> a driver.

Yup, I think somebody said Windows did something special with
this combination.  Figures.

> I'm advocating that the spec be clarified to explicitly
> allow or disallow this idiom.
> 
> In the mean-time, Bjorn's patch is now present in the acpi-test tree.

Sounds good to me.  Thanks for chasing it down!

Bjorn


--quote>

After reading the history for bjorn's workaround, what I understand is the
pseudo PCI root bridges don't need driver and we only need to scan the devices
below them.

So it's follow the spec (that even give bridge as example) and I don't see why
you need to add it in acpi driver layer.

Bjorn said they need the hiden MCH devices to do something (I can't recall 
clearly) not adding a MCH driver. But anyway, this workaround is very curious.

Created attachment 4274 [details]
Attempt to fix the problem

I think the parsing device loop should be modified : this hack allow the loop
to parse device child of 'functional but not present' devices. So we should
allow this without modifying present flag and adding the device to the acpi
layer.

I attached an attempt to do that (untested), but I don't know if it is possible
to not register this device in the acpi layer...

Created attachment 12872 [details]
patch vs 2.6.23

patch from comment #12 refreshed for linux-2.6.23

Created attachment 12873 [details]
the same patch as comment #13 but cleaner

Created attachment 12874 [details]
patch to workaround the issue

Proposed patch doesn't solve the issue, functional but not present device is stilled be plugged into ACPI layer. To workaround the issue, the new patch does a check in PNP driver.

Len, please check if this is ok.

Created attachment 13880 [details]
patch for the workaround this issue

Will someone test this patch on the machine with the unpresent but functional device? 
Thanks.

Created attachment 14424 [details]
patch vs 2.6.24 to fix autoload

Yakui,
Please update the patch in comment #16 so that it applies
on top of this "autoload.patch", which is already queued for 2.6.25.

Created attachment 15133 [details]
Build Linux ACPI device tree and load device driver according to the status of the device.

The attached is updated patch.

yakui, should we mark this resloved and let Len take the patch?

patch in comment #18 is queued for 2.6.28:

Author: Zhao Yakui <yakui.zhao@intel.com>  2008-08-11 01:40:22
Committer: Len Brown <len.brown@intel.com>  2008-09-19 14:57:47
Parent: 2f76f1bd9b3ed0992b987d0b3a9b60ee698467d4 (ACPI: Add DMI check to disable power state check in power transition)
Child:  a8c8bdb14ec941cf00103b725683f2d6952bd0b4 (Merge branch 'ec' into test)
Branches: bugfixes, test
Follows: v2.6.27-rc6
Precedes: 

    ACPI : Load device driver according to the status of acpi device

shipped in linux-2.6.28-rc1
closed

commit 39a0ad871000d2a016a4fa113a6e53d22aabf25d
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Mon Aug 11 13:40:22 2008 +0800

    ACPI : Load device driver according to the status of acpi device