Benjamin Herrenschmidt wrote:
quoted text
> On Mon, 2007-09-17 at 14:22 +0400, Ivan Kokshaysky wrote:
>> On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote:
>>> Agreed. I have a similar problem on ppc where it's common to have things
>>> like the main PIC on a PCI device. Note that another problem is (or at
>>> least was, i haven't checked recently) the P2P bridge scanning code
>>> that, in a similar way, can block the path to all devices below it. I
>>> -do- have a case for example with Apple Xserve G4's where the main Apple
>>> IO ASIC, which is a PCI device containing the PIC, the power management
>>> controller, and various low level system control IOs is behind a pair of
>>> P2P bridges.
>> I think the P2P probing code is pretty safe now - there are read-only
>> accesses to the bridge config, unless you request to reassign the bus
>> numbers. Though it won't be safe anymore with the patch in question.
> 
> In which case I will need to NAK the patch... Note that those Xserve
> G4's still have the subtle issue that they -also- reassign bus
> numbers :-) But that's going away the day I finally enable domains
> support for ppc32 (it's been off for now due to problems with X)

How is this a change in behavior as far as this device is concerned? If 
we are doing BAR sizing and moving the base address around, it's going 
to cause problems if you try to access the device during this time 
whether we disable decode or not.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/