Problem with PCI bus rescan on 460EX

[Felix Radensky]

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.