- 05 Aug, 2014 19 commits
-
-
Gavin Shan authored
pr_warn() is equal to pr_warning(), but the former is a bit more formal according to commit fc62f2f1 ("kernel.h: add pr_warn for symmetry to dev_warn, netdev_warn"). The patch replaces pr_warning() with pr_warn(). Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Gavin Shan authored
The patch prints 4 PCIE or AER config registers each line, which is part of the EEH log so that it looks a bit more compact. Suggested-by:
-
Gavin Shan authored
According to the experiment I did, PCI config access is blocked on P7IOC frozen PE by hardware, but PHB3 doesn't do that. That means we always get 0xFF's while dumping PCI config space of the frozen PE on P7IOC. We don't have the problem on PHB3. So we have to enable I/O prioir to collecting error log. Otherwise, meaningless 0xFF's are always returned. The patch fixes it by EEH flag (EEH_ENABLE_IO_FOR_LOG), which is selectively set to indicate the case for: P7IOC on PowerNV platform, pSeries platform. Signed-off-by:
-
Gavin Shan authored
There are multiple global EEH flags. Almost each flag has its own accessor, which doesn't make sense. The patch refactors EEH flag accessors so that they look unified: eeh_add_flag(): Add EEH flag eeh_clear_flag(): Clear EEH flag eeh_has_flag(): Check if one specific flag has been set eeh_enabled(): Check if EEH functionality has been enabled Signed-off-by:
-
Gavin Shan authored
Function eeh_iommu_group_to_pe() iterates each PCI device to check the binding IOMMU group with get_iommu_table_base(), which possibly fetches pdev->dev.archdata.dma_data.dma_offset. It's (0x1 << 59) for "bypass" cases. The patch fixes the issue by iterating devices hooked to the IOMMU group and fetch IOMMU table there. Signed-off-by:
-
Gavin Shan authored
On PHB3, PCI devices can bypass IOMMU for DMA access. If we pass through one PCI device, whose hose driver ever enable the bypass mode, pdev->dev.archdata.dma_data.iommu_table_base isn't IOMMU table. However, EEH needs access the IOMMU table when the device is owned by guest. The patch fixes pdev->dev.archdata.dma_data.iommu_table when passing through the device to guest in pnv_pci_ioda2_set_bypass(). Signed-off-by:
-
Mike Qiu authored
pci_get_slot() is called with hold of PCI bus semaphore and it's not safe to be called in interrupt context. However, we possibly checks EEH error and calls the function in interrupt context. To avoid using pci_get_slot(), we turn into device tree for fetching location code. Otherwise, we might run into WARN_ON() as following messages indicate: WARNING: at drivers/pci/search.c:223 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc3+ #72 task: c000000001367af0 ti: c000000001444000 task.ti: c000000001444000 NIP: c000000000497b70 LR: c000000000037530 CTR: 000000003003d114 REGS: c000000001446fa0 TRAP: 0700 Not tainted (3.16.0-rc3+) MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 48002422 XER: 20000000 CFAR: c00000000003752c SOFTE: 0 : NIP [c000000000497b70] .pci_get_slot+0x40/0x110 LR [c000000000037530] .eeh_pe_loc_get+0x150/0x190 Call Trace: .of_get_property+0x30/0x60 (unreliable) .eeh_pe_loc_get+0x150/0x190 .eeh_dev_check_failure+0x1b4/0x550 .eeh_check_failure+0x90/0xf0 .lpfc_sli_check_eratt+0x504/0x7c0 [lpfc] .lpfc_poll_eratt+0x64/0x100 [lpfc] .call_timer_fn+0x64/0x190 .run_timer_softirq+0x2cc/0x3e0 Cc: stable@vger.kernel.org Signed-off-by:
Mike Qiu <qiudayu@linux.vnet.ibm.com> Acked-by:
-
Lucas Tanure authored
Fix wrong __IO_H definition in boot/io.h Reported-by:
Fernando Silveira <fsilveira@gmail.com> Signed-off-by:
Lucas Tanure <tanure@linux.com> Signed-off-by:
-
Tyrel Datwyler authored
Commit bcdde7e2 made __sysfs_remove_dir() recursive and introduced a BUG_ON during PHB removal while attempting to delete the power managment attribute group of the bus. This is a result of tearing the bridge and bus devices down out of order in remove_phb_dynamic. Since, the the bus resides below the bridge in the sysfs device tree it should be torn down first. This patch simply moves the device_unregister call for the PHB bridge device after the device_unregister call for the PHB bus. Fixes: bcdde7e2 ("sysfs: make __sysfs_remove_dir() recursive") Cc: stable@vger.kernel.org Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
Brian W Hart authored
powerpc defines various machine-specific routines for handling pci_set_dma_mask(). The routines for machine "PowerNV" may neglect to set dev->dma_mask. This could confuse anyone (e.g. drivers) that consult dev->dma_mask to find the current mask. Set the dma_mask in the PowerNV leaf routine. Signed-off-by:
Brian W. Hart <hartb@linux.vnet.ibm.com> CC: <stable@vger.kernel.org> Signed-off-by:
-
Scott Wood authored
This silences a section mismatch warning. early_alloc_pgtable() is called from map_kernel_page() which cannot be __init, but only when slab_is_available() returns false which can only happen during early boot. Signed-off-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
-
Vaidyanathan Srinivasan authored
Flags from device-tree need to be parsed with accessors for interpreting correct value in little-endian. Signed-off-by:
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Reviewed-by:
Preeti U. Murthy <preeti@linux.vnet.ibm.com> CC: <stable@vger.kernel.org> Signed-off-by:
-
Vaidyanathan Srinivasan authored
Cpufreq depends on platform firmware to implement PStates. In case of platform firmware failure, cpufreq should not panic host kernel with BUG_ON(). Less severe pr_warn() will suffice. Add firmware_has_feature(FW_FEATURE_OPALv3) check to skip probing for device-tree on non-powernv platforms. Signed-off-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> CC: <stable@vger.kernel.org> Signed-off-by:
-
Andrey Utkin authored
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81631Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
Andrey Utkin <andrey.krieger.utkin@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by:
-
Mike Qiu authored
The sysfs entries are lost because of commit 2213fb14 ("powerpc/eeh: Skip eeh sysfs when eeh is disabled"). That commit added condition to create sysfs entries with EEH_ENABLED, which isn't populated when trying to create sysfs entries on PowerNV platform during system boot time. The patch fixes the issue by: * Reoder EEH initialization functions so that they're same on PowerNV/pSeries. * Cache PE's primary bus by PowerNV platform instead of EEH core to avoid kernel crash caused by the function reorder. Another benefit with this is to avoid one eeh_probe_mode_dev() in EEH core. Signed-off-by:
-
Gavin Shan authored
The patch adds new IOCTL commands for sPAPR VFIO container device to support EEH functionality for PCI devices, which have been passed through from host to somebody else via VFIO. Signed-off-by:
Alexander Graf <agraf@suse.de> Acked-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Gavin Shan authored
The patch exports functions to be used by new VFIO ioctl command, which will be introduced in subsequent patch, to support EEH functinality for VFIO PCI devices. Signed-off-by:
-
Gavin Shan authored
We must not handle EEH error on devices which are passed to somebody else. Instead, we expect that the frozen device owner detects an EEH error and recovers from it. This avoids EEH error handling on passed through devices so the device owner gets a chance to handle them. Signed-off-by:
-
Benjamin Herrenschmidt authored
Scott writes: Highlights include e6500 hardware threading support, an e6500 TLB erratum workaround, corenet error reporting, support for a new board, and some minor fixes.
-
- 31 Jul, 2014 2 commits
-
-
Shengzhou Liu authored
T2080PCIe-RDB is a Freescale Reference Design Board that hosts T2080 SoC. The board feature overview: Processor: - T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz DDR Memory: - Single memory controller capable of supporting DDR3 and DDR3-LP devices - 72bit 4GB DDR3-LP SODIMM in slot Ethernet interfaces: - Two 1Gbps RGMII ports on-board - Two 10Gbps SFP+ ports on-board - Two 10Gbps Base-T ports on-board Accelerator: - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC IFC/Local Bus - NOR: 128MB 16-bit NOR flash - NAND: 1GB 8-bit NAND flash - CPLD: for system controlling with programable header on-board eSPI: - 64MB N25Q512 SPI flash USB: - Two USB2.0 ports with internal PHY (both Type-A) PCIe: - One PCIe x4 goldfinger(support SR-IOV) - One PCIe x4 slot - One PCIe x2 end-point device (C293 crypto co-processor) SATA: - Two SATA 2.0 ports on-board SDHC: - support a MicroSD/TF card on-board I2C: - Four I2C controllers. UART: - Dual 4-pins UART serial ports Signed-off-by:
Shengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by:
-
Priyanka Jain authored
Some Freescale boards like T1040RDB have an on board CPLD connected on the IFC bus. Add binding for cpld in board.txt file Signed-off-by:
Priyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by:
-
- 30 Jul, 2014 6 commits
-
-
Himangi Saraogi authored
In commit ae91d60b, a bug was fixed that involved converting !x & y to !(x & y). The code below shows the same pattern, and thus should perhaps be fixed in the same way. This is not tested and clearly changes the semantics, so it is only something to consider. The Coccinelle semantic patch that makes this change is as follows: // <smpl> @@ expression E1,E2; @@ ( !E1 & !E2 | - !E1 & E2 + !(E1 & E2) ) // </smpl> Signed-off-by:
Himangi Saraogi <himangi774@gmail.com> Signed-off-by:
-
Himangi Saraogi authored
mpic_msgrs has type struct mpic_msgr **, not struct mpic_msgr *, so the elements of the array should have pointer type, not structure type. The advantage of kcalloc is, that will prevent integer overflows which could result from the multiplication of number of elements and size and it is also a bit nicer to read. The Coccinelle semantic patch that makes the first change is as follows: // <smpl> @disable sizeof_type_expr@ type T; T **x; @@ x = <+...sizeof( - T + *x )...+> // </smpl> Signed-off-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Scott Wood authored
The CoreNet Coherency Fabric is part of the memory subsystem on some Freescale QorIQ chips. It can report coherency violations (e.g. due to misusing memory that is mapped noncoherent) as well as transactions that do not hit any local access window, or which hit a local access window with an invalid target ID. Signed-off-by:
Bharat Bhushan <bharat.bhushan@freescale.com>
-
Scott Wood authored
Erratum A-008139 can cause duplicate TLB entries if an indirect entry is overwritten using tlbwe while the other thread is using it to do a lookup. Work around this by using tlbilx to invalidate prior to overwriting. To avoid the need to save another register to hold MAS1 during the workaround code, TID clearing has been moved from tlb_miss_kernel_e6500 until after the SMT section. Signed-off-by: -
Andy Fleming authored
The general idea is that each core will release all of its threads into the secondary thread startup code, which will eventually wait in the secondary core holding area, for the appropriate bit in the PACA to be set. The kick_cpu function pointer will set that bit in the PACA, and thus "release" the core/thread to boot. We also need to do a few things that U-Boot normally does for CPUs (like enable branch prediction). Signed-off-by:
Andy Fleming <afleming@freescale.com> [scottwood@freescale.com: various changes, including only enabling threads if Linux wants to kick them] Signed-off-by:
-
Scott Wood authored
This ensures that all MSR definitions are consistently unsigned long, and that MSR_CM does not become 0xffffffff80000000 (this is usually harmless because MSR is 32-bit on booke and is mainly noticeable when debugging, but still I'd rather avoid it). Signed-off-by:
-
- 28 Jul, 2014 13 commits
-
-
Benjamin Herrenschmidt authored
Michael has been backing me up and helping will all aspects of maintainership for a while now, let's make it official. Signed-off-by: -
Michael Ellerman authored
Power8 has a new register (MMCR2), which contains individual freeze bits for each counter. This is an improvement on previous chips as it means we can have multiple events on the PMU at the same time with different exclude_{user,kernel,hv} settings. Previously we had to ensure all events on the PMU had the same exclude settings. The core of the patch is fairly simple. We use the 207S feature flag to indicate that the PMU backend supports per-event excludes, if it's set we skip the generic logic that enforces the equality of excludes between events. We also use that flag to skip setting the freeze bits in MMCR0, the PMU backend is expected to have handled setting them in MMCR2. The complication arises with EBB. The FCxP bits in MMCR2 are accessible R/W to a task using EBB. Which means a task using EBB will be able to see that we are using MMCR2 for freezing, whereas the old logic which used MMCR0 is not user visible. The task can not see or affect exclude_kernel & exclude_hv, so we only need to consider exclude_user. The table below summarises the behaviour both before and after this commit is applied: exclude_user true false ------------------------------------ | User visible | N N Before | Can freeze | Y Y | Can unfreeze | N Y ------------------------------------ | User visible | Y Y After | Can freeze | Y Y | Can unfreeze | Y/N Y ------------------------------------ So firstly I assert that the simple visibility of the exclude_user setting in MMCR2 is a non-issue. The event belongs to the task, and was most likely created by the task. So the exclude_user setting is not privileged information in any way. Secondly, the behaviour in the exclude_user = false case is unchanged. This is important as it is the case that is actually useful, ie. the event is created with no exclude setting and the task uses MMCR2 to implement exclusion manually. For exclude_user = true there is no meaningful change to freezing the event. Previously the task could use MMCR2 to freeze the event, though it was already frozen with MMCR0. With the new code the task can use MMCR2 to freeze the event, though it was already frozen with MMCR2. The only real change is when exclude_user = true and the task tries to use MMCR2 to unfreeze the event. Previously this had no effect, because the event was already frozen in MMCR0. With the new code the task can unfreeze the event in MMCR2, but at some indeterminate time in the future the kernel will overwrite its setting and refreeze the event. Therefore my final assertion is that any task using exclude_user = true and also fiddling with MMCR2 was deeply confused before this change, and remains so after it. Signed-off-by:Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Michael Ellerman authored
To support per-event exclude settings on Power8 we need access to the struct perf_events in compute_mmcr(). Signed-off-by:
-
Michael Ellerman authored
Because we reuse cpuhw->mmcr on each call to compute_mmcr() there's a risk that we could forget to set one of the values and use whatever value was in there previously. Currently all the implementations are careful to set all the values, but it's safer to clear them all before we call compute_mmcr(). Signed-off-by:
-
Michael Ellerman authored
Signed-off-by:
-
Michael Ellerman authored
Signed-off-by:
-
Michael Ellerman authored
Signed-off-by:
-
Michael Ellerman authored
Signed-off-by:
-
Michael Ellerman authored
Although we expect some small discrepancies for very large counts, we seem to be able to count up to 64 billion instructions without too much skew, so do so. Also switch to using decimals for the instruction counts. This just makes it easier to visually compare the expected vs actual values, as well as the raw result from instructions. Before: instructions: result 68719476753 running/enabled 13101961654 cycles: result 38077343785 running/enabled 13101725752 Looped for 68719476736 instructions, overhead 17 Expected 68719476753 Actual 68719476753 Delta 0, 0.000000% success: count_instructions After: instructions: result 64000000016 running/enabled 12197599964 cycles: result 35412471674 running/enabled 12197534110 Looped for 64000000000 instructions, overhead 16 Expected 64000000016 Actual 64000000016 Delta 0, 0.000000% success: count_instructions Signed-off-by:
-
Michael Ellerman authored
Have a task eat some cpu while we are counting instructions to create some scheduler pressure. The idea being to try and unearth any bugs we have in counting that only appear when context switching is happening. Signed-off-by:
-
Michael Ellerman authored
Signed-off-by:
-
Michael Ellerman authored
There is at least one bug in core_busy_loop(), we use r0, but it's not in the clobber list. We were getting away with this it seems but that was luck. It's also fishy to be touching the stack, even if we do it below the stack pointer. It seems we get away with it, but looking at the generated code that may just be luck. So move it into assembler, do all the stack handling by hand. We create a stack frame to save the non-volatiles in, so we can muck around with them. Signed-off-by:
-
Michael Ellerman authored
start and end should be unsigned long. Signed-off-by:
-
