Skip to contentSkip to conversation

pci: return max reserved busnr

PATCH In review Kristen Accardi 6 participants 15 messages Jan 18, 2006 – Jan 23, 2006 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 20060116200218.275371000@whizzy

#1 lore raw

PATCH 1/4 pci: return max reserved busnr

Change the semantics of this call to return the max reserved bus number instead of just the max assigned bus number.

 drivers/pci/pci.c   |    5 +++--
 include/linux/pci.h |    1 +
 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/pci/pci.c +3 -2
@@ -19,7 +19,6 @@
 #include <asm/dma.h>	/* isa_dma_bridge_buggy */
 #include "pci.h"
 
-#if 0
 
 /**
  * pci_bus_max_busnr - returns maximum PCI bus number of given bus' children
@@ -34,7 +33,7 @@ pci_bus_max_busnr(struct pci_bus* bus)
 	struct list_head *tmp;
 	unsigned char max, n;
 
-	max = bus->number;
+	max = bus->subordinate;
 	list_for_each(tmp, &bus->children) {
 		n = pci_bus_max_busnr(pci_bus_b(tmp));
 		if(n > max)
@@ -42,7 +41,9 @@ pci_bus_max_busnr(struct pci_bus* bus)
 	}
 	return max;
 }
+EXPORT_SYMBOL_GPL(pci_bus_max_busnr);
 
+#if 0
 /**
  * pci_max_busnr - returns maximum PCI bus number
  *
include/linux/pci.h +1 -0
@@ -514,6 +514,7 @@ int pci_scan_bridge(struct pci_bus *bus,
 void pci_walk_bus(struct pci_bus *top, void (*cb)(struct pci_dev *, void *),
 		  void *userdata);
 int pci_cfg_space_size(struct pci_dev *dev);
+unsigned char pci_bus_max_busnr(struct pci_bus* bus);
 
 /* kmem_cache style wrapper around pci_alloc_consistent() */
 
#2 lore raw

PATCH 2/4 acpiphp: handle dock bridges

In reply to a message not in the archive

This patch will modify the acpiphp driver to handle docking and undocking events and hot adding of the PCI devices on the dock station. It currently has a workaround for a problem with acpi where the
acpi threads will deadlock and never return from executing the _DCK method. As a workaround, I spawn a separate thread to do the dock. In addition, I've found that some _DCK methods do some bad things, so have implemented a fixups section for after docking that will no doubt grow as more laptops get tested. This patch CONFLICTS with some acpi plugins that try to do their own docking support (such as ibm_acpi), so you cannot use this driver and the conflicting driver simultaneously.

 drivers/pci/hotplug/acpiphp.h      |    2 
 drivers/pci/hotplug/acpiphp_glue.c |  207 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 204 insertions(+), 5 deletions(-)
drivers/pci/hotplug/acpiphp.h +2 -0
@@ -189,6 +189,7 @@ struct acpiphp_attention_info
 #define SLOT_POWEREDON		(0x00000001)
 #define SLOT_ENABLED		(0x00000002)
 #define SLOT_MULTIFUNCTION	(0x00000004)
+#define SLOT_DOCKING		(0x00000008)
 
 /* function flags */
 
@@ -198,6 +199,7 @@ struct acpiphp_attention_info
 #define FUNC_HAS_PS1		(0x00000020)
 #define FUNC_HAS_PS2		(0x00000040)
 #define FUNC_HAS_PS3		(0x00000080)
+#define FUNC_HAS_DCK		(0x00000100)
 
 /* function prototypes */
 
drivers/pci/hotplug/acpiphp_glue.c +202 -5

272 lines not on this page · raw message

#3 lore raw

Re: [Pcihpd-discuss] [patch 2/4] acpiphp: handle dock bridges

Hi,

drivers/pci/hotplug/acpiphp_glue.c static int power_off_slot(struct acpiphp · line 906

Quoted 13 lines
drivers/pci/hotplug/acpiphp_glue.c +13 -0
+static struct acpiphp_func * get_func(struct acpiphp_slot *slot,
+					struct pci_dev *dev)
+{
+	struct list_head *l;
+	struct acpiphp_func *func;
+	struct pci_bus *bus = slot->bridge->pci_bus;
+
+	list_for_each (l, &slot->funcs) {
+		func = list_entry(l, struct acpiphp_func, sibling);
+		if (pci_get_slot(bus, PCI_DEVFN(slot->device,
+					func->function)) == dev)
+			return func;
+	}

This seems to leak reference counter of pci_dev. I think you must call pci_dev_put() also.

Thanks,
Kenji Kaneshige

#4 lore raw

Re: [Pcihpd-discuss] [patch 2/4] acpiphp: handle dock bridges

Quoted 18 lines · Kenji Kaneshige

Hi,

drivers/pci/hotplug/acpiphp_glue.c static int power_off_slot(struct acpiphp · line 906

Quoted 13 lines
drivers/pci/hotplug/acpiphp_glue.c +13 -0
+static struct acpiphp_func * get_func(struct acpiphp_slot *slot,
+					struct pci_dev *dev)
+{
+	struct list_head *l;
+	struct acpiphp_func *func;
+	struct pci_bus *bus = slot->bridge->pci_bus;
+
+	list_for_each (l, &slot->funcs) {
+		func = list_entry(l, struct acpiphp_func, sibling);
+		if (pci_get_slot(bus, PCI_DEVFN(slot->device,
+					func->function)) == dev)
+			return func;
+	}

This seems to leak reference counter of pci_dev. I think you must call pci_dev_put() also.

Yes, good catch.

thanks,

greg k-h

#5 lore raw

Re: [patch 2/4] acpiphp: handle dock bridges

In reply to Kristen Accardi

drivers/pci/hotplug/acpiphp_glue.c static int acpiphp_configure_ioapics(acp · line 782

Quoted 4 lines · Kristen Accardi
drivers/pci/hotplug/acpiphp_glue.c +4 -0
+
+	down(&slot->crit_sect);
+	list_for_each(l, &slot->funcs) {
+		func = list_entry(l, struct acpiphp_func, sibling);

list_for_each_entry() maybe?

drivers/pci/hotplug/acpiphp_glue.c static int power_off_slot(struct acpiphp · line 902

Quoted 9 lines
drivers/pci/hotplug/acpiphp_glue.c +9 -0
+static struct acpiphp_func * get_func(struct acpiphp_slot *slot,
+					struct pci_dev *dev)
+{
+	struct list_head *l;
+	struct acpiphp_func *func;
+	struct pci_bus *bus = slot->bridge->pci_bus;
+
+	list_for_each (l, &slot->funcs) {
+		func = list_entry(l, struct acpiphp_func, sibling);

And here?

Signature · 1 line
Dmitry
#6 lore raw

Re: [Pcihpd-discuss] [patch 2/4] acpiphp: handle dock bridges

In reply to Kristen Accardi
Quoted 11 lines · Kristen Accardi
drivers/pci/hotplug/acpiphp_glue.c +11 -0
+static acpi_status handle_dock(struct acpiphp_func *func, int dock)
+{
+	acpi_status status;
+	struct acpi_object_list arg_list;
+	union acpi_object arg;
+	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+
+	dbg("%s: enter\n", __FUNCTION__);
+
+	/* _DCK method has one argument */
+	arg_list.count = 1;

drivers/pci/hotplug/acpiphp_glue.c is_ejectable_slot(acpi_handle handle, u3 · line 143

Quoted 10 lines
drivers/pci/hotplug/acpiphp_glue.c +10 -0
+	arg_list.pointer = &arg;
+	arg.type = ACPI_TYPE_INTEGER;
+	arg.integer.value = dock;
+	status = acpi_evaluate_object(func->handle, "_DCK",
+					&arg_list, &buffer);
+	if (ACPI_FAILURE(status))
+		err("%s: failed to dock!!\n", MY_NAME);
+
+	return status;
+}

I think you need to add acpi_os_free() for freeing buffer.pointer.

Thanks,
Kenji Kaneshige

#7 lore raw

Re: [Pcihpd-discuss] [patch 2/4] acpiphp: handle dock bridges

In reply to Kristen Accardi

Hi,

At Tue, 17 Jan 2006 16:56:59 -0800,

Quoted 2 lines · Kristen Accardi
(quoted diff) +0 -0
@@ -681,6 +713,88 @@ static int acpiphp_configure_ioapics(acp

(snip)

Quoted 19 lines
drivers/pci/hotplug/acpiphp_glue.c +19 -0
+static int acpiphp_bus_add(struct acpiphp_func *func)
+{
+	acpi_handle phandle;
+	struct acpi_device *device, *pdevice;
+	int ret_val;
+
+	acpi_get_parent(func->handle, &phandle);
+	if (acpi_bus_get_device(phandle, &pdevice)) {
+		dbg("no parent device, assuming NULL\n");
+		pdevice = NULL;
+	}
+	ret_val = acpi_bus_add(&device, pdevice, func->handle,
+			ACPI_BUS_TYPE_DEVICE);
+	if (ret_val)
+		dbg("cannot add bridge to acpi list\n");
+
+	/*
+	 * try to start anyway.  We could have failed to add
+	 * simply because this bus had previously been added

drivers/pci/hotplug/acpiphp_glue.c static int acpiphp_configure_ioapics(acp · line 773

Quoted 10 lines
drivers/pci/hotplug/acpiphp_glue.c +10 -0
+	 * on another dock.  Don't bother with the return value
+	 * we just keep going.
+	 */
+	ret_val = acpi_bus_start(device);
+
+	return ret_val;
+}
+
+
+

When the device is docked, acpi_bus_add() is called to register the device into acpi list. But if the device is undocked, acpi_bus_trim() doesn't called.
Can you hot-add/remove the dock station repeatedly?

Thanks,
MUNE

Signature · 1 line
MUNEDA Takahiro <[email protected]>
#8 lore raw

Re: [Pcihpd-discuss] [patch 2/4] acpiphp: handle dock bridges

Quoted 42 lines · MUNEDA Takahiro

Hi,

At Tue, 17 Jan 2006 16:56:59 -0800,

Quoted 2 lines · Kristen Accardi
(quoted diff) +0 -0
@@ -681,6 +713,88 @@ static int acpiphp_configure_ioapics(acp

(snip)

Quoted 19 lines
drivers/pci/hotplug/acpiphp_glue.c +19 -0
+static int acpiphp_bus_add(struct acpiphp_func *func)
+{
+	acpi_handle phandle;
+	struct acpi_device *device, *pdevice;
+	int ret_val;
+
+	acpi_get_parent(func->handle, &phandle);
+	if (acpi_bus_get_device(phandle, &pdevice)) {
+		dbg("no parent device, assuming NULL\n");
+		pdevice = NULL;
+	}
+	ret_val = acpi_bus_add(&device, pdevice, func->handle,
+			ACPI_BUS_TYPE_DEVICE);
+	if (ret_val)
+		dbg("cannot add bridge to acpi list\n");
+
+	/*
+	 * try to start anyway.  We could have failed to add
+	 * simply because this bus had previously been added

drivers/pci/hotplug/acpiphp_glue.c static int acpiphp_configure_ioapics(acp · line 773

Quoted 10 lines
drivers/pci/hotplug/acpiphp_glue.c +10 -0
+	 * on another dock.  Don't bother with the return value
+	 * we just keep going.
+	 */
+	ret_val = acpi_bus_start(device);
+
+	return ret_val;
+}
+
+
+

When the device is docked, acpi_bus_add() is called to register the device into acpi list. But if the device is undocked, acpi_bus_trim() doesn't called.
Can you hot-add/remove the dock station repeatedly?

Quoted 3 lines

Thanks,
MUNE

Yes you can. The reason for this is because even if we fail the call to acpi_bus_add(), we ignore the return value and call acpi_bus_start() anyway.

#9 lore raw

PATCH 1/1 acpiphp: treat dck separate from dock bridge

In reply to Kristen Accardi

Here's an addition to the acpiphp dock station patch for interested people to try. It has a problem that I've not solved yet that will cause the driver to oops if you boot your laptop docked, then load the driver, then try to undock. But, it works for me if you boot undocked, then load the driver, then dock/undock etc. This patch is different from the original in that I no longer assume that _DCK is defined under the actual p2p dock bridge. However, the solution I came up with is not actually very good. I have to somehow find out which device is the actual p2p bridge, and what I try to do here is:
1) find the device that _DCK is defined under
2) if this is a bridged device, we are done (i.e. is has _ADR and is ejectable)
3) if not, then walk the namespace looking for _EJD. If you find one, see if the dependency is on the dock device. The dock bridge should be dependent on the dock device.

- when you find something that is dependent on the dock device, see if it has an _ADR and a _PRT entry. If so, then it is the p2p dock bridge.

So, this is likely a wrong assumption, so I will be thinking some more about how to tell which acpi device is the dock bridge. But meanwhile, this patch could be tested/reviewed to see if it gets us a step further in the right direction.

I patched against 2.6.16-rc1-mm2 because I wasn't sure if it was safe to just drop my other patch (since actually trying to just revert the broken out patch didn't actually work). So this patches the file with my original patch applied.

 drivers/pci/hotplug/acpiphp.h      |   11 +
 drivers/pci/hotplug/acpiphp_glue.c |  354 +++++++++++++++++++++++++++----------
 2 files changed, 272 insertions(+), 93 deletions(-)
drivers/pci/hotplug/acpiphp.h +11 -0
@@ -148,6 +148,17 @@ struct acpiphp_func {
 	u32		flags;		/* see below */
 };
 
+
+struct acpiphp_dock_bridge {
+	acpi_handle dock_bridge_handle;
+	acpi_handle dck_handle;
+	struct acpiphp_func *func;
+	struct acpiphp_slot *slot;
+	u32 last_dock_time;
+	u32 flags;
+};
+
+
 /**
  * struct acpiphp_attention_info - device specific attention registration
  *
drivers/pci/hotplug/acpiphp_glue.c +261 -93

536 lines not on this page · raw message

#10 lore raw

Re: [PATCH] acpiphp: treat dck separate from dock bridge

Hi!

Quoted 25 lines · Kristen Accardi

Here's an addition to the acpiphp dock station patch for interested people to try. It has a problem that I've not solved yet that will cause the driver to oops if you boot your laptop docked, then load the driver, then try to undock. But, it works for me if you boot undocked, then load the driver, then dock/undock etc. This patch is different from the original in that I no longer assume that _DCK is defined under the actual p2p dock bridge. However, the solution I came up with is not actually very good. I have to somehow find out which device is the actual p2p bridge, and what I try to do here is:
1) find the device that _DCK is defined under
2) if this is a bridged device, we are done (i.e. is has _ADR and is ejectable)
3) if not, then walk the namespace looking for _EJD. If you find one, see if the dependency is on the dock device. The dock bridge should be dependent on the dock device.

- when you find something that is dependent on the dock device, see if it has an _ADR and a _PRT entry. If so, then it is the p2p dock bridge.

So, this is likely a wrong assumption, so I will be thinking some more about how to tell which acpi device is the dock bridge. But meanwhile, this patch could be tested/reviewed to see if it gets us a step further in the right direction.

Quoted 4 lines

I patched against 2.6.16-rc1-mm2 because I wasn't sure if it was safe to just drop my other patch (since actually trying to just revert the broken out patch didn't actually work). So this patches the file with my original patch applied.

It oopsed on me while insmoding it: ... will try to investigate.

root@amd:/data/l/linux-mm/drivers/pci/hotplug# insmod acpiphp.ko
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000044
 printing eip:
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_governor
Modules linked in: acpiphp
CPU:    0
EIP:    0060:[<f9990d20>]    Not tainted VLI
EFLAGS: 00010286   (2.6.16-rc1-mm2 #2)
EIP is at acpiphp_get_power_status+0x0/0x10 [acpiphp]
eax: 00000000   ebx: f796bbe0   ecx: f9995384   edx: f7edc2c0
esi: f796bca0   edi: 00000014   ebp: f9992c35   esp: f7b35e14
ds: 007b   es: 007b   ss: 0068
Process insmod (pid: 1520, threadinfo=f7b34000 task=c1f36a50)
Stack: <0>f887e13a f9992e5c f9992c18 00000246 22222222 fffffff4 00000000 f784e000
       f784e4ac f784e4d0 f9995380 c0135636 f99953c8 c05be852 f999538c 00000008
       00000000 f999538c 0000001c 00000018 0000001c 00000018 f998bba8 f998ba90
Call Trace:
 [<f887e13a>] acpiphp_init+0x13a/0x290 [acpiphp]
 [<c0135636>] sys_init_module+0x146/0x1630
 [<c010f1b0>] acpi_register_ioapic+0x0/0x10
 [<c013fd87>] generic_file_aio_read+0x47/0x70
 [<c0168b93>] open_namei+0x83/0x560
 [<c012e930>] autoremove_wake_function+0x0/0x50
 [<c014d544>] do_brk+0x204/0x210
 [<c016f4fa>] dput_recursive+0x2a/0x1d0
 [<c015a891>] __fput+0xe1/0x140
 [<c017304b>] mntput_no_expire+0x1b/0x70
 [<c0102d1d>] syscall_call+0x7/0xb
Code: b9 ff ff ff ff b8 06 00 00 00 89 74 24 08 89 5c 24 04 c7 04 24 f0 0a 99 f9 e8 a6 f0 90 c6 8b 54 24 0c eb 9a 8d b4 26 00 00 00 00 <0f> b6 40 44 83 e0 01 c3 90 8d b4 26 00 00 00 00 e8 fb fc ff ff
 Segmentation fault
root@amd:/data/l/linux-mm/drivers/pci/hotplug#
Signature · 5 lines
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#11 lore raw

Re: [PATCH] acpiphp: treat dck separate from dock bridge

In reply to Kristen Accardi

Hi!

Quoted 9 lines

So, this is likely a wrong assumption, so I will be thinking some more about how to tell which acpi device is the dock bridge. But meanwhile, this patch could be tested/reviewed to see if it gets us a step further in the right direction.

I patched against 2.6.16-rc1-mm2 because I wasn't sure if it was safe to just drop my other patch (since actually trying to just revert the broken out patch didn't actually work). So this patches the file with my original patch applied.

Oops, there were preceding warnings before that oops...:

Pavel

acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_glue: get_slot_from_id: no object for id 0

BUG: warning at drivers/pci/hotplug/acpiphp_glue.c:1757/get_slot_from_id()
 [<f9990ec3>] get_slot_from_id+0x83/0x90 [acpiphp]
 [<f887e12c>] acpiphp_init+0x12c/0x290 [acpiphp]
 [<c0135636>] sys_init_module+0x146/0x1630
 [<c010f1b0>] acpi_register_ioapic+0x0/0x10
 [<c013fd87>] generic_file_aio_read+0x47/0x70
 [<c0168b93>] open_namei+0x83/0x560
 [<c012e930>] autoremove_wake_function+0x0/0x50
 [<c014d544>] do_brk+0x204/0x210
 [<c016f4fa>] dput_recursive+0x2a/0x1d0
 [<c015a891>] __fput+0xe1/0x140
 [<c017304b>] mntput_no_expire+0x1b/0x70
 [<c0102d1d>] syscall_call+0x7/0xb
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000044
 printing eip:
f9990d20
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_governor
Modules linked in: acpiphp
CPU:    0
EIP:    0060:[<f9990d20>]    Not tainted VLI
EFLAGS: 00010286   (2.6.16-rc1-mm2 #2)

EIP is at acpiphp_get_power_status+0x0/0x10 [acpiphp]
eax: 00000000 ebx: f796bbe0 ecx: f9995384 edx: f7edc2c0
esi: f796bca0 edi: 00000014 ebp: f9992c35 esp: f7b35e14
ds: 007b es: 007b ss: 0068
Process insmod (pid: 1520, threadinfo=f7b34000 task=c1f36a50)

Stack: <0>f887e13a f9992e5c f9992c18 00000246 22222222 fffffff4 00000000 f784e000
       f784e4ac f784e4d0 f9995380 c0135636 f99953c8 c05be852 f999538c 00000008
       00000000 f999538c 0000001c 00000018 0000001c 00000018 f998bba8 f998ba90
Call Trace:
 [<f887e13a>] acpiphp_init+0x13a/0x290 [acpiphp]
 [<c0135636>] sys_init_module+0x146/0x1630
 [<c010f1b0>] acpi_register_ioapic+0x0/0x10
 [<c013fd87>] generic_file_aio_read+0x47/0x70
 [<c0168b93>] open_namei+0x83/0x560
 [<c012e930>] autoremove_wake_function+0x0/0x50
 [<c014d544>] do_brk+0x204/0x210
 [<c016f4fa>] dput_recursive+0x2a/0x1d0
 [<c015a891>] __fput+0xe1/0x140
 [<c017304b>] mntput_no_expire+0x1b/0x70
 [<c0102d1d>] syscall_call+0x7/0xb
Signature · 1 line
Thanks, Sharp!
#12 lore raw

Re: [PATCH] acpiphp: treat dck separate from dock bridge

In reply to Kristen Accardi

Hi!

Quoted 8 lines

actual p2p bridge, and what I try to do here is:
1) find the device that _DCK is defined under
2) if this is a bridged device, we are done (i.e. is has _ADR and is ejectable)
3) if not, then walk the namespace looking for _EJD. If you find one, see if the dependency is on the dock device. The dock bridge should be dependent on the dock device.

Quoted 8 lines

- when you find something that is dependent on the dock device, see if it has an _ADR and a _PRT entry. If so, then it is the p2p dock bridge.

So, this is likely a wrong assumption, so I will be thinking some more about how to tell which acpi device is the dock bridge. But meanwhile, this patch could be tested/reviewed to see if it gets us a step further in the right direction.

Oopsen seems to be called because add_p2p_bridge is never called. I think it should be called for this device:

0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)

drivers/pci/hotplug/acpiphp_glue.c renamed from /drivers/pci/hotplug/acpiphp_glue.c +7 -1
@@ -454,16 +457,22 @@
 		return AE_OK;
 	}
 
+	printk("ADR ok\n");
+
 	device = (tmp >> 16) & 0xffff;
 	function = tmp & 0xffff;
 
 	dev = pci_get_slot(pci_bus, PCI_DEVFN(device, function));
 
+	printk("device, function = %lx\n", tmp);
+
 	if (!dev || !dev->subordinate)
 		goto out;
 
+	printk("detect slots\n");
+
 	/* check if this bridge has ejectable slots */
-	if (detect_ejectable_slots(handle) > 0) {
+	if ((tmp == 0x1e0000) || (detect_ejectable_slots(handle) > 0)) {
 		dbg("found PCI-to-PCI bridge at PCI %s\n", pci_name(dev));
 		add_p2p_bridge(handle, dev);
 	}

...but then bridge->slots is still empty. I tried forcing is_ejectable(), but then I get:

Jan 21 13:09:52 amd kernel: acpiphp: ACPI Hot Plug PCI Controller
Driver version: 0.5
Jan 21 13:09:53 amd kernel: add_bridge
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1f0000
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 10000
Jan 21 13:09:53 amd kernel: detect slots
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1e0000
Jan 21 13:09:53 amd kernel: detect slots
Jan 21 13:09:53 amd kernel: acpiphp_glue: found PCI-to-PCI bridge at
PCI 0000:00:1e.0
Jan 21 13:09:53 amd kernel: add_p2p_bridge
Jan 21 13:09:53 amd kernel: acpiphp_glue: _HPP evaluation failed
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1f0001
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0000
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0001
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0002
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0007
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1f0006
Jan 21 13:09:53 amd kernel: acpiphp_glue: Bus 0000:02 has 0 slots
Jan 21 13:09:53 amd kernel: acpiphp_glue: Total 0 slots
Jan 21 13:10:05 amd pam_limits[1345]: wrong limit value 'unlimited'

Pavel

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

Re: [PATCH] acpiphp: treat dck separate from dock bridge

On Sat, 2006-01-21 at 13:10 +0100, Pavel Machek wrote:
<snip>

Quoted 76 lines

Oopsen seems to be called because add_p2p_bridge is never called. I think it should be called for this device:

0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)

drivers/pci/hotplug/acpiphp_glue.c renamed from /drivers/pci/hotplug/acpiphp_glue.c +7 -1
@@ -454,16 +457,22 @@
 		return AE_OK;
 	}
 
+	printk("ADR ok\n");
+
 	device = (tmp >> 16) & 0xffff;
 	function = tmp & 0xffff;
 
 	dev = pci_get_slot(pci_bus, PCI_DEVFN(device, function));
 
+	printk("device, function = %lx\n", tmp);
+
 	if (!dev || !dev->subordinate)
 		goto out;
 
+	printk("detect slots\n");
+
 	/* check if this bridge has ejectable slots */
-	if (detect_ejectable_slots(handle) > 0) {
+	if ((tmp == 0x1e0000) || (detect_ejectable_slots(handle) > 0)) {
 		dbg("found PCI-to-PCI bridge at PCI %s\n", pci_name(dev));
 		add_p2p_bridge(handle, dev);
 	}

...but then bridge->slots is still empty. I tried forcing is_ejectable(), but then I get:

Jan 21 13:09:52 amd kernel: acpiphp: ACPI Hot Plug PCI Controller
Driver version: 0.5
Jan 21 13:09:53 amd kernel: add_bridge
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1f0000
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 10000
Jan 21 13:09:53 amd kernel: detect slots
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1e0000
Jan 21 13:09:53 amd kernel: detect slots
Jan 21 13:09:53 amd kernel: acpiphp_glue: found PCI-to-PCI bridge at
PCI 0000:00:1e.0
Jan 21 13:09:53 amd kernel: add_p2p_bridge
Jan 21 13:09:53 amd kernel: acpiphp_glue: _HPP evaluation failed
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1f0001
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0000
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0001
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0002
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1d0007
Jan 21 13:09:53 amd kernel: find_p2p_bridge
Jan 21 13:09:53 amd kernel: ADR ok
Jan 21 13:09:53 amd kernel: device, function = 1f0006
Jan 21 13:09:53 amd kernel: acpiphp_glue: Bus 0000:02 has 0 slots
Jan 21 13:09:53 amd kernel: acpiphp_glue: Total 0 slots
Jan 21 13:10:05 amd pam_limits[1345]: wrong limit value 'unlimited'
Quoted 1 line

Pavel

Well, let's back up a bit. I see a few things wrong. Starting with just the basics, it doesn't seem like we have even found your _DCK method, otherwise find_num_slots should have reported 1. If we had been able to find the dock bridge, then adding the p2p bridge would have worked as well. Let's debug this problem first - Can you please try this patch, making sure to load the module with debugging enabled:

modprobe acpiphp debug=1

and then send me the output of dmesg -s 10000? Thanks for helping me debug, I appreciate it. This patch just adds some extra debugging info to the code path that I would expect to be taken while trying to find your _DCK method. Other than that, it is unchanged.

Kristen

 drivers/pci/hotplug/acpiphp.h      |   11 +
 drivers/pci/hotplug/acpiphp_glue.c |  366 +++++++++++++++++++++++++++----------
 2 files changed, 284 insertions(+), 93 deletions(-)
drivers/pci/hotplug/acpiphp.h +11 -0
@@ -148,6 +148,17 @@ struct acpiphp_func {
 	u32		flags;		/* see below */
 };
 
+
+struct acpiphp_dock_bridge {
+	acpi_handle dock_bridge_handle;
+	acpi_handle dck_handle;
+	struct acpiphp_func *func;
+	struct acpiphp_slot *slot;
+	u32 last_dock_time;
+	u32 flags;
+};
+
+
 /**
  * struct acpiphp_attention_info - device specific attention registration
  *
drivers/pci/hotplug/acpiphp_glue.c +273 -93

548 lines not on this page · raw message

#14 lore raw

PATCH 3/4 pci: really fix parent's subordinate busnr

In reply to a message not in the archive

After you find the maximum value of the subordinate buses below the child bus, you must fix the parent's subordinate bus number again, otherwise it may be too small.

 drivers/pci/probe.c |    5 +++++
 1 files changed, 5 insertions(+)
drivers/pci/probe.c +5 -0
@@ -537,6 +537,11 @@ int __devinit pci_scan_bridge(struct pci
 			pci_fixup_parent_subordinate_busnr(child, max);
 			/* Now we can scan all subordinate buses... */
 			max = pci_scan_child_bus(child);
+			/*
+			 * now fix it up again since we have found
+			 * the real value of max.
+			 */
+			pci_fixup_parent_subordinate_busnr(child, max);
 		} else {
 			/*
 			 * For CardBus bridges, we leave 4 bus numbers
#15 lore raw

PATCH 4/4 pci: quirk for IBM Dock II cardbus controllers

In reply to a message not in the archive

The IBM Dock II cardbus bridges require some extra configuration before Yenta is loaded in order to setup the Interrupts to be routed properly.

 drivers/pci/quirks.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+)
drivers/pci/quirks.c +27 -0
@@ -1242,6 +1242,33 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IN
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_PXHV,	quirk_pcie_pxh);
 
 
+/*
+ * Fixup the cardbus bridges on the IBM Dock II docking station
+ */
+static void __devinit quirk_ibm_dock2_cardbus(struct pci_dev *dev)
+{
+	u32 val;
+
+	/*
+	 * tie the 2 interrupt pins to INTA, and configure the
+	 * multifunction routing register to handle this.
+	 */
+	if ((dev->subsystem_vendor == PCI_VENDOR_ID_IBM) &&
+		(dev->subsystem_device == 0x0148)) {
+		printk(KERN_INFO "PCI: Found IBM Dock II Cardbus Bridge "
+			"applying quirk\n");
+		pci_read_config_dword(dev, 0x8c, &val);
+		val = ((val & 0xffffff00) | 0x1002);
+		pci_write_config_dword(dev, 0x8c, val);
+		pci_read_config_dword(dev, 0x80, &val);
+		val = ((val & 0x00ffff00) | 0x2864c077);
+		pci_write_config_dword(dev, 0x80, val);
+	}
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_1420,
+				quirk_ibm_dock2_cardbus);
+
 static void __devinit quirk_netmos(struct pci_dev *dev)
 {
 	unsigned int num_parallel = (dev->subsystem_device & 0xf0) >> 4;