Felix Radensky wrote:
Hello, Kenji-san
I think the device is expected to be ready to work if pci_enable_device()
returns without error. So I think pci_enable_device() should return an
error if it fails to enable the device (device is not ready to work). In
this case, detecting your bridge's failure seems PPC specific to me. So I
thought pcibios_enable_device() was the right to return an error. If
pcibios_enable_device() returned an error, pci_dev->enable_cnt would
decremented by pci_enable_device() (like pci_disable_device() does) and
this problem would not happen.
As far as I can see on 460EX pcibios_enable_device() just calls
pci_enable_resources()
which does not return any error for my bridge, although it doesn't find
any memory or
I/O resource it can enable. Do you think it is correct behavior ?
Another question is whether by bridge behaves correctly when no device
is connected
to it. As you can see in dmesg output I've sent earlier
pci 0000:00:02.0: bridge window [mem 0x00000000-0x000fffff]
pci 0000:00:02.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
and later PCI code disables these memory windows
pci 0000:00:02.0: disabling bridge window [mem 0xd00000000-0xd000fffff
pref] to [bus 01-01] (unused)
pci 0000:00:02.0: disabling bridge window [mem 0xd00000000-0xd000fffff]
to [bus 01-01] (unused)
I misunderstood the problem.
My understanding was memory resource was not enabled even though Linux set
the Memory Space bit in the command register. But it was not correct. The
bridge memory window was marked unused and Linux didn't try to set Memory
Space bit in the command register. Current my understanding is as follows.
Please correct me if I'm still misunderstanding something.
1) Your BIOS doesn't assign any resource to the bridge if its child PCI
hot-plug slot is not occupied.
2) At the boot time, pci_assign_unassigned_resources() try to assign
memory resouces to the bridge using pci_bus_assign_resource(), but
it was disabled because there are no devices require memory resource.
3) And then pci_assign_unassigned_resouces() calls pci_enable_bridge(),
but Memory Space bit in the command register was not set because no
memory resource are assigned to the bridge. At the same time,
pci_dev->enable_cnt was incremented.
4) At the rescan time, pci_setup_bridge() and pci_enable_bridge() doesn't
work because the bridge is already marked "enabled" (i.e.
pci_dev->enable_cnt is not zero).
I don't have any concrete idea how to fix that so far, but I can say my idea
(pcibios_enable_device() should return an error) was wrong.
BTW, on my PCI hotplug capable system (SHPC and PCIe), I/O and Memory windows
of the bridge are assigned by BIOS regardless of whether hotplug slot(s)
behind the bridge is occupied or not. Maybe that is the reason why I have
never encountered this problem before.
Thanks,
Kenji Kaneshige
BTW, there's no problem accessing PCI_COMMAND register, as bus mastering
is enabled in the bridge.
On the other hand, as Ben suggested, handling this by specific hot-plug
driver would be one of the other candidate to fix the problem.
I'm not opposed to this idea, it's just that this bridge worked in an older
system based on linux-2.6.22 and patched fakephp driver was used for
hotplug.
There's existing userspace software that I don't really want to modify
heavily.
But I'll do that if generic PCI rescan cannot be fixed.
Thanks a lot for your help.
Felix.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
