On Mon, Jun 13, 2011 at 6:38 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 2011-06-13 at 16:34 -0500, Jon Mason wrote: >> For PCIE hotplug enabled slots not connected directly to a PCI-E root >> port, there can be problems when hotplugging devices. This is due to >> the possibility of hotplugging a device into the fabric with a smaller >> MPS that the devices currently running have configured. Modifying the >> MPS on the running devices could cause a fatal bus error due to an >> incoming frame being larger than the newly configured MPS. To work >> around this, the MPS for the entire fabric must be set to the minimum >> size. Any devices hotplugged into this fabric will have the minimum MPS >> set. If the PCI hotplug slot is directly connected to the root port and >> there are not other devices on the fabric (which seems to be the most >> common case), then this is not an issue and MPS discovery will occur as >> normal. > > Well, this is sub-optimal.... it would be nice if we could have some > arch control on that stuff. For example, on bare metal Power, I'd like > to do like our hypervisor, which assumes we don't do device -> device > transfers and that our host bridges never generate >cache line request. > > That means that the "upstream" MPS doesn't matter, all is needed is to > keep the hotplugged device one below its parent and all should be good. If I understand you correctly, you are saying the logic is correct but unnecessary only on ppc. If this is the case, I could create an arch specific bus fixup function pointer hanging off of the pci_bus struct. Then each arch could provide this and any number of other arch specific PCI fixups. Alternatively, I could simply move pcie_set_maxpayloadsize to arch/x86 and have you define a similar function in arch/ppc for the MPS fixup (similar to pcibios_fixup_bus). Thoughts? Thanks, Jon > > Cheers, > Ben. > > > -- 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
