| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The conversion from __get_cpu_var() to this_cpu_ptr() in iic_setup_cpu()
is wrong. It causes an oops at boot.
We need the per-cpu address of struct cpu_iic, not cpu_iic.regs->prio.
Sparse noticed this, because we pass a non-iomem pointer to out_be64(),
but we obviously don't check the sparse results often enough.
Fixes: 69111bac42f5 ("powerpc: Replace __get_cpu_var uses")
Signed-off-by: Michael Ellerman <[email protected]>
|
|
We get way too many bug reports that say "the kernel is hung in
prom_init", which stems from the fact that the last piece of output
people see is "returning from prom_init".
The kernel is almost never hung in prom_init(), it's just that it's
crashed somewhere after prom_init() but prior to the console coming up.
The existing message should give a clue to that, ie. "returning from"
indicates that prom_init() has finished, but it doesn't seem to work.
Let's try something different.
This prints:
Quiescing Open Firmware ...
Booting Linux via __start() ...
Which hopefully makes it clear that prom_init() is not the problem, and
although __start() probably isn't either, it's at least the right place
to begin looking.
Signed-off-by: Michael Ellerman <[email protected]>
Wistfully-Acked-by: Jeremy Kerr <[email protected]>
|
|
We have a powerpc specific global called mem_init_done which is "set on
boot once kmalloc can be called".
But that's not *quite* true. We set it at the bottom of mem_init(), and
rely on the fact that mm_init() calls kmem_cache_init() immediately
after that, and nothing is running in parallel.
So replace it with the generic and 100% correct slab_is_available().
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Signed-off-by: Aneesh Kumar K.V <[email protected]>
[mpe: Fix the 32-bit code also]
Signed-off-by: Michael Ellerman <[email protected]>
|
|
The callers of setbat() are actually passing a pgprot_t for the flags
parameter. This doesn't matter unless STRICT_MM_TYPECHECKS is enabled.
So we can turn that on without breaking the build, change setbat() to
take a pgprot_t and have it convert it to an unsigned long internally.
Signed-off-by: Michael Ellerman <[email protected]>
|
|
This is already declared in mmu_decl.h, so we don't need a second
version in the C file.
Signed-off-by: Michael Ellerman <[email protected]>
|
|
The celleb code has seen no actual development for ~7 years.
We (maintainers) have no access to test hardware, and it is highly
likely the code has bit-rotted.
As far as we're aware the hardware was never widely available, and is
certainly no longer available, and no one on the list has shown any
interest in it over the years.
So remove it. If anyone has one and cares please speak up.
Signed-off-by: Michael Ellerman <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
Acked-by: Jeremy Kerr <[email protected]>
|
|
The powernv code has some conditional support for running on bare metal
machines that have no OPAL firmware, but provide RTAS.
No released machines ever supported that, and even in the lab it was
just a transitional hack in the days when OPAL was still being
developed.
So remove the code.
Signed-off-by: Michael Ellerman <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
Acked-by: Stewart Smith <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc into next
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc into next
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into next
Freescale updates from Scott:
"Highlights include BMan device tree nodes, an MSI erratum workaround, a
couple minor performance improvements, config updates, and misc
fixes/cleanup."
|
|
By default we enable CONFIG_I2C_MUX and CONFIG_I2C_MUX_PCA954x,
which are needed on T2080QDS, T4240QDS, B4860QDS, etc.
Signed-off-by: Shengzhou Liu <[email protected]>
[[email protected]: fixed subject line]
Signed-off-by: Scott Wood <[email protected]>
|
|
RTC interrupt uses IRQ11 on T2080QDS.
Signed-off-by: Shengzhou Liu <[email protected]>
[[email protected]: fix subject line]
Signed-off-by: Scott Wood <[email protected]>
|
|
After previous discussions regarding the subject [1][2], there's no clear
explanation or reason why the call was needed in the first place. The sensible
argument is some sort of synchronization between the CPU and the MPIC, which
hasn't been pointed out precisely and is no longer required (at least on BookE
platforms).
The benefit of this change is saving a MMIO trap per interrupt when running in a
KVM guest.
[1] https://patchwork.ozlabs.org/patch/429098/
[2] https://patchwork.ozlabs.org/patch/433557/
Signed-off-by: Bogdan Purcareata <[email protected]>
Signed-off-by: Scott Wood <[email protected]>
|
|
The k(un)map function may be called in atomic context in the
function map_and_flush(), so use k(un)map_atomic to replace it,
else we would get the below warning during kdump:
BUG: sleeping function called from invalid context at include/linux/highmem.h:58
in_atomic(): 1, irqs_disabled(): 1, pid: 736, name: sh
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [< (null)>] (null)
hardirqs last disabled at (0): [<c000000000066d1c>] .copy_process.part.44+0x50c/0x1360
softirqs last enabled at (0): [<c000000000066d1c>] .copy_process.part.44+0x50c/0x1360
softirqs last disabled at (0): [< (null)>] (null)
CPU: 1 PID: 736 Comm: sh Tainted: G D W 3.10.62-ltsi-WR6.0.0.0_standard #2
Call Trace:
[c0000000f47cf120] [c00000000000b150] .show_stack+0x170/0x290 (unreliable)
[c0000000f47cf210] [c000000000b71334] .dump_stack+0x28/0x3c
[c0000000f47cf280] [c0000000000bb5d8] .__might_sleep+0x1a8/0x270
[c0000000f47cf310] [c0000000000440cc] .map_and_flush+0x4c/0xc0
[c0000000f47cf390] [c0000000000441cc] .mpc85xx_smp_machine_kexec+0x8c/0xec0
[c0000000f47cf420] [c00000000002ae00] .machine_kexec+0x60/0x90
[c0000000f47cf4b0] [c00000000010957c] .crash_kexec+0x8c/0x100
[c0000000f47cf6a0] [c000000000015df8] .die+0x348/0x450
[c0000000f47cf740] [c00000000002f3a0] .bad_page_fault+0xe0/0x130
[c0000000f47cf7c0] [c00000000001f3e4] storage_fault_common+0x40/0x44
Signed-off-by: Yanjiang Jin <[email protected]>
[[email protected]: fix subject line]
Signed-off-by: Scott Wood <[email protected]>
|
|
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
type T;
identifier f;
@@
static T f (...) { ... }
@@
identifier r.f;
declarer name EXPORT_SYMBOL;
@@
-EXPORT_SYMBOL(f);
// </smpl>
Furthermore, the function is never used, so its definition is dropped as
well.
Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: Scott Wood <[email protected]>
|
|
All the cache line size of the current book3e 64bit SoCs are 64 bytes.
So we should use this size to align the member of paca_struct.
This only change the paca_struct's members which are private to book3e
CPUs, and should not have any effect to book3s ones. With this, we save
192 bytes. Also change it to __aligned(size) since it is preferred over
__attribute__((aligned(size))).
Before:
/* size: 1920, cachelines: 30, members: 46 */
/* sum members: 1667, holes: 6, sum holes: 141 */
/* padding: 112 */
After:
/* size: 1728, cachelines: 27, members: 46 */
/* sum members: 1667, holes: 4, sum holes: 13 */
/* padding: 48 */
Signed-off-by: Kevin Hao <[email protected]>
Signed-off-by: Scott Wood <[email protected]>
|
|
Signed-off-by: Madalin Bucur <[email protected]>
Signed-off-by: Scott Wood <[email protected]>
|
|
This patch fixes a section mismatch warning
WARNING: vmlinux.o(.text+0x213b6): Section mismatch in reference from the function chrp_init_early() to the variable .init.data:boot_command_line
The function chrp_init_early() references
the variable __initdata boot_command_line.
This is often because chrp_init_early lacks a __initdata
annotation or the annotation of boot_command_line is wrong.
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Currently, when a sensor value is read, the kernel calls OPAL, which in
turn builds a message for the FSP, and waits for a message back.
The new device tree for OPAL sensors [1] adds new sensors that can be
read synchronously (core temperatures for instance) and that don't need
to wait for a response.
This patch modifies the opal call to accept an OPAL_SUCCESS return value
and cover the case above.
[1] https://lists.ozlabs.org/pipermail/skiboot/2015-March/000639.html
Signed-off-by: Cédric Le Goater <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
OPAL has its own list of return codes. The patch provides a translation
of such codes in errnos for the opal_sensor_read call, and possibly
others if needed.
Signed-off-by: Cédric Le Goater <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Use the normal return values for bool functions
Signed-off-by: Joe Perches <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Merge in Gavin EEH fixes
|
|
If M64 has been supported, the prefetchable 64-bits memory resources
shouldn't be mapped to the corresponding PE# via M32DT. Unfortunately,
we're doing that in pnv_ioda_setup_pe_seg() wrongly. The issue was
introduced by commit 262af55 ("powerpc/powernv: Enable M64 aperatus
for PHB3"). The patch fixes the issue by simply skipping M64 resources
when updating to M32DT.
Cc: <[email protected]> # v3.17+
Signed-off-by: Gavin Shan <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
The function eeh_add_parent_pe() is used to create a PE or add one
edev to its parent PE. Current code checks if PE#0 is valid for the
later case. Actually, we should validate PE#0 for both cases when
EEH core regards PE#0 as invalid one (without flag EEH_VALID_PE_ZERO).
Otherwise, not all EEH devices can be added to its parent PE#0 for
EEH on P7IOC.
The patch fixes the issue by validating PE#0 for the two cases. So far,
we don't have PE#0 for EEH on P7IOC, but it will show up when we enable
M64 for P7IOC. The patch also makes the error message more meaningful.
Signed-off-by: Gavin Shan <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
In order to enable SRIOV on PowerNV platform, the PF's IOV BAR needs to be
adjusted:
1. size expanded
2. aligned to M64BT size
This patch documents this change on the reason and how.
[bhelgaas: reformat, clarify, expand]
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Gavin Shan <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
When IOV BAR is big, each is covered by 4 M64 windows. This leads to
several VF PE sits in one PE in terms of M64.
Group VF PEs according to the M64 allocation.
[bhelgaas: use dev_printk() when possible]
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
supported
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this
will exceed the limitation and failed to be assigned.
Introduce a different mechanism based on the IOV BAR size:
- if IOV BAR size is smaller than 64MB, expand to total_pe
- if IOV BAR size is bigger than 64MB, roundup power2
[bhelgaas: make dev_printk() output more consistent, use PCI_SRIOV_NUM_BARS]
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
On PowerNV platform, resource position in M64 BAR implies the PE# the
resource belongs to. In some cases, adjustment of a resource is necessary
to locate it to a correct position in M64 BAR .
This patch adds pnv_pci_vf_resource_shift() to shift the 'real' PF IOV BAR
address according to an offset.
Note:
After doing so, there would be a "hole" in the /proc/iomem when offset
is a positive value. It looks like the device return some mmio back to
the system, which actually no one could use it.
[bhelgaas: rework loops, rework overlap check, index resource[]
conventionally, remove pci_regs.h include, squashed with next patch]
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
Implement pcibios_iov_resource_alignment() on powernv platform.
On PowerNV platform, there are 3 cases for the IOV BAR:
1. initial state, the IOV BAR size is multiple times of VF BAR size
2. after expanded, the IOV BAR size is expanded to meet the M64 segment size
3. sizing stage, the IOV BAR is truncated to 0
pnv_pci_iov_resource_alignment() handle these three cases respectively.
[bhelgaas: adjust to drop "align" parameter, return pci_iov_resource_size()
if no ppc_md machdep_call version]
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
number of total_pe
On PHB3, PF IOV BAR will be covered by M64 BAR to have better PE isolation.
M64 BAR is a type of hardware resource in PHB3, which could map a range of
MMIO to PE numbers on powernv platform. And this range is divided equally
by the number of total_pe with each divided range mapping to a PE number.
Also, the M64 BAR must map a MMIO range with power-of-two size.
The total_pe number is usually different from total_VFs, which can lead to
a conflict between MMIO space and the PE number.
For example, if total_VFs is 128 and total_pe is 256, the second half of
M64 BAR will be part of other PCI device, which may already belong to other
PEs.
This patch prevents the conflict by reserving additional space for the PF
IOV BAR, which is total_pe number of VF's BAR size.
[bhelgaas: make dev_printk() output more consistent, index resource[]
conventionally]
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
Previously the iommu_table had the same lifetime as a struct pnv_ioda_pe
and was embedded in it. The pnv_ioda_pe was assigned to a PE on the bootup
stage. Since PEs are based on the hardware layout which is static in the
system, they will never get released. This means the iommu_table in the
pnv_ioda_pe will never get released either.
This no longer works for VF PE. VF PEs are created and released dynamically
when VFs are created and released. So we need to assign pnv_ioda_pe to VF
PEs respectively when VFs are enabled and clean up those resources for VF
PE when VFs are disabled. And iommu_table is one of the resources we need
to handle dynamically.
Current iommu_table is a static field in pnv_ioda_pe, which will face a
problem when freeing it. During the disabling of a VF,
pnv_pci_ioda2_release_dma_pe will call iommu_free_table to release the
iommu_table for this PE. A static iommu_table will fail in
iommu_free_table.
According to these requirement, this patch allocates iommu_table
dynamically.
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
Flag PCI_REASSIGN_ALL_RSRC is used to ignore resources information setup by
firmware, so that kernel would re-assign all resources of pci devices.
On powerpc arch, this happens in a header fixup function
pcibios_fixup_resources(), which will clean up the resources if this flag
is set. This works fine for PFs, since after clean up, kernel will
re-assign the resources in pcibios_resource_survey().
Below is a simple call flow on how it works:
pcibios_init
pcibios_scan_phb
pci_scan_child_bus
...
pci_device_add
pci_fixup_device(pci_fixup_header)
pcibios_fixup_resources # header fixup
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++)
dev->resource[i].start = 0
pcibios_resource_survey # re-assign
pcibios_allocate_resources
However, the VF resources won't be re-assigned, since the VF resources are
completely determined by the PF resources, and the PF resources have
already been reassigned. This means we need to leave VF's resources
un-cleared in pcibios_fixup_resources().
In this patch, we skip the resource unset process in
pcibios_fixup_resources(), if the pci_dev is a VF.
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
pci_dn is the extension of PCI device node and is created from device node.
Unfortunately, VFs are enabled dynamically by PF's driver and they don't
have corresponding device nodes and pci_dn, which is required to access
VFs' config spaces.
The patch creates pci_dn for VFs in pcibios_sriov_enable() on their PF,
and removes pci_dn for VFs in pcibios_sriov_disable() on their PF. When
VF's pci_dn is created, it's put to the child list of the pci_dn of PF's
upstream bridge. The pci_dn is linked to pci_dev during early fixup time
to setup the fast path.
[bhelgaas: add ifdef around add_one_dev_pci_info(), use dev_printk()]
Signed-off-by: Gavin Shan <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
When sizing and assigning resources, we divide the resources into two
lists: the requested list and the additional list. We don't consider the
alignment of additional VF(n) BAR space.
This is because the alignment required for the VF(n) BAR space is the size
of an individual VF BAR, not the size of the space for *all* VFs. But we
want additional alignment to support partitioning on PowerNV.
Consider the additional IOV BAR alignment when sizing and assigning
resources. When there is not enough system MMIO space to accomodate both
the requested list and the additional list, the PF's IOV BAR alignment will
not contribute to the bridge. When there is enough system MMIO space for
both lists, the additional alignment will contribute to the bridge.
The additional alignment is stored in the min_align of pci_dev_resource,
which is stored in the additional list by add_to_list() at the end of
pbus_size_mem(). The additional alignment is calculated in
pci_resource_alignment(). For an IOV BAR, we have arch dependent function
to get the alignment for different arch.
[bhelgaas: changelog, printk cast]
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
Per the SR-IOV spec r1.1, sec 3.3.14, the required alignment of a PF's IOV
BAR is the size of an individual VF BAR, and the size consumed is the
individual VF BAR size times NumVFs.
The PowerNV platform has additional alignment requirements to help support
its Partitionable Endpoint device isolation feature (see
Documentation/powerpc/pci_iov_resource_on_powernv.txt).
Add a pcibios_iov_resource_alignment() interface to allow platforms to
request additional alignment.
[bhelgaas: changelog, adapt to reworked pci_sriov_resource_alignment(),
drop "align" parameter]
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
VFs are dynamically created when a driver enables them. On some platforms,
like PowerNV, special resources are necessary to enable VFs.
Add platform hooks for enabling and disabling VFs.
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
On PowerNV, some resource reservation is needed for SR-IOV VFs that don't
exist at the bootup stage. To do the match between resources and VFs, the
code need to get the VF's BDF in advance.
Rename virtfn_bus() and virtfn_devfn() to pci_iov_virtfn_bus() and
pci_iov_virtfn_devfn() and export them.
[bhelgaas: changelog, make "busnr" int]
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
An SR-IOV device can change its First VF Offset and VF Stride based on the
values of ARI Capable Hierarchy and NumVFs. The number of buses required
for all VFs is determined by NumVFs, First VF Offset, and VF Stride (see
SR-IOV spec r1.1, sec 2.1.2).
Previously pci_iov_bus_range() computed how many buses would be required by
TotalVFs, but this was based on a single NumVFs value and may not have been
the maximum for all NumVFs configurations.
Iterate over all valid NumVFs and calculate the maximum number of bus
numbers that could ever be required for VFs of this device.
[bhelgaas: changelog, compute busnr of NumVFs, not TotalVFs, remove
kerenl-doc comment marker]
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
The First VF Offset and VF Stride fields depend on the NumVFs setting, so
refresh the cached fields in struct pci_sriov when updating NumVFs. See
the SR-IOV spec r1.1, sec 3.3.9 and 3.3.10.
[bhelgaas: changelog, remove kernel-doc comment marker]
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
Most of PCI uses "res = &dev->resource[i]", not "res = dev->resource + i".
Use that style in iov.c also.
No functional change.
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
Currently we don't store the individual VF BAR size. We calculate it when
needed by dividing the PF's IOV resource size (which contains space for
*all* the VFs) by total_VFs or by reading the BAR in the SR-IOV capability
again.
Keep the individual VF BAR size in struct pci_sriov.barsz[], add
pci_iov_resource_size() to retrieve it, and use that instead of doing the
division or reading the SR-IOV capability BAR.
[bhelgaas: rename to "barsz[]", simplify barsz[] index computation, remove
SR-IOV capability BAR sizing]
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
When we size VF BAR0, VF BAR1, etc., from the SR-IOV Capability of a PF, we
learn the alignment requirement and amount of space consumed by a single
VF. But when VFs are enabled, *each* of the NumVFs consumes that amount of
space, so the total size of the PF resource is "VF BAR size * NumVFs".
Add a printk of the total space consumed by the VFs corresponding to what
we already do for normal non-IOV BARs.
No functional change; new message only.
[bhelgaas: split out into its own patch]
Signed-off-by: Wei Yang <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
If we don't have space for all the bus numbers required to enable VFs,
print the largest bus number required and the range available.
No functional change; improved error message only.
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Wei Yang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
|
|
This adds a test of the switch_endian() syscall we added in the previous
commit.
We test it by calling the endian switch syscall, and then executing some
code in the other endian to check everything went as expected. That code
checks registers we expect to be maintained are. If the endian switch
failed to happen that code sequence will be illegal and cause the test
to abort.
We then switch back to the original endian, do the same checks and
finally write a success message and exit(0).
Signed-off-by: Michael Ellerman <[email protected]>
|
|
We currently have a "special" syscall for switching endianness. This is
syscall number 0x1ebe, which is handled explicitly in the 64-bit syscall
exception entry.
That has a few problems, firstly the syscall number is outside of the
usual range, which confuses various tools. For example strace doesn't
recognise the syscall at all.
Secondly it's handled explicitly as a special case in the syscall
exception entry, which is complicated enough without it.
As a first step toward removing the special syscall, we need to add a
regular syscall that implements the same functionality.
The logic is simple, it simply toggles the MSR_LE bit in the userspace
MSR. This is the same as the special syscall, with the caveat that the
special syscall clobbers fewer registers.
This version clobbers r9-r12, XER, CTR, and CR0-1,5-7.
Signed-off-by: Michael Ellerman <[email protected]>
|
|
During suspend/migration operation we must wait for the VASI state reported
by the hypervisor to become Suspending prior to making the ibm,suspend-me
RTAS call. Calling routines to rtas_ibm_supend_me() pass a vasi_state variable
that exposes the VASI state to the caller. This is unnecessary as the caller
only really cares about the following three conditions; if there is an error
we should bailout, success indicating we have suspended and woken back up so
proceed to device tree update, or we are not suspendable yet so try calling
rtas_ibm_suspend_me again shortly.
This patch removes the extraneous vasi_state variable and simply uses the
return code to communicate how to proceed. We either succeed, fail, or get
-EAGAIN in which case we sleep for a second before trying to call
rtas_ibm_suspend_me again. The behaviour of ppc_rtas() remains the same,
but migrate_store() now returns the propogated error code on failure.
Previously -1 was returned from migrate_store() in the failure case which
equates to -EPERM and was clearly wrong.
Signed-off-by: Tyrel Datwyler <[email protected]>
Cc: Nathan Fontenont <[email protected]>
Cc: Cyril Bur <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Fix the attribute name of the configuration record class ID.
Signed-off-by: Philippe Bergheaud <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
One path in power_pmu_event_init() calls get_cpu_var(), but is
missing matching call to put_cpu_var(), which causes preemption
imbalance and crash in user-space:
Page fault in user mode with in_atomic() = 1 mm = c000001fefa5a280
NIP = 3fff9bf2cae0 MSR = 900000014280f032
Oops: Weird page fault, sig: 11 [#23]
SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: <snip>
CPU: 43 PID: 10285 Comm: a.out Tainted: G D 4.0.0-rc5+ #1
task: c000001fe82c9200 ti: c000001fe835c000 task.ti: c000001fe835c000
NIP: 00003fff9bf2cae0 LR: 00003fff9bee4898 CTR: 00003fff9bf2cae0
REGS: c000001fe835fea0 TRAP: 0401 Tainted: G D (4.0.0-rc5+)
MSR: 900000014280f032 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI> CR: 22000028 XER: 00000000
CFAR: 00003fff9bee4894 SOFTE: 1
GPR00: 00003fff9bee494c 00003fffe01c2ee0 00003fff9c084410 0000000010020068
GPR04: 0000000000000000 0000000000000002 0000000000000008 0000000000000001
GPR08: 0000000000000001 00003fff9c074a30 00003fff9bf2cae0 00003fff9bf2cd70
GPR12: 0000000052000022 00003fff9c10b700
NIP [00003fff9bf2cae0] 0x3fff9bf2cae0
LR [00003fff9bee4898] 0x3fff9bee4898
Call Trace:
---[ end trace 5d3d952b5d4185d4 ]---
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
in_atomic(): 1, irqs_disabled(): 0, pid: 10285, name: a.out
INFO: lockdep is turned off.
CPU: 43 PID: 10285 Comm: a.out Tainted: G D 4.0.0-rc5+ #1
Call Trace:
[c000001fe835f990] [c00000000089c014] .dump_stack+0x98/0xd4 (unreliable)
[c000001fe835fa10] [c0000000000e4138] .___might_sleep+0x1d8/0x2e0
[c000001fe835faa0] [c000000000888da8] .down_read+0x38/0x110
[c000001fe835fb30] [c0000000000bf2f4] .exit_signals+0x24/0x160
[c000001fe835fbc0] [c0000000000abde0] .do_exit+0xd0/0xe70
[c000001fe835fcb0] [c00000000001f4c4] .die+0x304/0x450
[c000001fe835fd60] [c00000000088e1f4] .do_page_fault+0x2d4/0x900
[c000001fe835fe30] [c000000000008664] handle_page_fault+0x10/0x30
note: a.out[10285] exited with preempt_count 1
Reproducer:
#include <stdio.h>
#include <unistd.h>
#include <syscall.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <linux/perf_event.h>
#include <linux/hw_breakpoint.h>
static struct perf_event_attr event = {
.type = PERF_TYPE_RAW,
.size = sizeof(struct perf_event_attr),
.sample_type = PERF_SAMPLE_BRANCH_STACK,
.branch_sample_type = PERF_SAMPLE_BRANCH_ANY_RETURN,
};
int main()
{
syscall(__NR_perf_event_open, &event, 0, -1, -1, 0);
}
Signed-off-by: Jan Stancek <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|