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)

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.