Skip to contentSkip to conversation

Hot Dock/Undock support

PATCH In review Kristen Accardi 4 participants 16 messages Jan 18, 2006 – Jan 20, 2006

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover Hot Dock/Undock support

This series of patches is against the -mm kernel, and will enable docking station support. It is an early patch, but still pretty functional, so I think it's worthwhile to include at this point. For some laptops, it's necessary to use the pci=assign-busses kernel parameter, because some _DCK methods will attempt to assign bus numbers to the dock bridge (incorrectly).

Supported Features:
* Hot Dock/Undock via hardware control
* Enumeration of PCI Devices on Dock Station (Hot Add/Remove) via pci

Not Supported Yet (but will be with laptops with sane dsdts):
* _EJD, _EDL support for devices that aren't enumerable
* hot add of devices other than PCI devices (such as the serial/lpt etc).
* More thorough testing needs to be done for everything, but especially video, as I've not even begun to worry about that.

All docking events are handled by the acpiphp driver. For docking, the acpiphp driver will call the _DCK acpi method, and then insert the docking bridge and all the pci devices behind the dock bridge. This is in conflict with some acpi platform drivers (ibm_acpi) that already attempt to implement a limited form of docking support only for that platform. You may not use both drivers at the same time right now. This is a generic docking solution that should work for all docking stations, not just IBM, although I tested it on an IBM docking station exclusively, because that's all I've got right now.

Right now devices that are not on enumerable buses (or on the PCI bus at all) will not be discovered by acpiphp. Your mileage will vary on any devices other than PCI. This is because in many cases, there are extra hardware configuration steps that need to occur after the _DCK method (because they really should have been done in the _DCK method but were not). Even with PCI devices, you may find that some things don't work properly, because there was some extra configuration step that needed to occur that didn't get done as part of _DCK. For example, included in this patch series is a quirk for the IBM Dock Station II, which seemed to need the cardbus controller interrupts tied together, but this didn't get done with any of the laptops I tested with. I've not yet been able to determine what needs to be done to the USB controller on the T30 or T41 to make it discover the USB hub on the docking station, although this works fine on the T20, and also I hear on the T42, although I've not tested the T42 myself.

You may also find that as soon as you call _DCK, everything is broken. For example, on the T30 laptop I tested, the _DCK method would set the dock bridge's parent secondary bus number to zero, even if it should have been something other than zero. This specific case is handled in the acpiphp driver in the post_dock_fixups() routine, but this may need to be changed for the future if it starts to get out of hand.

There is a workaround right now in this patch for a problem with acpi, where the acpi thread that notifies acpiphp of the dock event will deadlock while executing the _DCK method. I've managed to avoid trying to solve this problem for now by spawning a separate thread to handle the _DCK, but eventually this will be addressed when I'm brave enough.

Please comment on these patches, and test if you have a docking station available. When you find problems, if you would like me to debug them, please load the acpiphp driver with the debug param (modprobe acpiphp debug=1), and send me the output of dmesg -s 100000 as well as lspci -vv -x -n with the laptop booted in the station, and then the output after booting out of the station and attempting to dock, as well as a copy of your disassembled dsdt. Make sure you have PCI debugging enabled, and debugging enabled for whatever device you are having issues with. This should be a good starting point.

Kristen

#1 lore raw

Hi!

Quoted 3 lines

This series of patches is against the -mm kernel, and will enable docking station support. It is an early patch, but still pretty functional, so I think it's worthwhile to include at this point.

They seem to be in 2.6.16-rc1-mm1 patch, good.

Quoted 9 lines

Supported Features:
* Hot Dock/Undock via hardware control
* Enumeration of PCI Devices on Dock Station (Hot Add/Remove) via pci

Not Supported Yet (but will be with laptops with sane dsdts):
* _EJD, _EDL support for devices that aren't enumerable
* hot add of devices other than PCI devices (such as the serial/lpt etc).
* More thorough testing needs to be done for everything, but especially video, as I've not even begun to worry about that.

...

Quoted 4 lines

Please comment on these patches, and test if you have a docking station available. When you find problems, if you would like me to debug them, please load the acpiphp driver with the debug param (modprobe acpiphp debug=1),

I'll try to test them and write some small docking HOWTO (or maybe force you to write it :-). This is not exactly easy to setup...
Pavel

Signature · 1 line
Thanks, Sharp!
#2 lore raw
In reply to Kristen Accardi

Hi!

Quoted 6 lines

This series of patches is against the -mm kernel, and will enable docking station support. It is an early patch, but still pretty functional, so I think it's worthwhile to include at this point. For some laptops, it's necessary to use the pci=assign-busses kernel parameter, because some _DCK methods will attempt to assign bus numbers to the dock bridge (incorrectly).

On thinkpad X32: I selected

CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_HOTPLUG_PCI_ACPI=y
# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_ACPI_IBM=y

Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is empty. I then inserted machine into dock, and locked it:

root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
root@amd:/sys/bus/pci/slots# ls
root@amd:/sys/bus/pci/slots#

...still empty. What am I doing wrong?
Pavel

Signature · 1 line
Thanks, Sharp!
#3 lore raw
Quoted 24 lines · Pavel Machek

Hi!

Quoted 6 lines

This series of patches is against the -mm kernel, and will enable docking station support. It is an early patch, but still pretty functional, so I think it's worthwhile to include at this point. For some laptops, it's necessary to use the pci=assign-busses kernel parameter, because some _DCK methods will attempt to assign bus numbers to the dock bridge (incorrectly).

On thinkpad X32: I selected

CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_HOTPLUG_PCI_ACPI=y
# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_ACPI_IBM=y

Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is empty. I then inserted machine into dock, and locked it:

Quoted 6 lines
root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
root@amd:/sys/bus/pci/slots# ls
root@amd:/sys/bus/pci/slots#

...still empty. What am I doing wrong?
Pavel

You may not use the ibm_acpi driver at the same time as the acpiphp driver for docking. This is because the ibm_acpi driver also tries to handle the dock event notification, and doesn't actually do any hotplugging of the devices. So, you want to set that config option to N. What you are doing above is actually writing to the ibm_acpi driver. I didn't provide a way to do undocking via software. I just use the button on the dock station. You should however, see something in /sys/bus/pci/slots - can you scan your dmesg to make sure that the acpiphp driver is running? You might run it as a module and enable debugging:

modprobe acpiphp debug=1

This way we can see if it finds your dock slot and registers the notify handler.

Thanks for testing!

Kristen

#4 lore raw

Hi!

There's a bug in error handling:

int __init acpiphp_glue_init(void)
{
int num = 0;

acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_root_bridges, &num,
NULL);

        if (num <= 0)
                return -1;
        else
                acpi_pci_register_driver(&acpi_pci_hp_driver);

        return 0;
}

You register driver here, but if acpiphp_get_num_slots() returns 0 later, you return -ENODEV, aborting load of driver, but without undergistering that driver. It oopses after a while. Same problem if init_slots() returns error.

Pavel

Signature · 1 line
Thanks, Sharp!
#5 lore raw
Quoted 20 lines · Pavel Machek

Hi!

There's a bug in error handling:

int __init acpiphp_glue_init(void)
{
int num = 0;

acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_root_bridges, &num,
NULL);

        if (num <= 0)
                return -1;
        else
                acpi_pci_register_driver(&acpi_pci_hp_driver);

        return 0;
}
Quoted 6 lines

You register driver here, but if acpiphp_get_num_slots() returns 0 later, you return -ENODEV, aborting load of driver, but without undergistering that driver. It oopses after a while. Same problem if init_slots() returns error.

Pavel

This one needs some more thought on how to fix, because I'm not certain if we have the code in place to back out of this once we find root bridges that exist. it might be easy, but it might not be.

#6 lore raw
In reply to Kristen Accardi

Hi!

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines

This series of patches is against the -mm kernel, and will enable docking station support. It is an early patch, but still pretty functional, so I think it's worthwhile to include at this point. For some laptops, it's necessary to use the pci=assign-busses kernel parameter, because some _DCK methods will attempt to assign bus numbers to the dock bridge (incorrectly).

On thinkpad X32: I selected

...

Quoted 7 lines
Quoted 7 lines

Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is empty. I then inserted machine into dock, and locked it:

root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
root@amd:/sys/bus/pci/slots# ls
root@amd:/sys/bus/pci/slots#
Quoted 8 lines
Quoted 1 line

...still empty. What am I doing wrong?

You may not use the ibm_acpi driver at the same time as the acpiphp driver for docking. This is because the ibm_acpi driver also tries to handle the dock event notification, and doesn't actually do any hotplugging of the devices. So, you want to set that config option to N. What you are doing above is actually writing to the ibm_acpi driver.

Done.

Quoted 10 lines

I didn't provide a way to do undocking via software. I just use the button on the dock station. You should however, see something in /sys/bus/pci/slots - can you scan your dmesg to make sure that the acpiphp driver is running? You might run it as a module and enable debugging:

modprobe acpiphp debug=1

This way we can see if it finds your dock slot and registers the notify handler.

Result is:

root@amd:/data/l/linux-mm/drivers/pci/hotplug# insmod acpiphp.ko debug=1
insmod: error inserting 'acpiphp.ko': -1 No such device
root@amd:/data/l/linux-mm/drivers/pci/hotplug# dmesg | tail -3
Failure of coda_cnode_make for root: error -19
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_glue: Total 0 slots
root@amd:/data/l/linux-mm/drivers/pci/hotplug#

Should I have CONFIG_HOTPLUG_PCI_ACPI_IBM set?

Pavel

Signature · 1 line
Thanks, Sharp!
#7 lore raw
Quoted 50 lines · Pavel Machek

Hi!

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines

This series of patches is against the -mm kernel, and will enable docking station support. It is an early patch, but still pretty functional, so I think it's worthwhile to include at this point. For some laptops, it's necessary to use the pci=assign-busses kernel parameter, because some _DCK methods will attempt to assign bus numbers to the dock bridge (incorrectly).

On thinkpad X32: I selected

...

Quoted 7 lines
Quoted 7 lines

Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is empty. I then inserted machine into dock, and locked it:

root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
root@amd:/sys/bus/pci/slots# ls
root@amd:/sys/bus/pci/slots#
Quoted 8 lines
Quoted 1 line

...still empty. What am I doing wrong?

You may not use the ibm_acpi driver at the same time as the acpiphp driver for docking. This is because the ibm_acpi driver also tries to handle the dock event notification, and doesn't actually do any hotplugging of the devices. So, you want to set that config option to N. What you are doing above is actually writing to the ibm_acpi driver.

Done.

Quoted 10 lines

I didn't provide a way to do undocking via software. I just use the button on the dock station. You should however, see something in /sys/bus/pci/slots - can you scan your dmesg to make sure that the acpiphp driver is running? You might run it as a module and enable debugging:

modprobe acpiphp debug=1

This way we can see if it finds your dock slot and registers the notify handler.

Result is:

root@amd:/data/l/linux-mm/drivers/pci/hotplug# insmod acpiphp.ko debug=1
insmod: error inserting 'acpiphp.ko': -1 No such device
root@amd:/data/l/linux-mm/drivers/pci/hotplug# dmesg | tail -3
Failure of coda_cnode_make for root: error -19
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_glue: Total 0 slots
root@amd:/data/l/linux-mm/drivers/pci/hotplug#
Quoted 4 lines

Should I have CONFIG_HOTPLUG_PCI_ACPI_IBM set?

Pavel

Hum, I don't think so (but maybe someone else knows for sure), I thought that driver was specifically for a certain kind of IBM server, not an IBM laptop. It looks like from this output that the acpiphp is not recognizing any hotplug capable devices on your laptop. I believe that this is defined by acpiphp as a slot which is "ejectable", meaning contains an ACPI method called _EJ0. I think we should take a look at your dsdt to make sure that it seems reasonable, and also perhaps you could send the output of lspci -vv -x with the laptop booted in the dock just to see what kind of dock bridge you have and make sure everything seems like it should work. Please send the disassembled output of your dsdt - if you've never done it before, instructions for doing this can be found here:
http://acpi.sourceforge.net/dsdt/index.php

thanks!
Kristen

#8 lore raw
Quoted 6 lines · Kristen Accardi

Hum, I don't think so (but maybe someone else knows for sure), I thought that driver was specifically for a certain kind of IBM server, not an IBM laptop. It looks like from this output that the acpiphp is not recognizing any hotplug capable devices on your laptop. I believe that this is defined by acpiphp as a slot which is "ejectable", meaning contains an ACPI method called _EJ0.

To the best of my knowledge, the X-series docking station doesn't contain any PCI devices. It's an extension of the IDE bus plus some broken out serial, parallel, USB and so on. I'd expect driver support for it to just require supporting the dock object and calling its eject routine when the user hits the eject button.

Signature · 1 line
Matthew Garrett | [email protected]
#9 lore raw
Quoted 9 lines · Matthew Garrett
Quoted 6 lines · Kristen Accardi

Hum, I don't think so (but maybe someone else knows for sure), I thought that driver was specifically for a certain kind of IBM server, not an IBM laptop. It looks like from this output that the acpiphp is not recognizing any hotplug capable devices on your laptop. I believe that this is defined by acpiphp as a slot which is "ejectable", meaning contains an ACPI method called _EJ0.

Quoted 5 lines

To the best of my knowledge, the X-series docking station doesn't contain any PCI devices. It's an extension of the IDE bus plus some broken out serial, parallel, USB and so on. I'd expect driver support for it to just require supporting the dock object and calling its eject routine when the user hits the eject button.

My docking station (there are two different versions of them, "regular" and "port extender") certainly contains PCI device. I installed hp100 network card into it :-).

Pavel

Signature · 1 line
Thanks, Sharp!
#10 lore raw
In reply to Kristen Accardi

Hi!

Quoted 5 lines

Hum, I don't think so (but maybe someone else knows for sure), I thought that driver was specifically for a certain kind of IBM server, not an IBM laptop. It looks like from this output that the acpiphp is not recognizing any hotplug capable devices on your laptop. I believe that this is defined by acpiphp as a slot which is "ejectable", meaning

Quoted 8 lines

contains an ACPI method called _EJ0. I think we should take a look at your dsdt to make sure that it seems reasonable, and also perhaps you could send the output of lspci -vv -x with the laptop booted in the dock just to see what kind of dock bridge you have and make sure everything seems like it should work. Please send the disassembled output of your dsdt - if you've never done it before, instructions for doing this can be found here:
http://acpi.sourceforge.net/dsdt/index.php

I sent verbose lspci and acpidump via private email. Regular lspci looks like: (booted in dock but now undocked, sorry).

pavel@amd:~$ lspci
0000:00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
0000:00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
0000:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
0000:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
0000:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
0000:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
0000:00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
0000:00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
0000:00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY
0000:02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
0000:02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
0000:02:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02)
0000:02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev
03)
0000:02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
0000:02:03.0 ffff: Texas Instruments PCI2032 PCI Docking Bridge (rev ff)
0000:09:00.0 ffff: Hewlett-Packard Company J2585B HP 10/100VG PCI LAN Adapter (rev ff)
0000:09:01.0 ffff: Silicon Image, Inc. PCI0648 (rev ff)
0000:09:02.0 ffff: Texas Instruments PCI1420 (rev ff)
0000:09:02.1 ffff: Texas Instruments PCI1420 (rev ff)

The ffff: lines are probably what is contained inside the dock.

Device GDCK looks like dock to my untrained eye. Unfortunately its type is IBM0079... ...

Ahha, and ibm_acpi.c agrees with me.

IBM_HANDLE(dock, root, "\\_SB.GDCK", /* X30, X31, X40 */

        Scope (\_SB)
        {
            Device (GDCK)
            {
                Name (_HID, EisaId ("IBM0079"))
                Name (_CID, 0x150CD041)
                Method (_STA, 0, NotSerialized)
                {
...
                Method (_DCK, 1, NotSerialized)
                {
                    Store (0x00, Local0)
                    If (LEqual (GGID (), 0x03))
                    {
                        Store (\_SB.PCI0.LPC.EC.SDCK (Arg0), Local0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        Store (\_SB.PCI0.PCI1.DOCK.DDCK (Arg0), Local0)
                    }

                    Return (Local0)
                }

                Method (_EJ0, 1, NotSerialized)
                {
                    If (LEqual (GGID (), 0x03))
                    {
                        \_SB.PCI0.LPC.EC.SEJ0 (Arg0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        \_SB.PCI0.PCI1.DOCK.DEJ0 (Arg0)
                    }
                }

....

Hope this helps.
Pavel

Signature · 1 line
Thanks, Sharp!
#11 lore raw

On Wed, 2006-01-18 at 23:23 +0100, Pavel Machek wrote:
<snip>

Quoted 44 lines

Device GDCK looks like dock to my untrained eye. Unfortunately its type is IBM0079... ...

Ahha, and ibm_acpi.c agrees with me.

IBM_HANDLE(dock, root, "\\_SB.GDCK", /* X30, X31, X40 */

        Scope (\_SB)
        {
            Device (GDCK)
            {
                Name (_HID, EisaId ("IBM0079"))
                Name (_CID, 0x150CD041)
                Method (_STA, 0, NotSerialized)
                {
...
                Method (_DCK, 1, NotSerialized)
                {
                    Store (0x00, Local0)
                    If (LEqual (GGID (), 0x03))
                    {
                        Store (\_SB.PCI0.LPC.EC.SDCK (Arg0), Local0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        Store (\_SB.PCI0.PCI1.DOCK.DDCK (Arg0), Local0)
                    }

                    Return (Local0)
                }

                Method (_EJ0, 1, NotSerialized)
                {
                    If (LEqual (GGID (), 0x03))
                    {
                        \_SB.PCI0.LPC.EC.SEJ0 (Arg0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        \_SB.PCI0.PCI1.DOCK.DEJ0 (Arg0)
                    }
                }
Quoted 4 lines

....

Hope this helps.
Pavel

so the problem that I see is that this dsdt defines two separate dock devices, one outside the scope of pci, and one within it. The one outside the scope of pci defines the _EJ0 and _DCK methods. So, when acpiphp loads, it scans the pci slots for ejectable slots, finds none (because _EJ0 is defined in the dock device that is outside the scope of pci) and exits. This dsdt is different from the others I've used in that most of them define all methods related to docking under the actual dock bridge (within the scope of pci). perhaps some acpi people can shed some light on the best way to handle this - otherwise I'm sure I can hack something up that will be less than acceptable :).

#12 lore raw
Quoted 52 lines · Kristen Accardi

On Wed, 2006-01-18 at 23:23 +0100, Pavel Machek wrote:
<snip>

Quoted 44 lines

Device GDCK looks like dock to my untrained eye. Unfortunately its type is IBM0079... ...

Ahha, and ibm_acpi.c agrees with me.

IBM_HANDLE(dock, root, "\\_SB.GDCK", /* X30, X31, X40 */

        Scope (\_SB)
        {
            Device (GDCK)
            {
                Name (_HID, EisaId ("IBM0079"))
                Name (_CID, 0x150CD041)
                Method (_STA, 0, NotSerialized)
                {
...
                Method (_DCK, 1, NotSerialized)
                {
                    Store (0x00, Local0)
                    If (LEqual (GGID (), 0x03))
                    {
                        Store (\_SB.PCI0.LPC.EC.SDCK (Arg0), Local0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        Store (\_SB.PCI0.PCI1.DOCK.DDCK (Arg0), Local0)
                    }

                    Return (Local0)
                }

                Method (_EJ0, 1, NotSerialized)
                {
                    If (LEqual (GGID (), 0x03))
                    {
                        \_SB.PCI0.LPC.EC.SEJ0 (Arg0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        \_SB.PCI0.PCI1.DOCK.DEJ0 (Arg0)
                    }
                }
Quoted 4 lines

....

Hope this helps.
Pavel

Quoted 11 lines

so the problem that I see is that this dsdt defines two separate dock devices, one outside the scope of pci, and one within it. The one outside the scope of pci defines the _EJ0 and _DCK methods. So, when acpiphp loads, it scans the pci slots for ejectable slots, finds none (because _EJ0 is defined in the dock device that is outside the scope of pci) and exits. This dsdt is different from the others I've used in that most of them define all methods related to docking under the actual dock bridge (within the scope of pci). perhaps some acpi people can shed some light on the best way to handle this - otherwise I'm sure I can hack something up that will be less than acceptable :).

ACPI has (had?) a braindamage - it drops devices that do not present when initially scanning ACPI namespace. So if you boot undocked - too bad. Driver won't ever see your docking station.

--
Dmitry

#13 lore raw

Hi!

Quoted 16 lines
Quoted 4 lines
Quoted 2 lines

Hope this helps.
Pavel

Quoted 11 lines

so the problem that I see is that this dsdt defines two separate dock devices, one outside the scope of pci, and one within it. The one outside the scope of pci defines the _EJ0 and _DCK methods. So, when acpiphp loads, it scans the pci slots for ejectable slots, finds none (because _EJ0 is defined in the dock device that is outside the scope of pci) and exits. This dsdt is different from the others I've used in that most of them define all methods related to docking under the actual dock bridge (within the scope of pci). perhaps some acpi people can shed some light on the best way to handle this - otherwise I'm sure I can hack something up that will be less than acceptable :).

Quoted 3 lines

ACPI has (had?) a braindamage - it drops devices that do not present when initially scanning ACPI namespace. So if you boot undocked - too bad. Driver won't ever see your docking station.

I think I booted docked....

Signature · 1 line
Thanks, Sharp!
#14 lore raw
Quoted 18 lines · Pavel Machek

Hi!

Quoted 16 lines
Quoted 15 lines
Quoted 2 lines

Hope this helps.
Pavel

so the problem that I see is that this dsdt defines two separate dock devices, one outside the scope of pci, and one within it. The one outside the scope of pci defines the _EJ0 and _DCK methods. So, when acpiphp loads, it scans the pci slots for ejectable slots, finds none (because _EJ0 is defined in the dock device that is outside the scope of pci) and exits. This dsdt is different from the others I've used in that most of them define all methods related to docking under the actual dock bridge (within the scope of pci). perhaps some acpi people can shed some light on the best way to handle this - otherwise I'm sure I can hack something up that will be less than acceptable :).

Quoted 6 lines
Quoted 3 lines

ACPI has (had?) a braindamage - it drops devices that do not present when initially scanning ACPI namespace. So if you boot undocked - too bad. Driver won't ever see your docking station.

I think I booted docked....

Yeah, that's not the problem here. The problem is that I assumed that all _DCK methods would be defined under the actual pci dock bridge device. It seems that was a bad assumption. I am redoing this patch so as to not assume that anymore. I'll repost it as soon as I'm done with a little bit of testing.

#15 lore raw
In reply to Kristen Accardi

Few cleanups for acpiphp_glue, and spelling fix in warning. It still does not use consistent function definitions, but lets pretentd it is to fit into 80 columns.

drivers/pci/hotplug/acpiphp_glue.c +10 -13
@@ -91,14 +94,12 @@
 	acpi_handle tmp;
 
 	status = acpi_get_handle(handle, "_ADR", &tmp);
-	if (ACPI_FAILURE(status)) {
+	if (ACPI_FAILURE(status))
 		return 0;
-	}
 
 	status = acpi_get_handle(handle, "_EJ0", &tmp);
-	if (ACPI_FAILURE(status)) {
+	if (ACPI_FAILURE(status))
 		return 0;
-	}
 
 	return 1;
 }
@@ -470,7 +473,7 @@
 			dbg("%s: _STA evaluation failure\n", __FUNCTION__);
 			return 0;
 		}
-		if ((tmp & ACPI_STA_FUNCTIONING) == 0)
+		if (!(tmp & ACPI_STA_FUNCTIONING))
 			/* don't register this object */
 			return 0;
 	}
@@ -503,12 +508,12 @@
 		return 0;
 	}
 
 	/* search P2P bridges under this host bridge */
 	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
 				     find_p2p_bridge, pci_bus, NULL);
 
 	if (ACPI_FAILURE(status))
-		warn("find_p2p_bridge faied (error code = 0x%x)\n",status);
+		warn("find_p2p_bridge failed (error code = 0x%x)\n", status);
 
 	return 0;
 }
@@ -587,7 +593,7 @@
 	}
 }
 
-static struct pci_dev * get_apic_pci_info(acpi_handle handle)
+static struct pci_dev *get_apic_pci_info(acpi_handle handle)
 {
 	struct acpi_pci_id id;
 	struct pci_bus *bus;
@@ -891,8 +897,8 @@
  * this slot and return the one that represents the given
  * pci_dev structure.
  */
-static struct acpiphp_func * get_func(struct acpiphp_slot *slot,
-					struct pci_dev *dev)
+static struct
+acpiphp_func *get_func(struct acpiphp_slot *slot, struct pci_dev *dev)
 {
 	struct list_head *l;
 	struct acpiphp_func *func;
@@ -912,8 +918,7 @@
 /** acpiphp_max_busnr - find the max reserved busnr for this bus
  *  @bus: the bus to scan
  */
-static unsigned char
-acpiphp_max_busnr(struct pci_bus *bus)
+static unsigned char acpiphp_max_busnr(struct pci_bus *bus)
 {
 	struct list_head *tmp;
 	unsigned char max, n;
@@ -1476,9 +1481,9 @@
 	if (is_root_bridge(handle)) {
 		acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
 				handle_hotplug_event_bridge, NULL);
-			(*count)++;
+		(*count)++;
 	}
-	return AE_OK ;
+	return AE_OK;
 }
 
 static struct acpi_pci_driver acpi_pci_hp_driver = {
Signature · 1 line
Thanks, Sharp!