| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This implementation is simply bogus - hexagon only has a simple
direct mapped DMA implementation and thus doesn't care about the
address.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Richard Kuo <[email protected]>
|
|
Usually dma_supported decisions are done by the dma_map_ops instance.
Switch sparc to that model by providing a ->dma_supported instance for
sbus that always returns false, and implementations tailored to the sun4u
and sun4v cases for sparc64, and leave it unimplemented for PCI on
sparc32, which means always supported.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: David S. Miller <[email protected]>
|
|
We can just use pci32_dma_ops directly.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: David S. Miller <[email protected]>
|
|
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
All dma_map_ops instances now handle their errors through
->mapping_error.
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
DMA_ERROR_CODE is going to go away, so don't rely on it. Instead
define a ->mapping_error method for all IOMMU based dma operation
instances. The direct ops don't ever return an error and don't
need a ->mapping_error method.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Michael Ellerman <[email protected]>
|
|
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: David S. Miller <[email protected]>
|
|
s390 can also use noop_dma_ops, and while that currently does not return
errors it will so in the future. Implementing the mapping_error method
is the proper way to have per-ops error conditions.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Gerald Schaefer <[email protected]>
|
|
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Richard Kuo <[email protected]>
|
|
pnv_wakeup_noloss() expects r12 to contain SRR1 value to determine if the wakeup
reason is an HMI in CHECK_HMI_INTERRUPT.
When we wakeup with ESL=0, SRR1 will not contain the wakeup reason, so there is
no point setting r12 to SRR1.
However, we don't set r12 at all so r12 contains garbage (likely a kernel
pointer), and is still used to check HMI assuming that it contained SRR1. This
causes the OPAL msglog to be filled with the following print:
HMI: Received HMI interrupt: HMER = 0x0040000000000000
This patch clears r12 after waking up from stop with ESL=EC=0, so that we don't
accidentally enter the HMI handler in pnv_wakeup_noloss() if the value of
r12[42:45] corresponds to HMI as wakeup reason.
Prior to commit 9d29250136f6 ("powerpc/64s/idle: Avoid SRR usage in idle
sleep/wake paths") this bug existed, in that we would incorrectly look at SRR1
to check for a HMI when SRR1 didn't contain a wakeup reason. However the SRR1
value would just happen to never have bits 42:45 set.
Fixes: 9d29250136f6 ("powerpc/64s/idle: Avoid SRR usage in idle sleep/wake paths")
Signed-off-by: Akshay Adiga <[email protected]>
Reviewed-by: Nicholas Piggin <[email protected]>
[mpe: Change log and comment massaging]
Signed-off-by: Michael Ellerman <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into features
Pull kvm patches from Christian Borntraeger:
"s390,kvm: provide plumbing for machines checks when running guests"
This provides the basic plumbing for handling machine checks when
running guests
|
|
With vsie feature enabled, kvm can support nested guests (guest-3).
So inject machine check to the guest-2 if it happens when the nested
guest is running. And guest-2 will detect the machine check belongs
to guest-3 and reinject it into guest-3.
The host (guest-1) tries to inject the machine check to the picked
destination vcpu if it's a floating machine check.
Signed-off-by: QingFeng Hao <[email protected]>
Acked-by: Christian Borntraeger <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>
|
|
If the exit flag of SIE indicates that a machine check has happened
during guest's running and needs to be injected, inject it to the guest
accordingly.
But some machine checks, e.g. Channel Report Pending (CRW), refer to
host conditions only (the guest's channel devices are not managed by
the kernel directly) and are therefore not injected into the guest.
External Damage (ED) is also not reinjected into the guest because ETR
conditions are gone in Linux and STP conditions are not enabled in the
guest, and ED contains only these 8 ETR and STP conditions.
In general, instruction-processing damage, system recovery,
storage error, service-processor damage and channel subsystem damage
will be reinjected into the guest, and the remain (System damage,
timing-facility damage, warning, ED and CRW) will be handled on the host.
Signed-off-by: QingFeng Hao <[email protected]>
Acked-by: Christian Borntraeger <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kernelorgnext
s390,kvm: provide plumbing for machines checks when running guests
This provides the basic plumbing for handling machine checks when
running guests
|
|
Loongson-3A R3 is very similar to Loongson-3A R2.
All Loongson-3 CPU family:
Code-name Brand-name PRId
Loongson-3A R1 Loongson-3A1000 0x6305
Loongson-3A R2 Loongson-3A2000 0x6308
Loongson-3A R3 Loongson-3A3000 0x6309
Loongson-3B R1 Loongson-3B1000 0x6306
Loongson-3B R2 Loongson-3B1500 0x6307
Signed-off-by: Huacai Chen <[email protected]>
Cc: John Crispin <[email protected]>
Cc: Steven J . Hill <[email protected]>
Cc: Fuxin Zhang <[email protected]>
Cc: Zhangjin Wu <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16585/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
The various interrupt specifiers in the device tree are not in a valid
format for the MIPS GIC interrupt controller binding. Where each
interrupt should provide 3 values - GIC_LOCAL or GIC_SHARED, the
pin number & the type of interrupt - the device tree was only providing
the pin number. This causes interrupts for those devices to not be used
when a GIC is present. SEAD-3 systems without a GIC are unaffected since
the DT fixup code generates interrupt specifiers that are valid for the
CPU interrupt controller.
Fix this by adding the GIC_SHARED & IRQ_TYPE_LEVEL_HIGH values to each
interrupt specifier.
Signed-off-by: Paul Burton <[email protected]>
Fixes: c11e3b48dbc3 ("MIPS: SEAD3: Probe UARTs using DT")
Fixes: a34e93882de4 ("MIPS: SEAD3: Probe ethernet controller using DT")
Fixes: 7afd2a5aec2e ("MIPS: SEAD3: Probe EHCI controller using DT")
Cc: [email protected]
Cc: [email protected] # v4.9+
Patchwork: https://patchwork.linux-mips.org/patch/16189/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
The SEAD-3 board may be configured with or without a MIPS Global
Interrupt Controller (GIC). Because of this we have a device tree with a
default case of a GIC present, and code to fixup the device tree based
upon a configuration register that indicates the presence of the GIC.
In order to keep this DT fixup code simple, the interrupt-parent
property was specified at the root node of the SEAD-3 DT, allowing the
fixup code to simply change this property to the phandle of the CPU
interrupt controller if a GIC is not present & affect all
interrupt-using devices at once. This however causes a problem if we do
have a GIC & the device tree is used as-is, because the interrupt-parent
property of the root node applies to the CPU interrupt controller node.
This causes a cycle when of_irq_init() attempts to probe interrupt
controllers in order and boots fail due to a lack of configured
interrupts, with this message printed on the kernel console:
[ 0.000000] OF: of_irq_init: children remain, but no parents
Fix this by removing the interrupt-parent property from the DT root node
& instead setting it for each device which uses interrupts, ensuring
that the CPU interrupt controller node has no interrupt-parent &
allowing of_irq_init() to identify it as the root interrupt controller.
Signed-off-by: Paul Burton <[email protected]>
Reported-by: Keng Koh <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16187/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Drivers for the mc146818 RTC generally check control registers to
determine whether a value is encoded as binary or as a binary coded
decimal. Setting RTC_ALWAYS_BCD to 1 effectively bypasses these checks
and causes drivers to always expect binary coded decimal values,
regardless of control register values.
This does not seem like a sane default - defaulting to 0 allows the
drivers to check control registers to determine encoding type & allows
the driver to work generically with both binary & BCD encodings. Set
this in mach-generic/mc146818rtc.h such that the generic kernel, or
platforms which don't provide a custom mc146818rtc.h, can have an RTC
driver which works with both encodings.
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16185/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Introduce an apply_mips_fdt_fixups() function which can apply fixups to
an FDT based upon an array of fixup descriptions. This abstracts that
functionality such that legacy board code can apply FDT fixups without
requiring lots of duplication.
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16184/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Name aliases in the SEAD-3 device tree serial0 & serial1, rather than
uart0 & uart1. This allows the core serial code to make use of the
aliases to ensure that the UARTs are consistently numbered as expected
rather than having the numbering depend upon probe order.
When translating YAMON-provided serial configuration to a device tree
stdout-path property adjust accordingly, such that we continue to
reference a valid alias.
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16183/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
YAMON can expose more than 256MB of RAM to Linux on Malta by passing an
ememsize environment variable with the full size, but the kernel then
needs to be careful to choose the corresponding physical memory regions,
avoiding the IO memory window. This is platform dependent, and on Malta
it also depends on the memory layout which varies between system
controllers.
Extend yamon_dt_amend_memory() to generically handle this by taking
[e]memsize bytes of memory from an array of memory regions passed in as
a new parameter. Board code provides this array as appropriate depending
on its own memory map.
[[email protected]: SEAD-3 supports 384MB DDR from 0]
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16182/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
In preparation for supporting other YAMON-using boards (Malta) & sharing
code to translate information from YAMON into device tree properties,
pull the code doing so for the kernel command line, system memory &
serial configuration out of the SEAD-3 board code.
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16181/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
The SEAD-3 board doesn't & never has configured the GIC frequency.
Remove the timer node from the DT in order to avoid attempting to probe
the GIC clocksource/clockevent driver which will produce error messages
such as these during boot:
[ 0.000000] GIC frequency not specified.
[ 0.000000] Failed to initialize '/interrupt-controller@1b1c0000/timer': -22
[ 0.000000] clocksource_probe: no matching clocksources found
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16188/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Adjust the atomic loop in the MIPS_ATOMIC_SET operation of the sysmips
system call to branch straight back to the linked load rather than
jumping via a different subsection (whose purpose remains a mystery to
me).
Signed-off-by: James Hogan <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16150/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
EVA linked loads (LLE) and conditional stores (SCE) should be used on
EVA kernels for the MIPS_ATOMIC_SET operation of the sysmips system
call, or else the atomic set will apply to the kernel view of the
virtual address space (potentially unmapped on EVA kernels) rather than
the user view (TLB mapped).
Signed-off-by: James Hogan <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # 3.15.x-
Patchwork: https://patchwork.linux-mips.org/patch/16151/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
The MIPS sysmips system call handler may return directly from the
MIPS_ATOMIC_SET case (mips_atomic_set()) to syscall_exit. This path
restores the static (callee saved) registers, however they won't have
been saved on entry to the system call.
Use the save_static_function() macro to create a __sys_sysmips wrapper
function which saves the static registers before calling sys_sysmips, so
that the correct static register state is restored by syscall_exit.
Fixes: f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
Signed-off-by: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16149/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
The inline asm retry check in the MIPS_ATOMIC_SET operation of the
sysmips system call has been backwards since commit f1e39a4a616c ("MIPS:
Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
merged in v2.6.32, resulting in the non R10000_LLSC_WAR case retrying
until the operation was inatomic, before returning the new value that
was probably just written multiple times instead of the old value.
Invert the branch condition to fix that particular issue.
Fixes: f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
Signed-off-by: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16148/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Add a definition of the perf registers for the new I6500 core.
Since I6500 has the same event definitions as I6400, re-use the existing
i6400 map structures by renaming them to a slightly more generic
'i6x00_***_map'.
Signed-off-by: Marcin Nowakowski <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16362/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Introduce the I6500 PRID & probe it just the same way as I6400. The MIPS
I6500 is the latest in Imagination Technologies' I-Class range of CPUs,
with a focus on scalability & heterogeneity. It introduces the notion of
multiple clusters to the MIPS Coherent Processing System, allowing for a
far higher total number of cores & threads in a system when compared
with its predecessors. Clusters don't need to be identical, and may
contain differing numbers of cores & IOCUs, or cores with differing
properties.
This patch alone adds the basic support for booting Linux on an I6500
CPU without support for any of its new functionality, for which support
will be introduced in further patches.
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16190/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Recent CPUs from Imagination Technologies such as the I6400 or P6600 are
able to speculatively fetch data from memory into caches. This means
that if used in a system with non-coherent DMA they require that caches
be invalidated after a device performs DMA, and before the CPU reads the
DMA'd data, in order to ensure that stale values weren't speculatively
prefetched.
Such CPUs also introduced Memory Accessibility Attribute Registers
(MAARs) in order to control the regions in which they are allowed to
speculate. Thus we can use the presence of MAARs as a good indication
that the CPU requires the above cache maintenance. Use the presence of
MAARs to determine the result of cpu_needs_post_dma_flush() in the
default case, in order to handle these recent CPUs correctly.
Note that the return type of cpu_needs_post_dma_flush() is changed to
bool, such that it's clearer what's happening when cpu_has_maar is cast
to bool for the return value. If this patch were backported to a
pre-v4.7 kernel then MIPS_CPU_MAAR was 1ull<<34, so when cast to an int
we would incorrectly return 0. It so happens that MIPS_CPU_MAAR is
currently 1ull<<30, so when truncated to an int gives a non-zero value
anyway, but even so the implicit conversion from long long int to bool
makes it clearer to understand what will happen than the implicit
conversion from long long int to int would. The bool return type also
fits this usage better semantically, so seems like an all-round win.
Thanks to Ed for spotting the issue for pre-v4.7 kernels & suggesting
the return type change.
Signed-off-by: Paul Burton <[email protected]>
Reviewed-by: Bryan O'Donoghue <[email protected]>
Tested-by: Bryan O'Donoghue <[email protected]>
Cc: Ed Blake <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16363/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
KProbes of __seccomp_filter() are not very useful without access to
the syscall arguments.
Do what x86 does, and populate a struct seccomp_data to be passed to
__secure_computing(). This allows samples/bpf/tracex5 to extract a
sensible trace.
Signed-off-by: David Daney <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Matt Redfearn <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16368/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Since the eBPF machine has 64-bit registers, we only support this in
64-bit kernels. As of the writing of this commit log test-bpf is showing:
test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
All current test cases are successfully compiled.
Many examples in samples/bpf are usable, specifically tracex5 which
uses tail calls works.
Signed-off-by: David Daney <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Markos Chandras <[email protected]>
Cc: Matt Redfearn <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16369/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Follow on patches for eBPF JIT require these additional instructions:
insn_bgtz, insn_blez, insn_break, insn_ddivu, insn_dmultu,
insn_dsbh, insn_dshd, insn_dsllv, insn_dsra32, insn_dsrav,
insn_dsrlv, insn_lbu, insn_movn, insn_movz, insn_multu, insn_nor,
insn_sb, insn_sh, insn_slti, insn_dinsu, insn_lwu
... so, add them.
Sort the insn_* enumeration values alphabetically.
Signed-off-by: David Daney <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Matt Redfearn <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16367/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
DSHD was incorrectly classified as being BSHFL, and DSHD was missing
altogether.
Signed-off-by: David Daney <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Matt Redfearn <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16366/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Instead of doing a linear search through the insn_table for each
instruction, use the opcode as direct index into the table. This will
give constant time lookup performance as the number of supported
opcodes increases. Make the tables const as they are only ever read.
For uasm-mips.c sort the table alphabetically, and remove duplicate
entries, uasm-micromips.c was already sorted and duplicate free.
There is a small savings in object size as struct insn loses a field:
$ size arch/mips/mm/uasm-mips.o arch/mips/mm/uasm-mips.o.save
text data bss dec hex filename
10040 0 0 10040 2738 arch/mips/mm/uasm-mips.o
9240 1120 0 10360 2878 arch/mips/mm/uasm-mips.o.save
Signed-off-by: David Daney <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Matt Redfearn <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16365/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
The module load code has previously had entirely separate
implementations for rel & rela style relocs, which unnecessarily
duplicates a whole lot of code. Unify the implementations of both types
of reloc, sharing the bulk of the code.
Signed-off-by: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/15832/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
If we hit an error whilst processing a reloc then we would return early
from apply_relocate & potentially not free entries in r_mips_hi16_list,
thereby leaking memory. Fix this by ensuring that we always run the code
to free r_mipps_hi16_list when errors occur.
Signed-off-by: Paul Burton <[email protected]>
Fixes: 861667dc82f5 ("MIPS: Fix race condition in module relocation code.")
Fixes: 04211a574641 ("MIPS: Bail on unsupported module relocs")
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/15831/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
When uid checking is enabled firmware guarantees uniqueness of the uids
and we use them for device enumeration. Tests have shown that uid checking
can be toggled at runtime. This is unfortunate since it can lead to name
clashes.
Recognize these name clashes by allocating bits in zpci_domain even for
firmware provided ids.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Pierre Morel <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Add some debug data to observe the lifetime of the
architecture specific device information.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
In contrast to other hotplug events PEC 0x306 isn't about a single
but multiple devices. Also there's no information on what happened
to these devices. We correctly handled hotplug that way but failed
to handle hot-unplug. This patch addresses that and implements
hot-unplug of multiple devices via PEC 306.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
PCI hotplug events basically notify about the new state of a
function. Unfortunately some hypervisors implement hotplug
events in a way where it is not clear what the new state of
the function should be.
Use clp_get_state to find the current state of the function
and handle accordingly.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Code handling pci hotplug needs to determine the configuration
state of a pci function. Implement clp_get_state as a wrapper
for list pci functions.
Also change enum zpci_state to match the configuration state
values.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Cleanup in zpci_fmb_enable_device when fmb registration fails. Also
don't free the fmb when deregistration fails in zpci_fmb_disable_device
but handle error situations when a function was hot-unplugged.
Also remove the mod_pci helper since it is no longer used.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
DMA tables are freed in zpci_dma_exit_device regardless of the return
code of zpci_unregister_ioat. This could lead to a use after free. On
the other hand during function hot-unplug, zpci_unregister_ioat will
always fail since the function is already gone.
So let zpci_unregister_ioat report success when the function is gone
but don't cleanup the dma table when a function could still have it
in access.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
When we ask a function to stop creating interrupts this may fail
due to the function being already gone (e.g. after hot-unplug).
Consequently we don't free associated resources like summary bits
and bit vectors used for irq processing. This could lead to
situations where we ran out of these resources and fail to setup
new interrupts.
The fix is to just ignore the errors in cases where we can be
sure no new interrupts are generated.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
After failures in arch_setup_msi_irqs common code calls
arch_teardown_msi_irqs. Thus, remove cleanup code from
arch_setup_msi_irqs.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Gerald Schaefer <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Adds some explaination on how the vmemmap based struct page layout's
physical mapping is allocated and tracked through linked list. It
also keeps note of a possible race condition.
Signed-off-by: Anshuman Khandual <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Add some explaination to the layout of vmemmap virtual address
space and how physical page mapping is only used for valid PFNs
present at any point on the system.
Reviewed-by: Aneesh Kumar K.V <[email protected]>
Signed-off-by: Anshuman Khandual <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|