- 17 12月, 2015 12 次提交
-
-
由 Nathan Fontenot 提交于
Update the cpu dlpar add/remove paths to do better error recovery when a failure occurs during the add/remove operation. Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Nathan Fontenot 提交于
Re-factor the cpu hotplug code to support doing cpu hotplug completely in the kernel and using the existing sysfs probe/release interfaces. This patch pulls out pieces of existing cpu hotplug code into common routines, dlpar_cpu_add() and dlpar_cpu_remove(), to be used by both interfaces. There are no functional changes introduced. Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Nathan Fontenot 提交于
No functional changes, this patch is simply a move of the cpu hotplug code from pseries/dlpar.c to pseries/hotplug-cpu.c. This is in an effort to consolidate all of the cpu hotplug code in a common place. Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Nathan Fontenot 提交于
When DLPAR adding a CPU we should verify that the CPU does not already exist. Failure to do so can generate a kernel oops; [ 9.465585] kernel BUG at arch/powerpc/platforms/pseries/dlpar.c:382! [ 9.465796] Oops: Exception in kernel mode, sig: 5 [#1] This oops can be generated by causing a probe to be performed on a cpu by writing to the sysfs cpu probe file (/sys/devices/system/cpu/probe). This patch adds a check for the existence of cpu prior to probing the cpu so userspace doing the wrong thing won't trigger a BUG_ON(). Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Alistair Popple 提交于
NVLink is a high speed interconnect that is used in conjunction with a PCI-E connection to create an interface between CPU and GPU that provides very high data bandwidth. A PCI-E connection to a GPU is used as the control path to initiate and report status of large data transfers sent via the NVLink. On IBM Power systems the NVLink processing unit (NPU) is similar to the existing PHB3. This patch adds support for a new NPU PHB type. DMA operations on the NPU are not supported as this patch sets the TCE translation tables to be the same as the related GPU PCIe device for each NVLink. Therefore all DMA operations are setup and controlled via the PCIe device. EEH is not presently supported for the NPU devices, although it may be added in future. Signed-off-by: NAlistair Popple <alistair@popple.id.au> Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Alistair Popple 提交于
Move __raw_rm_writeq() from platforms/powernv/pci-ioda.c to include/asm/io.h so that it can be used by other code. Signed-off-by: NAlistair Popple <alistair@popple.id.au> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Alistair Popple 提交于
This commit removed the pcidev field from struct pci_dn as it was no longer in use by the kernel. However to support finding the association of Nvlink devices to GPU devices from the device-tree this field is required. This reverts commit 250c7b27 ("powerpc/pci: Remove unused struct pci_dn.pcidev field"). Signed-off-by: NAlistair Popple <alistair@popple.id.au> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Gavin Shan 提交于
The name of PCI root bus's M64 resource isn't initialized properly. When dumping "/proc/iomem", "<BAD>" is seen for those M64 resources on PCI root buses. ~# cat /proc/iomem | grep -e "BAD" 3b0000000000-3b0fefffffff : <BAD> 3b1000000000-3b1fefffffff : <BAD> 3c0000000000-3c0fefffffff : <BAD> 3c1000000000-3c1fefffffff : <BAD> 3c2000000000-3c2fefffffff : <BAD> This fixes the issue by setting the name of PCI root bus's M64 resource to that of PHB's device node full name. With the patch, no "<BAD>" is seen from "/proc/iomem". Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Michael Ellerman 提交于
Avoid open coding the logic by using rtas_call_unlocked(). Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Stewart Smith 提交于
Long ago, only in the lab, there was OPALv1 and OPALv2. Now there is just OPALv3, with nobody ever expecting anything on pre-OPALv3 to be cared about or supported by mainline kernels. So, let's remove FW_FEATURE_OPALv3 and instead use FW_FEATURE_OPAL exclusively. Signed-off-by: NStewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Stewart Smith 提交于
OPALv2 only ever existed in the lab and didn't escape to the world. All OPAL systems in the wild are OPALv3. The probability of there being an OPALv2 system still powered on anywhere inside IBM is approximately zero, let alone anyone expecting to run mainline kernels. So, start to remove references to OPALv2. Signed-off-by: NStewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Stewart Smith 提交于
The OpenPower Abstraction Layer firmware went through a couple of iterations in the lab before being released. What we now know as OPAL advertises itself as OPALv3. OPALv2 and OPALv1 never made it outside the lab, and the possibility of anyone at all ever building a mainline kernel today and expecting it to boot on such hardware is zero. Signed-off-by: NStewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 16 12月, 2015 1 次提交
-
-
由 Daniel Axtens 提交于
GregorianDay() is supposed to calculate the day of the week (tm->tm_wday) for a given day/month/year. In that calcuation it indexed into an array called MonthOffset using tm->tm_mon-1. However tm_mon is zero-based, not one-based, so this is off-by-one. It also means that every January, GregoiranDay() will access element -1 of the MonthOffset array. It also doesn't appear to be a correct algorithm either: see in contrast kernel/time/timeconv.c's time_to_tm function. It's been broken forever, which suggests no-one in userland uses this. It looks like no-one in the kernel uses tm->tm_wday either (see e.g. drivers/rtc/rtc-ds1305.c:319). tm->tm_wday is conventionally set to -1 when not available in hardware so we can simply set it to -1 and drop the function. (There are over a dozen other drivers in drivers/rtc that do this.) Found using UBSAN. Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andrew Morton <akpm@linux-foundation.org> # as an example of what UBSan finds. Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Cc: rtc-linux@googlegroups.com Signed-off-by: NDaniel Axtens <dja@axtens.net> Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 14 12月, 2015 4 次提交
-
-
由 Rashmica Gupta 提交于
All users of QPACE have upgraded to QPACE2 so remove the Cell QPACE code. Signed-off-by: NRashmica Gupta <rashmicy@gmail.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Vipin K Parashar 提交于
Kernel prints respective warnings about various EPOW events for user information/action after parsing EPOW interrupts. At times below EPOW reset event warning is seen to be flooding kernel log over a period of time. May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared These EPOW reset events are spurious in nature and are triggered by firmware without an actual EPOW event being reset. This patch avoids these multiple EPOW reset warnings by using a counter variable. This variable is incremented every time an EPOW event is reported. Upon receiving a EPOW reset event the same variable is checked to filter out spurious events and decremented accordingly. This patch also improves log messages to better describe EPOW event being reported. Merged adjacent log messages into single one to reduce number of lines printed per event. Signed-off-by: NKamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: NVipin K Parashar <vipin@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Aneesh Kumar K.V 提交于
This will bulk read 4 hash pte slot entries and should reduce the loop Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Aneesh Kumar K.V 提交于
We support THP only with book3s_64 and 64K page size. Move THP details to hash64-64k.h to clarify the same. Acked-by: NScott Wood <scottwood@freescale.com> Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 26 11月, 2015 2 次提交
-
-
由 Rashmica Gupta 提交于
Most architectures use NR_syscalls as the #define for the number of syscalls. We use __NR_syscalls, and then define NR_syscalls as __NR_syscalls. __NR_syscalls is not used outside arch code, whereas NR_syscalls is. So as NR_syscalls must be defined and __NR_syscalls does not, replace __NR_syscalls with NR_syscalls. Signed-off-by: NRashmica Gupta <rashmicy@gmail.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 John Ogness 提交于
The xmon and cascade irq handlers must not run as threads. pmac_pic_lock is already a raw_spinlock, but the irq flag IRQF_NO_THREAD needs to be set as well. Signed-off-by: NJohn Ogness <john.ogness@linutronix.de> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 24 11月, 2015 1 次提交
-
-
由 Krzysztof Kozlowski 提交于
platform_driver does not need to set an owner because platform_driver_register() will set it. Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 28 10月, 2015 3 次提交
-
-
由 Nathan Fontenot 提交于
Commit a030e1e4 make a change to use kstrndup() instead of kmalloc() + strlcpy() in the pseries_of_derive_parent() routine that introduces a subtle change in the parent path name generated. The kstrndup() routine will copy n characters followed by a terminating null, whereas strlcpy() will copy n-1 characters and add a terminating null. This slight difference results in having a parent path that includes the tailing '/' character, "/cpus/" vs. "/cpus". This then causes the subsequent call to of_find_node_by_path() to fail, and in the case of DLPAR add operations the DLPAR request fails. This patch decrements the pointer returned from kbasename() to point to the '/' character before the base name instead of the base name. This then adjusts the string length calculations to not include the trailing '/' in the parent path name. Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Scott Wood 提交于
The new kernel will be expecting secondary threads to be disabled, not spinning. Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Tiejun Chen 提交于
Unlike 32-bit 85xx kexec, we don't do a core reset. Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com> [scottwood: edit changelog, and cleanup] Signed-off-by: NScott Wood <scottwood@freescale.com>
-
- 22 10月, 2015 4 次提交
-
-
由 Himangi Saraogi 提交于
This patch moves data allocated using kzalloc to managed data allocated using devm_kzalloc and cleans now unnecessary kfree in probe function. The following Coccinelle semantic patch was used for making the change: @platform@ identifier p, probefn, removefn; @@ struct platform_driver p = { .probe = probefn, .remove = removefn, }; @prb@ identifier platform.probefn, pdev; expression e, e1, e2; @@ probefn(struct platform_device *pdev, ...) { <+... - e = kzalloc(e1, e2) + e = devm_kzalloc(&pdev->dev, e1, e2) ... ?-kfree(e); ...+> } Signed-off-by: NHimangi Saraogi <himangi774@gmail.com> Acked-by: NJulia Lawall <julia.lawall@lip6.fr> Signed-off-by: NAnatolij Gustschin <agust@denx.de>
-
由 Alexander Popov 提交于
This driver for Freescale MPC512x LocalPlus Bus FIFO (called SCLPC in the Reference Manual) allows Direct Memory Access transfers between RAM and peripheral devices on LocalPlus Bus. Signed-off-by: NAlexander Popov <alex.popov@linux.com> Signed-off-by: NAnatolij Gustschin <agust@denx.de>
-
由 Luis de Bethencourt 提交于
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: NAnatolij Gustschin <agust@denx.de>
-
由 Scott Wood 提交于
Freescale's Layerscape ARM chips use the same structure. Signed-off-by: NScott Wood <scottwood@freescale.com>
-
- 21 10月, 2015 6 次提交
-
-
由 Paul Mackerras 提交于
This fixes a bug where it is possible for an off-line CPU to fail to go into a low-power state (nap/sleep/winkle), and to become unresponsive to requests from the KVM subsystem to wake up and run a VCPU. What can happen is that a maskable interrupt of some kind (external, decrementer, hypervisor doorbell, or HMI) after we have called local_irq_disable() at the beginning of pnv_smp_cpu_kill_self() and before interrupts are hard-disabled inside power7_nap/sleep/winkle(). In this situation, the pending event is marked in the irq_happened flag in the PACA. This pending event prevents power7_nap/sleep/winkle from going to the requested low-power state; instead they return immediately. We don't deal with any of these pending event flags in the off-line loop in pnv_smp_cpu_kill_self() because power7_nap et al. return 0 in this case, so we will have srr1 == 0, and none of the processing to clear interrupts or doorbells will be done. Usually, the most obvious symptom of this is that a KVM guest will fail with a console message saying "KVM: couldn't grab cpu N". This fixes the problem by making sure we handle the irq_happened flags properly. First, we hard-disable before the off-line loop. Once we have hard-disabled, the irq_happened flags can't change underneath us. We unconditionally clear the DEC and HMI flags: there is no processing of timer interrupts while off-line, and the necessary HMI processing is all done in lower-level code. We leave the EE and DBELL flags alone for the first iteration of the loop, so that we won't fail to respond to a split-core request that came in just before hard-disabling. Within the loop, we handle external interrupts if the EE bit is set in irq_happened as well as if the low-power state was interrupted by an external interrupt. (We don't need to do the msgclr for a pending doorbell in irq_happened, because doorbells are edge-triggered and don't remain pending in hardware.) Then we clear both the EE and DBELL flags, and once clear, they cannot be set again (until this CPU comes online again, that is). This also fixes the debug check to not be done when we just ran a KVM guest or when the sleep didn't happen because of a pending event in irq_happened. Signed-off-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Gavin Shan 提交于
Similar to commit b6541db1 ("powerpc/eeh: Block PCI config access upon frozen PE"), this blocks the PCI config space of Broadcom Shiner adapter until PE reset is completed, to avoid recursive fenced PHB when dumping PCI config registers during the period of error recovery. ~# lspci -ns 0003:03:00.0 0003:03:00.0 0200: 14e4:168a (rev 10) ~# lspci -s 0003:03:00.0 0003:03:00.0 Ethernet controller: Broadcom Corporation \ NetXtreme II BCM57800 1/10 Gigabit Ethernet (rev 10) Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Gavin Shan 提交于
This simplifies pnv_eeh_set_option() to avoid unnecessary nested if statements, to improve readability. No functional changes. Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Gavin Shan 提交于
This moves the logic of pnv_eeh_cap_start() to pnv_eeh_find_cap() as the function is only called by pnv_eeh_find_cap(). The logic of both functions are pretty simple. No need to have separate functions. Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Gavin Shan 提交于
This applies cleanup on eeh-powernv.c, no functional changes: * Remove unnecessary comments and empty line. * Correct inaccurate comments. Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Gavin Shan 提交于
This cleans up pseries_eeh_get_state(), no functional changes: * Return EEH_STATE_NOT_SUPPORT early when the 2nd RTAS output argument is zero to avoid nested if statements. * Skip clearing bits in the PE state represented by variable "result" to simplify the code. Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 19 10月, 2015 1 次提交
-
-
由 Michael Ellerman 提交于
The TUNE_CELL option allows you to build a kernel that runs on multiple CPUs but is tuned (ie. optimised) to run on Cell CPUs. Now days no one is building a distro in that fashion, and any users who are building custom kernels for their Cell machines are better off building with CONFIG_CELL_CPU, which builds a kernel that only runs on Cell and therefore can be optimised even more aggresively. Dropping the option also avoids confusing other users, who are presented with an option to tune for Cell when they are not building for a Cell CPU at all. Suggested-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 17 10月, 2015 5 次提交
-
-
由 Scott Wood 提交于
85xx currently uses the generic timebase sync mechanism when CONFIG_KEXEC is enabled, because 32-bit 85xx kexec support does a hard reset of each core. 64-bit 85xx kexec does not do this, so we neither need nor want this (nor is the generic timebase sync code built on ppc64). FWIW, I don't like the fact that the hard reset is done on 32-bit kexec, and I especially don't like the timebase sync being triggered only on the presence of CONFIG_KEXEC rather than actually booting in that environment, but that's beyond the scope of this patch... Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Scott Wood 提交于
Problems have been observed in coreint (EPR) mode if interrupts are left pending (due to the lack of device quiescence with kdump) after having tried to deliver to a CPU but unable to deliver due to MSR[EE] -- interrupts no longer get reliably delivered in the new kernel. I tried various ways of fixing it up inside the crash kernel itself, and none worked (including resetting the entire mpic). Masking all interrupts and issuing EOIs in the crashing kernel did help a lot of the time, but the behavior was not consistent. Thus, stick to standard IACK mode when kdump is a possibility. Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Scott Wood 提交于
This allows SMP kernels to work as kdump crash kernels. While crash kernels don't really need to be SMP, this prevents things from breaking if a user does it anyway (which is not something you want to only find out once the main kernel has crashed in the field, especially if whether it works or not depends on which cpu crashed). Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 Andy Fleming 提交于
This board uses a P5020 chip, and boots just fine using the corenet_generic code. The device tree is very similar to the P5020DS, except that there is no Flash memory. The environment is, instead, stored on an MMC card on the motherboard. Signed-off-by: NAndy Fleming <afleming@gmail.com> [scottwood: fixed trailing whitespace] Signed-off-by: NScott Wood <scottwood@freescale.com>
-
由 chenhui zhao 提交于
Core reset may cause issue if using the proxy mode of MPIC. Use the mixed mode of MPIC if enabling CPU hotplug. Signed-off-by: NChenhui Zhao <chenhui.zhao@freescale.com> Signed-off-by: NScott Wood <scottwood@freescale.com>
-
- 15 10月, 2015 1 次提交
-
-
由 Michael Ellerman 提交于
Now that pseries selects PCI_MSI && PCI, EEH will always be true, and therefore CONFIG_PSERIES_MSI will always be true. So drop it, and move msi.o to obj-y. Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-