- 23 11月, 2012 1 次提交
-
-
由 Alexey Kardashevskiy 提交于
The new EEH code introduced a small regression, if the EEH PEs are missin (which happens currently in qemu for example), it will deref a NULL pointer in the MSI code. Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 10 9月, 2012 1 次提交
-
-
由 Gavin Shan 提交于
There're 2 conditions to trigger EEH error detection: invalid value returned from reading I/O or config space. On each case, the function eeh_dn_check_failure will be called to initialize EEH event and put it into the poll for further processing. The patch changes the function for a little bit so that the EEH error will be traced based on PE instead of EEH device any more. Also, the function eeh_find_device_pe() has been removed since the eeh device is tracing the PE by struct eeh_dev::pe. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 07 9月, 2012 1 次提交
-
-
由 Anton Blanchard 提交于
The pseries firmware currently refuses any non power of two MSI-X request. Unfortunately most network drivers end up asking for that because they want a power of two for RX queues and one or two extra for everything else. This patch rounds up the firmware request to the next power of two if the quota allows it. If this fails we fall back to using the original request size. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 09 3月, 2012 1 次提交
-
-
由 Gavin Shan 提交于
The EEH has been implemented on pSeries platform. The original code looks a little bit nasty. The patch does cleanup on the current EEH implementation so that it looks more clean. * Try adding prefix "eeh" for functions. * Some function names have been adjusted so that they looks shorter and meaningful. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 29 3月, 2011 1 次提交
-
-
由 Thomas Gleixner 提交于
Scripted with coccinelle. Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 11 3月, 2011 1 次提交
-
-
由 Nishanth Aravamudan 提交于
On upcoming hardware, we have a PCI adapter with two functions, one of which uses MSI and the other uses MSI-X. This adapter, when MSI is disabled using the "old" firmware interface (RTAS_CHANGE_FN), still signals an MSI-X interrupt and triggers an EEH. We are working with the vendor to ensure that the hardware is not at fault, but if we use the "new" interface (RTAS_CHANGE_MSI_FN) to disable MSI, we also automatically disable MSI-X and the adapter does not appear to signal any stray MSI-X interrupt. Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com> Acked-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 05 11月, 2009 1 次提交
-
-
由 Andre Detsch 提交于
Patch f598282f exposed a problem in powerpc MSI-X functionality, making network interfaces such as ixgbe and cxgb3 stop to work when MSI-X is enabled. RX interrupts were not being generated. The problem was caused because MSI irq was not being effectively unmasked after device initialization. Signed-off-by: NAndre Detsch <adetsch@br.ibm.com> Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 11 3月, 2009 1 次提交
-
-
由 Michael Ellerman 提交于
There's no way for us to express to firmware that we want a discontiguous, or non-zero based, range of MSI-X entries. So we must reject such requests. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 23 2月, 2009 2 次提交
-
-
由 Michael Ellerman 提交于
There are hardware limitations on the number of available MSIs, which firmware expresses using a property named "ibm,pe-total-#msi". This property tells us how many MSIs are available for devices below the point in the PCI tree where we find the property. For old firmwares which don't have the property, we assume there are 8 MSIs available per "partitionable endpoint" (PE). The PE can be found using existing EEH code, which uses the methods described in PAPR. For our purposes we want the parent of the node that's identified using this method. When a driver requests n MSIs for a device, we first establish where the "ibm,pe-total-#msi" property above that device is, or we find the PE if the property is not found. In both cases we call this node the "pe_dn". We then count all non-bridge devices below the pe_dn, to establish how many devices in total may need MSIs. The quota is then simply the total available divided by the number of devices, if the request is less than or equal to the quota, the request is fine and we're done. If the request is greater than the quota, we try to determine if there are any "spare" MSIs which we can give to this device. Spare MSIs are found by looking for other devices which can never use their full quota, because their "req#msi(-x)" property is less than the quota. If we find any spare, we divide the spares by the number of devices that could request more than their quota. This ensures the spare MSIs are spread evenly amongst all over-quota requestors. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
If a driver asks for more MSIs than the devices "req#msi(-x)" property, we currently return -ENOSPC. This doesn't give the driver any chance to make a new request with a number that might work. So if "req#msi(-x)" is less than the request, return its value. To be 100% safe, make sure we return an error if req_msi == 0. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 11 2月, 2009 4 次提交
-
-
由 Michael Ellerman 提交于
If we can't allocate the requested number of MSIs, we can still tell the generic code how many we were able to allocate. That can then be passed onto the driver, allowing it to request that many in future, and probably succeeed. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
We also need to check that the device isn't using MSI-X in the irq fixup routine, otherwise we might leave MSI-Xs configured at boot. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
Firmware encodes the number of MSI-X requested by a device in a different property than for MSI. Pull the property name out as a parameter and share the logic for both cases. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
We need to increment i in the loop that queries what interrupts firmware gave us, otherwise we'll incorrectly use the first value over and over. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 08 11月, 2007 1 次提交
-
-
由 Michael Ellerman 提交于
There are plans afoot to use pci_restore_msi_state() to restore MSI state after a device reset. In order for this to work for the RTAS MSI backend, we need to read back the MSI message from config space after it has been setup by firmware. This should be sufficient for restoring the MSI state after a device reset, however we will need to revisit this for suspend to disk if that is ever implemented on pseries. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 03 10月, 2007 2 次提交
-
-
由 Michael Ellerman 提交于
Currently rtas_change_msi() returns either the error code from RTAS, or if the RTAS call succeeded the number of irqs that were configured by RTAS. This makes checking the return value more complicated than it needs to be. Instead, have rtas_change_msi() check that the number of irqs configured by RTAS is equal to what we requested - and return an error otherwise. This makes the return semantics match the usual 0 for success, something else for error. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
rtas_setup_msi_irqs() doesn't need to call teardown() itself, the generic code will do this for us as long as we return a non-zero value. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 08 5月, 2007 1 次提交
-
-
由 Michael Ellerman 提交于
Implement MSI support via RTAS (RTAS = run-time firmware on pSeries machines). For now we assumes that if the required RTAS tokens for MSI are present, then we want to use the RTAS MSI routines. When RTAS is managing MSIs for us, it will/may enable MSI on devices that support it by default. This is contrary to the Linux model where a device is in LSI mode until the driver requests MSIs. To remedy this we add a pci_irq_fixup call, which disables MSI if they've been assigned by firmware and the device also supports LSI. Devices that don't support LSI at all will be left as is, drivers are still expected to call pci_enable_msi() before using the device. At the moment there is no pci_irq_fixup on pSeries, so we can just set it unconditionally. If other platforms use the RTAS MSI backend they'll need to check that still holds. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-